Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouLuan Miguel Alterado mais de 10 anos atrás
1
Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos
Eduardo Magno Lages Figueiredo Orientador: Carlos J P Lucena Co-Orientador: Alessandro F Garcia 24 de Março de 2005
2
Tópicos da Apresentação
Definição do Problema Trabalhos Relacionados Solução Visão Geral O Método de Avaliação Novas Métricas Orientadas a Aspectos Regras Heurísticas A Ferramenta AJATO Estudos Experimentais Contribuições e Trabalhos Futuros Laboratório de Engenharia de Software – PUC-Rio
3
Problema: Interesses Transversais
Todo sistema de software lida com diferentes interesses Alguns interesses, chamados transversais, não são bem modularizados em paradigmas tradicionais Exemplos comuns de interesses transversais são: Persistência Segurança Auditoria Tratamento de exceções Laboratório de Engenharia de Software – PUC-Rio
4
Problema: Interesses Transversais
Separação de interesses Tradicional Orientada a Aspectos Laboratório de Engenharia de Software – PUC-Rio
5
Problema: Interesses Transversais
Interesse transversal (a) separado em aspecto (b) Laboratório de Engenharia de Software – PUC-Rio
6
Problema: Avaliação de Software
A avaliação de qualidade é usualmente baseada em métricas A interpretação dos números não é trivial Conclusões equivocadas ocorrem com freqüência Análise sem suporte automatizado é custosa No Desenvolvimento de Software Orientado a Aspectos (DSOA) os problemas são maiores Aspectos afetam vários módulos, incluindo outros aspectos, de maneira bastante heterogênea As classes não devem ser cientes da existência de aspectos (obliviousness), o que torna difícil entender como elas são afetadas Laboratório de Engenharia de Software – PUC-Rio
7
Problema: Avaliação de Software
Pelo menos seis problemas podem decorrer de uma interpretação incorreta de medições Alerta falso por interesse espalhado e entrelaçado Alerta falso por alto acoplamento e/ou baixa coesão Resultados não mostram um problema existente Resultados não indicam onde está o problema Conflitos entre valores medidos Métricas não relacionam os problemas existentes Laboratório de Engenharia de Software – PUC-Rio
8
Trabalhos Relacionados: Métricas
Várias métricas orientadas a aspectos tem sido propostas nas literatura: Sant’Anna et al. [1], Ceccato e Tonella [2], Zacaria e Hosny [3] e Zhao [4] Entretanto, a avaliação baseada em números não é trivial, consome tempo e pode levar à interpretações erradas [1] Sant’Anna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp [2] Ceccato, M. e Tonella, P. Measuring the Effects of Software Aspectization. In: 1st Workshop on Aspect Reverse Engineering. Proceedings… The Netherlands, (CD-ROM). [3] ZACARIA, A.; HOSNY, H. Metrics for Aspect-Oriented Software Design. In: 3rd International Workshop on Aspect-Oriented Modeling. Proceedings… USA, 2003. [4] ZHAO, J. Towards a Metrics Suite for Aspect-Oriented Software. Technical-Report SE , Information Processing Society of Japan (IPSJ), 2002, 8p. Laboratório de Engenharia de Software – PUC-Rio
9
Trabalhos Relacionados: Avaliação
Sant’Anna et al. [1] propõem um framework de avaliação Mede reusabilidade e manutenibilidade de software Composto de um modelo de qualidade e métricas O modelo de qualidade não apresenta passos para guiar o engenheiro de qualidade O framework não inclui atividades ou regras de avaliação que possam ser automatizadas [1] Sant’Anna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp Laboratório de Engenharia de Software – PUC-Rio
10
Trabalhos Relacionados: Ferramentas
Ferramentas de suporte ao DSOA têm sido desenvolvidas e encontram-se disponíveis [1-4] Elas são principalmente destinadas a visualização [3] ou extração [2, 4] de interesses transversais Quando aplicadas a avaliação, estas ferramentas suportam apenas a atividade de medição [1] [1] Ceccato, M. e Tonella, P. Measuring the Effects of Software Aspectization. In: 1st Workshop on Aspect Reverse Engineering. Proceedings… The Netherlands, (CD-ROM). [2] Concern Manipulation Environment. Disponível em: < Acesso em: 13 mar [3] ROBILLARD, M.; MURPHY, G. Concern Graphs: Finding and Describing Concerns Using Structural Program Dependencies. In: International Conference on Software Engineering (ICSE'02). Proceedings… USA, 2002. [4] SHEPHERD, D.; POLLOCK, L. Ophir: A Framework for Automatic Mining and Refactoring of Aspects. Technical Report, no , Department of Computer and Information Sciences - University of Delaware. Newark, DE, 2003. Laboratório de Engenharia de Software – PUC-Rio
11
Esboço da Solução Um método, organizado em passos, para avaliação de forma sistemática Novas métricas orientadas a aspectos que oferecem informações de fina granularidade Um conjunto de regras heurísticas orientado a interesses para auxiliar na interpretação das medições Uma ferramenta de suporte automatizado ao método, métricas e regras heurísticas Laboratório de Engenharia de Software – PUC-Rio
12
O Método de Avaliação Avalia atributos relevantes da Engenharia de Software, tais como separação de interesses, acoplamento, coesão e tamanho É organizado em passos bem definidos, permitindo automatização Suporta iterações sucessivas para melhoria contínua da qualidade Pode ser usado tanto no nível de projeto detalhado quanto no nível de implementação Laboratório de Engenharia de Software – PUC-Rio
13
O Método de Avaliação Laboratório de Engenharia de Software – PUC-Rio
14
Novas Métricas: NOAconcern
Nome Número de Atributos do Interesse Definição NOAconcern conta o número de atributos de um componente cujo propósito principal é a implementação do interesse avaliado Relevância Mede o grau de espalhamento do interesse pelos atributos de um componente Mede o quanto os atributos do componente são destinados à implementação do interesse Laboratório de Engenharia de Software – PUC-Rio
15
Novas Métricas: NOOconcern
Nome Número de Operações do Interesse Definição NOOconcern conta o número de operações de um componente cujo propósito principal é implementar o interesse avaliado Relevância Mede o grau de espalhamento do interesse pelos métodos, construtores e adendos de um componente Mede o quanto as operações do componente são destinadas ao interesse Laboratório de Engenharia de Software – PUC-Rio
16
Novas Métricas: LOCconcern
Nome Número de Linhas de Código do Interesse Definição LOCconcern conta o número de linhas de código de um componente cujo propósito principal é implementar o interesse avaliado Relevância Mede o grau de espalhamento do interesse pelas linhas de código de um componente Mede o quanto as linhas de código do componente são destinadas ao interesse Laboratório de Engenharia de Software – PUC-Rio
17
Novas Métricas: Exemplos
Legenda: Papel Colleague do padrão Mediator public class Button extends JButton implements GUIColleague { private GUIMediator mediator; public Button(String name) { ... } public void clicked() { mediator.changed(this); public void setMediator(GUIMediator m) { this.mediator = m; Button GUIColleague NOAconcern 1 NOOconcern LOCconcern 6 3 Laboratório de Engenharia de Software – PUC-Rio
18
Métricas do Método de Avaliação
Separação de Interesses Difusão de Interesse em Componente (CDC) [1] Difusão de Interesse em Linhas de Código (CDLOC) [1] Número de Atributos do Interesse (NOAconcern) Número de Operações do Interesse (NOOconcern) Número de Linhas de Código do Interesse (LOCconcern) Coesão Perda de Coesão em Operações (LCOO) [1, 2] [1] Sant’Anna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp [2] CHIDAMBER, S.; KEMERER, C. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, v. 20 n. 6, p , 1994. Laboratório de Engenharia de Software – PUC-Rio
19
Métricas do Método de Avaliação
Acoplamento Acoplamento entre Componentes (CBC) [1, 2] Profundidade da Árvore de Herança (DIT) [1, 2] Número de Filhos (NOC) [2] Tamanho Tamanho do Vocabulário (VS) [1] Número de Atributos (NOA) [1] Número de Operações (NOO) Número de Linhas de Código (LOC) [1] [1] Sant’Anna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp [2] CHIDAMBER, S.; KEMERER, C. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, v. 20 n. 6, p , 1994. Laboratório de Engenharia de Software – PUC-Rio
20
Problemas em Medições Problema 1: Alerta falso por interesse espalhado e entrelaçado Factory Method CDC = 6 CDLOC = 8 Componentes NOAconcern NOOconcern Component ConcreteBind MetaObject 1 MetaObjectComposite 2 MetaObjectEncapsu 4 MetaObjectFactoryComposite MetaObjectFactoryEncapsule MetaObjFactory MetaObserver MetaSubject Laboratório de Engenharia de Software – PUC-Rio
21
Problema 1: Alerta Falso de Interesse
Laboratório de Engenharia de Software – PUC-Rio
22
As Regras Heurísticas São baseadas em resultados de medições
Permitem uma avaliação orientada a interesses Detectam problemas não triviais (como os seis anteriores) Geram alertas que devem ser verificados pelo desenvolvedor Se dividem em: Regras de Separação de Interesses (SI) Regras de Acoplamento e Coesão Laboratório de Engenharia de Software – PUC-Rio
23
Regras de Separação de Interesses
Utilizam métricas de separação de interesses e tamanho Classificam os interesses do sistema em: Modularizado: quando todos os componentes responsáveis pela sua implementação são totalmente dedicados ao interesse Interesse Primário: quando todos os componentes responsáveis pela sua implementação são principalmente dedicados ao interesse Interesse Secundário: quando pelo menos um componente responsável pela sua implementação não é principalmente dedicado ao interesse Laboratório de Engenharia de Software – PUC-Rio
24
Regras de Separação de Interesses
Interesse Entrelaçado: quando se encontra misturado a outros interesses dentro de pelo menos um componente Interesse de Elevado Espalhamento: quando vários componentes implementam o interesse Interesse de Baixo Espalhamento: quando apenas alguns componentes são dedicados ao interesse As mudanças entre as classificações dos interesses são definidas pelas regras de separação de interesses Laboratório de Engenharia de Software – PUC-Rio
25
Laboratório de Engenharia de Software – PUC-Rio
26
Regras de Separação de Interesses
Se CDLOC é 2 então INTERESSE MODULARIZADO R02 Se CDLOC é maior que 2 então INTERESSE ENTRELAÇADO R03 Se CDC / VS de INTERESSE ENTRELAÇADO é alto então INTERESSE DE ELEVADO ESPALHAMENTO R04 Se CDC / VS de INTERESSE ENTRELAÇADO não é alto então INTERESSE DE BAIXO ESPALHAMENTO Laboratório de Engenharia de Software – PUC-Rio
27
Regras de Separação de Interesses
Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE ELEVADO ESPALHAMENTO então INTERESSE POSSIVELMENTE PRIMÁRIO R06 Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE ELEVADO ESPALHAMENTO então INTERESSE POSSIVELMENTE SECUNDÁRIO R07 Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE BAIXO ESPALHAMENTO R08 Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE BAIXO ESPALHAMENTO Laboratório de Engenharia de Software – PUC-Rio
28
Regras de Separação de Interesses
Se (LOCconcern / LOC é alto) para todos os componentes de POSSÍVEL INTERESSE PRIMÁRIO então INTERESSE PRIMÁRIO R10 Se (LOCconcern / LOC é baixo) para pelo menos um componente de POSSÍVEL INTERESSE SECUNDÁRIO então INTERESSE SECUNDÁRIO Laboratório de Engenharia de Software – PUC-Rio
29
Regras de Acoplamento e Coesão
Utilizam métricas de acoplamento, coesão e tamanho Devem ser aplicadas nos componentes que possuem interesses Secundários ou Possivelmente Secundários (regras de SI) Classificam os componentes em: Componente de Elevada/Baixa Coesão Componente de Elevado/Baixo Acoplamento Componente Candidato a Reestruturação Global Componente Candidato a Extração de Interesses Laboratório de Engenharia de Software – PUC-Rio
30
Regras de Acoplamento e Coesão
Componente Candidato a Reestruturação Global Componente apresenta interesses secundários, baixa coesão e alto acoplamento Classificação mais problemática de um componente e este deve ser avaliado cuidadosamente Componente Candidato a Extração de Interesses Interesses secundários não causarem problemas aparentes de acoplamento e coesão Classificação não descarta a existência de problemas, mas o ameniza nestes componentes Laboratório de Engenharia de Software – PUC-Rio
31
Regras de Acoplamento e Coesão
As mudanças nas classificações dos componentes são definidas pelas regras de acoplamento e coesão Laboratório de Engenharia de Software – PUC-Rio
32
Regras de Acoplamento e Coesão
Se LCOO do COMPONENTE COM INTERESSE SECUNDÁRIO é alto em relação à média de LCOO dos componentes do sistema então COMPONENTE POUCO COESO R12 Se LCOO do COMPONENTE COM INTERESSE SECUNDÁRIO é baixo em relação à média de LCOO dos componentes do sistema então COMPONENTE MUITO COESO R13 Se CBC do COMPONENTE COM INTERESSE SECUNDÁRIO é alto em relação à média de CBC dos componentes do sistema então COMPONENTE MUITO ACOPLADO R14 Se CBC do COMPONENTE COM INTERESSE SECUNDÁRIO é baixo em relação à média de CBC dos componentes do sistema então COMPONENTE POUCO ACOPLADO R15 Se (COMPONENTE POUCO COESO) e (COMPONENTE MUITO ACOPLADO) então COMPONENTE CANDIDATO A REESTRUTURAÇÃO R16 Se (COMPONENTE MUITO COESO) e (COMPONENTE POUCO ACOPLADO) então COMPONENTE CANDIDATO A EXTRAÇÃO DE INTERESSE Laboratório de Engenharia de Software – PUC-Rio
33
A Ferramenta AJATO Acrônimo para AspectJ Assessment Tool
Suporta as atividades de medição e aplicação das regras heurísticas Recebe como artefato de entrada o código fonte do sistema a ser avaliado Laboratório de Engenharia de Software – PUC-Rio
34
AJATO: Organização Arquitetural
Laboratório de Engenharia de Software – PUC-Rio
35
AJATO: Modelo de Programas AspectJ
Estrutura de dados representativa do sistema avaliado Laboratório de Engenharia de Software – PUC-Rio
36
AJATO: Modelo de Programas AspectJ
Laboratório de Engenharia de Software – PUC-Rio
37
AJATO: Extrator de Modelo AspectJ
Utiliza uma linguagem de meta-programação, MetaJ [1], para extrair informações do código Implementado seguindo o padrão Interpreter É composto de dois sub-módulos: Parser de Código: extrai as estruturas sintáticas do código (classes, operações, atributos, etc.) Analisador de Referências: captura os relacionamentos entre elementos sintáticos (importações, herança, associações, etc.) [1] OLIVEIRA, A.; BRAGA, T.; MAIA, M.; BIGONHA, R. MetaJ: An Extensible Environment for Metaprogramming in Java. Journal of Universal Computer Science, v. 10, n. 7, p , 2004. Laboratório de Engenharia de Software – PUC-Rio
38
AJATO: Extrator de Modelo AspectJ
Laboratório de Engenharia de Software – PUC-Rio
39
AJATO: Gerenciador de Interesses
Efetua o mapeamento entre estruturas sintáticas e interesses Um aspecto é utilizado para implementar a persistência deste módulo Laboratório de Engenharia de Software – PUC-Rio
40
AJATO: Coletor de Métricas
Efetua medições a partir do Modelo AspectJ Implementa o padrão Visitor para obter o resultado das medições Armazena este resultado em uma estrutura que implementa o padrão Composite Laboratório de Engenharia de Software – PUC-Rio
41
AJATO: Coletor de Métricas
Laboratório de Engenharia de Software – PUC-Rio
42
AJATO: Analisador de Regras
Aplica as regras heurísticas sobre o resultado das medições Gera alertas de possíveis problemas relacionados a separação de interesses Estes alertas devem ser verificados pelo desenvolvedor Permite configuração/customização das regras em relação aos valores limites Laboratório de Engenharia de Software – PUC-Rio
43
AJATO: Analisador de Regras
Laboratório de Engenharia de Software – PUC-Rio
44
Estudos Experimentais
Foram feitos cinco estudos de caso para avaliação e amadurecimento dos elementos da abordagem Padrões de Projetos: compara implementações OO e OA dos 23 padrões descritos no livro GoF Middleware OpenOrb: avalia, no contexto de uma aplicação realística, as interações entre os padrões Portalware: avalia como as técnicas de DSOA podem ser usadas para separar interesses de agentes Health Watcher: avalia a separação em aspectos de interesses transversais bem conhecidos, como concorrência, distribuição e persistência Telestrada: verificar quão bem sucedida é a separação de tratamento de exceções em aspectos Laboratório de Engenharia de Software – PUC-Rio
45
Estudos Experimentais
Elementos da abordagem avaliados em cada estudo de caso Estudos Elementos Principais da Abordagem Método Regras Ferramenta Padrões GoF Individuais X Composição de Padrões Portalware Health Watcher Telestrada Laboratório de Engenharia de Software – PUC-Rio
46
Estudos Experimentais: Contribuições
A organização (atividades) do método emergiu dos estudos de caso Permitiram definir a prioridade na avaliação de interesses sobre outros atributos Permitiram inferir novas regras e descartar àquelas menos eficazes Ajudaram na identificação de bugs na ferramenta Avaliaram o sucesso da abordagem na identificação de problemas não triviais Laboratório de Engenharia de Software – PUC-Rio
47
Estudos Experimentais: Contribuições
Estudos de Caso Interesses Avaliados Problemas Identificados A B C D E F 1º Builder Papel Director X Factory Method Papel Creator Observer Papel Observer Papel Subject 2º Factory Method com Observer Padrão Factory Method Padrão Observer Façade com Singleton Padrão Façade Padrão Singleton Prototype com State Padrão Prototype Padrão State Interpreter com Proxy Padrão Interpreter Padrão Proxy 3º Health Watcher Concorrência Distribuição Persistência 4º Portalware Adaptação Autonomia Colaboração Laboratório de Engenharia de Software – PUC-Rio
48
Contribuições do Trabalho
Um método de avaliação de sistemas Três novas métricas orientadas a aspectos Um conjunto de regras heurísticas para avaliação orientada a interesses Uma ferramenta implementada e documentada de suporte à abordagem Cinco estudos experimentais envolvendo implementações OO e OA Sete publicações nacionais e internacionais Intercâmbio com pessoas em diversas instituições de pesquisa Laboratório de Engenharia de Software – PUC-Rio
49
Contribuições do Trabalho
Publicações FIGUEIREDO, E. GARCIA, A.; SANT'ANNA, C.; KULESZA, U.; LUCENA, C. Assessing Aspect-Oriented artifacts: Towards a Tool-Supported Quantitative Method. In: 9th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'05). Proceedings... UK, 2005. FIGUEIREDO, E.; STAA, A. Avaliação de um Modelo de Qualidade para Implementações Orientadas a Objetos e Orientadas a Aspectos. Monografia em Ciência da Computação nº 14/05, Departamento de Informática, PUC-Rio. Rio de Janeiro, 2005, 29 p. GARCIA, A.; SANT'ANNA, C.; FIGUEIREDO, E..; KULESZA, U.; LUCENA, C.; STAA, A. Modularizing Design Patterns with Aspects: A Quantitative Study. LNCS Transactions on Aspect-Oriented Software Development (TAOSD'05), v. 31, n. 2, p , 2006. Laboratório de Engenharia de Software – PUC-Rio
50
Contribuições do Trabalho
Publicações (continuação) CACHO, N.; SANT'ANNA, C.; FIGUEIREDO, E.; GARCIA, A.; BATISTA, T.; LUCENA, C. Composing Design Patterns: A Scalability Study of Aspect-Oriented Programming. In: 5th International Conference on Aspect Oriented Software Development (AOSD'06). Proceedings… Bonn, Germany, 2006. GARCIA, A.; SANT'ANNA, C.; FIGUEIREDO, E.; KULESZA, U.; LUCENA, C.; STAA, A. Modularizing Design Patterns with Aspects: A Quantitative Study. In: 4th International Conference on Aspect Oriented Software Development (AOSD'05). Proceedings… USA MuLATo: A Multi-Language Assessment Tool (SourceForge.net). Disponível em: < Acesso em: 17 fev Laboratório de Engenharia de Software – PUC-Rio
51
Contribuições do Trabalho
Publicações (continuação) CACHO, N.; FIGUEIREDO, E.; SANT'ANNA, C.; GARCIA, A.; BATISTA, T.; LUCENA, C. Aspect-Oriented Composition of Design Patterns: A Quantitative Assessment. MCC nº 34/05, Departamento de Informática, PUC-Rio. Rio de Janeiro, 2005, 29p. GARCIA, A. F.; SANT'ANNA, C. N.; FIGUEIREDO, E. M. L.; KULESZA, U.; LUCENA, C. J. P.; STAA, A. Aspectizing Design Patterns: Rewards and Pitfalls. MCC nº 43/04, Departamento de Informática, PUC-Rio. Rio de Janeiro, 2004, 21p. Laboratório de Engenharia de Software – PUC-Rio
52
Contribuições do Trabalho
Interação Internacional Nélio Cacho: University of Lancaster (UK) Estudos de caso Middleware OpenOrb Fernando Castor: Universidade Estadual de Campinas (UNICAMP) Estudos de caso Health Watcher Gary Thewlis: University of Lancaster (UK) Desenvolvimento da Ferramenta Thiago Bartolomei: Universidade de Ciências Aplicadas de Kiel (Alemanha) Extensões da Ferramenta Hans-Arno Jacobsen: Universidade de Toronto (Canadá) Estudos de caso utilizando o método Laboratório de Engenharia de Software – PUC-Rio
53
Contribuições do Trabalho
Interação Internacional: outras pessoas interessadas ou que utilizam a ferramenta Cássio Higino de Freitas: Universidade Federal da Bahia (UFBA) Daniel Oskarsson: University of Skövde (Suécia) Lukasz Szala: Wroclaw University of Technology (Polônia) Laboratório de Engenharia de Software – PUC-Rio
54
Trabalhos Futuros Método de Avaliação, Métricas e Regras Heurísticas
Definir um conjunto de refatorações orientadas a aspectos Definir novas métricas e regras heurísticas Associar as regras com possíveis sugestões de refatorações Ferramenta AJATO Extensões para outras linguagens de programação Extensões para avaliar artefatos no nível de projeto detalhado Desenvolvimento de um novo módulo para permitir refatorações Laboratório de Engenharia de Software – PUC-Rio
55
Trabalhos Futuros Estudos Experimentais
Estudo mais aprofundado em relação ao Telestrada Estudos em sistemas implementados em outras linguagens (além de Java e AspectJ) Laboratório de Engenharia de Software – PUC-Rio
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.