projeto arquitetural de software orientado a aspectos
Post on 14-Jan-2016
54 Views
Preview:
DESCRIPTION
TRANSCRIPT
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]
top related