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

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

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

Problema: Interesses Transversais Separação de interesses Tradicional Orientada a Aspectos Laboratório de Engenharia de Software – PUC-Rio

Problema: Interesses Transversais Interesse transversal (a) separado em aspecto (b) Laboratório de Engenharia de Software – PUC-Rio

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

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

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. 19-34.  [2] Ceccato, M. e Tonella, P. Measuring the Effects of Software Aspectization. In: 1st Workshop on Aspect Reverse Engineering. Proceedings… The Netherlands, 2004. (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-136-25, Information Processing Society of Japan (IPSJ), 2002, 8p. Laboratório de Engenharia de Software – PUC-Rio

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. 19-34. Laboratório de Engenharia de Software – PUC-Rio

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, 2004. (CD-ROM).  [2] Concern Manipulation Environment. Disponível em: <http://www.research.ibm.com/cme/> Acesso em: 13 mar. 2006.  [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.2004-03, Department of Computer and Information Sciences - University of Delaware. Newark, DE, 2003. Laboratório de Engenharia de Software – PUC-Rio

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

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

O Método de Avaliação Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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. 19-34.  [2] CHIDAMBER, S.; KEMERER, C. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, v. 20 n. 6, p. 476-493, 1994. Laboratório de Engenharia de Software – PUC-Rio

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. 19-34.  [2] CHIDAMBER, S.; KEMERER, C. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, v. 20 n. 6, p. 476-493, 1994. Laboratório de Engenharia de Software – PUC-Rio

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

Problema 1: Alerta Falso de Interesse Laboratório de Engenharia de Software – PUC-Rio

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

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

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

Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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

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

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

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

AJATO: Organização Arquitetural Laboratório de Engenharia de Software – PUC-Rio

AJATO: Modelo de Programas AspectJ Estrutura de dados representativa do sistema avaliado Laboratório de Engenharia de Software – PUC-Rio

AJATO: Modelo de Programas AspectJ Laboratório de Engenharia de Software – PUC-Rio

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. 872-891, 2004. Laboratório de Engenharia de Software – PUC-Rio

AJATO: Extrator de Modelo AspectJ Laboratório de Engenharia de Software – PUC-Rio

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

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

AJATO: Coletor de Métricas Laboratório de Engenharia de Software – PUC-Rio

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

AJATO: Analisador de Regras Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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

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. 36-74, 2006. Laboratório de Engenharia de Software – PUC-Rio

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. 2005. MuLATo: A Multi-Language Assessment Tool (SourceForge.net). Disponível em: <http://sourceforge.net/projects/mulato>. Acesso em: 17 fev. 2006. Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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