Projeto Arquitetural de Software Orientado a Aspectos

Apresentação em tema: "Projeto Arquitetural de Software Orientado a Aspectos"— Transcrição da apresentação:

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

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

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]