A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Projeto Arquitetural de Software Orientado a Aspectos Alessandra Guaracy de Oliveira Patrick Henrique da Silva Brito."— 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çãoMotivaçãoFerramentas 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, Kandé, Kienzle, Strohmeier. From AOP to UML: Towards na Aspect-Oriented Architetural Modeling Approach. Agosto, Mens, Kim. Architectural Aspects. Fevereiro, Kishi, Tomoji. Studies on Software Architectural Design. Junho, 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. Aumento da complexidade dos componentes 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 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) ? 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 legibilidade; Maior modularidade Maior modularidade Maior manutenibilidade; Maior manutenibilidade; Maior flexibilidade; Maior flexibilidade; Divide o sistema em dois níveis Componentes funcionais – Requisitos funcionais Componentes funcionais – Requisitos funcionais Aspectos – Requisitos não-funcionais ou entrelaçados 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 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 AfterAround

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 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; Tratamento dos requisitos de cada aspecto 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 desmembrados em fatores; 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 Pontos de conexãoTipos: Entrada (passivo) Mapeado para uma chamada pointcut em AspectJ Entrada (passivo) Mapeado para uma chamada pointcut em AspectJ Saída (ativo) Mapeado para interface ou classe abstrata Saída (ativo) Mapeado para interface ou classe abstrataCaracterísticas: Semelhantes a Interface Semelhantes a Interface Podem ser instanciados Podem 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 (porta) – Expansibilidade Necessidade de elementos de interface entre componentes (porta) – Expansibilidade Representação dos advices Representação dos advices before, around, after 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] 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. 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 em UML. Falta de padronização da arquitetura. Falta de padronização da arquitetura. Inexistência de ferramentas específicas para suporte ao projeto arquitetural. 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]


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

Apresentações semelhantes


Anúncios Google