Desenvolvimento de software orientado a aspectos

Independentemente do processo de software escolhido, os desenvolvedores de software

complexos, invariavelmente, implementam um conjunto de recursos, funções e conteúdo localizados.

Essas características de software localizadas são modeladas como componentes (por

exemplo, classes orientadas a objetos) e, em seguida, construídas dentro do contexto da arquitetura

do sistema. À medida que os modernos sistemas baseados em computadores se tornam

mais sofisticados (e complexos), certas restrições - propriedades exigidas pelo cliente ou áreas

de interesse técnico - se estendem por toda a arquitetura. Algumas restrições são propriedades

de alto nível de um sistema (por exemplo, segurança, tolerância a falhas). Outras afetam funções

(por exemplo, a aplicação de regras de negócio), sendo que outras são sistêmicas (por exemplo,

sincronização de tarefas ou gerenciamento de memória).

Quando restrições cruzam múltiplas funções, recursos e informações do sistema, elas são,

frequentemente, denominadas restrições cruzadas. Os requisitos de aspectos definem as restrições

cruzadas que têm um impacto por toda a arquitetura de software. O desenvolvimento de

software orientado a aspectos AOSD, Aspect-Oriented Software Development), com frequência

conhecido como programação orientada a aspectos (AOP, Aspect-Oriented Programming), é um

paradigma de engenharia de software relativamente novo que oferece uma abordagem metodológica

e de processos para definir, especificar, projetar e construir aspectos - "mecanismos

além das sub-rotinas e herança para localizar a expressão de uma restrição cruzada" [Elr01]

Um processo distinto orientado a aspectos ainda não atingiu sua maturação. Entretanto,

é provável que um processo desses irá adotar características tanto dos modelos de processo

evolucionário quanto de concorrente. O modelo evolucionário é apropriado quando os aspectos

são identificados e então construídos. A natureza paralela do desenvolvimento concorrente é

essencial, porque os aspectos são criados independentemente de componentes de software localizado

e, apesar disso, os aspectos têm um impacto direto sobre esses componentes. Portanto,

é essencial instanciar comunicação assíncrona entre as atividades de processos de software

aplicadas na engenharia e construção de aspectos e componentes.