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