Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages...

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


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



• Separação de interessesTradicional Orientada a Aspectos

Aluno Matricular Alterar

Disciplina Criar Cancelar

Nota Lançar AlterarAluno Matricular Alterar


Nota Lançar Alterar

SegurançaPersistência

Aluno Matricular Alterar


Nota Lançar Alterar

SegurançaPersistência

(b)Separação em dados, funções e aspectos

(a)Separação em dados e funções



• Interesse transversal (a) separado em aspecto (b)

Interesse Transversal

Legenda

Classe

AspectoRelacionamento

Interesse TransversalInteresse Transversal

Legenda

ClasseClasse

AspectoAspectoRelacionamentoRelacionamento

(a)

(b)(b)


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


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


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.


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



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.


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


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


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


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


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


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


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


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]


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


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]


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


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


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


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


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



– 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


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



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



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



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


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



• 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



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



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


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


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


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


AJATO: Modelo de Programas AspectJ


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.


AJATO: Extrator de Modelo AspectJ


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


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


AJATO: Coletor de Métricas


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


AJATO: Analisador de Regras


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


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


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


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


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



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



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



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



• 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



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


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


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)

Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages...

Documents

Transcript of Uma Abordagem Quantitativa para Desenvolvimento de Software Orientado a Aspectos Eduardo Magno Lages...