Projeto Arquitetural de Software Orientado a Aspectos

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

2. 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

3. 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.

4. 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]

5. 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)?

6. 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”

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

8. Ferramentas • AspectJ: Before After returning After throwing After Around

9. 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

10. 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;

11. 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)

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

13. Extensão de UML • Aspectos • Pontos de conexão • 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

14. 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.

15. Estudo de caso (elevador)

16. 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.

17. 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]