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

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

Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages Figueiredo Orientador: Carlos J P Lucena Co-Orientador:

Apresentações semelhantes


Apresentação em tema: "Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages Figueiredo Orientador: Carlos J P Lucena Co-Orientador:"— Transcrição da apresentação:

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 Laboratório de Engenharia de Software – PUC-Rio 2 Tópicos da Apresentação 1.Definição do Problema 2.Trabalhos Relacionados 3.Solução Visão Geral O Método de Avaliação Novas Métricas Orientadas a Aspectos Regras Heurísticas A Ferramenta AJATO 4.Estudos Experimentais 5.Contribuições e Trabalhos Futuros

3 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

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

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

6 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

7 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 1.Alerta falso por interesse espalhado e entrelaçado 2.Alerta falso por alto acoplamento e/ou baixa coesão 3.Resultados não mostram um problema existente 4.Resultados não indicam onde está o problema 5.Conflitos entre valores medidos 6.Métricas não relacionam os problemas existentes

8 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: –SantAnna 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] SantAnna, 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, [4] ZHAO, J. Towards a Metrics Suite for Aspect-Oriented Software. Technical-Report SE , Information Processing Society of Japan (IPSJ), 2002, 8p.

9 Laboratório de Engenharia de Software – PUC-Rio 9 Trabalhos Relacionados: Avaliação SantAnna 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] SantAnna, 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

10 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, [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.

11 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

12 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

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

14 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

15 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

16 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

17 Laboratório de Engenharia de Software – PUC-Rio 17 Novas Métricas: Exemplos 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; } ButtonGUIColleague NOAconcern10 NOOconcern11 LOCconcern63 Legenda: Papel Colleague do padrão Mediator

18 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] SantAnna, 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.

19 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] SantAnna, 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.

20 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 = 6CDLOC = 8 Componentes NOA concern NOO concern Component0 0 ConcreteBind0 0 MetaObject1 1 MetaObjectComposite1 2 MetaObjectEncapsu2 4 MetaObjectFactoryComposite0 1 MetaObjectFactoryEncapsule0 1 MetaObjFactory0 1 MetaObserver0 0 MetaSubject0 0

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

22 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

23 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

24 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

25 Laboratório de Engenharia de Software – PUC-Rio 25

26 Laboratório de Engenharia de Software – PUC-Rio 26 Regras de Separação de Interesses R01Se CDLOC é 2 então INTERESSE MODULARIZADO R02Se CDLOC é maior que 2 então INTERESSE ENTRELAÇADO R03Se CDC / VS de INTERESSE ENTRELAÇADO é alto então INTERESSE DE ELEVADO ESPALHAMENTO R04Se CDC / VS de INTERESSE ENTRELAÇADO não é alto então INTERESSE DE BAIXO ESPALHAMENTO

27 Laboratório de Engenharia de Software – PUC-Rio 27 Regras de Separação de Interesses R05Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE ELEVADO ESPALHAMENTO então INTERESSE POSSIVELMENTE PRIMÁRIO R06Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE ELEVADO ESPALHAMENTO então INTERESSE POSSIVELMENTE SECUNDÁRIO R07Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE BAIXO ESPALHAMENTO então INTERESSE POSSIVELMENTE PRIMÁRIO R08Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE BAIXO ESPALHAMENTO então INTERESSE POSSIVELMENTE SECUNDÁRIO

28 Laboratório de Engenharia de Software – PUC-Rio 28 Regras de Separação de Interesses R09Se (LOCconcern / LOC é alto) para todos os componentes de POSSÍVEL INTERESSE PRIMÁRIO então INTERESSE PRIMÁRIO R10Se (LOCconcern / LOC é baixo) para pelo menos um componente de POSSÍVEL INTERESSE SECUNDÁRIO então INTERESSE SECUNDÁRIO

29 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

30 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

31 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

32 Laboratório de Engenharia de Software – PUC-Rio 32 Regras de Acoplamento e Coesão R11Se LCOO do COMPONENTE COM INTERESSE SECUNDÁRIO é alto em relação à média de LCOO dos componentes do sistema então COMPONENTE POUCO COESO R12Se LCOO do COMPONENTE COM INTERESSE SECUNDÁRIO é baixo em relação à média de LCOO dos componentes do sistema então COMPONENTE MUITO COESO R13Se CBC do COMPONENTE COM INTERESSE SECUNDÁRIO é alto em relação à média de CBC dos componentes do sistema então COMPONENTE MUITO ACOPLADO R14Se CBC do COMPONENTE COM INTERESSE SECUNDÁRIO é baixo em relação à média de CBC dos componentes do sistema então COMPONENTE POUCO ACOPLADO R15Se (COMPONENTE POUCO COESO) e (COMPONENTE MUITO ACOPLADO) então COMPONENTE CANDIDATO A REESTRUTURAÇÃO R16Se (COMPONENTE MUITO COESO) e (COMPONENTE POUCO ACOPLADO) então COMPONENTE CANDIDATO A EXTRAÇÃO DE INTERESSE

33 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

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

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

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

37 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.

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

39 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

40 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

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

42 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

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

44 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

45 Laboratório de Engenharia de Software – PUC-Rio 45 Estudos Experimentais Estudos Elementos Principais da Abordagem MétodoRegrasFerramenta Padrões GoF IndividuaisXX Composição de PadrõesXXX PortalwareXXX Health WatcherXXX TelestradaX Elementos da abordagem avaliados em cada estudo de caso

46 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

47 Laboratório de Engenharia de Software – PUC-Rio 47 Estudos Experimentais: Contribuições Estudos de CasoInteresses Avaliados Problemas Identificados ABCDEF 1º BuilderPapel DirectorX Factory MethodPapel CreatorXX Observer Papel ObserverX Papel Subject 2º Factory Method com Observer Padrão Factory MethodXXX Padrão Observer Façade com Singleton Padrão FaçadeX Padrão Singleton Prototype com State Padrão Prototype Padrão StateXX Interpreter com Proxy Padrão InterpreterX Padrão Proxy 3º Health Watcher ConcorrênciaXX Distribuição Persistência 4º Portalware Adaptação Autonomia ColaboraçãoXXXX

48 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

49 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, –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.

50 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, –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

51 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.

52 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

53 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)

54 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

55 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)


Carregar ppt "Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages Figueiredo Orientador: Carlos J P Lucena Co-Orientador:"

Apresentações semelhantes


Anúncios Google