Analise Estruturada

Identificar por meio da leitura do Passo 1 Tópico 2 a Técnica mais adequada para elaborar uma analise de requisitos. Elaborar um resumo que descreva um comparativo com as vantagens e desvantagens de cada uma das técnicas que o texto apresenta.

Neste capítulo é descrito o conceito de Desenvolvimento Orientado a Aspectos, bem como a motivação para a sua relevância no campo da Engenharia de Requisitos. O conceito de desenvolvimento de software orientado a aspectos surgiu da necessidade de melhorar a modularidade dos programas, promovendo uma melhor separação de interesses. O nome interesses vem do inglês concerns , e é um termo geral que diz respeito a requisitos, funcionais ou não, que são relevantes e precisam estar presentes nos sistemas [7]. Uma definição mais específica, fornecida pelo padrão para arquiteturas IEEE é dada a seguir: “ Co ncerns são interesses que pertencem ao desenvolvimento do sistema, seu funcionamento ou quaisquer outras características que são críticas ou de outra forma importantes para uma ou mais partes interessadas” [8]. O conceito de separação de interesses envolve quebrar o esforço de desenvolvimento de um programa em partes, o que muitas vezes se reflete na quebra do programa em módulos que se sobrepõem em funcionalidade o mínimo possível [9]. Este é um princípio fundamental em engenharia de software, pois reduz a complexidade do processo de desenvolvimento além de tornar mais fácil o entendimento do software desenvolvido. O impacto das mudanças também é minimizado, ao separarmos cada interesse em módulos separados. Os paradigmas de programação oferecem mecanismos que dão suporte à separação e encapsulamento de interesses. Como exemplo, citamos procedimentos, pacotes, classes, métodos. No entanto, alguns interesses não se encaixam nas formas de encapsulamento providas por paradigmas tradicionais, como o funcional ou orientação a objetos. Estes são os chamados interesses transversais ( crosscutting concerns ) ou ortogonais. Tais interesses são difíceis de modularizar, e por esta razão a sua implementação acaba atravessando várias partes do programa, espalhada por entre os módulos que o compõem. São chamados de transversais em relação a outros interesses. Como exemplo destes interesses, podemos citar requisitos não-funcionais como logging , persistência, debuggin g e gerenciamento de exceções, além de alguns requisitos funcionais. Em alguns casos, uma porção considerável de código de uma operação ou classe não está relacionada com o interesse da classe ou operação e sim com estes interesses transversais. O código então se torna (i) disperso, pois interesses estão espalhados por meio de diversas partes do programa; (ii) entrelaçado, pois uma parte do programa pode envolver diversos interesses, e o entendimento e modificação do código torna-se difícil, pois se deve entender e levar em conta todos estes interesses. O conceito de orientação a aspectos [10] (AOSD – Aspect Oriented S o f t w a r e D e v elo p m e n t ), assim como a primeira linguagem orientada a aspectos, AspectJ [11], surgiu para complementar o paradigma de orientação a objetos. AOSD provê técnicas, métodos e ferramentas para auxiliar o desenvolvedor na tarefa de identificação, separação, representação e composição de interesses transversais, modularizando-os de forma a que eles se sobreponham em funcionalidade o mínimo possível

...