Projeto Arquitetural de Software Projeto Arquitetural de Software Orientado a AspectosOrientado a Aspectos

Alessandra Guaracy de OliveiraAlessandra Guaracy de Oliveira

Patrick Henrique da Silva BritoPatrick Henrique da Silva Brito

SumárioSumário

IntroduçãoIntrodução

MotivaçãoMotivação

FerramentasFerramentas

Arquitetura de Software Orientada a AspectosArquitetura de Software Orientada a Aspectos

Conceito de Orientação a Aspectos no projeto Conceito de Orientação a Aspectos no projeto de Arquiteturade Arquitetura

Extensão de UMLExtensão de UML

Estudo de caso (elevador)Estudo de caso (elevador)

Considerações FinaisConsiderações Finais

Referências BibliográficasReferências Bibliográficas

Kandé, Kienzle, Strohmeier. Kandé, Kienzle, Strohmeier. From AOP to UML: From AOP to UML: Towards na Aspect-Oriented Architetural Modeling Towards na Aspect-Oriented Architetural Modeling ApproachApproach. Agosto, 2002.. Agosto, 2002.

Mens, Kim. Mens, Kim. Architectural Aspects. Architectural Aspects. Fevereiro, 2002.Fevereiro, 2002.

Kishi, Tomoji. Kishi, Tomoji. Studies on Software Architectural DesignStudies on Software Architectural Design. . Junho, 2002.Junho, 2002.

Kishi, Tomoji; Noda, Natsuko. Kishi, Tomoji; Noda, Natsuko. Aspect-Oriented Analysis Aspect-Oriented Analysis for Architectural Designfor Architectural Design. 2002.. 2002.

Piveta, Eduardo. Piveta, Eduardo. Aspect-Oriented Principles Applied to Aspect-Oriented Principles Applied to Architectural StylesArchitectural Styles. Junho 2003.. Junho 2003.

IntroduçãoIntrodução

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

MotivaçãoMotivação

Conseqüências do entrelaçamento de código:Conseqüências do entrelaçamento de código: Aumento da complexidade dos componentes Aumento da complexidade dos componentes

funcionais do sistema.funcionais do sistema. Pouca modularidade (entrelaçamento de código)Pouca modularidade (entrelaçamento de código)

É uma abordagem que permite a separação dos É uma abordagem que permite a separação dos requisitos funcionais e não funcionais do requisitos funcionais e não funcionais do sistema de uma forma natural e concisasistema de uma forma natural e concisa.. Porque não também usar esse conceito na etapa de Porque não também usar esse conceito na etapa de

projeto do software (inclusive arquitetural)projeto do software (inclusive arquitetural)??

Orientação a AspectosOrientação a Aspectos

Pelo não entrelaçamento de código, proporciona:Pelo não entrelaçamento de código, proporciona: Maior legibilidade;Maior legibilidade; Maior modularidadeMaior modularidade Maior manutenibilidade;Maior manutenibilidade; Maior flexibilidade;Maior flexibilidade;

Divide o sistema em dois níveisDivide o sistema em dois níveis Componentes funcionais – Requisitos funcionaisComponentes funcionais – Requisitos funcionais Aspectos – Requisitos não-funcionais ou “entrelaçados”Aspectos – Requisitos não-funcionais ou “entrelaçados”

Orientação a AspectosOrientação a Aspectos

Join Point – Pontos onde aspectos podem interceptar componentes Join Point – Pontos onde aspectos podem interceptar componentes funcionaisfuncionais

Before, around , afterBefore, around , after

O requisito não-funcional fica espalhado porque é tratado na dimensão errada!

TracingO requisito não-funcional é ortogonal à decomposição funcional!

FerramentasFerramentas

AspectJ:AspectJ:

BeforeBefore

After returningAfter returning

After throwingAfter throwing

AfterAfter

AroundAround

Arquitetura de Software Arquitetura de Software Orientada a AspectosOrientada a Aspectos

O conceito de Orientação a Aspectos pode ser O conceito de Orientação a Aspectos pode ser incorporado em estilos arquiteturais já conhecidos incorporado em estilos arquiteturais já conhecidos (ou estilos combinados):(ou estilos combinados): Crosscuting (atalho), evitando o entrelaçamento de Crosscuting (atalho), evitando o entrelaçamento de

códigocódigo

Aspectos são visões das funções ou dos atributos Aspectos são visões das funções ou dos atributos de qualidadede qualidade

Arquitetura de Software Arquitetura de Software Orientada a AspectosOrientada a Aspectos

É importante tratar os requisitos do É importante tratar os requisitos do software de uma maneira particular:software de uma maneira particular:

Tratamento dos requisitos de cada aspecto Tratamento dos requisitos de cada aspecto separadamente;separadamente;

Categorização desses requisitos;Categorização desses requisitos; Análise geral dos requisitos (todos);Análise geral dos requisitos (todos); Os requisitos não-funcionais são Os requisitos não-funcionais são

desmembrados em desmembrados em fatoresfatores;;

Conceito de Orientação a Aspectos no Conceito de Orientação a Aspectos no projeto de Arquiteturaprojeto de Arquitetura

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

Extensão de UMLExtensão de UML

Implementar o conceito de pontos de conexão Implementar o conceito de pontos de conexão (connection points)(connection points)

Detecção dos pontos de conexão:

Extensão de UMLExtensão de UML

AspectosAspectos Pontos de conexãoPontos de conexão

Tipos:Tipos: Entrada (passivo) Entrada (passivo) Mapeado para uma chamada Mapeado para uma chamada pointcutpointcut em em

AspectJAspectJ Saída (ativo) Saída (ativo) Mapeado para interface ou classe abstrata Mapeado para interface ou classe abstrata

Características:Características: Semelhantes a InterfaceSemelhantes a Interface Podem ser instanciadosPodem ser instanciados Podem ter atributos e implementação de métodos Podem ter atributos e implementação de métodos Necessidade de elementos de interface entre componentes Necessidade de elementos de interface entre componentes

(“porta”) – Expansibilidade(“porta”) – Expansibilidade Representação dos “advices”Representação dos “advices”

before, around, afterbefore, around, after

Extensão de UMLExtensão de UML

ConectoresConectores ““Conectores de software ... Interação intermediária entre Conectores de software ... Interação intermediária entre

componentes; que estabelece regras que governam interações e componentes; que estabelece regras que governam interações e mecanismos auxiliares necessários” [Shaw e Garlan]mecanismos auxiliares necessários” [Shaw e Garlan]

Assim como conectores, aspectos são intermediários entre Assim como conectores, aspectos são intermediários entre componentes que se interceptam e são modularizados nessa componentes que se interceptam e são modularizados nessa abstração.abstração.

Estudo de caso (elevador)Estudo de caso (elevador)

Considerações FinaisConsiderações Finais

Ideal para sistemas que tenham muitos Ideal para sistemas que tenham muitos requisitos não-funcionais ou funções requisitos não-funcionais ou funções “espalhadas” no código.“espalhadas” no código.

Pontos Fracos: Pontos Fracos: Falta de padronização em UML.Falta de padronização em UML. Falta de padronização da arquitetura.Falta de padronização da arquitetura. Inexistência de ferramentas específicas para suporte Inexistência de ferramentas específicas para suporte

ao projeto arquitetural.ao projeto arquitetural.

Considerações FinaisConsiderações Finais““Como a arquitetura de software é a base para o projeto e algumas Como a arquitetura de software é a base para o projeto e algumas decisões dependem da arquitetura, mudanças arquiteturais podem decisões dependem da arquitetura, mudanças arquiteturais podem ser muito caras” [ser muito caras” [Tomoji Kishi & Natsuko Noda, 2002Tomoji Kishi & Natsuko Noda, 2002]]

““O conceito de ‘crosscutting’ (atalho) não afeta a análise tanto quanto O conceito de ‘crosscutting’ (atalho) não afeta a análise tanto quanto o projeto, porque na análise, requisitos não funcionais normalmente o projeto, porque na análise, requisitos não funcionais normalmente não são modelados. No desenvolvimento de software orientado a não são modelados. No desenvolvimento de software orientado a aspectos (AOSD), o projeto pode ser modificado para atualizar aspectos (AOSD), o projeto pode ser modificado para atualizar apenas o local do atalho.” [Piveta, 2003]apenas o local do atalho.” [Piveta, 2003]

““A arquitetura orientada a aspectos mostra a estrutura estática do A arquitetura orientada a aspectos mostra a estrutura estática do aspecto e especifica pontos de conexão bem definidos, que são a aspecto e especifica pontos de conexão bem definidos, que são a base da ligação entre componentes. Como essa abordagem utiliza o base da ligação entre componentes. Como essa abordagem utiliza o conceito de porta, a expansibilidade da conexão se torna possível conceito de porta, a expansibilidade da conexão se torna possível graças a esses ‘pontos de extensão’.” [Kandé & Kienzle & graças a esses ‘pontos de extensão’.” [Kandé & Kienzle & Strohmeier, 2002]Strohmeier, 2002]