Uma Abordagem Quantitativa para Desenvolvimento de Software
Orientado a Aspectos
Eduardo Magno Lages FigueiredoOrientador: Carlos J P Lucena
Co-Orientador: Alessandro F Garcia
24 de Março de 2005
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
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 interessesTradicional Orientada a Aspectos
Aluno Matricular Alterar
Disciplina Criar Cancelar
Nota Lançar AlterarAluno Matricular Alterar
Disciplina Criar Cancelar
Nota Lançar Alterar
SegurançaPersistência
Aluno Matricular Alterar
Disciplina Criar Cancelar
Nota Lançar Alterar
SegurançaPersistência
(b)Separação em dados, funções e aspectos
(a)Separação em dados e funções
Laboratório de Engenharia de Software – PUC-Rio 5
Problema: Interesses Transversais
• Interesse transversal (a) separado em aspecto (b)
Interesse Transversal
Legenda
Classe
AspectoRelacionamento
Interesse TransversalInteresse Transversal
Legenda
ClasseClasse
AspectoAspectoRelacionamentoRelacionamento
(a)
(b)(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
1. Alerta falso por interesse espalhado e entrelaçado2. Alerta falso por alto acoplamento e/ou baixa coesão3. Resultados não mostram um problema existente4. Resultados não indicam onde está o problema5. Conflitos entre valores medidos6. 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. 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 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. 19-34.
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, 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 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
Avaliação Melhoria
RegrasHeurísticas
Projeto Detalhadoe/ou Código
MétricasOA
Aplicaçãodas Métricas
Projeto e/ou Implementação Final
Refatoração doprojeto / código
Problemasde SI
Ok
AnáliseAplicação
das Regras
Refatorações OA
artefato
atividade
recurso
Legenda
Avaliação Melhoria
RegrasHeurísticas
Projeto Detalhadoe/ou Código
MétricasOA
Aplicaçãodas Métricas
Projeto e/ou Implementação Final
Refatoração doprojeto / código
Problemasde SI
Ok
AnáliseAplicação
das Regras
Refatorações OA
artefato
atividade
recurso
Legenda
artefato
atividade
recurso
Legenda
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
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; }}
Label
Label()changed()
Label
Label()changed()
GUIColleague
setMediator()
GUIColleague
setMediator()
GUIMediator
changed()
GUIMediator
changed()
JLabel
…
JLabel
…
JButton
…
JButton
…
Button
mediator
Button()clicked()setMediator()
Button
mediator
Button()clicked()setMediator()
Button GUIColleague
NOAconcern 1 0
NOOconcern 1 1
LOCconcern 6 3
Legenda:
Papel Colleague do padrão Mediator
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. 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 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. 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 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 0 0
ConcreteBind 0 0
MetaObject 1 1
MetaObjectComposite 1 2
MetaObjectEncapsu 2 4
MetaObjectFactoryComposite 0 1
MetaObjectFactoryEncapsule 0 1
MetaObjFactory 0 1
MetaObserver 0 0
MetaSubject 0 0
Laboratório de Engenharia de Software – PUC-Rio 21
Problema 1: Alerta Falso de Interesse
createMetaObject()
<<interface>>MetaObjFactory
createMetaObject()
<<interface>>MetaObjFactory
createMetaObject()
MetaObjectFactoryEncapsule
createMetaObject()
MetaObjectFactoryComposite
createMetaObject()
MetaObjectFactoryComposite
refresh()
<<interface>>MetaObserver
refresh()
<<interface>>MetaObserver
state
getNameInstance()refresh()
MetaObject
state
getNameInstance()refresh()
MetaObject
graph
createGraph()rebind()refresh()
MetaObjectComposite
graph
createGraph()rebind()refresh()
MetaObjectComposite
nextPreHandlernextPosHandler
addPreMethod()addPosMethod()handlePreMethods()handlePosMethods()Refresh()
MetaObjectComposite
nextPreHandlernextPosHandler
addPreMethod()addPosMethod()handlePreMethods()handlePosMethods()Refresh()
MetaObjectComposite
addObserver()removeObserver()notifyObservers()
<<interface>>MetaSubject
addObserver()removeObserver()notifyObservers()
<<interface>>MetaSubject
observers......addObserver()removeObserver()notifyObservers()
ConcreteBind
observers......addObserver()removeObserver()notifyObservers()
ConcreteBind
observersstate...addObserver()removeObserver()notifyObservers()
Component
observersstate...addObserver()removeObserver()notifyObservers()
Component
Legenda:
Observer
Factory Method
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
Interessede Elevado
Espalhamento
Interesse
InteresseEntrelaçado
Interessede Baixo
Espalhamento
InteresseSecundário
InteressePrimário
R01
R02
R03 R04
R05
R06 R07
R08
InteressePossivelmente
Secundário
InteressePossivelmente
Primário
R10R09
InteresseModularizado
Legenda:
Estado Inicial
Estado Intermediário
Estado Final
Legenda:
Estado Inicial
Estado Intermediário
Estado Final
Laboratório de Engenharia de Software – PUC-Rio 26
Regras de Separação de Interesses
R01 Se CDLOC é 2então INTERESSE MODULARIZADO
R02 Se CDLOC é maior que 2então INTERESSE ENTRELAÇADO
R03 Se CDC / VS de INTERESSE ENTRELAÇADO é altoentão INTERESSE DE ELEVADO ESPALHAMENTO
R04 Se CDC / VS de INTERESSE ENTRELAÇADO não é altoentão INTERESSE DE BAIXO ESPALHAMENTO
Laboratório de Engenharia de Software – PUC-Rio 27
Regras de Separação de Interesses
R05 Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE ELEVADO ESPALHAMENTOentão INTERESSE POSSIVELMENTE PRIMÁRIO
R06 Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE ELEVADO ESPALHAMENTOentão INTERESSE POSSIVELMENTE SECUNDÁRIO
R07 Se (NOAconcern / NOA é alto) e (NOOconcern / NOO é alto) para todos os componentes de INTERESSE DE BAIXO ESPALHAMENTOentão INTERESSE POSSIVELMENTE PRIMÁRIO
R08 Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo) para pelo menos um componente de INTERESSE DE BAIXO ESPALHAMENTOentão INTERESSE POSSIVELMENTE SECUNDÁRIO
Laboratório de Engenharia de Software – PUC-Rio 28
Regras de Separação de Interesses
R09 Se (LOCconcern / LOC é alto) para todos os componentes de POSSÍVEL INTERESSE PRIMÁRIOentão INTERESSE PRIMÁRIO
R10 Se (LOCconcern / LOC é baixo) para pelo menos um componente de POSSÍVEL INTERESSE SECUNDÁRIOentã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
Componente deBaixa Coesão
Componentecom Interesse
Secundário
Componente deElevada Coesão
R11
R12R13
R14
Componente Candidato aReestruturação Global
Componente deElevado Acoplamento
Componente deBaixo Acoplamento
Componente Candidato aExtração de Interesses
R15R15 R16R16
Legenda:
Estado Inicial Estado Intermediário Estado Final
Legenda:
Estado Inicial Estado Intermediário Estado Final
• 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
R11 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
Parserde
Código
Extrator de Modelo AspectJ
Analisadorde
ReferênciasCódigo FonteCódigo Fonte
Gerenciador de Interesses
Modelo AspectJModelo AspectJ
Mapeamento deInteresses ( XML )
Coletor de Métricas
Tamanho
Acoplamento Coesão
SI
RegrasRegras Dados deMediçãoDados deMedição
Alertas deProblemasAlertas deProblemas
Analisador de Regras
Acoplamento e Coesão
Separação de Interesses
Analisador de Regras
Acoplamento e Coesão
Separação de Interesses
Laboratório de Engenharia de Software – PUC-Rio 35
AJATO: Modelo de Programas AspectJ
• Estrutura de dados representativa do sistema avaliado
Sistema
Pacotes
Componentes
Atributos Operações Conjuntos de Junção Declarações Intertipo
Blocos de ComandosBlocos de ComandosComandosLegenda:
contém
Legenda:
contém
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. 872-891, 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
Legenda:
afeta (corta)
classe
aspecto
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
EstudosElementos Principais da Abordagem
Método Regras Ferramenta
Padrões GoF Individuais X X
Composição de Padrões X X X
Portalware X X X
Health Watcher X X X
Telestrada X
• Elementos da abordagem avaliados em cada estudo de caso
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 AvaliadosProblemas Identificados
A B C D E F1º Builder Papel Director X
Factory Method Papel Creator X X
ObserverPapel Observer X
Papel Subject
2ºFactory Method com
ObserverPadrão Factory Method X X X
Padrão Observer
Façade com SingletonPadrão Façade X
Padrão Singleton
Prototype com StatePadrão Prototype
Padrão State X X
Interpreter com ProxyPadrão Interpreter X
Padrão Proxy
3º
Health Watcher
Concorrência X X
Distribuição
Persistência
4º
Portalware
Adaptação
Autonomia
Colaboração X X X X
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. 36-74, 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. 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 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)
Top Related