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
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
2
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
3
Problema: Interesses Transversais
• Separação de interesses
Tradicional
Aluno
Nota
Disciplina
Matricular
Lançar
Criar
Orientada a Aspectos
Alterar
Persistência
Segurança
Aluno
Matricular
Alterar
Nota
Lançar
Alterar
Criar
Cancelar
Alterar
Cancelar
Disciplina
(a)
(b)
Separação em dados e funções
Separação em dados, funções e aspectos
Laboratório de Engenharia de Software – PUC-Rio
4
Problema: Interesses Transversais
• Interesse transversal (a) separado em aspecto (b)
(a)
Legenda
(b)
Interesse Transversal
Classe
Relacionamento
Aspecto
Laboratório de Engenharia de Software – PUC-Rio
5
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
6
Problema: Avaliação de Software
• Pelo menos seis problemas podem decorrer de
uma interpretação incorreta de medições
1.
2.
3.
4.
5.
6.
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
7
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 AspectOriented 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
8
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
9
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
10
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
11
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
12
O Método de Avaliação
Métricas
OA
Regras
Heurísticas
Refatorações OA
Avaliação
Projeto Detalhado
e/ou Código
Aplicação
das Métricas
Legenda
Aplicação
das Regras
Melhoria
Análise
Problemas
de SI
Ok
Refatoração do
projeto / código
Projeto e/ou
Implementação Final
artefato
atividade
recurso
Laboratório de Engenharia de Software – PUC-Rio
13
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
14
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
15
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
16
Novas Métricas: Exemplos
JLabel
…
GUIMediator
GUIColleague
changed()
setMediator()
JButton
…
Legenda:
Label
Papel Colleague
do padrão Mediator
mediator
Label()
changed()
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;
}
}
Laboratório de Engenharia de Software – PUC-Rio
Button
Button()
clicked()
setMediator()
Button
GUIColleague
NOAconcern
1
0
NOOconcern
1
1
LOCconcern
6
3
17
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
18
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
19
Problemas em Medições
• Problema 1: Alerta falso por interesse espalhado
e entrelaçado
Factory Method
CDC = 6
CDLOC = 8
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
Componentes
Laboratório de Engenharia de Software – PUC-Rio
20
Problema 1: Alerta Falso de Interesse
<<interface>>
<<interface>>
MetaSubject
MetaObserver
refresh()
addObserver()
removeObserver()
notifyObservers()
MetaObject
Component
ConcreteBind
observers
state
...
addObserver()
removeObserver()
notifyObservers()
observers
...
...
addObserver()
removeObserver()
notifyObservers()
<<interface>>
MetaObjFactory
state
getNameInstance()
refresh()
MetaObjectComposite
graph
createGraph()
rebind()
refresh()
createMetaObject()
MetaObjectFactoryComposite
MetaObjectFactoryEncapsule
createMetaObject()
createMetaObject()
MetaObjectComposite
nextPreHandler
nextPosHandler
addPreMethod()
addPosMethod()
handlePreMethods()
handlePosMethods()
Refresh()
Legenda:
Observer
Factory Method
Laboratório de Engenharia de Software – PUC-Rio
21
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
22
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
23
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
24
Interesse
R01
Interesse
Modularizado
R02
Interesse
Entrelaçado
R03
Interesse
de Elevado
Espalhamento
R05
Interesse
Possivelmente
Primário
R09
R04
R06
R07
Interesse
de Baixo
Espalhamento
R08
Interesse
Possivelmente
Secundário
R10
Legenda:
Estado Inicial
Estado Intermediário
Interesse
Primário
Laboratório de Engenharia de Software – PUC-Rio
Interesse
Secundário
Estado Final
25
Regras de Separação de Interesses
R01
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
26
Regras de Separação de Interesses
R05
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
então INTERESSE POSSIVELMENTE PRIMÁRIO
R08
Se (NOAconcern / NOA é baixo) e (NOOconcern / NOO é baixo)
para pelo menos um componente de INTERESSE DE BAIXO
ESPALHAMENTO
então INTERESSE POSSIVELMENTE SECUNDÁRIO
Laboratório de Engenharia de Software – PUC-Rio
27
Regras de Separação de Interesses
R09
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
28
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
Componente
Componente
Componente
Laboratório de Engenharia de Software – PUC-Rio
de Elevada/Baixa Coesão
de Elevado/Baixo Acoplamento
Candidato a Reestruturação Global
Candidato a Extração de Interesses
29
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
30
Regras de Acoplamento e Coesão
R11
Componente
com Interesse
Secundário
R13
Componente de
Baixa Coesão
Componente de
Elevado Acoplamento
R14
R12
Componente de
Elevada Coesão
R15
Componente Candidato a
Reestruturação Global
Componente de
Baixo Acoplamento
R16
Componente Candidato a
Extração de Interesses
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
31
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
32
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
33
AJATO: Organização Arquitetural
Parser
de
Código
Código Fonte
Analisador
de
Referências
Extrator de Modelo AspectJ
Modelo AspectJ
Acoplamento
Coesão
Tamanho
SI
Coletor de Métricas
Gerenciador de Interesses
Mapeamento de
Interesses ( XML )
Separação de Interesses
Acoplamento e Coesão
Regras
Analisador de Regras
Dados de
Medição
Alertas de
Problemas
Laboratório de Engenharia de Software – PUC-Rio
34
AJATO: Modelo de Programas AspectJ
Sistema
Pacotes
Componentes
Atributos
Operações
Comandos
Conjuntos de Junção
Blocos de Comandos
Declarações Intertipo
Legenda:
contém
• Estrutura de dados representativa do sistema
avaliado
Laboratório de Engenharia de Software – PUC-Rio
35
AJATO: Modelo de Programas AspectJ
Laboratório de Engenharia de Software – PUC-Rio
36
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
37
AJATO: Extrator de Modelo AspectJ
Laboratório de Engenharia de Software – PUC-Rio
38
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
39
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
40
AJATO: Coletor de Métricas
Laboratório de Engenharia de Software – PUC-Rio
41
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
42
AJATO: Analisador de Regras
Laboratório de Engenharia de Software – PUC-Rio
43
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
44
Estudos Experimentais
• Elementos da abordagem avaliados em cada
estudo de caso
Elementos Principais da Abordagem
Estudos
Método
Regras
Padrões GoF Individuais
X
X
Composição de Padrões
X
X
X
Portalware
X
X
X
Health Watcher
X
X
X
Telestrada
Laboratório de Engenharia de Software – PUC-Rio
Ferramenta
X
45
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
46
Estudos Experimentais: Contribuições
Estudos de Caso
1º Builder
Factory Method
Observer
2º Factory Method com
Observer
Façade com Singleton
Prototype com State
Interpreter com Proxy
3º
Health Watcher
4º
Portalware
Laboratório de Engenharia de Software – PUC-Rio
Interesses Avaliados
Papel Director
Papel Creator
Papel Observer
Papel Subject
Padrão Factory Method
Padrão Observer
Padrão Façade
Padrão Singleton
Padrão Prototype
Padrão State
Padrão Interpreter
Padrão Proxy
Concorrência
Distribuição
Persistência
Adaptação
Autonomia
Colaboração
Problemas Identificados
A
B
C
D
E
F
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
47
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
48
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 ObjectOriented 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, PUCRio. 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
49
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
50
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
51
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
52
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
53
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
54
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
55