Projeto Arquitetural de Software Orientado a Aspectos Alessandra Guaracy de Oliveira Patrick Henrique da Silva Brito

Sumário Introdução Motivação Ferramentas Arquitetura de Software Orientada a Aspectos Conceito de Orientação a Aspectos no projeto de Arquitetura Extensão de UML Estudo de caso (elevador) Considerações Finais

Referências Bibliográficas Kandé, Kienzle, Strohmeier. From AOP to UML: Towards na Aspect-Oriented Architetural Modeling Approach. Agosto, 2002. Mens, Kim. Architectural Aspects. Fevereiro, 2002. Kishi, Tomoji. Studies on Software Architectural Design. Junho, 2002. Kishi, Tomoji; Noda, Natsuko. Aspect-Oriented Analysis for Architectural Design. 2002. Piveta, Eduardo. Aspect-Oriented Principles Applied to Architectural Styles. Junho 2003.

Introdução “Quando analisamos, é importante considerar não somente os requisitos funcionais do sistema, mas também atributos de qualidade, porque a arquitetura de software pode ser alterada se houver mudança dos requisitos não funcionais.” [Tomoji Kishi & Natsuko Noda, 2002]

Motivação Conseqüências do entrelaçamento de código: Aumento da complexidade dos componentes funcionais do sistema. Pouca modularidade (entrelaçamento de código) É uma abordagem que permite a separação dos requisitos funcionais e não funcionais do sistema de uma forma natural e concisa. Porque não também usar esse conceito na etapa de projeto do software (inclusive arquitetural)?

Orientação a Aspectos Pelo não entrelaçamento de código, proporciona: Maior legibilidade; Maior modularidade Maior manutenibilidade; Maior flexibilidade; Divide o sistema em dois níveis Componentes funcionais – Requisitos funcionais Aspectos – Requisitos não-funcionais ou “entrelaçados”

Orientação a Aspectos O requisito não-funcional fica espalhado porque é tratado na dimensão errada! Tracing O requisito não-funcional é ortogonal à decomposição funcional! Join Point – Pontos onde aspectos podem interceptar componentes funcionais Before, around , after

Ferramentas AspectJ: Before After returning After throwing After Around

Arquitetura de Software Orientada a Aspectos O conceito de Orientação a Aspectos pode ser incorporado em estilos arquiteturais já conhecidos (ou estilos combinados): Crosscuting (atalho), evitando o entrelaçamento de código Aspectos são visões das funções ou dos atributos de qualidade

Arquitetura de Software Orientada a Aspectos É importante tratar os requisitos do software de uma maneira particular: Tratamento dos requisitos de cada aspecto separadamente; Categorização desses requisitos; Análise geral dos requisitos (todos); Os requisitos não-funcionais são desmembrados em fatores;

Conceito de Orientação a Aspectos no projeto de Arquitetura “Estes aspectos podem ser modelados/implementados usando filtros de composição, onde cada filtro afeta um ou mais sub-sistemas ou componentes, em um alto nível de granularidade.” [Piveta, 2003] Os filtros podem ser mudados dinamicamente, flexibilizando a adequação do sistema aos requisitos representados por aspectos. (normalmente não-funcionais)

Extensão de UML Implementar o conceito de pontos de conexão (connection points) Detecção dos pontos de conexão:

Extensão de UML Aspectos Pontos de conexão Representação dos “advices” Tipos: Entrada (passivo)  Mapeado para uma chamada pointcut em AspectJ Saída (ativo)  Mapeado para interface ou classe abstrata Características: Semelhantes a Interface Podem ser instanciados Podem ter atributos e implementação de métodos Necessidade de elementos de interface entre componentes (“porta”) – Expansibilidade Representação dos “advices” before, around, after

Extensão de UML Conectores “Conectores de software ... Interação intermediária entre componentes; que estabelece regras que governam interações e mecanismos auxiliares necessários” [Shaw e Garlan] Assim como conectores, aspectos são intermediários entre componentes que se interceptam e são modularizados nessa abstração.

Estudo de caso (elevador)

Considerações Finais Ideal para sistemas que tenham muitos requisitos não-funcionais ou funções “espalhadas” no código. Pontos Fracos: Falta de padronização em UML. Falta de padronização da arquitetura. Inexistência de ferramentas específicas para suporte ao projeto arquitetural.

Considerações Finais “Como a arquitetura de software é a base para o projeto e algumas decisões dependem da arquitetura, mudanças arquiteturais podem ser muito caras” [Tomoji Kishi & Natsuko Noda, 2002] “O conceito de ‘crosscutting’ (atalho) não afeta a análise tanto quanto o projeto, porque na análise, requisitos não funcionais normalmente não são modelados. No desenvolvimento de software orientado a aspectos (AOSD), o projeto pode ser modificado para atualizar apenas o local do atalho.” [Piveta, 2003] “A arquitetura orientada a aspectos mostra a estrutura estática do aspecto e especifica pontos de conexão bem definidos, que são a base da ligação entre componentes. Como essa abordagem utiliza o conceito de porta, a expansibilidade da conexão se torna possível graças a esses ‘pontos de extensão’.” [Kandé & Kienzle & Strohmeier, 2002]