engenharia reversa de padroes em˜ arquitecturas reutilizaveis´ · o processo de engenharia...

Faculdade de Engenharia da Universidade do Porto

Departamento de Engenharia Electrotecnica e de Computadores

Engenharia Reversa de Padroes emArquitecturas Reutilizaveis

Nuno Honorio Rodrigues Flores

Licenciado em Engenharia Informatica e Computacaopela

Faculdade de Engenharia da Universidade do Porto

Dissertacao apresentada para a obtencao do grau de Mestre emEngenharia Informatica

Dissertacao realizada sob a orientacao cientıfica de

Doutor Ademar Manuel Teixeira de Aguiar

Professor Auxiliar do Departamento de Electrotecnica e Computadoresda Faculdade de Engenharia da Universidade do Porto

Porto, Setembro de 2005

ii

Contacto :

Nuno Honorio Rodrigues FloresFaculdade de Engenharia da Universidade do PortoDepartamento de Engenharia Electrotecnica e de Computadores

Rua Dr. Roberto Frias, s/n4200 - 465 PortoPORTUGAL

Tel: +351 91 4904126Email : [email protected]

Nuno Honorio Rodrigues Flores”Engenharia Reversa de Padroes em Arquitecturas Reutilizaveis”Copyright c© 2005 Todos os direitos reservados

iii

aos meus pais, Eugenio e Elvira.a minha irma, Raquel.

Resumo

O processo de engenharia reversa proposto nesta dissertacao assenta numa abordagem derecuperacao de desenho que realca aqueles elementos que implementam a flexibilidade de umaframework, ajudando na sua aprendizagem e conveniente reutilizacao.

As frameworks aplicacionais orientadas por objectos constituem uma poderosa tecnica dereutilizacao de software em larga escala. Atraves de elevados nıveis de reutilizacao de codigo edesenho, as frameworks permitem aumentar a produtividade, reduzir tempos de desenvolvimentoe aumentar a qualidade das aplicacoes. No entanto, antes de se conseguir utilizar uma frameworkde forma eficaz, e normalmente necessario dedicar tempo e esforco consideraveis na aprendizageme compreensao dos detalhes essenciais da sua arquitectura e desenho. Esta tarefa torna-se difıcile morosa, quando a framework nao vem acompanhada de uma documentacao adequada, devidoa mas praticas de manutencao e evolucao. A informacao sobre o desenho da framework perde-secom o tempo e torna-se indisponıvel ou difıcil de obter.

Frameworks e padroes de desenho sao dois conceitos fortemente relacionados, representandodois nıveis diferentes de abstraccao, ao nıvel da definicao do desenho e arquitectura de umsistema de software. Tipicamente, uma framework e composta por diversos padroes de desenho,pelo facto de estes seres extremamente uteis na sua construcao, ao abordarem um problemarecorrente com uma solucao considerada boa, dotando aquela de mecanismos que fomentam asua extensibilidade e flexibilidade.

Nesta dissertacao e proposta uma abordagem de recuperacao dos elementos de desenho deuma framework que a dotam de flexibilidade, nomeadamente padroes de desenho. A abordagemassenta num processo semi-automatico de engenharia reversa dividido em fases, atraves dasquais se detectam estruturas de desenho de crescente nıvel de abstraccao. A representacao dospadroes de desenho baseia-se numa formalizacao recorrendo ao conceito de meta-padrao, umaabstraccao de alto-nıvel e que define a estrutura e relacionamento dos elementos constituintesdos padroes de desenho, os mesmos que lhe conferem a flexibilidade.

Esta abordagem permite ao utilizador de uma framework uma rapida consciencializacao dospontos de variabilidade desta, atraves do fornecimento de resultados intermedios uteis (hot spots,meta-padroes e padroes de desenho) e que ajudam na eficaz reutilizacao do codigo e desenho daframework: o seu principal proposito.

v

Abstract

The reverse engineering process proposed in this dissertation relies on a design recovery approachthat aims at recovering flexible framework design elements, thus assisting in its learning processand efective reuse.

Object-oriented frameworks are a powerful technique for large-scale reuse that helpsdevelopers achieve higher productivity and shorter time-to-market through high levels of designand code reuse. However, before starting to use a frawework successfully, users usually need toinvest time on understanding its underlying architecture and design principles. This can be adificult and tiresome task, when the available framework documentation is poorly written, lacksdetail and is clearly outdated. Design information is lost throughout maintenance and evolutionand becomes unavailable or hard to find.

Frameworks and design patterns are closely retaled concepts, representing two differentcategories of high-level design abstractions. A single framework typically encompasses severaldesign patterns, as they provide a good generic solution to a recurring design problem, becomingthe building blocks for the framework flexibility and extensibility aspects.

This dissertation presents an approach for recovering frawework design, namely designpatterns, through a semi-automatic reverse engineering multi-phased process that recovers designelements of increasing level of abstraction. Design patterns are represented through a formalmodel based on metapatterns, a high-level abstraction that structures and relates its constituentelements, the same that provide flexibility to the framework.

This approach helps on the understanding of a framework’s design by providing usefulintermediate results (hot spots, metapatterns and design patterns), therefore assisting on thelearning process and supporting an efective design and code reuse: a framework’s main goal.

vii

Prefacio

”A Carolina e uma tolaQue tudo faz ao reves

Veste-se pela cabecaE veste-se pelos pes”

excerto de uma cancao popular

Assim como o vestir da Carolina, tambem a engenharia se pode fazer de tras para a frentecomo da frente para tras.

A primeira vez que ouvi falar de engenharia reversa foi durante o relato da razao pela qualmuito provavelmente, hoje em dia, o mercado de venda de computadores de pessoais e taocompetitivo: ”Como a Compaq clonou o IBM PC”. Em Fevereiro de 1982, tres gestores dagrande Texas Instruments (Rod Canion, Jim Harris e Bill Murto ), deixam a multinacional einvestem 1000 dolares cada na criacao da sua empresa: a Compaq Computer Corporation. Oseu primeiro produto, rabiscado num papel a mesa de um cafe em Houston, foi um computadorportatil 100% compatıvel com o IBM PC, na altura, o popular monopolista dos computadorespessoais e detentor patenteado da sua propria BIOS, nao divulgada. Como? Engenharia reversa.

Impedimentos legais impediam a Compaq de copiar a BIOS do IBM PC para a sua maquinapor forma a torna-la 100% compatıvel, pois tal seria facil de provar. A solucao passou porter dois grupos de programadores: o primeiro com acesso ao codigo-fonte da IBM, o segundosem conhecimento nenhum acerca deste. O primeiro grupo analisou o codigo e tomou anotacoes,criando um documento que especificava quais as funcionalidades fornecidas pelo codigo, mas semrevelar detalhes de implementacao. O segundo grupo pegou no documento e desenvolveu todoo sistema de raiz. Um ano e um milhao de dolares depois, conseguiram ter em funcionamento,e de forma perfeitamente legal, uma BIOS identica a da IBM. Adicionalmente, o produto daCompaq era portatil, e nao muito maior que uma mala de viagem (das pequenas). Resultado:111 milhoes de dolares de vendas no primeiro ano, batendo o recorde de volume de negocios nosEstados Unidos da America.

Na altura, meados de 19971, este relato despertou-me primeiro o espanto, mas depois ointeresse pela forma como a engenharia reversa funcionava, nao pelas potenciais ilegalidades,como e obvio, mas pelo processo de analise e descoberta. Claro que, nao estando ligadodirectamente ao hardware, explorei alguns aspectos da engenharia reversa de software. Tal

1Pode-se pensar que a engenharia reversa e um assunto muito especıfico do campo da engenharia mas asua popularidade tem vindo a aumentar, havendo mesmo despertado o interesse da industria cinematograficade Hollywood que recentemente produziu um filme cujo teor gira a volta da engenharia reversa (falo do filme”Paycheck”de Jonh Woo, de 2003).

ix

x Prefacio

exploracao levou-me a conhecer os padroes de desenho, nao tanto como produtos de engenhariareversa, mas como ferramentas de desenho de software. Rapidamente me tornei adepto da suautilizacao e cheguei mesmo a ”evangelizar”alguns colegas, mais chegados, na sua utilizacao.

Durante as minhas incursoes na vida profissional, sempre que podia empregava padroes dedesenho no desenvolvimento de solucoes a medida para problemas recorrentes (e sim, erambastante recorrentes). Daı ate a utilizacao de frameworks foi um salto. A sua utilidaderapidamente me fez recorrer a elas como fonte de solucoes e desenvolvimento rapido e seguro.Por outro lado, a sua complexidade associada a alguma genialidade de construcao, seduzia-me.Sempre achei que codificar devia ser tambem uma arte, pois envolve creatividade, imaginacao einspiracao. Decidido a continuar os meus estudos, enveredei pelo mestrado, sabendo de antemaoque o tema da dissertacao andaria sempre ha volta destes conceitos, ou, no seu ambito maisalargado, em redor da engenharia de software.

Durante a cadeira de Arquitectura de Sistemas de Software, cujo docente viria a ser omeu orientador, abordaram-se todos os temas sob os quais eu tinha interesse: frameworks,padroes de desenho, padroes de arquitectura, reengenharia, reestruturacao de codigo, etc.Consequentemente, recaiu a escolha de um trabalho pratico no desenvolvimento de umaferramenta de recuperacao de desenho, no caso, de hot spots, pontos de variabilidade eflexibilidade de uma framework, no seu nıvel de abstraccao mais baixo. Estava lancado o motepara o que viria a ser o tema da dissertacao.

A proposta concreta para o tema surgiu da tese de doutoramento [Aguiar 03b] do meuorientador, o Doutor Ademar Aguiar, que aborda a problematica em torno da documentacao deuma framework e que propoe uma abordagem minimalista. Em conversa sobre o assunto, tenteimeter a engenharia reversa e os padroes de desenho ao barulho, temas que encaixaram muitobem logo desde o inıcio.

As dificuldades inerentes a documentacao, como ferramenta de comunicacao do desenho euso das frameworks, tinham como uma das solucoes o uso de padroes de desenho e meta-padroescomo bons representadores das nocoes de desenho de alto-nıvel e, por conseguinte, bons parausar na documentacao. Estes factos, aliados as mas praticas de manutencao e evolucao dadocumentacao, levantaram o problema de recuperar o desenho perdido ao longo de iteracoessucessivas, onde se menospreza a actualizacao conveniente da documentacao.

Foi com esta problematica em mente, que se partiu para esta dissertacao: explorar a definicaode um processo que procedesse a recuperacao do desenho perdido, e que fosse util para aprendera utilizar a framework. Como consequencia, a abordagem teria como pedras basilares, osmeta-padroes, ambos bons na representacao dos pontos de flexibilidade e na documentacaoda frameworks e como objectivo final a identificacao de instancias de padroes de desenho. Umdos seus contextos seria a continuacao de uma das vertentes de trabalho futuro, despoletadopela tese de doutoramento do meu orientador.

Findo o trabalho de investigacao, resta dizer que o entusiasmo so aumentou e o potencialpara continuar o trabalho nesta area e enorme. As dificuldades que existiram, sobretudo a nıveltemporal, fizeram-me tomar consciencia de ambitos dos quais nao tinha nocao e tomar contactocom determinadas nocoes de grande interesse pessoal.

A todos os que me apoiaram neste trabalho, queria agradecer primeiro e muito em especialao meu orientador Ademar Aguiar, que, acima de tudo, foi um companheiro, amigo e colega.Desde o inıcio esteve sempre disponıvel, sempre motivador e sempre crente no trabalho e no seuexecutante. Foi um apoio constante em todas as fases do trabalho e tinha sempre aquela palavra

xi

de desembaraco que mantinha acesa a chama do desafio e da investigacao. Obrigado, Ademar.Bem hajas.

Queria enderecar outro agradecimento especial aos meus colegas de mestrado, Helder Ferreirae Marco Rodrigues que me acompanharam durante a parte lectiva e que me fizeram acreditar denovo no trabalho cooperativo altruısta e na forca de vontade que se descobre no fim de umas boasgargalhadas. Aos restantes colegas, um cumprimento de apreco pela companhia nesta cruzadaque todos trilhamos.

Queria tambem agradecer ao colectivo de docentes do mestrado, nomeadamente aosprofessores: Joao Falcao e Cunha, pela postura frontal e directa com que sempre abordou todasas questoes ligadas a investigacao; Cristina Ribeiro, pela paciencia e tolerancia demonstradas;Joao Pascoal Faria, pela objectividade, Antonio Augusto de Sousa e Raul Vidal, pelo constanteencorajamento. Um agradecimento ao director do mestrado, Prof. Eugenio de Oliveira, portodo o apoio prestado.

Um agradecimento sentido a Kris de Volder, que me ajudou bastante na fase dos formalismose da sua traducao usando o TyRuBa. A sua ajuda foi fundamental na concretizacao doJFREEDOM. Many thanks, Kris. Hope to keep working with you.

Agradecimentos tambem ao Alexandre Sousa, por me libertar das tardes de docencia noISMAI, nas quais me pude concentrar na dissertacao.

Obrigado especial a minha companheira Diana Soares, que me abriu os horizontes para abenefica partilha de conhecimentos e consciencializacao de que o software nao e desprovido debeleza, arte e prazer. Obrigado por sempre me empurrares para a frente em perseguicao dosmeus objectivos, mesmo quando pareciam inatingıveis.

Obrigado ao Nuno Bettencourt, Vangelis, Dead Can Dance, Luar na Lubre, Xose ManuelBudino, Nitin Sawhney e The Humble Brothers pela vossa musica.

Obrigado aos arrefole, pela musica, companheirismo, digressoes e actuacoes.

Para os meus pais, Eugenio e Elvira, e a minha irma Raquel, que sempre estiveram e estaraopresentes em todos os momentos, obrigado pelo amor e dedicacao.

Conteudo

Prefacio ix

1 Introducao 1

1.1 Reutilizacao de Frameworks Orientadas por Objectos . . . . . . . . . . . . . . . . 1

1.2 Dificuldades na Reutilizacao de Frameworks . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objectivos de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Engenharia Reversa de Padroes em Arquitecturas Reutilizaveis . . . . . . . . . . 4

1.5 Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Organizacao da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Revisao Bibliografica 7

2.1 Engenharia Reversa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Principais Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Reutilizacao de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Definicao, Princıpios e Objectivos . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Pre-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.3 Potencialidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Restricoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.5 Tecnicas de Reutilizacao de Software . . . . . . . . . . . . . . . . . . . . . 16

2.3 Arquitectura de Software Orientada por Objectos . . . . . . . . . . . . . . . . . . 19

2.3.1 Enquadramento e Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Nıveis Arquitecturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Frameworks Aplicacionais Orientadas por Objectos . . . . . . . . . . . . . . . . . 22

2.4.1 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.2 Vantagens e Desvantagens no Uso de Frameworks . . . . . . . . . . . . . . 23

2.5 Padroes de Desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

xiii

xiv Conteudo

2.5.1 O que sao Padroes de Desenho? . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.2 Vantagens e Desvantagens no Uso dos Padroes de Desenho. . . . . . . . . 26

2.5.3 Meta-padroes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Recuperacao de Desenho com vista a Reutilizacao de Software 31

3.1 Principais Problemas na Reutilizacao de Software e das Frameworks . . . . . . . 31

3.1.1 Frameworks : Problemas na Reutilizacao de Software . . . . . . . . . . . 31

3.1.2 Obstaculos a Facil Compreensao de Frameworks . . . . . . . . . . . . . . 32

3.2 Trabalho Relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1 Pat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.2 KT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.3 Seeman-Gudenberg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.4 SPOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.5 Albin-Amiot & Gueheneuc . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.6 Heuzeroth-Holl-Hogstrom-Lowe . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.7 SPQR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.8 DPVK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.9 Niere-Schafer-Wadsack-Wendehals-Welsh . . . . . . . . . . . . . . . . . . 40

3.2.10 Campo-Marcos-Ortigosa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.11 Balanyi-Ferenc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Abordagem para Recuperacao de Desenho 45

4.1 Elementos de Desenho de uma Framework a Recuperar . . . . . . . . . . . . . . 45

4.1.1 Templates e Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.2 Meta-Padroes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.3 Padroes de Desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Processo de Engenharia Reversa . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 Analise do Codigo-Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.2 Deteccao de Hot spots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.3 Deteccao de Meta-Padroes . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.4 Reconhecimento de Padroes de Desenho . . . . . . . . . . . . . . . . . . . 62

4.2.5 Producao de Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 A Abordagem em 4 Passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5 JFREEDOM — um plug-in para o Eclipse 69

5.1 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Conteudo xv

5.1.2 Java e o JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1.3 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.1 Modulo de Analise e Pesquisa do Codigo-Fonte . . . . . . . . . . . . . . . 76

5.2.2 HotSpotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.3 Detector de Meta-Padroes . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.4 Identificador de Padroes de Desenho . . . . . . . . . . . . . . . . . . . . . 80

5.2.5 Repositorio de Regras e Definicoes . . . . . . . . . . . . . . . . . . . . . . 82

5.3 Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.3.1 Identificacao de Estruturas Genericas . . . . . . . . . . . . . . . . . . . . 83

5.3.2 Identificacao de Invocacao por Variavel ou Argumento . . . . . . . . . . . 85

5.3.3 Requisitos de Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3.4 Proliferacao de Ficheiros da Base de Factos . . . . . . . . . . . . . . . . . 85

5.4 Caracterısticas principais do JFREEDOM . . . . . . . . . . . . . . . . . . . . . . 86

6 Caso de Estudo e Experimentacao 87

6.1 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1.1 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2 Experimentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.1 Padrao: Template Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.2 Padrao: Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.3 Padrao: Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2.4 Padrao: Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3 Analise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7 Conclusoes 97

7.1 Principais Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A Predicados definidos para o JFREEDOM 101

A.1 Predicados de Relacao Entre os Participantes do Modelo Formal . . . . . . . . . 102

A.2 Predicados que Mapeam os Meta-Padroes Fundamentais . . . . . . . . . . . . . . 107

A.3 Predicados que Mapeam Padroes de Desenho . . . . . . . . . . . . . . . . . . . . 109

Bibliografia 109

Lista de Tabelas

3.1 Comparacao de ferramentas de recuperacao de padroes de desenho. . . . . . . . . 43

5.1 Correspondencia entre os cinco meta-padroes fundamentais e os padroes dedesenho (GoF) que os podem instanciar. . . . . . . . . . . . . . . . . . . . . . . . 81

xvii

Lista de Figuras

2.1 Relacao entre os conceitos de engenharia reversa e as varias fases do processo dedesenvolvimento de software (extraıda de [Chikofsky 90]. . . . . . . . . . . . . . . 9

2.2 Nıveis de arquitectura de software orientado por objectos [Aguiar 03b]. . . . . . . 20

2.3 Exemplo de um padrao de desenho: Composite (retirada de [Gamma 95]). . . . . 26

2.4 Meta-padroes segundo [Pree 95]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5 Meta-padrao 1:1 Connection mapeado nos padroes de desenho State e Strategy. . 30

4.1 Exemplo de templates e hooks na classe TestCase. . . . . . . . . . . . . . . . . . 46

4.2 Unification metapattern e Connection metapattern, segundo Pree [Pree 95]. . . . 48

4.3 Recursive Unification metapattern e Recursive Connection metapattern, segundoPree [Pree 95]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Fases do processo de recuperacao de desenho. . . . . . . . . . . . . . . . . . . . . 50

4.5 Definicao de hot spot, segundo Schauer [Schauer 99]. . . . . . . . . . . . . . . . . 52

4.6 Definicao das relacoes primitivas entre classes, segundo o modelo formal deTourwe (retirada de [Tourwe 02]). . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.7 Definicao das relacoes primitivas entre metodos, segundo o modelo formal deTourwe (retirada de [Tourwe 02]). . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.8 Definicao das relacoes primitivas entre classes, metodos e variaveis, segundo omodelo formal de Tourwe (retirada de[Tourwe 02]). . . . . . . . . . . . . . . . . . 56

4.9 Definicoes preliminares sobre hierarquias de classes, segundo o modelo formal deTourwe (retirada de [Tourwe 02]). . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.10 Mapeamento do padrao de desenho Composite segundo o meta-padrao fundamen-tal Recursion (adaptada de [Gamma 95]). . . . . . . . . . . . . . . . . . . . . . . 62

4.11 Mapeamento do padrao de desenho Factory Method segundo o meta-padraofundamental Creation (adaptada de [Gamma 95]). . . . . . . . . . . . . . . . . . 64

4.12 Mapeamento do padrao de desenho State segundo o meta-padrao fundamentalConnection (adaptada de [Gamma 95]). . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Arquitectura da plataforma Eclipse (retirada de [IBM Corporation 04]). . . . . . 72

5.2 Vista do plug-in JQuery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

xix

xx Lista de Figuras

5.3 JFREEDOM: Arquitectura do plug-in. . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4 Arquitectura do modulo HotSpotter. . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5 Vista da ferramenta HotSpotter. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6 Arquitectura interna do modulo de deteccao de meta-padroes. . . . . . . . . . . . 78

5.7 Vista da ferramenta JFREEDOM apos a deteccao de meta-padroes sobre o codigodo JUnit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.8 Consulta de documentacao relativa aos padroes de desenho candidatos aposdeteccao de meta-padroes sobre o codigo do JUnit. . . . . . . . . . . . . . . . . . 81

6.1 Modelo de desenho do JUnit anotado com os padroes de desenho (retirada de[Gamma 03a]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2 Estrutura do padrao de desenho Template Method (retirada de [Gamma 95]). . . 91

6.3 Instancia do padrao Template Method no JUnit. . . . . . . . . . . . . . . . . . . 91

6.4 Deteccao de uma instancia do meta-padrao unification fundamental metapatternque indicia a existencia de um padrao de desenho Template Method. . . . . . . . 91

6.5 Estrutura do padrao de desenho Factory Method (retirada de [Gamma 95]). . . . 92

6.6 Instancia do padrao Factory Method no JUnit. . . . . . . . . . . . . . . . . . . . 92

6.7 Deteccao de uma instancia do meta-padrao creation fundamental metapattern queindicia a existencia de um padrao de desenho Factory Method. . . . . . . . . . . . 92

6.8 Estrutura do padrao de desenho Decorator (retirada de [Gamma 95]). . . . . . . 93

6.9 Instancia do padrao Decorator no JUnit. . . . . . . . . . . . . . . . . . . . . . . . 93

6.10 Deteccao de uma instancia do meta-padrao recursion fundamental metapatternque indicia a existencia de um padrao de desenho Decorator. . . . . . . . . . . . . 94

6.11 Fragmento de codigo-fonte da classe TestSuite onde se mostra o uso de umcontentor generico para referenciar instancias de outras classes. . . . . . . . . . . 95

Capıtulo 1

Introducao

A problematica em redor da reutilizacao de software, nomeadamente de arquitecturas orientadaspor objectos, e em particular de frameworks orientadas por objectos, prende-se com a suaeficiente reutilizacao. As frameworks orientadas por objectos sao uma ferramenta poderosana reutilizacao de software, permitindo reutilizar nao so codigo-fonte, mas tambem o propriodesenho do sistema de software [Aguiar 03b][Fayad 99][Pree 95].

Para serem utilizadas de forma eficiente, as frameworks obrigam a um investimento previo detempo na sua aprendizagem, tarefa que se revela normalmente difıcil e morosa. Tal deve-se aofacto do desenho das frameworks ser bastante complexo (abstracto, incompleto, muito flexıvele por vezes obscuro) o que aumenta em muito a dificuldade da sua compreensao. A frequentefalta de documentacao adequada agrava ainda mais esta situacao.

Uma framework e desenhada com o objectivo de separar os aspectos constantes numdomınio de aplicacao - denominados frozen spots - daqueles variantes, e que dotam a frameworkda flexibilidade e configurabilidade que a compoe - denominados hot spots. Os padroes dedesenho [Gamma 95] representam solucoes comprovadamente boas para problemas recorrentese mostram-se extremamente uteis para implementar a flexibilidade necessaria nos hot spots. Porconseguinte, ao conhecer os padroes de desenho que compoem uma framework, melhora-se acompreensao sobre as areas de flexibilidade, contribuindo para uma reutilizacao mais eficiente.

Esta dissertacao propoe uma abordagem semi-automatica para identificar os padroes dedesenho que compoem uma framework, que se baseia num processo faseado de engenhariareversa. A abordagem adopta, como um dos seus pilares, o conceito de meta-padrao [Pree 95],uma representacao, de alto-nıvel de abstraccao, das areas de flexibilidade de uma framework.

Este capıtulo faz uma introducao geral ao tema da dissertacao. Comeca por abordaras questoes em volta da reutilizacao de frameworks orientadas por objectos, identificando osproblemas existentes e o objecto de investigacao. Os objectivos e tema da dissertacao saodefinidos, terminando com a indicacao do que se esperam ser os resultados no final e respectivotrabalho futuro.

1.1 Reutilizacao de Frameworks Orientadas por Objectos

Com um constante crescimento das necessidades do mercado de produtos de software, a rapidezde resposta dos agentes que desenvolvem estes produtos e de vital importancia. E preemente que

1

2 1 Introducao

os processos de desenvolvimento de software instaurados adoptem metodologias que aumentema sua productividade, sem desprezar a qualidade.

Uma intensa investigacao em torno da engenharia de software concluiu que a reutilizacao desoftware aparenta ser a unica aproximacao realista capaz de melhorar os nıveis de produtividadee qualidade, por forma a satisfazer as necessidades da industria [Mili 95].

Esta doutrina defende a construcao de um novo sistema, utilizando componentes previamentedesenvolvidos, sem a necessidade de os construir de raız e que resolvem problemas recorrentesnum determinado domınio de aplicacao [Krueger 92][Smolarova 97]. Existem varias tecnicas dereutilizacao que usam diferentes tipos de componentes, variantes estes em dimensao, nıvel deabstraccao e complexidade e cujos exemplos vao desde modulos concretos de codigo-fonte atearquitecturas de alto-nıvel de abstraccao [Krueger 92]. Entre estes exemplos, encontram-se asframeworks orientadas por objectos.

Uma framework pode ser definida como uma arquitectura e implementacao semi-completaspara um conjunto de aplicacoes num determinado domınio de problemas [Johnson 88]. Atravesda reutilizacao de desenho e codigo, uma framework ajuda na melhoria do nıvel de produtividade,encurtando o tempo de resposta as necessidades do mercado. Adicionalmente, promove aconsistencia e compatibilidade das aplicacoes num mesmo domınio de problemas. Quandocombinadas com componentes e padroes, as frameworks sao consideradas uma das tecnologiasmais promissoras no campo da reutilizacao de software em larga escala.

1.2 Dificuldades na Reutilizacao de Frameworks

Apesar de muitos indicadores sugerirem que o uso de frameworks pode fomentar a reutilizacaode software em troca de um menor esforco de desenvolvimento [Moser 96], esta tarefa nao serevela trivial.

Os benefıcios advindos do uso de frameworks apenas se tornam visıveis ao longo do tempo,e requerem um investimento inicial de recursos na sua aprendizagem. Sendo um dos maiscomplexos artefactos orientados por objectos reutilizaveis, as frameworks exigem um maior gastode recursos a priori, quando comparados com outras metodologias mais simples. Pelo facto deserem compostas por componentes sem uma implementacao completa, fortemente relacionados ecom um alto nıvel de abstraccao, as frameworks sao difıceis de aprender a usar. Em consequenciada sua complexidade, as frameworks sao igualmente difıceis de desenhar.

Lidar com os aspectos ligados ao uso e desenvolvimento de frameworks abrange uma panopliade questoes: definir o ambito da framework e estabelecer metodos e estrategias adequadasde a desenvolver, testar, documentar, manter e evoluir; aferir a aplicabilidade da framework,compreender como funciona e aprender a usa-la para que se possa desenvolver aplicacoes de umaforma sustentada. Ignorar estes aspectos e comprometer os benefıcios que se podem colher como uso de frameworks [Fayad 97].

Em suma, a conveniente reutilizacao de um qualquer artefacto de software exige que seinvista tempo na sua compreensao e a aprender como se usa. Quanto maior a complexidade,maior o tempo gasto nestas tarefas. Logo, aprender a usar uma framework pode ser uma tarefadispendiosa e morosa, especialmente por novos utilizadores.

A acompanhar uma framework deve haver uma boa documentacao. Sem uma descricao clara,completa e precisa do funcionamento, arquitectura e modo de utilizacao de uma framework,

1.3. Objectivos de Investigacao 3

esta torna-se difıcil de compreender e quase impossıvel de utilizar por outros que nao os seusconstrutores iniciais.

Independentemente das dificuldades inerentes a producao de uma boa documentacao, estatem de ser mantida actualizada durante o tempo de vida da framework. Assim como umaframework evolui para se adaptar a novos requisitos, ou expande o seu domınio de aplicacao,tambem a documentacao tem de acompanhar estas mudancas. Razoes de varia ordem levam aque nem sempre este acompanhamento seja o mais adequado, perdendo-se informacao relativaao desenho da framework. A pressao de mercado, o tempo de inactividade da sua utilizacao ea migracao dos especialistas entre diferentes contextos fazem com que o conhecimento profundoda framework se dissipe ao longo do tempo, afectando a sua eficaz reutilizacao.

E motivado por este problema de perda de informacao de desenho que se apresenta o temaconstante desta dissertacao.

1.3 Objectivos de Investigacao

Para reutilizar convenientemente uma framework e preciso uma clara compreensao do seudesenho e arquitectura. Sem esta informacao disponıvel ou de difıcil acesso, a sua reutilizacaoencontra-se comprometida.

Uma framework e constituıda por elementos de desenho que lhe conferem a flexibilidadedesejada para que esta seja adaptada a um problema concreto. A sua construcao e orientadapara este conceitos, logo, descobrir quais sao estes elementos e como se estruturam e relacionam,traz mais-valias para quem a pretende reutilizar.

No nucleo da sua composicao, uma framework esta ”semi-implementada”, assentando estadefinicao na separacao de dois conceitos: a arquitectura estavel e os pontos de variabilidade[Pree 95]. O primeiro conceito (tambem conhecido por frozen spots) representa a parte”implementada”da framework, ou seja, os pontos de invariabilidade e que nao mudam,permitindo partir sempre da mesma arquitectura base. O segundo conceito (tambem chamadohot spots) parametriza a arquitectura base, permitindo dar-lhe uma implementacao e, logo, umcomportamento especıfico.

Saber onde estes elementos se encontram numa framework e de vital importancia para outilizador que a pretende usar para desenvolver uma aplicacao especıfica no domınio em questao,pois e nesses pontos que tera de actuar.

As frameworks implementam os seus pontos de flexibilidade atraves de dois elementosessenciais: metodos template e metodos hook. Estes podem ser estruturados e compostos emclasses que se relacionam entre si segundo uma serie finita de padroes denominados meta-padroes[Pree 95]. Conhecer estas estruturas de elevado nıvel de abstraccao e como estao implementadasna framework facilita em grande medida o trabalho de compreender como esta funciona.

Os meta-padroes encontram-se presentes nos padroes de desenho [Gamma 93], entidadesque descrevem solucoes comprovadamente boas para problemas recorrentes num determinadodomınio. Por estas razoes, os padroes de desenho e as frameworks sao conceitos estreitamenteligados, estando os primeiros frequentemente presentes na arquitectura dos segundos.

Os padroes de desenho sao boas escolhas para o desenho de uma framework porque capturama experiencia a um nıvel de abstraccao intermedio e englobam meta-informacao de comoincorporar a flexibilidade na framework [Beck 94]. Por conseguinte, sao de grande utilidade

4 1 Introducao

na descricao do proposito da framework, na motivacao por detras de determinadas decisoes dedesenho e no ensino da utilizacao daquela.

Por fornecerem um vocabulario comum entre utilizadores, fomentarem boas praticas dedesenho e clarificar a arquitectura de uma framework, os padroes de desenho sao uma formanatural de documentar frameworks [Johnson 92].

E objectivo desta dissertacao recuperar os elementos de desenho de uma framework que lheincorporam flexibilidade (hot spots, meta-padroes e padroes de desenho) a diferentes nıveis deabstraccao, como forma de ajudar o utilizador da framework a compreender como esta funciona,e como a utilizar convenientemente.

1.4 Engenharia Reversa de Padroes em Arquitecturas Reuti-lizaveis

A recuperacao de desenho e uma doutrina da engenharia reversa, cujo objectivo e analisarum sistema de software existente e identificar ou descobrir os seus componentes constituintese respectivas relacoes por forma a extrair e (re)criar o desenho e abstraccoes daquele. Numprocesso inverso ao da engenharia tradicional, parte-se do codigo-fonte da aplicacao e obtem-se a arquitectura do sistema. No caso das frameworks, ou arquitecturas reutilizaveis, os seuscomponentes constituintes sao os padroes de desenho.

Esta dissertacao propoe uma abordagem de recuperacao de desenho que visa a identificacaodos padroes de desenho constantes de uma framework. Esta abordagem assenta num processosemi-automatico em passos sucessivos, produzindo informacao intermedia de relevancia para outilizador, realcando desde cedo as abstraccoes que imputam flexibilidade a framework, comosejam os hot spots, os meta-padroes e os padroes de desenho.

O processo adopta um modelo formal de meta-padroes, desenvolvido por [Tourwe 02]e adaptado ao problema, como base de representacao para os padroes de desenho. Estaformalizacao permite dar consistencia a abordagem e clareza no mapeamento dos conceitosabstractos.

Em suma, os objectivos do trabalho sao:

• Adoptar uma aproximacao baseada em meta-padroes, onde cada fase do processo derecuperacao de desenho produz informacao relevante e clara sobre as possıveis zonas deflexibilidade de um sistema de software orientado por objectos;

• Usar uma representacao de padroes de desenho baseada na sua composicao com meta-padroes. Deve ser generica o suficiente para se poder representar qualquer padrao dedesenho, ja descoberto ou por descobrir;

• Fornecer uma ferramenta de apoio que permita automatizar o processo de recuperacao dedesenho, que seja flexıvel, integravel, extensıvel e capaz de produzir resultados visuais aoutilizador.

1.5. Resultados esperados 5

1.5 Resultados esperados

Com este trabalho de investigacao pretende-se desenvolver uma ferramenta que implemente oprocesso de recuperacao de desenho e que seja caracterizada pelos seguintes aspectos:

• integravel num ambiente de desenvolvimento de software;

• flexıvel, por forma a permitir configurar e estender a sua base de conhecimento para abarcarnovas de definicoes de padroes de desenho e outra informacao relevante ao processo derecuperacao de desenho;

• interactiva ate um determinado nıvel, permitindo ao utilizador intervir e controlar oprocesso de recuperacao de desenho;

• geradora de informacao visual util, seja sob a forma textual ou grafica, para que o utilizadorpossa imediatamente aferir a utilidade dos resultados.

1.6 Organizacao da dissertacao

Esta dissertacao esta dividida em quatro partes. A primeira parte faz uma revisao bibliograficadas areas de investigacao e conceitos chave abordados (capıtulo 2). A segunda parte abordao problema da reutilizacao de frameworks, nomeadamente ao nıvel da perda de informacaode desenho e apresenta a abordagem proposta para o resolver (capıtulos 3 e 4). A terceiraparte apresenta a ferramenta que implementa a abordagem previamente referida e a suaexperimentacao recorrendo a um caso de estudo (capıtulos 5 e 6). Por fim, a quarta parteanalisa os resultados e apresenta as conclusoes do trabalho (capıtulo 7).

Capıtulo 2

Revisao Bibliografica

2.1 Engenharia Reversa

Uma das areas de investigacao abordada pelo trabalho constante desta dissertacao e a engenhariareversa. Nesta seccao, da-se uma definicao do conceito, quais os seus objectivos e uma faz-seuma sıntese dos principais conceitos que a compoem.

2.1.1 Definicao

Entende-se por “Engenharia Reversa” o processo de analisar um sistema existente e identificar oudescobrir os seus componentes constituıntes e respectivas relacoes por forma a extrair e (re)criaro desenho e abstraccoes daquele. Esta definicao dada por Chifosky e Cross [Chikofsky 90]caracteriza de uma forma geral o conceito por detras da engenharia reversa.

Mas a origem do termo remonta a 1985, onde Rekoff [Rekoff Jr. 85] aplica a definicao deengenharia reversa nao ao software, mas ao hardware1. Nessa altura era pratica correntea extraccao do desenho de sistemas acabados, tanto para melhorar um produto como para“espiar” a concorrencia [Chikofsky 90]. Rekoff define a engenharia reversa como “o processode desenvolvimento de um conjunto de especificacoes para um sistema de hardware complexoatraves da analise complementada de implementacoes finais desse sistema”. Segundo o autor,este processo seria sempre conduzido por alguem que nao o futuro implementador do novosistema. Este papel teria de ser levado a cabo sem acesso aos planos iniciais do sistema (mesmoexistindo) com o proposito de criar uma copia do sistema original.

Transpondo esta definicao para o ambito do software, o processo revela-se similar mas comobjectivos diferentes. Igualmente se pretende ter nocao do desenho do sistema e como estefunciona, mas o objectivo nao e o de criar um sistema novo a imagem do anterior, mas sim ode obter informacao de alto nıvel que permita ajudar a manutencao, introducao de melhorias eeventual substituicao por um sistema melhor.

Nesta dissertacao pretende-se contribuir para o avanco da engenharia reversa no ambito dossistemas de software.

1Do ingles, significando equipamento informatico

7

8 2 Revisao Bibliografica

2.1.2 Objectivos

Em complemento a definicao formal de engenharia reversa, [Chikofsky 90] identifica seisobjectivos principais que a orientam a medida que a tecnologia evolui:

• Lidar com a complexidade. O desenvolvimento de metodos e formas de lidar com acrescente complexidade dos sistemas e cada vez mais uma necessidade, pelo que o controledeste factor atraves de ferramentas de automacao e um elemento chave. A combinacaode metodos e ferramentas de engenharia reversa permitira aos decisores a recuperacao eextraccao de informacao relevante para a eficiente monitorizacao e controlo do processoevolutivo do software;

• Gerar vistas alternativas. Apesar das representacoes graficas de informacao seremperfeitamente aceites como ajudas preciosas na compreensao de um sistema, a sua criacaoe manutencao continua morosa e geradora de entropia. Com a ajuda de ferramentasde engenharia reversa, rapidamente se podem gerar estas representacoes, converter entrevarias formas e ate gerar documentacao inexistente;

• Recuperar informacao perdida. A contınua evolucao e crescimento dos sistemas,especialmente os de maior longevidade, levam a perda de informacao relativa a arquitecturae desenho original do mesmo. Durante o processo de manutencao e normal efectuarem-se alteracoes a um nıvel de abstraccao acima do codigo-fonte que, muitas vezes, naosao devidamente registadas na documentacao. A engenharia reversa, em especial, arecuperacao de desenho, permite “resgatar” a informacao possıvel, perdida por entrealteracoes nao documentadas. Da mesma forma, permite adquirir melhorar a compreensaofuncionamento e proposito dos sistemas, sobretudo quando estes nao sao faceis de entender;

• Detectar ramificacoes. Erros iniciais de analise e constantes modificacoes no sistema podemlevar a que este se comporte de formas inesperadas e imprevistas. A engenharia reversapermite olhar para o sistema numa outra perspectiva, diferente daquele que se teria comum processo normal de engenharia (directa). Tal abordagem leva a deteccao previa deanomalias e discrepancias antes que estas sejam descobertas pelos utilizadores finais;

• Sintetizar abstraccoes de alto nıvel O processo de engenharia reversa permite a criacaode conceitos de alto nıvel de abstraccao. Apesar de se questionar o quao automatico esteprocesso podera ser, os sistemas periciais a volta desta tematica tem vindo a ganhar umpapel importante em potenciar a geracao destas abstraccoes;

• Facilitar a reutilizacao. A reutilizacao de software aplica-se em boa medida aoscomponentes e artefactos existentes. A engenharia reversa pode ser uma ajuda preciosana identificacao de componentes reutilizaveis presentes em sistemas existentes.

2.1.3 Principais Conceitos

Quando se fala em engenharia reversa, surge associado um conjunto de termos e conceitos quetorna dubio o que de facto a compoe. Para esclarecer o ambito da engenharia reversa e comoesta se relaciona com o desenvolvimento de software, ter-se-a de manter presentes tres conceitosindependentes:

2.1. Engenharia Reversa 9

Figura 2.1: Relacao entre os conceitos de engenharia reversa e as varias fases do processo dedesenvolvimento de software (extraıda de [Chikofsky 90].

• Processo faseado de desenvolvimento de software, seja ele em cascata [Sommerville 00] ouem espiral [Boehm 87]. O objectivo e que seja constituıdo por fases navegaveis, quer paramontante, quer para jusante do decorrer do processo;

• Sistema subjacente, seja um bloco de codigo ou um conjunto de programas que interagementre si. Normalmente, o sistema subjacente e o ponto de partida no processo engenhariareversa, em oposicao ao processo regular de engenharia,no qual o sistema e o resultadofinal da aplicacao do mesmo;

• Nıveis de Abstraccao. Ao longo do processo de desenvolvimento de software, o nıvel deabstraccao dos conceitos vai-se refinando e tornando-se mais concreto. Nas etapas iniciais,lida-se com conceitos gerais e independentes da implementacao, ao passo que nas etapasfinais o enfase vai para os detalhes de implementacao.

Em [Chikofsky 90], o processo de desenvolvimento e dividido em tres etapas para simplificaro posicionamento de cada uma dos conceitos anteriores associadas a engenharia reversa. Cadauma destas etapas tem, claramente, nıveis de abstraccao distintos:

1. Requisitos. Fase de especificacao dos varios requisitos do sistema (funcionais e naofuncionais). Analise do problema.

2. Desenho. Especificacao da arquitectura e desenho da solucao a desenvolver para solucionaro problema.

3. Implementacao. Escrita de codigo, testes e entrega do sistema desenvolvido.

Tendo estas nocoes em consideracao, e possıvel elaborar um pouco cada um dos conceitospresentes, e assim definir melhor o que e a engenharia reversa:


Engenharia “Directa”

Neste contexto entende-se por engenharia directa, o processo normal de desenvolvimento desoftware que parte de um nıvel de abstraccao alto e generico, evoluindo progressivamente para umnıvel mais baixo e detalhado. Parte-se de um entendimento dos conceitos gerais e independentesda implementacao, atravessando sucessivamente as varias etapas do processo ate atingir umdetalhe mais proximo da implementacao fısica do sistema. O proposito de lhe chamar directaprende-se apenas com o facto de se distinguir da reversa.

Engenharia Reversa

Como ja foi referido anteriormente, o processo de engenharia reversa tem como objectivo aanalise de um sistema existente com os seguintes propositos:

1. Identificar os elementos que compoem o sistema e as suas respectivas interrelacoes.

2. Criar uma representacao alternativa do sistema a um nıvel de abstraccao superior.

O processo de engenharia reversa pode comecar em qualquer etapa do processo dedesenvolvimento de software, independentemente do nıvel de abstraccao em que se encontre,e abranger as restantes fases. Este e um processo de analise e nao de re-criacao ou duplicacaodo sistema existente e que, normalmente, envolve a extraccao de conceitos ligados ao desenhodo sistema podendo mesmo descobrir quais os requisitos por detras do mesmo. Ao contrario doprocesso de engenharia directa, a engenharia reversa move-se no sentido contrario, partindo doparticular para o geral, ou seja, da implementacao para o desenho.

Das varias areas existentes dentro da propria engenharia reversa, a Redocumentacao e aRecuperacao de Desenho sao as duas mais conhecidas e referenciadas [Chikofsky 90], pelo quemerecem aqui uma atencao especial.

Redocumentacao

Segundo [Chikofsky 90], redocumentacao e o processo de rever e (re)criar a representacaosemanticamente equivalente num mesmo nıvel de abstraccao. Basicamente, esta-se perante umatarefa para criar formas alternativas de visualizar ou representar a informacao relativa ao sistema,que facilite a comunicacao e compreensao do mesmo. Exemplos como uma listagem melhorada docodigo, diagramas de arquitectura derivados deste, esquemas de controlo de fluxo e interligacaodos componentes sao os mais encontrados em ferramentas de redocumentacao. Considera-se estacomo a pratica mais simples e nao-intrusiva de engenharia reversa, cujo proposito passa apenaspor restruturar ou recuperar documentacao existente ou que deveria ter existido.

Recuperacao do Desenho

Segundo Biggerstaff [Biggerstaff 89], a recuperacao de desenho consiste em recriar ou redescobrirconceitos abstractos e genericos do sistema a partir de uma combinacao de varias fontes deinformacao, nomeadamente, codigo-fonte, documentacao existente, experiencia pessoal, e nocoesgerais do ambito do problema e domınio da aplicacao.

2.1. Engenharia Reversa 11

Este processo deve produzir toda a informacao necessaria, com elementos formais e informais,para que uma pessoa possa compreender o que o sistema faz, como funciona, o seu proposito eos seus objectivos. Tal abrangencia faz com que se tenha de lidar com informacao existente forado processo normal de desenvolvimento de software. A necessidade de compreender o sistemae crucial em tarefas ligadas ao desenvolvimento de software tais como a manutencao, melhoriae reutilizacao do mesmo, a construcao de um novo sistema similar e ate para a formacao deutilizadores.

Reestruturacao

O conceito de reestruturacao remonta a 1989, em que Arnold [Arnold 89] o define como a tarefade modificar o software no sentido de o tornar mais legıvel, compreensıvel e pronto a abarcaralteracoes derivadas de manutencao, actualizacao ou evolucao. As transformacoes ocorremdentro do mesmo nıvel de abstraccao, preservando o comportamento externo do sistema, ou seja,as suas funcionalidades e semantica [Chikofsky 90]. Neste contexto, o “software” abarca quero codigo-fonte, quer a documentacao associada. Estas modificacoes nao pretendem introduzirnovas funcionalidades, mas simplesmente mudar a forma e a representacao do software existente:mudar o “como”, sem mudar o “que”. A nova forma pretende suscitar modificacoes a introduzirno software que podem melhorar a sua qualidade e funcionamento [Kang 99].

Entre as formas de reestruturacao mais conhecidas temos a melhoria do estilo do codigo-fontee respectiva documentacao, a transformacao de componentes do programa (renomear variaveis,mover expressoes, abstrair funcionalidades, etc.) e a melhoria de estruturas funcionais atravesda modularizacao e recontextualizacao de componentes existentes.

Mais recentemente o termo refactoring foi introduzido por Opdyke [Opdyke 92] no contextoda aplicacao da reestruturacao ao software orientado por objectos. No fundo, nao e maisdo que uma variante “orientada por objectos” da reestruturacao, a que Fowler [Fowler 99] acaracteriza como o processo de modificar software [orientado por objectos] de tal forma que oseu comportamento externo permaneca inalterado, enquanto se melhora a sua estrutura interna.A ideia e aplicar as mesmas praticas da reestruturacao mas desta vez a estruturas e conceitosproprios dos sistemas de software orientado por objectos (classes, atributos, metodos, hierarquia,encapsulamento, polimorfismo, etc).

Em suma, reduzindo o alto nıvel de complexidade pelo qual o software e muitas vezescaracterizado, esta tecnica contribui para um aumento da qualidade do software produzido,garantindo ganhos na manutencao do mesmo [Mens 04].

Reengenharia

A reengenharia consiste no processo de criar uma descricao abstracta do sistema existente,analisar quais as mudancas pelo qual este tem de passar e voltar a re-implementar aquele segundoa nova forma [Jacobson 91]. Todo este processo contribui para uma melhor compreensao dosoftware e prepara o mesmo para melhorias ao nıvel da facilidade de manutencao, reutilizacao eposterior evolucao [Arnold 93].

Analisando em mais detalhe, pode-se dividir o processo de reengenharia em duas fases: aprimeira consiste num exercıcio de engenharia reversa, onde se parte de um nıvel de abstraccaobaixo, atingindo posteriormente um nıvel de abstraccao alto; a segunda faz com que se voltenovamente ao nıvel de abstraccao baixo atraves das transformacoes tidas como necessarias,


nitidamente num processo de engenharia directa. Em suma, a reengenharia consiste na somade tres parcelas: engenharia reversa, engenharia directa e um conjunto de transformacoes[Jacobson 91][Chikofsky 90][Philip 95].

Confundem-se muitas vezes as definicoes entre reengenharia e reestruturacao. Apesar desimilares, a diferenca principal esta no facto de que na segunda, nao existe o acrescentode funcionalidades ao sistema existente, enquanto que na primeira e possıvel ocorrer odesenvolvimento de novas funcionalidades, se a analise intermedia decidir que e preciso actuarao nıvel dos requisitos do proprio sistema.

2.2 Reutilizacao de Software

A reutilizacao de software e uma area de investigacao em plena expansao, tendo havido umcrescimento acentuado de contribuicoes de alguns anos para ca. A necessidade de responder, deuma forma cada vez mais rapida, as crescentes necessidades do mercado leva a que se descubramnovas tecnicas de acelerar o processo de desenvolvimento de software. Aproveitar softwarepreviamente desenvolvido, faz com que se poupe tempo, desde que tal seja viavel. O trabalhoconstante desta dissertacao aborda conceitos bem no centro desta tematica.

2.2.1 Definicao, Princıpios e Objectivos

Durante o processo de desenvolvimento de software, o engenheiro debate-se com os mesmosproblemas de uma forma recorrente, resolvendo-os vezes sem conta. O objectivo da reutilizacaode software e acabar com este ciclo repetitivo de resolver problemas que ja foram anteriormenteresolvidos. Por definicao, a reutilizacao de software consiste...

Na construcao de um novo sistema, utilizando componentes previamentedesenvolvidos sem a necessidade de os construir de raız e que resolvem os problemasrecorrentes em questao [Krueger 92][Smolarova 97].

Para tal, e preciso um esforco extra para identificar, extrair, organizar e representar estainformacao reutilizavel, de uma forma que seja facil de compreender e utilizar. Por forma a serreutilizavel, um componente de software tem de ser desenhado, documentado e implementadocom esse objectivo, para alem de escrito e armazenado por forma a permitir a sua facilcompreensao, indexacao e obtencao [Tracz 88][Tracz 94]. Esta tarefa pode, por vezes, ser maismorosa do que desenvolver um novo sistema de raiz. No entanto, no posterior desenvolvimentorepetitivo de sistemas com requisitos comuns ou similares, esta abordagem torna-se bastantevantajosa.

O conceito de reutilizacao de software surgiu pela primeira vez em 1968, numa conferenciasobre engenharia de software organizada pela OTAN2. A conferencia abordava o tema “SoftwareCrisis”, ou seja, a problematica associada ao desenvolvimento de sistemas de grande dimensaonum ambiente controlado de qualidade e custos inerentes. Nessa conferencia, McIlroy[McIlroy 68] propos uma biblioteca de componentes reutilizaveis e automatismos para configuraresses componentes com diferentes graus de precisao e robustez. Acreditava que estas bibliotecaspoderiam ser usadas eficazmente na computacao numerica, conversao I/O, processamento de

2Organizacao do Tratado do Atlantico Norte

2.2. Reutilizacao de Software 13

texto e alocacao dinamica de memoria. Esta nocao de construir sistemas complexos a partirde blocos de construcao disponıveis em catalogos de componentes reutilizaveis foi o ponto departida para a nocao de reutilizacao de software.

Desde entao o conceito de reutilizacao de software alargou o seu ambito, introduzindo-semais tarde a nocao de artefacto reutilizavel, como sendo todo e qualquer pedaco de informacaoconstante de uma biblioteca de componentes reutilizaveis [Steyaert 96][Seidewitz 93]. Desde adocumentacao e especificacoes da arquitectura do sistema ate ao codigo-fonte e baterias de testes,tudo o que fosse relevante do ponto de vista da reutilizacao era considerado uma mais-valia. Noseu sentido mais lato, a reutilizacao de software envolve a organizacao e encapsulamento deexperiencia, i.e., conhecimento ganho ao longo do processo de desenvolvimento de software, e ainstituicao e concretizacao de todos os mecanismos e estruturas organizacionais que a suportame apoiam.[Smolarova 97].

2.2.2 Pre-requisitos

As caracterısticas que um sistema de software deve possuir para que se considere (num estado)proprio para a reutilizacao, nao sao sempre faceis de alcancar. Segundo [Mili 95], o softwaredeve ser:

• util, ou seja, responder a necessidades comuns;

• (re)utilizavel, ou seja, estar em conformidade com padroes de qualidade, simples osuficiente para ser compreendido e utilizado por novos programadores.

[Karlsson 95] vai mais longe e define mesmo 5 factores qualitativos para classificar o quaopropenso a reutilizacao pode estar um artefacto de software:

• Adaptabilidade. Qual a facilidade com que um componente pode ser adaptado parapreencher um requisito ou funcao diferentes daqueles para os quais foi inicialmenteconstruıdo? Muitas vezes referido tambem como flexibilidade, este factor pode serdivido em modularidade (a possibilidade de sub-dividir a solucao em funcoes dijuntas)e generalidade (o grau de independencia do componente do restante sistema);

• Compreensibilidade. Este factor contabiliza as caracterısticas que o software detem e queinfluenciam o esforco do utilizador em reconhecer o conceito inerente e a sua aplicabilidade;

• Portabilidade. A facilidade com que o software migra entre sistemas operativos diferentese ambientes computacionais distintos. O quao independente e o software do ambiente emque e utilizado;

• Confianca. A probabilidade de falhas (i.e. o sistema comportar-se de acordo com oesperado) que o software pode apresentar num ambiente diferente daquele para o qualfoi construıdo e testado;

• Qualidade. De uma forma geral o software tera de ter qualidade, dividindo-se este pontoem dois sub-factores principais: eficacia, ou seja, se o sistema e eficaz nas funcoes para oqual foi desenvolvido, e facilidade de manutencao, ou seja, qual o esforco para manter osoftware produzido, na resposta a novas necessidades.


2.2.3 Potencialidades

E aceite pela comunidade que a pratica de reutilizar software tem o potencial de melhorar oprocesso de desenvolvimento. Os benefıcios sao, na sua maior parte, de natureza economica epodem-se categorizar da seguinte forma:

• Aumento da produtividade. Com a reutilizacao de software observa-se uma diminuicao dotempo de producao e custos associados, visto nao ser necessario construir todo o sistemade raiz;

• Aumento da qualidade. A reutilizacao de componentes previamente desenvolvidos etestados leva a que estes tenham menos erros quando comparados com componentescompletamente novos, aumentando a qualidade do produto final. Consequentemente, ocusto de manutencao dos mesmos sera mais baixo.

2.2.4 Restricoes

No entanto, existem factores restritivos ao sucesso da reutilizacao de software. Uma analisepor varios autores, entre os quais nao ha um consenso sobre aqueles que mais significativamenteafectam a reutilizacao de software, identifica um conjunto de razoes de ındole nao-tecnica e outrode ındole tecnica [Prieto-Dıaz 91][Prieto-Dıaz 93][Tracz 95]. No primeiro, pode-se incluir:

• Factores economicos. Devido ao esforco extra necessario para acomodar a reutilizacao desoftware, terao de ser desenvolvidos e validados modelos que mecam o custo e retorno doinvestimento efectuado;

• Factores organizacionais. Deve-se atentar a forma como os artefactos reutilizaveis saodistruibuıdos, pesquisados e disponibilizados. Um bom componente reutilizavel e inutil seninguem o conhecer, se demorar muito tempo a ser obtido ou se e demasiado caro paraadquirir;

• Factores educacionais. Ter-se-a de dispender recursos para formar e treinar as equipasde desenvolvimento, nao so na construcao de software reutilizavel, mas tambem nodesenvolvimento de software a partir de outro ja existente;

• Factores psicologicos. Tera de haver confianca nos componentes existentes. A aceitacaoda reutilizacao de software por parte dos utilizadores derrapa no chamado sındroma do“Nao Inventado Aqui”;

• Factores de gestao. As estruturas de gestao existentes nao se adequam a realidade dareutilizacao de software. A definicao de novos papeis e funcoes e o seu preenchimento porquadros adequados e de importancia vital.

Ha cerca de uma decada atras, as razoes de ındole tecnica mais importantes eram as seguintes[Smolarova 97]:

• Falta de maturidade do processo de desenvolvimento de software como uma disciplina deengenharia:

– E necessaria uma maior normalizacao na representacao de componentes reutilizaveis;


– Facilitar o acesso a mais arquitecturas reutilizaveis.

• Falta de bibliotecas de componentes reutilizaveis em que o suporte a obtencao dessescomponentes seja aceitavel;

• Falta de metodologias que incorporem a reutilizacao como uma pratica corrente dedesenvolvimento de software;

• Falta de ferramentas de apoio a reutilizacao de software.

Desde essa altura ate agora, tem-se vindo a verificar uma reducao destes factores[Schmidt 99], em grande medida devido a:

• Disponibilizacao de tecnologias de desenvolvimento que assentam em bibliotecas decomponentes e arquitecturas reutilizaveis, como sejam a CORBA [Group 05], J2EE[Microsystems 05] e .NET [Corporation 05];

• Um cada vez maior numero de projectos assenta o seu desenvolvimento no paradigma deorientacao por objectos, quer a nıvel de desenho (UML e padroes de desenho[Gamma 95]),quer a nıvel de implementacao, adoptando linguagens orientadas por objectos (C++, Java,C#);

• O aparecimento de metodologias leves e ageis [Cockburn 01] que fomentam e abarcamo uso explıcito, senao intensivo, da reutilizacao de software. O Extreme Programming[Beck 99] e um dos exemplos mais populares.

Estas medidas sao particularmente evidentes em mercados onde o curto tempo dedesenvolvimento e crucial para o sucesso do negocio, como o comercio electronico e as redesde dados.

Uma outra lacuna no campo da reutilizacao de software e a falta de terminologia comum.Nao existe uma definicao formal de reutilizacao de software, pelo que varios autores tentaramdar o seu entendimento sobre o conceito, muitas vezes sem chegar a uma definicao sequer.Esta diversidade levou ao estabelecimento de varias correntes de pensamento divergentesrelativamente a reutilizacao de software, pelo que [Dusink 95], juntamente com [Prieto-Dıaz 93]dividem-nas em seis vertentes:

• Geracao vs Composicao. No primeiro, a reutilizacao obtem-se atraves de transformacoesa partir da definicao alto-nıvel do sistema pretendido. No segundo, efectua-se umacombinacao de componentes existentes, normalmente por um engenheiro de software;

• Caixa preta vs caixa branca. No primeiro, os componentes reutilizaveis sao utilizadose combinados sem modificar o seu conteudo (as-is), enquanto que no segundo, oscomponentes sao modificados e adaptados ao sistema pretendido;

• Nıvel de Abstraccao. A reutilizacao pode ser aplicada a varios nıveis de abstraccao:desenho, codigo, testes, requisitos, etc. A maior parte abrange apenas os dois primeiros;

• Produto vs Processo. Que tipo de conhecimento e reutilizado? Apenas o produto final oua forma como o mesmo produto foi desenvolvido?


• Desenvolvimento de componentes reutilizaveis vs aplicacao da reutilizacao. Ate que pontoa preocupacao com o desenvolvimento de objectos que fomentem e facilitem a reutilizacaoira, no futuro, ter resultados e aplicabilidade pratica visıvel?

• Vertical vs Horizontal. No primeiro, reutiliza dentro do mesmo domınio de aplicacao,enquanto que no segundo partilham-se componentes entre varias areas aplicacionais.

E difuso classificar a pratica da reutilizacao de software, pelo que um enquadramento nao-ambıguo seria difıcil, senao impossıvel. Poder-se-a pesar a presenca de cada uma destas vertentese descrever pontualmente cada caso de reutilizacao de software.

2.2.5 Tecnicas de Reutilizacao de Software

Olhando para o processo de desenvolvimento de software como um conjunto de passos e fases,no qual se parte de uma especificacao relativamente informal e se chega a obtencao de codigoexecutavel, atraves de sucessivas transicoes entre nıveis de abstraccao (do mais alto para o maisbaixo), podemos dividir as tecnicas de reutilizacao de software em dois grandes grupos: tecnicasde geracao e tecnicas de composicao.

Tecnicas de geracao

Estas tecnicas permitem reutilizar as sucessivas transformacoes aplicadas as descricoes formaisdos problemas a resolver, ou seja, os requisitos, para gerar as aplicacoes. Dentro destaabordagem, podem-se identificar tres grandes vertentes:

• Sistemas baseados em linguagens formais. Estes sistemas usam modelos matematicos,como, por exemplo, teoria de conjuntos ou equacoes com restricoes que modelam padroesreutilizaveis numa linguagem de alto-nıvel. Sao tambem conhecidos como linguagens deespecificacao executaveis ou linguagens de muito alto nıvel (Very-High Level Languages -VHLLs);

• Geradores aplicacionais. Estes geradores automatizam todo o processo de desenvolvimentonum dominio de aplicacao bastante restrito. Trata-se de uma ferramenta que parte deespecificacoes alto-nıvel dentro do domınio restrito da aplicacao e produz codigo executavel.A construcao e adopcao desta aproximacao requer um denso conhecimento do domınio daaplicacao, em que este tem de ser curto, compreensıvel e de uma tecnologia pouco evolutiva.Identificar o domınio concreto, as suas fronteiras, ambito e modelo computacional, bemcomo a linguagem de definicao das especificacoes e quais os produtos esperados comoresultado tornam difıcil compor um gerador aplicacional;

• Sistemas obtidos por transformacao. Estes sistemas nao automatizam completamente todoo processo de desenvolvimento de software, pois precisam de intervencao do engenheirode software na escolha de quais transformacoes operar. E o que se pode chamar deprocesso semi-automatizado, o qual se divide em duas fases: primeiro, toda a semanticada aplicacao e especificada atraves de uma linguagem, e seguidamente sao aplicadas sobreela as respectivas transformacoes.


Tecnicas de composicao

Esta e a forma mais comum de reutilizar software. O objectivo principal e a reutilizacao decomponentes de software previamente desenvolvidos, usando-os como os principais constituintesdo sistema a desenvolver. Esta aproximacao e bastante directa, pelo que involve artefactosbastante concretos, sejam codigo-fonte, subsistemas, testes e respectivos dados, documentacao,elementos de desenho, arquitectura, etc. No entanto, existem alguns aspectos a ter em conta naaplicacao destas tecnicas, para que possam ser utilizadas de forma conveniente:

Identificacao de componentes reutilizaveis. O primeiro passo para a eficaz e sistematicareutilizacao de software consiste na identificacao dos seus componentes reutilizaveis [Prieto-Dıaz 93].Prever oportunidades de reutilizacao e uma tarefa difıcil e que requer experiencia e conhecimentodo domınio do problema. Nao existe ainda uma definicao de como deve ser um componentereutilizavel e como o identificar, no entanto, este processo deve ser progressivo e incremental.Entre os aspectos a ter em conta na identificacao de componentes reutilizaveis, destacam-se:

• Granularidade. A dimensao do componente requer um compromisso entre quantidadee complexidade. Quanto maior for o componente, mais funcionalidades poderao serreutilizaveis, no entanto, tambem maior sera a sua complexidade, o que o tornara maisdifıcil de reutilizar;

• Categoria. Um componente reutilizavel pode ser um qualquer artefacto produzido numadas varias fases do processo de desenvolvimento (codigo-fonte, desenho, requisitos, testes,documentacao). Quanto maior o nıvel de abstraccao, maior o seu poder de reutilizacao;

• Generalidade. Apesar de componentes mais genericos (independentes da aplicacao)poderem ser frequentemente mais utilizados num ambito alargado de domınios, a suageneralidade torna-os mais difıceis de reutilizar.

Descricao dos componentes . A descricao dos componentes ajuda na compreensao das suasfuncionalidades. Uma boa descricao deve clarificar o que o componente faz sem saber como ofaz. Alem de abstracta, a descricao deve estar desprovida de ambiguidades e ser clara, concisae facil de entender. Igualmente, deve permitir a descricao de uma variedade de componentes[Weide 91] [Rich 89]. Existe trabalho de investigacao no sentido de definir um modelo formalpara a descricao de componentes [Edwards 92] ou mesmo uma linguagem descritiva que consigacapturar os atributos essenciais dos componentes reutilizaveis [Whittle 95].

Obtencao de componentes reutilizaveis. Quando agregados (para mais facil distribuicao)em vastas bibliotecas de componentes, torna-se relevante organiza-las por forma a que sejafacil a obtencao de um componente especıfico. Formas e metodos para obter os componentesdevem constar destas bibliotecas e podem basear-se em varias aproximacoes, nomeadamente[Frakes 94]:

• Ciencia da Informacao. As obtencao e feita optando por duas vertentes: usando umvocabulario restrito e controlado, classificando previamente os componentes segundo asua semantica, com a desvantagem de poderem originar diferentes interpretacoes entrereutilizadores; usando pesquisa de texto livre em linguagem natural, mais facil de pesquisar


(sem restricoes de vocabulario), em contraste com a falta de precisao trazida pelaambiguidade e inconsistencia inerentes a linguagem natural;

• Base de conhecimento. A construcao da biblioteca e complementada com uma base deconhecimento sobre os seus componentes constituintes que permite a execucao de pesquisasformais sobre aquela. Esta aproximacao obriga a um maior dispendio de recursos mas, emcompensacao, o resultado e mais facil de pesquisar e reutilizar;

• Hipertexto. Os componentes sao organizados numa rede de nodos, ligados (navegaveis)atraves de hiperligacoes. A pesquisa faz-se navegando no grafo de componentes. Esteconceito de ”navegacao”e facil de usar e rapido de navegar para o componente pretendido.No entanto, obriga a um estudo extensivo do domınio da aplicacao para encontrar a melhorforma de relacionar os componentes, bem como dificulta o acrescento de novos;

• Especificacao. Os componentes sao descritos atraves da sua especificacao formal, sendoesta a base da sua organizacao na biblioteca. As limitacoes prendem-se com a forma comoo potencial da propria linguagem de especificacao e explorado. A descricao do componentepode ir desde a sua assinatura (interface) ate a propria semantica da sua especificacao.

Nao existe consenso sobre qual dos metodos de obtencao e o mais adequado. A conclusaoe que apenas um metodo nao e suficiente para encontrar todos os componentes que sejamrelevantes para uma determinada pesquisa. As preferencias variam de utilizador para utilizador,assim como o sucesso e precisao na pesquisa dos mesmos, cuja discrepancia nao tem relevanciapara a escolha de um metodo em detrimento do outro. Apenas a registar que, a nıvel de temposde execucao, os metodos mais formalizantes e restritos a nıvel de classificacao dos componentesganham aos restantes [Frakes 94].

Adaptacao de componentes a necessidades especıficas . Uma das caracterısticas maisimportantes de um componente reutilizavel e a sua generalidade, ou seja, a possibilidadede este ser aplicado numa variedade de situacoes. Para tal, o componente tem depermitir a sua extensao ou configurabilidade por forma a poder adaptar-se a situacaoparticular[Krueger 92][Karlsson 95][Fayad 99]. Esta adaptacao ou especializacao pode ser feitade diversas maneiras:

• Submissao de parametros. Os componentes foram construidos de tal forma que asubmissao de determinados parametros permite configurar o funcionamento esperado doscomponentes;

• Heranca. No paradigma da orientacao por objectos, este mecanismo permite configurarcomportamento do componente atraves da extensao e redefinicao dos seus metodosconstituintes. Este mecanismo nao e intrusivo para o componente;

• Modificacao interna. Esta aproximacao e intrusiva e consiste em modificar o codigo-fontedo proprio componente (white-box reuse), obrigando a uma compreensao exaustiva detodos os detalhes de implementacao do mesmo. E alta a probabilidade de interferir nacorrecta execucao do proposito do componente.

2.3. Arquitectura de Software Orientada por Objectos 19

Integracao de componentes em sistemas em desenvolvimento . A eficacia com que sereutilizam componentes depende em grande parte da forma como estes se combinam. A correctaintegracao entre os varios componentes obriga a que se entenda convenientemente a relacao entreeles. Os diversos estilos de integracao entre componentes, sejam estes funcoes, classes, modulosou processos, condicionam o sucesso da sua reutilizacao e estipulam a sua aplicabilidade. Osestilos variam desde liguagens de interoperabilidade entre modulos a frameworks aplicacionais earquitecturas de software [Whittle 95, Krueger 92, Garlan 93].

Escolher qual a tecnica que mais se adequa ao projecto em maos e, frequentemente, umatarefa difıcil, dependendo em grande parte da especificidade daquele.

Segundo [Aguiar 03b], a tecnica de reutilizacao ideal sera aquela que proporciona uma rapidaobtencao dos componentes que se adequam perfeitamente as necessidades, prontos a usar semconfiguracao adicional ou tempo de aprendizagem. Ao recorrer as abstraccoes inerentes astecnicas de reutilizacao, um reutilizador de software ve-se, muitas vezes, limitado na sua formade raciocinar sobre os conceitos concretos onde aplicar as tecnicas.

Por conseguinte, quanto menor a distancia cognitiva [Krueger 92] entre o raciocınio informale os conceitos abstractos da tecnica em questao, melhor a sua aplicabilidade. Descricoes dosartefactos reutilizaveis, que os caracterizem como abstraccoes de alto nıvel de uma forma naturale sucinta, focadas mais ”no que este faz”, do que ”como o faz”sao muito importantes para umaeficaz reutilizacao de software. A reutilizacao de arquitecturas de software, como tecnica decomposicao, sera talvez a que mais se aproxima deste ideal.

2.3 Arquitectura de Software Orientada por Objectos

O paradigma da orientacao por objectos esta vincadamente implantado nas metodologias dedesenvolvimento de software actuais. Com o aumento da envergadura dos sistemas e aplicacoesdesenvolvidos, a preocupacao com a sua estruturacao e desenho torna-se crescente e importantepara a sua sustentabilidade.

2.3.1 Enquadramento e Definicao

A tarefa de definir ou desenhar um sistema de software ocorre a diferentes nıveis. Segundo[Shaw 96], e possıvel identificar pelo menos tres nıveis de desenho de software:

1. Nıvel arquitectural, onde o desenho abarca a organizacao geral do sistema como umacomposicao de componentes, a definicao de estruturas globais de controle e a atribuicaode funcionalidades aos elementos de desenho.

2. Nıvel de codigo, onde se abordam questoes relacionadas com algoritmos e estruturas dedados.

3. Nıvel executavel, onde o foco vai para mapeamento de memoria, pilhas de execucao,alocacao de registos e operacoes codigo-maquina.

Com os sistemas de software em constante crescimento, quer em tamanho, quer emcomplexidade, os problemas de desenho mais importantes ja nao pertencem ao nıvel de codigo,


Figura 2.2: Nıveis de arquitectura de software orientado por objectos [Aguiar 03b].

mas sim ao nıvel arquitectural [Garlan 93]. A arquitectura de software lida com o desenho dosistema de software a este nıvel. Este campo emergente de investigacao surge como resposta ascrescentes necessidades de evidenciar semelhancas arquitecturais em varios sistemas, fazer boasescolhas entre alternativas de desenho e descrever conceitos de alto nıvel em sistemas complexos.

O principal objectivo da arquitectura de software esta em definir e desenhar a estruturaglobal do sistema e nao entrar em detalhe relativamente ao conteudo e implementacao doscomponentes individuais que a constituem e que lhe darao existencia. De uma forma abstracta,a arquitectura de software descreve os componentes que compoem o sistema e a forma comoestes interagem (normalmente referidos como os conectores). Podera igualmente descrever quaisas regras e mecanismos que ditam a composicao dos componentes, bem como restricoes quepossam a condicionar.

Componentes ao nıvel arquitectural podem ser elementos como clientes, servidores, basesde dados, filtros e camadas num sistema hierarquico. Os seus conectores podem variar entre asimples invocacao de procedimentos ate protocolos complexos (cliente-servidor, acesso a base dedados, geracao de eventos e pipes) [Aguiar 03b].

2.3.2 Nıveis Arquitecturais

A arquitectura de software orientada por objectos foca essencialmente os sistemas orientados porobjectos, ou seja, aqueles que tem, como elementos basicos de desenho, as classes e os objectos.No ambito da sua arquitectura, identificam-se quatro nıveis de granularidade para descrever umsistema orientado por objectos: o nıvel das classes, o nıvel dos padroes (ou micro-arquitecturas),o nıvel das frameworks (ou macro-arquitecturas) e o nıvel dos componentes (ver figura 2.3.2).

2.3. Arquitectura de Software Orientada por Objectos 21

Classes

No seu nıvel mais baixo de granularidade, um sistema e desenhado como um conjunto declasses, cujas instancias cooperam para implementar um determinado comportamento, complexoo suficiente para ser impossıvel de conseguir apenas com uma classe.

Uma classe representa um conceito ou entidade bem definidos, de um determinado domınio.Um objecto e uma instancia ou concretizacao dessa classe, tem um estado, exibe umcomportamento estabelecido e tem uma identidade unica. A estrutura e comportamento deobjectos similares sao definidos na sua classe comum. Enquanto um objecto e uma entidade desoftware concreta que existe no tempo e no espaco, uma classe representa apenas uma abstraccao,a essencia do objecto [Booch 94b].

Para sistemas de pequena dimensao, classes e objectos sao suficientes para descrever a suaarquitectura. No entanto, a medida que o sistema cresce, o numero de classes envolvidas naarquitectura aumenta, assim como a sua complexidade. A existencia de abstraccoes de maisalto nıvel ajudam a lidar com esta complexidade, apoiando o desenvolvimento e implementacaodo sistema.

Padroes

Subindo um nıvel de abstraccao, imediatamente a seguir ao nıvel das classes, pode-se usarpadroes para descrever as micro-arquitecturas de um sistema. Um padrao abstrai e identificaos aspectos essenciais de uma estrutura de desenho usada para resolver um problema recorrente[Gamma 95].

Os conceitos de padrao e linguagem de padroes foram introduzidos no ambito do softwareatraves da influencia do trabalho do arquitecto Christopher Alexander. O seu trabalho inclui umestudo exaustivo sobre os padroes encontrados na arquitectura de casas, edifıcios e comunidades[Alexander 77, Alexander 79].

Como especificam conceitos a um nıvel superior as classes e objectos, os padroes ajudam aabstrair o processo de desenho e a reduzir a complexidade do software. Existem varios tipos depadroes, classificados segundo a sua escala e nıvel de abstraccao, e que [Buschmann 96] descreveda seguinte forma (por ordem decrescente de abstraccao) :

• Padroes arquitecturais descrevem esquemas fundamentais para a organizacao estrutural desistemas de software. Muitos destes padroes de larga escala sao influenciados pelos estilosconceptuais descritos por [Shaw 96];

• Padroes de desenho sao padroes de media escala que descrevem os detalhes de estrutura ecomportamento de um conjunto de entidades, bem como a forma como se interrelacionam.Sem influenciar a estrutura global do sistema, estes padroes definem micro-arquitecturasde sub-sistemas ou componentes. Os mais conhecidos sao os constantes em [Gamma 95];

• Idiomas sao padroes de baixo nıvel de abstraccao que descrevem como implementaraspectos particulares de componentes ou relacoes usando a sıntaxe propria de umalinguagem de programacao especıfica. Exemplos destes padroes podem ser vistos em[Coplien 92] (C++) e [Beck 97] (Smalltalk).


Frameworks

Sistemas orientados por objectos com alguma envergadura sao geralmente compostos por umgrande numero de classes, alguns padroes e algumas camadas de frameworks que cooperam entresi. As frameworks permitem descrever um sistema num nıvel de abstraccao superior aos nıveisde classes e padroes.

Os conceitos de framework e padrao estao estreitamente relacionados, mas nenhum estasubordinado ao outro. As frameworks sao normalmente compostas por varios padroes dedesenho, sendo mais complexas que um unico padrao de desenho. No contexto destes, umaframework e por vezes definida como uma implementacao de uma coleccao de padroes de desenho.

Uma boa framework tem as suas fronteiras bem definidas, sobre as quais interage com osseus clientes de uma forma transparente, ou seja, a sua implementacao nao e visıvel do exterior.Apesar de terem um papel importante no desenvolvimento de sistemas de media e larga escala,mesmo estas tem um limite para lidar com altos nıveis de complexidade [Baumer 97].

Componentes

No mais alto nıvel de granularidade, um sistema pode ser descrito como um conjunto decomponentes de larga escala que cooperam para dar suporte a um conjunto de responsabilidades.Segundo [Szyperski 98], um componente e definido como ”uma unidade de composicao cominterfaces especificados contractualmente e dependencias de contexto explıcitas, [...] podendoser utilizados independentemente e sujeitos a composicao por terceiros”. Como exemplos decomponentes de larga escala existem os componentes de domınio, que sao coleccoes de classesque abrangem um domınio (ou parte deste) de aplicacao bem definido. Apesar de nem sempreser assim, no caso de sistemas orientados por objectos, estes componentes sao normalmenteconstruıdos a partir de uma ou mais frameworks orientadas por objectos.

Para o trabalho apresentado por esta dissertacao, as frameworks e os padroes de desenhodetem um papel bastante importante, pelo que ambos os conceitos sao abordados com maisdetalhe nas seccoes seguintes.

2.4 Frameworks Aplicacionais Orientadas por Objectos

Reutilizar software significa recorrer a artefactos previamente desenvolvidos e que se adequam,de alguma forma, aos novos requisitos do problema em maos. Para o engenheiro de software,quanto mais moldavel for o artefacto, mais facil e de se adaptar facilmente ao novo problema efornecer mais rapidamente uma solucao adequada. As frameworks fornecem esta possibilidade.

2.4.1 Definicao

Uma framework e uma arquitectura reutilizavel acrescida de uma implementacao. Consistenuma coleccao de classes cooperantes, quer abstractas quer concretas, as quais compoemuma arquitectura de alto-nıvel de abstraccao com vista a permitir implementar solucoes paraproblemas num domınio de aplicacao especıfico [Aguiar 03b, Fayad 99, Gamma 95, Pree 95].

2.4. Frameworks Aplicacionais Orientadas por Objectos 23

Mas uma framework e mais do que uma coleccao de classes, pois define a sua estruturaglobal, ou seja, a sua arquitectura. Uma framework estabelece a estrutura geral da aplicacao, oseu particionamento em classes e objectos, as responsabilidades a estas afectadas, a forma comocolaboram e o fluxo de controle. Em suma, dita a arquitectura das aplicacoes que com aquelasao construıdas, deixando espaco para redesenhar solucoes particulares.

Pela predefinicao de especificidades arquitecturais constantes no domınio de aplicacao, umaframework ajuda a manter as pedras basilares da arquitectura desde o inıcio do desenvolvimento,concentrando-se o engenheiro nos aspectos particulares da sua aplicacao.

Ao utilizar uma framework, nao se reutiliza so a analise e o desenho feitos sobre o dominioespecıfico, mas tambem uma implementacao. Pode-se construir uma aplicacao estendendo ouconfigurando apenas algumas partes da framework, reutilizando a implementacao existente dorestante, mantendo-se sempre a arquitectura original. Em sıntese, uma framework pode serdefinida como uma arquitectura e implementacao semi-completas para um conjunto de aplicacoesnum determinado domınio de problemas.

2.4.2 Vantagens e Desvantagens no Uso de Frameworks

Uma das principais vantagens no uso de frameworks advem do facto de que o nıvel de reutilizacaodo software, quer do codigo, quer do desenho, e muito superior ao possıvel noutras formasde reutilizacao, como sejam os geradores de codigo ou as bibliotecas de classes. Para alemdesta, outras vantagens provem da inversao do controlo da execucao, da modularidade e dapossibilidade de estender a sua implementacao [Fayad 99].

Em todas as fases do processo de desenvolvimento de software, o uso de frameworks trazvantagens. Durante a fase inicial de analise, o esforco para compreender e conhecer o dominio daaplicacao e mais reduzido, focando-se o interesse nos detalhes particulares do problema especıficoa resolver.

Mas e durante as fases de desenho, implementacao e testes que as frameworks trazem maisbenefıcios que as praticas tradicionais de desenvolvimento de software, sobretudo devido apossibilidade de reutilizacao de desenho e codigo e inversao do controlo de execucao:

• fornece uma arquitectura base para iniciar a construcao de uma aplicacao;

• permite aumentar a produtividade de desenvolvimento e a qualidade do codigo, poisdiminui a quantidade de codigo a desenhar e escrever;

• ao fornecer (encapsular) uma implementacao configuravel por detras de um interfaceestavel, aumenta a modularidade e melhora a compreensao das suas funcionalidades;

• promove o desenvolvimento de solucoes genericas, reutilizaveis num mesmo domınio deaplicacao;

• melhora a interoperabilidade e integracao com outros componentes devido a partilhar amesma arquitectura base.

Nas fases de manutencao e evolucao, a reutilizacao e extensibilidade das frameworksdiminuem o esforco de manter ou evoluir as aplicacoes, pois explicitam quais os pontos de


configurabilidade a manipular para que facilmente se possa alterar o seu comportamento, e porconseguinte, da aplicacao em si.

Generalizando, o uso de frameworks no desenvolvimento de aplicacoes provoca um aumentona productividade, qualidade e um mais curto time-to-market. No entanto, os ganhos nao saoimediatos, antes visıveis ao longo do tempo. Como os primeiros sinais de melhoria apenascomecam a aparecer apos varias utilizacoes da tecnologia, as frameworks podem-se considerarum investimento a medio-longo prazo.

Mas nem sempre e facil utilizar as frameworks. Empresas ou equipas de desenvolvimentoque queiram beneficiar das suas vantagens para desenvolvimento em larga escala, terao de lidarcom algumas questoes [Fayad 99]:

• Esforco de desenvolvimento. Se desenvolver software complexo e uma tarefa difıcil, fazercom que esse software seja de alta qualidade, reutilizavel e configuravel e ainda maisdifıcil. O know-how necessario para atingir estes objectivos concentra-se muitas vezesnalguns especialistas, sendo necessario disseminar esse conhecimento pela restante equipade desenvolvimento;

• Curva de aprendizagem. Aprender a utilizar convenientemente uma framework requeretempo e esforco, devido a sua complexidade. E necessario investir consideravelmente naformacao dos tecnicos, a qual, se nao for possıvel de amortizar ao longo de varios projectos,podera nao se tornar rentavel. Por outro lado, a aplicabilidade da framework ao domınioque se pretende podera apenas tornar-se visıvel apos algum tempo de aprendizagem;

• Capacidade de integracao. Cada vez mais o desenvolvimento de aplicacoes se baseiana integracao de multiplas frameworks, juntamente com bibliotecas de classes, sistemaslegados e outros componentes existentes. Muitas frameworks de primeira geracaoforam concebidas para extensao interna, e nao estao preparadas para integracao comoutras desenvolvidas externamente. E preciso lidar com questoes de integracao, desdedocumentacao a aspectos de concorrencia de processos e esquema de resposta a eventos;

• Capacidade de manutencao. Com a mudanca dos requisitos das aplicacoes, tambemmudam os requisitos das frameworks. As tarefas de manutencao de uma frameworkinvolvem modificacao e adaptacao da mesma as novas necessidades. Um entendimentoprofundo das especificidades, componentes e relacoes entre estes e de vital importanciapara a sua manutencao. Muitas vezes os utilizadores finais da framework contam apenascom os construtores daquela para realizar esta tarefa;

• Verificacao e validacao. Apesar da benefica contribuicao que as frameworks tem paraprevenir defeitos no codigo produzido, a tarefa de depurar uma aplicacao construıda apartir de uma framework, tal nao e uma contenda facil, em grande parte devido a doisfactores:

– Componentes genericos e abstractos sao mais difıceis de validar, pois tendem aafastar-se dos detalhes especıficos da aplicacao. Nao e possıvel isolar componentesgenericos da sua instanciacao especıfica e proceder a sua validacao. Por outro lado, edıficil distiguir entre erros na framework e erros na aplicacao. As possıveis fontes deerros aumentam sempre que se tenta configurar uma framework para uma aplicacaoparticular, seja atraves de uma interpretacao errada dos requisitos, um redesenho daarquitectura demasiado fechado ou uma implementacao errada;

2.5. Padroes de Desenho 25

– Inversao do controlo de execucao e fluxo de execucao pouco explıcito tornam difıcilproceder a tracagem do codigo, pois a execucao oscila entre o codigo da framework eo codigo da aplicacao. Muitas vezes, quem testa nao tem sequer acesso ao codigo daframework. A inversao do controlo de execucao de uma framework e tambem muitasvezes denominado por Hollywood Principle, em analogia com a expressao ”Don’t callus, we’ll call you” [Cotter 95].

• Eficiencia. A flexibilidade promovida pelas frameworks atraves da sua generalidade eextensibilidade tende a reduzir a sua eficiencia. Tecnicas como a alocacao dinamica(dynamic binding) de classes para implementar esta flexibilidade sao frequentementeusadas, mas impedem que outras tecnicas (como tipos concretos de dados, vitais parasistemas em tempo real) sejam aplicadas, afectando a eficiencia das aplicacoes;

• Falta de normas. Nao existe actualmente uma norma aceite que medeie o desenho,construcao e desenvolvimento de frameworks. Mais, frameworks recentes na industria(CORBA, DCOM, Java RMI) foram construıdas sem terem efectivamente capacidade deabranger mais do que um domınio de aplicacao. Outras surgiram mais capacitadas paraabranger varios domınios, mas ainda pecam pela falta de interoperabilidade com outrasframeworks.

As frameworks, porque sao poderosas e complexas, sao dıficeis de aprender a usar. Porconseguinte, e comparativamente a outros sistemas, e preciso dota-las de mais documentacaoadequada e requerem um maior tempo de formacao dos tecnicos. Mais, alem de dificeis deaprender a usar, sao tambem difıceis de desenvolver. Tal significa que gastam mais recursos adesenvolver do que uma aplicacao normal. Estas razoes levam a que as frameworks nao sejammais utilizadas do que o sao. No entanto, outras tecnicas de reutilizacao partilham dos mesmosproblemas. A reutilizacao de software tem as suas vantagens, mas tambem tem o seu preco.

Apesar das dificuldades, muitas frameworks tem tido um papel importante do desenvolvi-mento, quer industrial, quer academico, de software actual. Alguns exemplos de sucesso assen-tam em frameworks bem populares, tais como: CORBA, .NET, JAVA (RMI, AWT, SWING,J2EE), MFCs, diversas frameworks da Apache, Eclipse SDK.

2.5 Padroes de Desenho

A motivacao por detras dos padroes de desenho e a reutilizacao de software de qualidade a umnıvel intermedio de abstraccao. Segundo [Fayad 99], isso pode-se atingir de duas formas: (1)atraves da criacao de um catalogo de padroes de desenho, ao estilo de um manual de desenho desoftware, como inumeros problemas e solucoes correspondentes e (2) incorporando os padroes dedesenho numa linguagem que permite ao arquitecto de software pensar e idealizar o seu sistema.

2.5.1 O que sao Padroes de Desenho?

Segundo [Gamma 95], a nocao de padrao de desenho define-se da seguinte forma:

Um padrao de desenho sistematicamente nomeia, motiva e explica uma (micro)arquitectura generalista que responde a um problema recorrente em sistemasorientados por objectos. Descreve o problema, a solucao, quando a aplicar e as suas


Figura 2.3: Exemplo de um padrao de desenho: Composite (retirada de [Gamma 95]).

consequencias. Igualmente fornece dicas de implementacao e exemplos. A solucao ecomposta por um arranjo de classes e objectos que resolve o problema. A solucao econfigurada e implementada para resolver o problema num determinado contexto.

Um padrao de desenho captura a essencia de uma ideia que arquitectos experientes temusado vezes sem conta para resolver um problema comum. Como essa ideia e abstraıda de umasituacao especıfica, um padrao de desenho e independente do domınio da aplicacao e tera deser adaptado a situacao especıfica para ser implementado com classes concretas. Os padroesde desenho capturam solucoes de desenho comprovadamente boas para problemas comuns erecorrentes. Por conseguinte, o seu uso torna o desenvolvimento de software mais eficiente,reduzindo potencialmente o numero de iteracoes necessario para este atingir um estado dematuracao satisfatorio. Na figura 2.3 pode-se ver um exemplo de um padrao de desenho.

Como ja visto na seccao 2.3.2, os padroes de desenho encontram-se num nıvel intermedio deabstraccao, entre os padroes arquitecturais e os idiomas.

2.5.2 Vantagens e Desvantagens no Uso dos Padroes de Desenho.

Como ferramenta de apoio ao arquitecto de software, os padroes de desenho sao de extremautilidade para resolver problemas recorrentes. Por outro lado, sao largamente utilizados naconstrucao de frameworks. Em grande parte, tal deve-se ao seguinte [Tourwe 02]:

• Definem um vocabulario comum entre arquitectos. Usando os nomes dos padroes dedesenho, os arquitectos passam a dispor de uma metafora rapida para comunicar o desenhopresente num sistema ou framework, a um nıvel alto de abstraccao. A conversa com outrosarquitectos ou mesmo na documentacao, um padrao de desenho suprime a necessidade deentrar em detalhes de implementacao. Desta forma, e mais facil e simples para o arquitectopensar no desenho da aplicacao;

• Ajudam na identificacao de abstraccoes e nos objectos que as capturam. Como ja foivisto, o sucesso de uma framework assenta na sua capacidade de fornecer as abstraccoesapropriadas no(s) seu(s) domınio(s) de aplicacao para que estas sejam convenientementereutilizadas, ou seja, configuradas e adaptadas as situacoes especıficas. Identificar estas


abstraccoes, definir as classes que as representam e as respectivas relacoes entre elas naoe tarefa facil para quem desenvolve frameworks. Os padroes de desenho ajudam nestatarefa;

• Ajudam a determinar a correcta granularidade para objectos. Os objectos podemvariar quer em numero, quer em tamanho. Tanto entidades de baixo nıvel (variaveisindexadas, a.k.a., vectores) como entidades de alto nıvel (aplicacoes completas) podemser representadas por um objecto. E tarefa para quem desenvolve sistemas orientadospor objectos determinar qual a granularidade apropriada, onde os padroes de desenhosao ferramentas uteis. Estes auxiliam, descrevendo como representar subsistemas comoobjectos, como lidar com um grande numero de objectos de baixa granularidade,como decompor objectos noutros mais pequenos e como distribuir as responsabilidadesadequadamente;

• Ajudam na definicao de interfaces apropriadas. Quem desenvolve uma framework eresponsavel pela definicao de uma interface apropriada para cada objecto. Uma boainterface dota a framework de flexibilidade e fomenta a reutilizacao, pois objectos coma mesma interface podem ser substituıdos um pelo outro em tempo de execucao (latebinding). Os padroes de desenho ajudam na definicao destas interfaces, identificando quaisos elementos e informacao importantes que fluem atraves de uma interface. Igualmenteespecificam as relacoes entre as diferentes interfaces, obrigam classes a ter a mesmainterface ou restringem as interfaces de certas classes;

• Ajudam na especificacao da real implementacao dos objectos. Como exemplo, os padroes dedesenho explicam em que circusntancias a heranca de classes deve ser usada em deterimentoda heranca de interfaces. Promovem a programacao de uma interface em vez de umaimplementacao concreta das funcionalidades, fazendo com que uma framework se torneindependente dos objectos concretos que usa, reduzindo assim a dependencia para coma implementacao. Igualmente, os padroes de desenho realcam a importancia de outrosconceitos de orientacao por objectos como sejam a heranca, alocacao dinamica em tempode execucao (late binding) e o polimorfismo, bem como outras tecnicas como a composicaoe delegacao de objectos, tudo em prol de uma maior flexibilidade;

• Ajudam na implementacao de frameworks introduzindo flexibilidade. Cada padrao dedesenho permite que certos aspectos da framework possam variar independentemente deoutros, tornando-a mais robusta e propensa a tomar um determinado sentido particularde extensao e configuracao. Dito de outra forma, os padroes de desenho ajudam naimplementacao dos pontos de variabilidade (hot spots) da framework de uma forma flexıvele extensıvel. Desta forma, evitam-se futuras reestruturacoes da frameworks assegurando-seque esta evolui de uma forma predefinida e especıfica.

Por outro lado, os padroes de desenho tambem se caracterizam por introduzir algumasdesvantagens do desenvolvimento de software, senao vejamos:

• Introduzem complexidade. Os padroes de desenho implementam a sua flexibilidadeatraves da introducao de abstraccoes e indireccoes. Isto pode tornar o desenho difıcilde compreender a primeira vista, pois aquelas podem nao ser imediatamente obvias.Documentar cuidadosamente quais os padroes de desenho utilizados numa framework evital para uma clara compreensao da sua arquitectura, especialmente para utilizadorespouco experientes e pouco familiarizados com estes conceitos;


• Podem induzir um desenho exagerado (overdesign). Por forca da sua popularidade ealegados benefıcios, os arquitectos podem usar os padroes de desenho de uma formaexagerada, tentando desenhar toda a arquitectura recorrendo a eles. Em pontos onde aflexibilidade nao e tao importante, o uso de padroes de desenho pode tornar a arquitecturadesnecessariamente complexa. [Gamma 95] reconhece esta lacuna, afirmando que odesenho deve ser apenas flexıvel quanto necessario e nao tao flexıvel quanto possıvel;

• Podem afectar o desempenho. Devido a introducao de abstraccoes e ao seu teorabstracto, os padroes de desenho induzem uma implementacao que e muitas vezesmenos eficiente em termos de desempenho do que outras implementacoes mais directas[Tourwe 99, Schultz 00]. Questoes relacionadas com o desempenho sao ja um problemaabordado nas linguagens de programacao orientadas por objectos. Tecnicas como opolimorfismo e a alocacao de objectos em tempo de execucao levam a que os compiladoresnao possam aplicar optimizacoes tradicionais para melhorar o desempenho dos executaveis.[Chambers 92]. A introducao de mais flexibilidade com abstraccoes e indireccoes agravaainda mais esta situacao;

• Nao dispoem de uma base formal. O crescente numero de padroes de desenho quesao descobertos, aliado ao facto destes nao terem nenhuma base formal, torna difıcila tarefa de desenvolver ferramentas de apoio adequadas [Eden 00, Eden 99, Eden 96,Eden 98, Toufik 01]. Estas ferramentas sao necessarias para que se tire todo o partidodas vantagens que os padroes de desenho oferecem. Ferramentas de geracao automaticade codigo [Budinsky 96, Volder 99], reestruturacao de codigo para albergar padroes dedesenho [Tokuda 95], escolha do melhor padrao de desenho a aplicar numa determinadasituacao, entre outras, tornar-se-ao indispensaveis;

• Descoberta crescente torna diversidade incomportavel. Segundo [Agerbo 98], o vocabulariocomum definido pelos padroes de desenho comeca a tornar-se difıcil de gerir pela crescentedescoberta de novos padroes. Alem do mais, a descoberta de inumeros padroes de desenhoem varias domınios de aplicacao torna mais difıcil a identificacao de qual utilizar pararesolver um problema concreto. Este facto pode dissuadir o uso dos padroes de desenho.

2.5.3 Meta-padroes

O conceito de meta-padrao [Pree 95] surgiu como uma forma de descrever um padrao de desenhonum nıvel de abstraccao mais elevado. Um meta-padrao e uma abstraccao sobre os padroes dedesenho (um padrao dentro dos padroes de desenho) que os descreve tendo como base a suaestrutura, relacoes e colaboracoes.

Os conceitos base sobre os quais se definem os meta-padroes assentam numa analise dosmetodos que compoes as classes. Esses metodos podem ser de dois tipos: os templates e oshooks. Os templates sao metodos concretos que definem o fluxo de controlo de um determinadoalgoritmo e fornecem uma implementacao invocando outros metodos. Estes outros metodos saoos denomidados hooks, e podem ser metodos abstractos, metodos concretos que fornecem umaimplementacao, ou mesmo outros templates.

A distincao entre um template e um hook depende claramente do ponto de vista. Um metodom e um hook se for invocado por outro metodo, o template. Por sua vez, o metodo m podeinvocar outros metodos (hooks), tornando-se ele tambem um template.


Figura 2.4: Meta-padroes segundo [Pree 95].

Uma classe que contenha um metodo template denomina-se classe template e uma classeque contenha um metodo hook denomina-se classe hook. A ideia por detras da metaforatemplate/hook e que o metodo template na classe template invoca o metodo hook na classehook. Existe o caso em que os metodos template e hook estao na mesma classe, logo essa classepassa a ter os dois papeis em simultaneo.

As classes hook sao tipicamente abstractas pois contem os hooks, que podem ser abstractos.Por conseguinte, estas precisam de ser redefinidas (normalmente recorrendo a heranca) paradar uma implementacao concreta aos hooks. As classes template, visto ja conterem umaimplementacao, nao precisam de ser redefinidas.

Os meta-padroes definem um conjunto finito de combinacoes entre classes template e classeshook e caracterizam-se segundo dois aspectos [Tourwe 02]:

1. A cardinalidade da associacao entre a classe template e a classe hook. Um objecto daclasse template pode referenciar um ou mais objectos da classe hook.

2. A relacao hierarquica entre a classe template e a classe hook. A classe template e a classehook podem estar unificadas na mesma classe, ou relacionarem-se ou nao hierarquicamente.

No seu estudo sobre meta-padroes, [Pree 95] identificou sete meta-padroes existentes e quemapeam as combinacoes possıveis entre classes template e classes hook, como se pode ver nafigura 2.4.

Os meta-padroes sao bastante uteis na analise de estruturas de desenho ja existentes,nomeadamente, padroes de desenho. Enquanto que um padrao de desenho descreve uma solucao


Figura 2.5: Meta-padrao 1:1 Connection mapeado nos padroes de desenho State e Strategy.

para um problema num determinado contexto, um meta-padrao descreve os aspectos maistecnicos da estrutura dessa solucao, independentemente do contexto.

Um meta-padrao fornece uma visao mais abstracta de combinacao de classes (abstractcoupling) a solucao proposta por um padrao de desenho, permitindo (1) tratar um conjuntointerligado de objectos (em lista ou em arvore) ou um unico objecto, de forma uniforme(recursive metapatterns) e (2) introduz uma combinacao mais abstracta entre classes (connectionmetapatterns) e metodos (unification metapatterns) [Fayad 99]. E possıvel identificar nospadroes de desenho a existencia de meta-padroes. Como exemplo, atente-se a figura 2.5 quemostra o meta-padrao 1:1 Connection em ambos padroes de desenho Strategy [Gamma 95] eState [Gamma 95].

Capıtulo 3

Recuperacao de Desenho com vista aReutilizacao de Software

3.1 Principais Problemas na Reutilizacao de Software e dasFrameworks

As definicoes de uma framework variam de autor para autor e nao sao consensuais [Aguiar 03b].Resumidamente, uma framework pode ser definida como uma (macro) arquitectura semi-completa juntamente com uma implementacao das suas funcionalidades base. Uma frameworke desenhada para abarcar um conjunto de aplicacoes dentro de um domınio de problemas. Otermo ”semi-completa”significa que esta se encontra num estado em que pode ser configuravelou extensıvel para se adaptar ao problema concreto a resolver.

As frameworks encontram-se firmemente no centro das tecnicas de reutilizacao de software.Sao mais abstractas e flexıveis do que componentes (e mais difıceis de aprender a usar), mas maisconcretas e faceis de reutilizar (no entanto, menos flexıveis e menos sujeitas a serem aplicaveis)do que uma arquitectura mais especializada [Fayad 99]. As frameworks sao consideradasuma poderosa tecnica de reutilizacao porque levam a uma das formas mais importantes dereutilizacao, a reutilizacao do desenho e de arquitectura.

Especialistas em reutilizacao de software afirmam frequentemente que reutilizar o desenhoe mais importante que reutilizar o codigo, em grande parte devido a poder abarcar um maiorleque de contextos e logo, ser mais comum. [Fayad 99]. Igualmente, sendo aplicado numa faseinicial do processo de desenvolvimento, tera um maior impacto ao longo do projecto.

3.1.1 Frameworks : Problemas na Reutilizacao de Software

Um dos principais problemas quando se pretende reutilizar o desenho e informacao a esteassociada, e a sua captura e representacao [Biggerstaff 96]. Tipicamente, a arquitectura deuma framework e bastante complexa [Butler 98], em virtude de:

• Ser dotada de um alto nıvel de abstraccao, por forma a captar os conceitos base e alargaro seu espaco de abrangencia num determinado domınio;

• Estar imcompleta, sendo necessario a implementacao de classes adicionais para criar uma

31

32 3 Recuperacao de Desenho com vista a Reutilizacao de Software

aplicacao funcional;

• Ser mais flexıvel do que a aplicacao especıfica requer;

• Ser pouco clara no que toca as dependencias e interaccoes internas entre as suas classesconstituıntes.

Sendo uma arquitectura direccionada para a reutilizacao, a sua preocupacao principal centra-se na separacao dos aspectos que nao variam ao longo das varias aplicacoes num determinadodomınio - os denominados frozen spots - daqueles que sao variaveis e, por conseguinte, precisamde se manter flexıveis e configuraveis para se adaptarem a cada aplicacao em particular -denominados hot spots, ou pontos de variabilidade [Pree 95].

O desafio no desenvolvimento de uma framework cuja arquitectura seja adequada aos seusutilizadores reside na identificacao dos pontos de variabilidade necessarios para fornecer o nıvelde flexibilidade pretendido. Mas demasiada flexibilidade torna-a dıficil de desenhar e usar, daıa solucao para uma boa framework estar num arquitectura equilibrada.

Enquanto que a pratica sugere que o uso de frameworks pode aumentar significativamente areutilizacao e fazer diminuir o esforco de desenvolvimento [Moser 96], tal apresenta-se como umatarefa nao-trivial. Questoes do foro tecnico, organizacional e de gestao tornam-se obstaculos aultrapassar durante o processo de desenvolvimento de software, abrangendo um variado lequede actividades, quer ao nıvel do uso, que ao nıvel do desenvolvimento de frameworks. Estesobstaculos, quando nao tratados de forma conveniente, podem comprometer os benefıcios dasframeworks no que toca a reutilizacao e que segundo [Fayad 97, Bosch 99, Mattsson 99], sao arazao principal para o seu uso e desenvolvimento. Estes aspectos, ja abordados na seccao 2.4.2,sao de seguida sumariados:

• Desenvolvimento. Aspectos ligados ao desenvolvimento de frameworks abordam questoescomo a definicao do domınio de problemas que esta abrange, a falta de metodosde desenvolvimento adequados, a dificuldade em testar e depurar erros, a producaode documentacao de qualidade e a seleccao de estrategias de manutencao e evolucaoadequadas;

• Uso. Aspectos ligados ao uso de frameworks abordam questoes como aferir a suaaplicabilidade, aprender a usar e compreender o seu funcionamento, a falta de processosconsolidados de desenvolvimento de aplicacoes usando frameworks e a validacao edepuracao das respectivas aplicacoes.

3.1.2 Obstaculos a Facil Compreensao de Frameworks

Particulamente importantes para a eficacia da reutilizacao, estao as questoes de compreender eaprender a usar convenientemente a framework. Antes de se conseguir efectivamente reutilizarum qualquer elemento de software, ha que investir tempo na sua compreensao e aprendizagem.Quanto mais complexo esse elemento reutilizavel e, mais difıceis e morosas se tornam estastarefas.

Sendo um dos elementos de software mais complexos, as frameworks orientadas por objectossao, por conseguinte, difıceis de compreender, comunicar e aprender a usar, sobretudo porutilizadores inexperientes. Segundo [Booch 94a], uma framework, por mais bem desenhada que

3.1. Principais Problemas na Reutilizacao de Software e das Frameworks 33

esteja, nunca sera usada se o custo de a compreender e aprender a usar for superior ao custoesperado de desenvolver a aplicacao de raiz.

Tornar uma framework facil de compreender e, portanto, um importante prerequisito paraa sua reutilizacao de software. Uma melhor compreensao, leva a uma melhor reutilizacao. Em[Fayad 97] encontram-se algumas alternativas que visam a uma melhor compreensao de umaframework, atraves de:

• um refinamento do desenho da arquitectura;

• uma utilizacao de metodos que promovam um melhor uso e desenvolvimento;

• uma adesao a normas e standards para o desenvolvimento, adaptacao e integracao deframeworks (ainda nao existentes);

• uma producao de documentacao adequada e compreensıvel.

Focando mais o ambito no ultimo topico, para uma framework ter sucesso tem de fazeracompanhar por documentacao de qualidade. Mas uma documentacao completa, clara, simplese concisa e uma tarefa que tambem se apresenta difıcil, dispendiosa e morosa. Diversa informacaotem de ser produzida, organizada e mantida consistente ao longo do tempo. A documentacaotera de descrever o domınio de aplicacao, o seu proposito, como se usa, como funciona edetalhes relativos ao seu desenho interno, o que normalmente involve uma grande diversidadede conteudos e diferentes formas de os apresentar [Butler 98].

Adicionalmente, a complexidade da documentacao aumenta quando se tem de obedecer arequisitos de qualidade como sejam: lidar com diversos tipos de leitores; a necessidade de tervarios tipos de representacao dos conteudos; variantes quanto ao tipo de notacao e, como se naobastasse, ser facil de usar, quer em consulta, quer em navegabilidade.

E frequente as organizacoes e os projectos de desenvolvimento de software nao conseguirematingir os parametros de qualidade pretendidos, nomeadamente ao nıvel da documentacao, pelasrazoes ja vistas na seccao 2.2.4. Aprofundando um pouco mais o contexto, salientam-se asseguintes:

• Manutencao e evolucao inadequadas. As frameworks sao normalmente mantidas, alteradase configuradas por uma equipa, ou conjunto de pessoas. Estas alteracoes podem advir denecessidades de manutencao (correccoes de erros ou falhas, optimizacao de algoritmos,etc.) ou evolucao (resposta a novos requisitos, alargamento do dominio de aplicacao,etc.) e, muitas vezes, nao sao convenientemente documentadas, ou a documentacao nao eadequadamente actualizada;

• Inactividade ou migracao do conhecimento. Normalmente, o tecnico ou a equipa quedesenvolve a framework produz documentacao ad-hoc para sua propria referencia, sempreocupacoes com outras audiencias que poderao vir a usufruir dessa documentacao.Em projectos de grande dimensao, onde existem equipas multi-disciplinares, os tecnicospodem migrar entre equipas, levando com eles o conhecimento detalhado e necessariopara compreender a framework e deixando os novos utilizadores com a difıcil tarefa de aaprender a usar. Por outro lado, pode acontecer que quem desenvolveu a framework mudede contexto para outras tarefas, perdendo o contacto com aquela e, fazendo com que o seuconhecimento se dilua com o tempo. Ao tornar a usar a framework, a sua mestria ja naoe a mesma, forcando a um tempo de re-aprendizagem;


• Pressao do mercado. Com o mercado cada vez mais exigente ao nıvel do tempos de respostadas organizacoes as suas necessidades, os processos de desenvolvimento menosprezamo papel que uma boa documentacao tem na qualidade do produto que desenvolvem.E comum diferir-se as tarefas de documentacao, que nao sejam aquelas estritamentenecessarias para responder ao projecto em maos. Ao longo do tempo, a documentacaotorna-se confusa, imprecisa e inconsistente;

• Falta de ferramentas de apoio. A falta de ferramentas que apoiem o utilizador acompreender melhor como se utiliza uma framework e como recuperar a informacao que sefoi perdendo ao longo do tempo, pela deficiente actualizacao da documentacao, e um dosfactores que leva a que o processo de aprendizagem seja ainda mais moroso e fatigante.

Associado as mas praticas acima salientadas, vai-se perdendo informacao relativa ao desenhoda framework, vital para a clara compreensao desta e para o processo de aprendizagem eformacao com vista a sua eficaz utilizacao. Assim, uma ferramenta de apoio a recuperacaodessa informacao, nomeadamente do desenho, traria benefıcios para o utilizador da framework.

Esta dissertacao propoe uma ferramenta de engenharia reversa que procede a recuperacaodo desenho de uma framework, atraves da identificacao das estruturas-base da sua arquitectura,e que lhe conferem as caracterısticas que a tornam um artefacto reutilizavel. Esta recuperacaode desenho e feita em passos sucessivos, identificando os elementos do desenho com umnıvel crescente de abstraccao, num processo semi-automatico. O objectivo e o de fornecerinformacao util ao (re-)utilizador sobre o desenho da framework, nomeadamente sobre as zonasde flexibilidade onde aquele tera de intervir para a adaptar ao seu problema.

3.2 Trabalho Relacionado

Sob o topico da recuperacao de desenho, nomeadeamente, de padroes de desenho, existemja algumas abordagens desenvolvidas nos ultimos anos para lidar com este problema. Desdeferramentas de deteccao automatica a heurısticas de extraccao de padroes, apresentam as maisvariadas caracterısticas e resultados do que respeita a disponibilidade, flexibilidade, eficienciae eficacia. Nesta seccao apresentam-se e analisam-se as mais conhecidas e relevantes para estetrabalho.

3.2.1 Pat

O sistema Pat [Kramer 96] e uma ferramenta de recuperacao de desenho para C++. A suaabordagem assenta na extraccao de informacao dos ficheiros de cabecalho (header files) e oseu armazenamento num repositorio. Este procedimento e feito recorrendo a linguagem logicaPROLOG, onde os padroes de desenho sao definidos como regras de inferencia e a informacaoextraıda como factos na base de conhecimento. O reconhecimento dos padroes e deixado a cargodo motor de inferencia que se encarrega de tentar resolver as regras.

Vantagens

• Recorre a uma representacao formal dos padroes de desenho;

• Utiliza o poder de um motor de inferencia;

3.2. Trabalho Relacionado 35

• E eficiente, apesar de apenas lidar com cinco padroes de desenho.

Desvantagens

• Apenas consegue identificar padroes de desenho estruturais, pois nao lida com informacaorelativa ao comportamento e relacionamento com classes;

• Apenas usa os ficheiros de cabecalho para extrair a informacao, o que faz com que sopossa actuar ao nıvel estrutural, sem ter mais informacao relativa ao relacionamento entreas classes;

• E pouco eficaz. Com um grau de precisao que varia entre os 14 e os 50 por cento. Osautores alegam que haveria uma melhoria se houvesse informacao relativa a delegacao demetodos entre classes;

• Nao se encontra disponıvel como um produto de software.

3.2.2 KT

O KT [Brown 96] e uma ferramenta que permite recuperar informacao de desenho sob a formade diagramas de codigo-fonte Smalltalk. Estes diagramas sao usados para capturar e mapearinformacao estrutural e comportamental das classes. Esta informacao e depois utilizada paradetectar instancias de padroes de desenho.

Vantagens

• Procede a uma analise estatica e dinamica do codigo, extraındo informacao de estrutura ecomportamento das classes;

• Apresenta os resultados sobre a forma de diagramas (OMT 1), permitindo uma melhorcompreensao e rastreabilidade dos mesmos.

Desvantagens

• Depende da linguagem de programacao Smalltalk;

• As heuristicas de reconhecimento dos padroes estao implementadas directamente no codigoda ferramenta, retirando-lhe flexibilidade;

• A generalidade do Smalltalk (fracamente tipada) faz com que sejam necessarios meta-modelos intermedios para lidar com a captura de informacao estrutural;

• Para a captura da informacao dinamica (invocacao de metodos), a ferramenta obriga aexecucao do codigo, o que, alem de ser um problema, levanta questoes relativamente acompleta analise de todas as invocacoes;

• Nao se encontra disponıvel como um produto de software;

• Nada e dito quanto a forma de apresentar os resultados.1Notacao para modelar sistemas de software, antecessora do UML [Object Management Group 03]


3.2.3 Seeman-Gudenberg

Esta aproximacao [Seemann 98] introduz diversas nocoes de como recuperar informacao dedesenho de codigo-fonte Java. O processo decorre ao longo de passos sucessivos, identificandoelementos a diferentes nıveis de abstraccao. Num primeiro passo, um grafo e construıdo a partirda interpretacao do codigo-fonte e da identificacao e extraccao de informacao relativa a heranca,invocacao de metodos e convencoes de nomes (metodos, tipos nativos, estruturas de dadosnativas, etc). De seguida, o grafo e transformado usando uma gramatica de regras de producao.Estas tranformacoes visam a eliminar redundancia e a agregar equivalencias, tornando o grafomais leve e orientado para o passo final. Finalmente, um passo de deteccao de padroes e aplicado,baseado numa representacao previa do padrao segundo a sıntaxe do grafo.

Vantagens

• Utiliza um processo faseado de deteccao, onde a informacao vai sendo filtrada, afunilandoo domınio de solucoes;

• Apesar de recorrer principalmente a informacao estrutural (analise estatica), utilizatambem informacao comportamental (analise dinamica) para reduzir o domınio desolucoes. E exemplo disso o uso de informacao relativa a invocacao de metodos.

Desvantagens

• Apesar de usar informacao relativa ao comportamento das classes, apresenta limitacoespois baseia-se maioritariamente em informacao estrutural para detectar os padroes.Significa que pode apenas detectar os padroes para algumas implementacoes dos mesmos,restringindo em grande medida o domınio de solucoes;

• O uso de convencoes de nomes pode ser uma desvantagem na medida em que basta oprogramador usar uma convencao de nomes diferente para que a deteccao falhe;


• Nada e dito quanto a forma de apresentar os resultados.

3.2.4 SPOOL

O projecto SPOOL [Keller 99] (Spreading Desirable Properties into the Design of Object-Oriented, Large-scale software systems e uma parceria entre a Bell Canada (industria) e auniversidade de Montreal para a construcao de um ambiente de desenvolvimento baseado empadroes de desenho. Na sua arquitectura, existe um modulo que trata da engenharia reversa depadroes. Este modulo e composto por uma arquitectura em ”trevo”composta pelos seguinteselementos:

• uma base de dados onde se guarda a informacao relativa ao desenho do codigo, capturadae convertida numa notacao baseada em UML [Object Management Group 03];

• um repositorio intermedio que guarda o esquema do modelo de engenharia reversa, nomeada-mente a informacao relativa aos padroes de desenho, sua estrutura e comportamento;


• um conjunto de ferramentas graficas que permitem aceder as funcionalidades fornecidaspelo ambiente (seja deteccao de padroes, captura de codigo, etc).

O processo de recuperacao de padroes pode ser completamente automatico, semi-automaticoe manual, havendo intervencao do utilizador nos dois ultimos. Em todas eles, a deteccao dospadroes e feita ao nıvel da representacao da informacao atraves de diagramas, tendo estes todaa informacao necessaria.

Vantagens

• Fornece tres versoes de operacao: automatica, semi-automatica e manual. Permite que outilizador intervenha no processo de recuperacao, afunilando mais rapidamente o domıniode solucoes e dando controlo sobre todo o processo;

• Recorre quer a informacao estatica (estrutura) como a informacao dinamica (relacoes ecomportamento) das classes;

• Boa visualizacao. As ferramentas executam em ambiente grafico e usam a notacao UMLe HTML para visualizar as classes;

• Independente da linguagem de programacao. Ao criar uma representacao do desenhointermedia baseada em diagramas, perde-se toda a dependencia com a linguagem deprogramacao em que foi implementado.

Desvantagens

• Nao disponıvel. Como todo o ambiente foi feito para um cliente industrial, nem ha acessoa este, nem a detalhes de implementacao ou quais os processos que foram usados para adeteccao dos padroes.

3.2.5 Albin-Amiot & Gueheneuc

Esta aproximacao [Albin-Amiot 01] baseia-se numa definicao de um meta-modelo pararepresentar padroes de desenho. Esta representacao permite que a deteccao se possa fazercom base na estrutura e aspectos comportamentais dos padroes. E criada uma instanciacaodo meta-modelo de acordo com a informacao obtida atraves da analise do codigo-fonte. Essainstanciacao e entao confrontada com instanciacoes previas dos padroes de desenho utilizando omesmo meta-modelo.

Vantagens

• Utiliza um meta-modelo de representacao, tornando-se independente da linguagem deprogramacao;

• O meta-modelo abrange informacao de estrutura (estatica) e de comportamento(dinamica).


Desvantagens

• Recorre apenas a informacao de estrutura para a deteccao devido a problemas de rastreio.Apos a instanciacao do meta-modelo, a unica informacao possıvel de ser rastreada para ocodigo e apenas a de cariz estrutural. Logo, para manter a rastreabilidade, o processo dedeteccao de padroes assenta apenas nessa informacao;

• Deteccao de variacoes de implementacao. O processo apresenta limitacoes no reconheci-mento de variacoes de implementacao dos padroes de desenho, pois limita-se a analisar ainformacao estrutural, baseado numa linguagem de restricoes bastante inflexıvel;



3.2.6 Heuzeroth-Holl-Hogstrom-Lowe

[Heuzeroth 03] propoem uma aproximacao faseada de analise da informacao estatica do codigo-fonte para descobrir potenciais candidatos, seguida de uma analise dinamica em tempo deexecucao, para eliminar possibilidades. Esta analise nao depende de convencoes ou normasde escrita de codigo. Aplicada sobre codigo Java, e feita uma analise a arvore de sıntaxe docodigo-fonte e os candidatos a padroes de desenho sao compostos por tuplos de classes, metodose atributos, segundo regras definidas previamente. O passo final de analise dinamica analisacomo estes tuplos se relacionam, excluindo aqueles que nao correspondem ao esperado.

Vantagens

• Utiliza uma formalizacao previa dos padroes de desenho;

• Analisa informacao de estrutura (estatica) e comportamento (dinamica);

• Aceita a introducao de novos padroes de desenho na sua base de conhecimento, atraves deuma linguagem formal de especificacao.

Desvantagens

• Obriga a execucao do codigo-fonte para capturar informacao dinamica. Tal pode levar aque nem todas as classes sejam executadas, pondo em causa a tarefa de eliminar falsoscandidatos positivos;

• Num processo dito automatico, este nao elimina a necessidade da intervencao do utilizadorpara assegurar a fiabilidade dos resultados;


• Nada e dito quanto a apresentacao dos resultados.


3.2.7 SPQR

SPQR (System for Pattern Query and Recognition) [Smith 03] e uma aproximacao baseadanuma arquitectura Pipes & Filters [Garlan 93] onde o codigo-fonte e progressivamente filtrado etransformado em notacoes intermedias, ate atingir um nıvel em que pode ser submetido a provasformais de deteccao de padroes de desenho. Todo o processo requer uma extensiva formalizacaodos padroes de desenho a priori, baseada na sua estrutura e relacoes entre os seus componentes.As nocoes utilizadas para formalizar os padroes de desenho assentam em abstraccoes num meta-nıvel que capturam as nocoes de estrutura e relacionamento comuns entre padroes de desenho(um tanto similar a meta-padroes (2.4)) as quais os autores denominam como padroes de desenhoelementares. A formalizacao destes padroes recorre a linguagem ρ− calculus, uma extensao deζ − calculus [Abadi 96] mais um operador de relacionamento.

Vantagens

• Utiliza uma forte formalizacao dos padroes de desenho;

• O uso de um modelo de abstraccao a um nıvel superior ao padroes de desenho, daabrangencia e flexibilidade a abordagem, capturando quer informacao de estrutura(estatica), quer de comportamento (dinamica);

• Apresenta um catalogo de padroes de desenho ja formalizados, facil de extender comrecurso a uma linguagem propria de formalizacao;

• Os resultados sao apresentados sob a forma de XML, podendo ser rapidamente convertidosnoutros formatos.

Desvantagens

• Exige tempo para o estudo e compreensao da linguagem de formalizacao, para mapearnovos padroes de desenho;

• Nao e integravel num ambiente de desenvolvimento, alias, uma preocupacao referida pelosautores.

3.2.8 DPVK

DPVK [Wang 04] e uma ferramenta de engenharia reversa para deteccao de padroes de desenhoem codigo-fonte Eiffel. A aproximacao assenta num catalogo de definicoes de padroes de desenhosegundo uma notacao propria, que mapeia informacao sobre a estrutura e comportamentodaquelas. A informacao de comportamento baseia-se na ordem pela qual sao invocados osmetodos entre as classes. Apresenta-se como um plug-in para a plataforma de desenvolvimentoEclipse [Eclipse Foundation 05].

Vantagens

• A abordagem, recorre a informacao de estrutura (estatica), bem como a informacao decomportamento (dinamica) das classes;


• Apresenta um catalogo de padroes de desenho ja formalizados, passıvel de ser extendidocom a adicao de novos padroes;

• Apresenta-se com o formato de um plug-in, integravel num ambiente de desenvolvimento.

Desvantagens

• A captura de informacao dinamica obriga a execucao do codigo-fonte, levantandoproblemas de integridade (nao existe a garantia que todo o codigo e executado);

• O mapeamento dos padroes de desenho no catalogo nao e generico o suficiente paraagrupar variantes de implementacao do mesmo padrao de desenho, havendo a necessidadede introduzir versoes diferentes para o mesmo padrao;

• Nao sendo um processo totalmente automatico, so e permitido intervencao do utilizadorno final para avaliar os resultados obtidos;


3.2.9 Niere-Schafer-Wadsack-Wendehals-Welsh

Em [Niere 02], os autores apresentam uma aproximacao que assenta num processo iterativoque combina uma estrategia top-down com uma estrategia bottom-up. O processo comeca comesta ultima estrategia, analisando o codigo-fonte e tentando aplicar regras de enquadramentonum meta-modelo pre-definido. Esta estrategia pretende que se agrupem elementos basicos dedesenho a nıvel estrutural, ate se atingir um nıvel intermedio de abstraccao. Se os resultadosintermedios nao forem satisfatorios, muda-se de estrategia para a primeira (top-down), ondese tenta enquadrar os resultados intermedios de um ponto de vista mais global, segundo asoutras regras de enquadramento mais alto-nıvel, normalmente tendo em conta o comportamentodinamico dos elementos de desenho. Sendo um processo iterativo, estes resultados intermediospodem ser adaptados ou modificados pelo utilizador para que na proxima iteracao do processoestes possam gerar melhores solucoes.

Vantagens

• A abordagem recorre a um processo faseado e iterativo, permitindo a sua interrupcao paraintervencao do utilizador;

• E possıvel obter resultados intermedios que podem ja ser uteis para o utilizador, podendoeste fazer anotacoes e alteracoes que poderao melhorar as proximas iteracoes do processo;

• Baseia-se num meta-modelo desenvolvido para mapear informacao de estrutura (estatica)e de comportamento (dinamica) dos elementos de desenho;

• Apresenta os resultados segundo uma notacao similar ao UML, sendo mais facil aoutilizador analisar os resultados e iterar sobre eles;

• O meta-modelo esta disponıvel e permite a adicao de novas regras de definicao de padroes,sendo extensıvel e dando flexibilidade a ferramenta;


• Encontra-se disponıvel como um produto de software, apesar de nao ser integravel numambiente de desenvolvimento.

Desvantagens

• Nao resolve o problema das variantes de implementacao de padroes de desenho. O meta-modelo nao e suficientemente generico para abarcar com todas as hipoteses de uma formaabstracta, havendo a necessidade de mapear varias implementacoes distintas;


3.2.10 Campo-Marcos-Ortigosa

Esta aproximacao [Campo 97] baseia-se num mapeamento dos padroes de desenho atraves deregras Prolog, que descrevem as propriedades de estrutura e comportamento daqueles, assimcomo algumas heurısticas para distincao entre padroes similares. Recorrendo a uma plataformade desenvolvimento de ferramentas de visualizacao denominada Luthier [Campo 97], os autoresdesenvolvem uma aplicacao que permite visualizar os resultados finais atraves de diagramasOMT.

Vantagens

• Existe um forte formalismo na representacao dos padroes de desenho;

• A visualizacao dos resultados faz-se atraves de diagramas graficos OMT, permitindo umamais clara e perceptıvel analise dos resultados;

• Recorre a informacao de estrutura (estatica) e de comportamento (dinamica) dos padroesde desenho para a sua deteccao e recuperacao;

• Encontra-se disponıvel como um produto de software, apesar de nao ser integravel numambiente de desenvolvimento.

Desvantagens

• O mapeamento em regras Prolog e feito recorrendo a nocoes genericas de nıvel deabstraccao intermedio (nao recorrem a normas de escrita de codigo ou convencoes de nomes,mas sim a invocacoes de metodos segundo uma determinada estrutura ou protocolo).Poderiam tirar partido de nocoes mais abstractas, como por exemplo, o comportamentocomum entre padroes e depois aplicarem as heurısticas de afericao dos detalhes de cadapadrao. Desta forma, a representacao dos padroes em regras Prolog pode ser bastanteextenso;

• Segundo os autores, a ferramenta induz na exploracao de detalhes que poderao nao serrelevantes e nao ajuda muito a reduzir o tempo de desenvolvimento;

• Nao permite a intervencao do utilizador a passos intermedios;

• Nada e dito quanto a extensibilidade da biblioteca de padroes, ou onde esta a definicaodestes.


3.2.11 Balanyi-Ferenc

Esta abordagem [Balanyi 03] baseia-se numa representacao dos padroes de desenho recorrendoa uma linguagem de anotacao desenvolvida pelos autores e denominada DPML (Design PatternMarkup Language). O processo de recuperacao procede com a analise do codigo-fonte (no caso,C++) e a sua representacao num grafo semantico (ASG, i.e. Abstract Semantic Graph). Estegrafo e depois comparado e analisado em confronto com os padroes de desenho carregadospreviamente para uma arvore DOM 2.

Vantagens

• A representacao dos padroes de desenho atraves de uma linguagem de anotacao permiteuma facil compreensao por parte do utilizador, no que respeita a estender a biblioteca depadroes;

• Recorre a informacao de estrutura (estatica) e de comportamento (dinamica) das classes.

Desvantagens

• A linguagem de anotacao apresenta importantes restricoes no mapeamento de padroes,nao permitindo a definicao de conceitos mais alto nıvel como tipos genericos de dados einterfaces de metodos redefinıveis;

• A heurıstica de deteccao de padroes recorre ao nome dos metodos (em vez da suaassinatura, por exemplo) para a analise de comportamento dinamico das classes;

• Nao permite a intervencao do utilizador em passos intermedios;

• O processo tem dificuldade em distinguir entre padroes de desenho muito similares;

• A ferramenta mostra pouca eficiencia;

• Nada e dito quanto a apresentacao dos resultados;

• Nao e integravel num ambiente de desenvolvimento.

Um resumo comparativo das caracterısticas mais relavantes das ferramentas analisadas nestaseccao pode ser vista na Tabela 3.1.

Em resumo, pode-se tirar as seguintes conclusoes das abordagens ja existentes:

Formalizacao. Uma boa formalizacao em torno de padroes de desenho leva a que hajauma maior eficacia na deteccao dos seus elementos constituintes, sejam eles estruturais oucomportamentais.

2Document Object Model, uma norma da W3C (World Wide Web Consortium) que define um conjunto deinterfaces para navegar numa arvore documental XML.


Tabela 3.1: Comparacao de ferramentas de recuperacao de padroes de desenho.

Alto nıvel de abstraccao. No entanto, uma formalizacao, se mapear conceitos de baixo nıvelde abstraccao, leva a que a deteccao nao seja abrangente, obrigando ao mapeamento de variantesde implementacao dos padroes de desenho.

Meta-modelo. O recurso a um meta-modelo que permita abstrair os conceitos de composicaodos padroes de desenho fomenta a maior abrangencia dos metodos de recuperacao e deteccao,dando mais flexibilidade.

Aproveitamento de informacao comportamental. A analise feita ao nıvel dos compo-nentes estruturais (classes, atributos, metodos), complementada com informacao ao nıvel dainterrelacao entre aqueles (invocacao de metodos, generalizacoes, delegacao, etc.) e vital para aeficacia do processo de recuperacao de desenho.

Flexibilidade. A utilizacao de uma linguagem de formalizacao/definicao dos padroes dedesenho que esteja disponıvel e que possa ser estendida pelo utilizador como novas definicoesconfere a ferramenta flexibilidade e extensibilidade para que o processo de deteccao possa seroptimizado e adaptado a novos padroes ou heurısticas que surjam.

Clareza e rastreabilidade. E importante que a ferramenta permita a boa e clara visualizacaodos resultados ao utilizador, dando a possibilidade de rastrear os padroes de desenho (e seuscomponentes) no codigo-fonte, e, quando possıvel, permitir a anotacao e filtragem dos resultados.

Resultados intermedios por iteracoes. A adopcao de um processo de recuperacao dedesenho faseado ou iterativo, por etapas, onde os resultados intermedios ja trazem algumainformacao relevante ao utilizador e onde este pode actuar para ajudar na obtencao de resultadosmais exactos e mais adequado do que um processo completamente automatizado. Pela naturezados padroes de desenho, sobretudo a nıvel de variantes de implementacao e sobreposicao deconceitos comuns, as heurısticas actuais ainda nao estao suficientemente desenvolvidas paraconseguir atingir resultados plenamente satisfatorios e com uma certeza bastante alta.

E com estas conclusoes em mente que se partiu para a abordagem proposta por estadissertacao.

Capıtulo 4

Abordagem para Recuperacao deDesenho

As frameworks sao uma tecnica poderosa para a reutilizacao de software. Por definicao, compoem-se de uma arquitectura semi-completa e de uma implementacao das suas funcionalidades base,fomentando a reutilizacao quer do desenho quer do codigo. A preocupacao principal de umaframework reside na separacao dos aspectos comuns e invariaveis no domınio de aplicacoes queabrange — os frozen spots — dos aspectos variaveis e sujeitos a modificacao e configuracao — oshot spots — possibilitando a adaptacao da framework e construcao de uma aplicacao concretae assim resolver um problema especıfico [Pree 95].

O conceito de recuperacao de desenho (seccao 2.1.3) assenta num processo de engenhariareversa que visa a identificar e capturar elementos da arquitectura de um sistema que nao seencontram explıcitos ou vısiveis para o utilizador, conjungando varias fontes de informacao.

Neste capıtulo, serao apresentados os elementos do desenho de uma framework que sepretendem recuperar e qual a sua utilidade, sendo de seguida apresentado processo pelo qual seespera atingir essa recuperacao.

4.1 Elementos de Desenho de uma Framework a Recuperar

Sendo o objectivo principal de uma framework a reutilizacao de software, a decomposicao dosseus elementos de desenho pode ser vista a tres nıveis de abstraccao distintos : os templates ehooks, os meta-padroes e os padroes de desenho.

4.1.1 Templates e Hooks

Uma framework e caracterizada pelo chamado Open Closed Principle [Martin 96]. Este atributodescreve a flexibilidade de uma framework, abarcando as nocoes de ”open” e ”closed”. A primeirarefere-se aos pontos de variabilidade (hot spots), que se consideram ”abertos”1 a configuracaopor parte do utilizador. A segunda refere-se aos pontos de invariabilidade (frozen spots), que seencontram ”fechados”2 a qualquer intervencao por parte do utilizador, garantindo a estabilidade

1em ingles, open2em ingles, closed

45

46 4 Abordagem para Recuperacao de Desenho

Figura 4.1: Exemplo de templates e hooks na classe TestCase.

da arquitectura.

Estas nocoes sao implementadas por uma framework, recorrendo a dois elementos essenciais:os templates e os hooks [Wirfs-Brock 90, Gamma 93, Pree 95].

Tal como anteriormente definido em 2.5.3, os templates sao metodos concretos que definemo fluxo de controlo de um determinado algoritmo e fornecem uma implementacao que invocaoutros metodos. Estes outros metodos sao denomidados hooks, podendo ser:

• metodos abstractos, desprovidos de implementacao e que apenas fornecem uma interface;

• metodos concretos, que contem uma implementacao, mas, neste contexto, nao invocamoutros metodos hook ;

• templates, se a sua implementacao invocar outros metodos hook.

De uma forma geral, os templates sao usados na implementacao dos pontos invariaveis deuma framework, sendo responsaveis pela representacao do comportamento abstracto, controlodo fluxo de execucao ou relacionamentos comuns entre objectos. Podera dizer-se, com algumaimprecisao, que os templates sao metodos complexos implementados com base nos hooks. Estesultimos sao usados na implementacao dos pontos de variabilidade de uma framework. E naredefinicao destes hooks que o utilizador da framework a consegue configurar e adaptar aoseu problema concreto, fornecendo implementacoes especıficas para funcionalidades genericas epassıveis de reconfiguracao.

Na figura 4.1, podemos ver um exemplo que demonstra a existencia e o uso de templates ehooks na classe TestCase, existente na framework de testes JUnit [Gamma 03b].

Genericamente um teste e composto de por tres etapas: inicializacao, execucao e terminacao.Independentemente do contexto de cada teste, todos eles passam por estas tres fases. Porforma a capturar este comportamento comum, a classe TestCase fornece tres metodos quecorrespondem a cada uma destas operacoes, respectivamente, setUp), runTest e tearDown. Estesmetodos carecem de implementacao, pois essa e da responsabilidade do utilizador fornecer, paraa adequar ao seu caso particular. Tal deve ser feito, pela criacao de uma nova classe que descendade TestCase e que reimplemente os metodos supra-citados.

Resta garantir que a execucao das tres etapas do teste e feita pela ordem correcta. Essaresponsabilidade esta do lado de TestCase atraves do metodo run. Este garante que a invocacao

4.1. Elementos de Desenho de uma Framework a Recuperar 47

dos restantes tres metodos e feita sempre e pela ordem correcta. Gracas ao mecanismo dedynamic binding 3 sao invocadas as implementacoes constantes da classe definida pelo utilizador.

Portanto, quando um utilizador pretende executar um teste, basta para tal fornecerimplementacao para as tres etapas (setUp), runTest e tearDown) e, no final, invocar o metodorun, responsavel pelo controlo sobre o fluxo de execucao geral do teste.

Em conclusao, o metodo run e um template, ponto de invariabilidade da framework, enquantoque os metodos setUp, runTest e tearDown sao hooks, pontos de variabilidade da framework aosquais o utilizador pode fornecer a sua propria implementacao.

4.1.2 Meta-Padroes

Os templates e hooks podem ser organizados de varias formas. Apesar de se poderem colocar ouunificar numa mesma classe, como no caso do exemplo com TestCase, na maioria das situacoese aconselhavel separa-los em classes distintas. Desta forma, para alem da distincao estrutural,previne-se que o utilizador confunda os metodos e possa redefinir um template acidentalmente,pondo em causa o controlo do lado da framework.

Quando usadas em classes separadas, a classe que contem o(s) hook(s) denonima-se por classehook. Aa classe que contem o(s) template(s) que o(s) invoca(m), e por sua vez denominada porclasse template. Pode-se considerar que a classe hook parametriza a correspondente classetemplate. Um template invoca um ou mais hooks, podendo estes estar:

• Na mesma classe em que se encontra o template;

• Numa classe diferente, podendo esta ser subclasse, superclasse ou nao constar da hierarquiada classe onde se encontra o template.

Estas combinacoes entre classes template e classes hook foram estudadas por Pree em[Pree 95] no qual identificou sete combinacoes possıveis, as quais denominou de meta-padroes.Estas combinacoes sao caracterizadas por dois aspectos:

• Cardinalidade associacao entre a classe template e a classe hook ;

• Relacao hierarquica entre a classe template e a classe hook

Cardinalidade

Relativamente a cardinalidade, existem duas combinacoes (figura 4.2):

• Ambos templates e hooks estao na mesma classe, acumulando esta ambos os papeis declasse template e classe hook. A este meta-padrao chama-se Unification metapattern ;

• No caso dos templates e hooks estarem em classes separadas e a classe template fazerreferencia a uma ou mais instancias da classe hook, esta-se perante um Connection

3Mecanismo da orientacao por objectos que permite adiar ate ao tempo de execucao do codigo qual aimplementacao que e executada em resposta a invocacao de um metodo, quando os parametros para essa operacao,caso existam, sejam conhecidos [Meyer 88, Booch 94a].


Figura 4.2: Unification metapattern e Connection metapattern, segundo Pree [Pree 95].

metapattern . Consoante o numero de instancias referidas, pode-se ter um 1:1 Connectionmetapattern, no caso de apenas uma instancia, ou um 1:N Connection metapattern, no casode mais do que uma instancia.

Hierarquia

Estas combinacoes podem ser vistas na figura 4.3.

Caso haja uma relacao hierarquica entre a classe template e a classe hook, juntamentecom uma referencia da primeira para instancias da segunda, esta-se perante um Recursivemetapattern . Ao combinar esta forma com as restantes, obtem-se os padroes constantes dafigura 4.3.

• No caso de se ter classes template e classes hook distintas, esta-se perante um 1:1 RecursiveConnection metapattern (em que se refere apenas uma instancia da classe hook) ou um1:N Recursive Connection metapattern (se referir mais do que uma instancia da classehook);

• No caso de se ter a mesma classe com ambos papeis de classe template e classe hook,a relacao hierarquica dilui-se e mantem-se apenas a associacao entre classes (no caso, amesma). Assim sendo, esta-se perante um 1:1 Recursive Unification metapattern (se referirapenas uma instancia) ou um 1:N Recursive Unification metapattern (se referir mais doque uma instancia).

Todos estes meta-padroes constituem os sete identificados por Pree e ja vistos anteriormentena figura 2.4.

Os meta-padroes podem ser considerados uma abstraccao sobre os padroes de desenho (seccao2.5.1). Enquanto que um padrao de desenho aborda um problema e respectiva solucao dentrode um contexto, um meta-padrao aborda questoes de desenho de uma qualquer solucao, a umnıvel mais abstracto, ou seja, menos contextualizado.

Como os meta-padroes sao expressos recorrendo uma linguagem mais rıgida (mecanismosbasicos da orientacao por objectos) do que os padroes de desenho, e mais facil de descobrir ondese encontram os meta-padroes instanciados num qualquer programa [Jacobson 99].

4.1. Elementos de Desenho de uma Framework a Recuperar 49

Figura 4.3: Recursive Unification metapattern e Recursive Connection metapattern, segundoPree [Pree 95].

4.1.3 Padroes de Desenho

Frameworks e padroes de desenho sao dois conceitos fortemente relacionados, representando doisnıveis diferentes de abstraccao, ao nıvel da definicao do desenho e arquitectura de um sistemade software (seccao 2.3.2). Tipicamente, uma framework e composta por diversos padroes dedesenho, pelo facto de estes seres extremamente uteis na sua construcao, ao abordarem umproblema recorrente com uma solucao considerada boa, dotando aquela de mecanismos quemelhoram a sua extensibilidade e flexibilidade (hot spots).

Os padroes de desenho tambem sao considerados elementos adequados para documentaruma framework [Beck 94, Pree 95, Schmid 95] e desenvolver novas arquitecturas reutilizaveisorientadas por objectos. Alem disso, as tarefas de manter a framework actualizada ou a suaadaptacao a novos requisitos tornam-se mais rapidas com menos erros se os padroes de desenhoconstantes daquela estiverem convenientemente documentados [Prechelt 98]. Os padroes dedesenho sao particularmente uteis na documentacao de uma framework porque capturam aexperiencia consolidada no desenho de solucoes para problemas recorrentes e abarca a meta-informacao de como a flexibilidade esta incorporada na framework.

Apesar de se poder utilizar meta-padroes para documentar directamente os papeis deelementos participantes na framework, eles sao muitos mais uteis para documentar os papeisdos elementos participantes nos padroes de desenho.

Em geral, e preferıvel relacionar os meta-padroes com os padroes de desenho, e,posteriormente, os padroes de desenho aos elementos participantes na framework que osinstanciam. Esta abordagem advem de dois factores:

1. Redundancia. Ter meta-padroes e padroes de desenho seria redundante, visto um estarintimamente relacionado com o outro.


Figura 4.4: Fases do processo de recuperacao de desenho.

2. Contextualizacao. Usar directamente meta-padroes sobre os elementos da framework trariapouca utilidade na resolucao de problemas concretos e contextuais. Tal deve-se ao alto-nıvel de abstraccao, livre de contexto, que carateriza os meta-padroes. Logo, usar padroesde desenho e mais util do ponto de vista da contextualizacao.

No entanto, enquanto elemento constituinte dos padroes de desenho e devido a suadescontextualizacao, os meta-padroes sao uma boa abstraccao para definir uma base de partidapara a identificacao de instancias de padroes de desenho.

4.2 Processo de Engenharia Reversa

Sendo a maioria das frameworks compostas por padroes de desenho, os quais abarcam umarepresentacao intermedia do desenho da framework, constituındo os elementos basilares da suaarquitectura [Fayad 99].

De um ponto de vista unico da reutilizacao, o conceito de meta-padrao pode ser usado paraagregar os elementos de flexibilidade. O meta-padrao e uma abstraccao sobre os padroes dedesenho que permite isolar apenas os aspectos de flexibilidade (templates e hooks) e descreveraqueles sob este ponto de vista.

Com vista a recuperacao destes elementos, definiu-se no ambito deste trabalho um processosemi-automatico de engenharia reversa por fases, partindo-se do codigo-fonte (de qualquerdimensao) e evoluindo progressivamente ate se obter um nıvel satisfatorio de informacao sobreo desenho da framework (figura 4.4).

O processo avanca por etapas, gerando no final de cada uma delas, informacao desde logorelevante para o utilizador da framework, sejam templates, hooks, hot spots, instancias de meta-padroes ou padroes de desenho. No final de todo o processo, pretende-se ter informacao relativaas instancias de padroes de desenho existentes no codigo. Esta informacao tera um grau decerteza variavel, mas sera sempre util para o utilizador, visto a informacao intermedia queentretanto vai sendo fornecida ja permitir identificar as zonas onde tera de intervir para reutilizarconvenientemente a framework.

Em resumo, a aproximacao baseia-se na analise do codigo-fonte, sondagem e identificacaode pontos de flexibilidade e o seu consequente agrupamento em estruturas de nıvel crescente deabstraccao.

Em [Canfora 92], Canfora alerta para alguns problemas quando se define um processo derecuperacao de desenho, nomeadamente: (1) a identificacao dos nıveis de detalhe relevantesa nıvel de desenho e a sua apresentacao ao utilizador, mediante uma ou varias estrategiasadequadas; (2) a recuperacao apenas de uma pequena parte do desenho necessario para a correcta

4.2. Processo de Engenharia Reversa 51

compreensao do sistema; e (3) a falta de flexibilidade que a ferramenta exibe, impedindo a suaextensao ou adaptacao aos ambientes de desenvolvimento.

O trabalho apresentado nesta dissertacao visou alcancar os seguintes objectivos:

• Adoptar uma aproximacao baseada em meta-padroes, onde cada fase do processo derecuperacao de desenho produz informacao relevante e clara sobre as possıveis zonas deflexibilidade de um sistema de software orientado por objectos;

• Usar uma representacao de padroes de desenho baseada na sua composicao com meta-padroes. Deve ser generica o suficiente para se poder representar qualquer padrao dedesenho, ja descoberto ou por descobrir;

• Fornecer uma ferramenta de apoio que permita automatizar o processo de recuperacao dedesenho, que seja flexıvel, integravel, extensıvel e capaz de produzir resultados visuais aoutilizador.

De seguida, faz-se uma descricao de cada uma das fases do processo de recuperacao dedesenho.

4.2.1 Analise do Codigo-Fonte

O ponto de partida para a recuperacao do desenho de uma framework e o codigo-fonte. Estetem de estar disponıvel e acessıvel sem qualquer restricao. Normalmente, este encontra-se numformato de texto, armazenado em ficheiros, segundo uma determinada organizacao. Podendovariar consoante a linguagem de programacao, e usual ver-se um ficheiro conter apenas umaclasse, ou seja, para cada classe existir um ficheiro independente.

E pratica comum recorrer-se a uma estrutura em arvore para mapear e relacionar todosos elementos constantes do codigo, denominada Arvore de Sıntaxe Abstracta4. Esta tecnicae extensivamente utilizada pelos compiladores para representar a estrutura interna do codigo,onde todos os elementos se relacionam entre eles consoante a sua posicao na arvore. Esta praticapermite uma maior eficiencia na pesquisa e analise do codigo-fonte.

A analise do codigo-fonte e, por conseguinte, uma analise das estruturas elementares (classes,atributos, metodos, estruturas de dados) constantes daquele, filtrando-se aquelas que saorelevantes para os objectivos do processo.

4.2.2 Deteccao de Hot spots

O segundo passo do processo de recuperacao de desenho consiste na deteccao dos pontos devariabilidade da framework, ao seu nıvel de abstraccao mais baixo, ou seja, templates e hooks.

Quando se fala em pontos de variabilidade, normalmente fala-se apenas nos hooks. Noentanto, e para uma total compreensao do proposito destes, e aconselhavel que se saiba quaisos templates que estes parametrizam (ou seja, que os invocam). Logo, a definicao de hot spotcompreende a inclusao de ambos templates e hooks.

Por conseguinte, o processo de deteccao de hot spots consiste na identificacao dos templatese hooks e o seu respectivo relacionamento, e posterior agrupamento em hot spots. Este

4do ingles, Abstract Syntax Tree (AST)


Figura 4.5: Definicao de hot spot, segundo Schauer [Schauer 99].

agrupamento levanta uma questao: granularidade. Qual a melhor forma de agupar templates ehooks por forma a que nao haja uma excessiva redundancia de informacao?

No caso de existir um template a invocar um hook, estamos na presenca de um hot spot. Masse esse mesmo template invocar outro hook, temos outro hot spot. Mas, e no caso de um templateinvocar varios hooks? E se um determinado hook for invocado por mais do que um template?Se todos estes casos fossem considerados hot spots, haveria uma tal redundancia de informacaoque seria muito difıcil que a informacao gerada fosse util para o utilizador, tal seria o esforco dea navegar e compreender.

Um estudo sobre esta problematica foi feito por Schauer em [Schauer 99], o qual apresentauma definicao de hot spot que lida com a questao da granularidade de uma forma equilibrada:

...(um hot spot e) um conjunto de hooks e os seus respectivos templates, em quecada hook e invocado exactamente pelo mesmo conjunto de templates.

Desta forma, agrupam-se todos os hooks que sao invocados pelo mesmo conjunto de templates.Esta definicao pode ser vista na figura 4.5, onde temos um exemplo composto por cinco templates(t1, t2, t3, t4, t5) e tres hooks (h1, h2, h3). O hook h1 e invocado por todos os templates e h2 eh3 sao invocados igualmente por t4 e t5. Logo, o agrupamento gera dois hot spots: HS1 e HS2.

E recorrendo a esta definicao de hot spot que se pretende agrupar os templates e os hooksdetectados no codigo-fonte e apresentar os resultados ao utilizador nesta fase.

4.2.3 Deteccao de Meta-Padroes

Como ja foi dito anteriormente, alem dos hot spots, templates e hooks podem ser agrupadosem classes e relacionados mutuamente segundo abstraccoes denominadas meta-padroes. Nodesenvolvimento de um processo de recuperacao de desenho, no caso, de padroes de desenho,e necessaria uma definicao formal destes. Os meta-padroes fornecem um adequado nıvel deabstraccao para esta definicao.


Modelo formal para a definicao de meta-padroes

Na procura de uma formalizacao para padroes de desenho, considerou-se para este trabalhoque o trabalho de Tourwe, constante na sua tese de doutoramento [Tourwe 02], na qual defineum modelo formal para representar meta-padroes e utilizado para mapear os sete meta-padroesdescobertos por Pree. [Pree 95]. Este modelo baseia-se na definicao de cinco meta-padroesfundamentais a partir dos quais se podem mapear os meta-padroes de Pree.

No ambito do seu modelo formal, Tourwe apresenta a seguinte definicao de meta-padrao:

Um meta-padrao e um tuplo (P, R), onde P e um conjunto de participantes e Re um conjunto de relacoes (ou restricoes) que se verificam entre estes participantes.

O conjunto P de participantes contem as classes, metodos e variaveis que compoem aestrutura do meta-padrao. Alias, um participante pode ser uma simples classe, uma hierarquiade classes, um metodo, um conjunto de metodos ou uma variavel (atributo). Mais, a cadaparticipante e atribuıdo o papel que representa na instancia do meta-padrao. Por exemplo,se uma hierarquia de classes H desempenha o papel de hierarquia de classes hook entao edenominada hookHierarchy(H).

O conjunto R de relacoes (ou restricoes) especifica como os diferentes participantes do meta-padrao se relacionam e interagem entre si. Estas relacoes devem ser respeitadas sempre, porforma a manter a coerencia da estrutura do meta-padrao. Tourwe mapeou todas as relacoesentre participantes que achou relevantes, como se pode ver nas figuras 4.6, 4.7 e 4.8. Nestasrelacoes, considera-se o conjunto C como o conjunto de todas as classes existentes no codigo(ou seja, na framework), o conjunto M como o conjunto de todos os metodos e o conjuntoV como o conjunto de todas as variaveis (atributos) definidas por essas classes. Este ultimoinclui quer variaveis de classe e instancia, quer parametros formais passados para os metodos.Variaveis locais ou temporarias nao sao consideradas, pois nao fazem parte da estrutura de ummeta-padrao.

Notacao do Modelo Formal

Esta representacao textual obedece a algumas regras de notacao, explicadas a seguir para melhorcompreensao da formalizacao.

• Um classe unica e representada por uma letra maiuscula (por exemplo, T ou C );

• Uma variavel (ou atributo) e representada pela letra minuscula v;

• Um metodo e representado pela letra minuscula m. Para diferenciar entre diferentesmetodos, sao utilizados ındices em subscrito (m1,m2,m3);

• Para representar conjuntos finitos de metodos englobam-se estes entre chavetas. Porexemplo, {m1,m2,m3} representa um conjunto de tres metodos distintos. No caso de oconjunto conter apenas um elemento, omitem-se as chavetas (usando-se m para representaro conjunto {m};

• Um metodo pode ser precedido da classe onde esta definido. Por exemplo C :: {h1, h2}significa que a classe C define dois metodos h1 e h2. Quando nao e explicitamente conhecido


uses ⊆ C× C× {single,multiple}uses(C1, C2, single) = usesSingle(C1, C2)uses(C1, C2,multiple) = usesMultiple(C1, C2)

usesSingle ⊆ C× CusesSingle(C1, C2) = a classe C1 referencia apenas uma instancia da classe C2.

usesMultiple ⊆ C× CusesMultiple(C1, C2) = a classe C1 referencia mais do que uma instancia da classe C2.

inherits ⊆ P(C)× Cinherits({C1}, C2) = classe C1 herda directamente da classe C2.inherits(C, C2) = ∀C1 ∈ C : inherits(C1, C2).

inherits? ⊆ P(C)× Cinherits?({C1}, C2) = inherits(C, C2) .inherits?({C1}, C2) = ∃C3 ∈ C : inherits({C1}, C3), inherits?({C3}, C2) .inherits?(C, C2) = ∀C1 ∈ C : inherits?({C1}, C2) .

Figura 4.6: Definicao das relacoes primitivas entre classes, segundo o modelo formal de Tourwe(retirada de [Tourwe 02]).

quais ou quantos metodos contem o conjunto de metodos, utiliza-se a notacao C ::M, ondeM representa um conjunto de metodos. Note-se que nao se confundem os sımbolos paraclasse e conjunto de metodos, pois apesar de serem ambos letras maiusculas, o conjuntode metodos vem sempre precedido pela classe que o define;

• Nas relacoes existe a definicao do domınio dos seus argumentos. Por exemplo, no caso dopredicado uses que tem tres argumentos, a definicao do seu domınio faz-se da seguinteforma: nomedopredicado seguido do sımbolo ⊆ (que significa que os argumentos teraoinstanciacao num subconjunto dos domınios especificados), sendo de seguida especificadosos domınios de cada argumento, separados pelo sımbolo ×. No caso particular de uses,o seu domınio e definido segundo uses ⊆ C × C × {single, multiple}. Isto significa queos primeiros dois argumentos do predicado sao classes e o terceiro e um argumento cujovalor esta contido no conjunto {single,multiple}. Nas definicoes subsequentes da relacao,o sımbolo = (equivale a) serve para definir o corpo do predicado.

Relacoes entre os participantes

Segue-se uma breve descricao das relacoes constantes do modelo formal de Tourwe. Segundoeste, estas relacoes nao estao totalmente formalizadas, dando-se definicoes intuitivas de algumasem linguagem natural. No entanto, as nocoes por formalizar podem se-lo rapida e directamente,utilizando conceitos basicos da orientacao por objectos. Para nao baixar o nıvel de abstraccaoao qual se faz a analise dos meta-padroes, esta formalizacao nao foi abordada no ambito dadefinicao do modelo formal.


invokes ⊆ P(M)× P(M)× {self, v}invokes({m1}, {m2}, self) = metodo m1 invoca metodo m2 na mesma instancia.invokes({m1}, {m2}, v) = metodo m1 invoca metodo m2 atraves da variavel v.invokes(M, {m2}, x) = ∀m1 ∈M : invokes(m1,m2, x).invokes({m1},M, x) = ∀m2 ∈M : invokes({m1}, {m2}, x).invokes(M1,M2, x) = ∀m1 ∈M1,∃m2inM2 : invokes({m1}, {m2}, x).

invokesr ⊆ P(M)× P(M)× {self, v}invokesr(M1,M2, x) = invokes(M1,M2, x),M1 ∩M2 6= 0.

invokes↔ ⊆ P(M)× P(M)× {self, v}invokes↔(M1,M2, x) = ∀m1inM1,∃!m2 ∈M2 : invokes({m1}, {m2}, x),

∀m2inM2,∃!m1 ∈M1 : invokes({m1}, {m2}, x).

Figura 4.7: Definicao das relacoes primitivas entre metodos, segundo o modelo formal de Tourwe(retirada de [Tourwe 02]).

understandsMessage ⊆ C × M. Esta relacao especifica que uma determinada classe Ccompreende uma determinada mensagem m. Isto significa que a classe C ou uma dassuas superclasses fornece uma implementacao concreta para o metodo correspondente.

defineMethod ⊆ C ×M. A classe C define um metodo m se o declara na sua interface. Ometodo pode ser abstracto ou provido de uma implementacao.

definesVariable ⊆ C×V×{variable, formal}. A classe C define uma variavel v se esta e umavariavel de instancia ou de classe (de C) ou foi passado como um parametro formal paraum dos metodos da classe C.

creates ⊆ M × C Esta relacao pode existir entre um metodo e uma classe e significa que ometodo cria e devolve uma instancia dessa classe.

usesSingle ⊆ C×C. Esta relacao pode existir entre duas classes e especifica que um instanciada primeira classe refere uma e so uma instancia da segunda classe.

usesMultiple ⊆ C × C. Esta relacao ocorre entre duas classes e indica que a primeira referemais do que uma instancia da segunda classe. Nao especifica quantas, apenas que saovarias.

inherits ⊆ C × C. Esta relacao pode ocorrer entre duas classes e siginfica que a primeira esubclasse directa da segunda. Existe uma variante transitiva desta relacao denominadainherits?, e que especifica que uma classe C1 e descendente de outra classe C2, nao sendonecessario ser subclasse directa.

invokes ⊆ M × M. Esta relacao pode-se verificar entre dois metodos e especifica que oprimeiro invoca o segundo. Note-se que esta relacao e estatica, ou seja, nao garante que oprimeiro metodo invoque o segundo em tempo de execucao. Por exemplo, se a chamada aosegundo metodo estiver numa clausula condicional, na parte que e executada caso esta sejaverdadeira, e a clausula e sempre falsa, o segundo metodo nunca e invocado. No entanto,


understandsMessage ⊆ P(C)× P(M)understandsMessage({C}, {m}) = classe C conhece o metodo m (talvez indirecta-

mente).understandsMessage(C, {m}) = ∀C ∈ C : understandsMessage({C}, {m}).understandsMessage({C},M) = ∀m ∈M : understandsMessage({C}, {m}).understandsMessage(C,M) = ∀C ∈ C,∀m ∈M :

understandsMessage({C}, {m}).

definesMethod ⊆ P(C)× P(M)definesMethod({C}, {m}) = classe C define o metodo m.definesMethod(C, {m}) = ∀C ∈ C : definesMethod({C}, {m}).definesMethod({C},M) = ∀m ∈M : definesMethod({C}, {m}).definesMethod(C,M) = ∀C ∈ C,∀m ∈M : definesMethod({C}, {m}).

definesV ariable ⊆ P(C)× V× {variable, formal}definesV ariable({C}, v, variable) = classe C define a variavel v como variavel de

instancia.definesV ariable(C, v, variable) = ∀C ∈ C : definesV ariable({C}, v, variable).definesV ariable({C}, v, formal) = classe C define a variavel v como uma parametro

formal num dos seus metodos.definesV ariable(C, v, formal) = ∀C ∈ C : definesV ariable({C}, v, formal).

creates ⊆ P(M)× P(C) .creates({m1}, {C1}) = metodo m1 cria uma instancia da classe C1.creates(M, C) = ∀m ∈M,∃!C ∈ C : creates({m}, {C}).

Figura 4.8: Definicao das relacoes primitivas entre classes, metodos e variaveis, segundo o modeloformal de Tourwe (retirada de[Tourwe 02]).

esta informacao de tempo de execucao nao e relevante para a estrutura do meta-padrao,no que toca a sua deteccao no codigo.

Existem duas variantes desta relacao. A primeira, denominada invokesr especifica que ummetodo invoca-se a si mesmo recursivamente. A segunda, denominada invokes↔, indicaque uma metodo invoca apenas e so um outro metodo e cada metodo so pode ser invocadopor apenas um outro.

Apesar destas descricoes assumirem que as relacoes apenas se verificam para participantessingulares, algumas relacoes tambem se verificam para conjuntos de participantes. Por exemplo,a relacao understandsMessage pode ocorrer entre uma classe C e um metodo m, mas tambemse pode verificar entre um conjunto de classes C e um metodo m ou uma classe C e um conjuntode metodos M. Estes casos apenas estabelecem que cada classe pertencente ao conjunto Cimplementa o metodo m ou que a classe C implementa todos os metodos pertencentes aoconjunto M.

Uma definicao similar, utilizando quantificacao universal (∀), e dada para todas as outrasrelacoes que se verifiquem entre participantes singulares e conjuntos de participantes, exceptopara a relacao invokes. A definicao desta relacao para conjuntos de metodos usa o quantificador


root ⊆ H −→ C : H −→ C onde C e o elemento maximo de H para arelacao inherits.

leafs ⊆ H −→ P(C) : H −→ {C1, C2, ..., Cn} onde Ci e o elemento mınimo de H para arelacao inherits?.

hierarchy ⊆ C −→: C −→ H onde H e a hierarquia de classes geradapor C.

Figura 4.9: Definicoes preliminares sobre hierarquias de classes, segundo o modelo formal deTourwe (retirada de [Tourwe 02]).

existencial (∃!), isto porque todos os metodos do conjunto M1 nao devem invocar todos osmetodos do conjunto M2, mas pelo menos um deles. Por outro lado, nem todos os metodos doconjunto M2 precisam de ser invocados por um metodo do conjunto M1.

Nocao de Hierarquia de Classes

Para alem de classses, metodos e atributos, uma parte importante da framework consiste nasdiferentes hierarquias de classes que define. Sendo este um conceito importante, esta incluıdono modelo formal de representacao de meta-padroes.

Define-se por H o conjunto de todas as hierarquias da framework, o qual e um subconjunto deP(C), onde P representa o conjunto de todos os subconjuntos e C o conjunto de todas as classesda framework. Se C e uma classe da framework, entao define-se hierarchy(C) como a hierarquiade classes gerada por C, ou seja, a classe C juntamente com os seus descendentes directos eindirectos. Uma hierarquia de classes H ∈ H define sempre uma relacao inherits ⊆ C × C,e tem um elemento (classe) maximo unico ou raiz da hierarquia denominado root(H) e umconjunto de elementos (classes) mınimos ou folhas da hierarquia denominado leafs(H). Nafigura 4.9 pode-se ver as definicoes destes predicados. Note-se que as folhas da hierarquia naoprecisam de ser descendentes directos da raiz da hierarquia.

Uma hierarquia de classes sera representada pelo simboloH. Uma hierarquia que implementeum conjunto de metodos sera representada por este precedido pelo sımbolo da hierarquia:H :: M. De notar que, ao contrario da notacao para metodos implementados por classes(C ::M), para hierarquias isto nao significa que cada classe da hierarquia H tera de implementartodos os metodos de M. Significa que todos os metodos de M estao definidos na classe raizda hierarquia (rootH), sao abstractos ou com um implementacao por omissao, e todas as folhas(classes) da hierarquia (leafsH), conhecem (understandsMessage) os metodos. Isto nao querdizer que todas as classes-folha tenham de ter uma implementacao concreta dos metodos, masalgures nas suas classes ascendentes essa implementacao tera de existir (no limite, existira naclasse raiz). Formalizando:

H :: M⇔ definesMethod({root(H)},M) e understandsMessage(leafs(H),M)


Meta-padroes fundamentais

Nesta seccao, apresentam-se as bases do modelo formal de Tourwe para a definicao dos meta-padroes. Ao inves de mapear os sete meta-padroes conhecidos de Pree [Pree 95], Tourweanalisa-os e descobre que estes tambem tem participantes comuns, que denomina de meta-padroes fundamentais. Estes fornecem uma abstraccao extra sobre os meta-padroes e, como sepodera verificar, os seus nomes sao abstraıdos dos de Pree. Estes meta-padroes fundamentaissao bastante parametrizaveis para os tornar o mais genericos possıvel. E possıvel mapear ospadroes de Pree utilizando estes cinco meta-padroes, como e provado em [Tourwe 02], e cujademonstracao nao cabe no ambito desta dissertacao.

Unification fundamental metapattern

Este padrao consiste de tres participantes: uma hierarquia H, um conjunto de templatesH :: Mt e um conjunto de hooks H :: Mh. A classe template e a classe hook deste meta-padraosao a mesma e uma so: a classe raiz da hierarquia H. Esta classe implementa todos os templatesH ::Mt, em que cada um destes invoca um ou mais hooks de H ::Mh. Estes hooks sao definidospela classe raiz, existindo uma implementacao concreta na hierarquia de modo a que todas asclasses-folha conhecam o metodo. Relembre-se que a definicao do predicado invokes especificaque cada template participante deve invocar pelo menos um hook participante, e que nem todosos hooks participantes tem de ser invocados por um template participante. Deste modo, o meta-padrao pode ser definido formalmente da seguinte forma:

unificationFundamentalMP (H,H :: Mt,H :: Mh) em que:

participantes:

hookhierarchy(H)templatemethods(H :: Mt)hookmethods(H :: Mh)

restricoes:

understandsMessage(root(H),H :: Mt)definesMethod(root(H),H :: Mh)understandsMessage(leafs(H),H :: Mh)invokes(H :: Mt,H :: Mh, self)

Connection fundamental metapattern

Este padrao e composto por cinco participantes: uma classe template T , uma hierarquiade hooks H, um conjunto de templates T :: (M)(t), um conjunto de hooks H :: (M)(h) e umavariavel de referencia v. Esta variavel e definida na classe template T participante e podeguardar uma referencia a uma unica instancia de uma classe-folha da hierarquia classe template,ou a varias instancias dessas classes. Alem disso, a classe template T implementa um numero


de templates T :: (M)(t). Cada um destes templates usa o objecto referenciado pela variavel vpara invocar o(s) hook(s) respectivo(s). Estes hooks H :: (M)(h) sao definidos pela classe raizda hierarquia H, e existe uma implementacao concreta presente na hierarquia para que todasas classes-folha a conhecam. Formalmente:

connecionFundamentalMP (T,H, T :: Mt,H :: Mh, v, Multiplicity, Association) em que:

participantes:

referenceV ariable(v)templateClass(T )hookhierarchy(H)templatemethods(T :: Mt)hookmethods(H :: Mh)

restricoes:

understandsMessage(T,H :: Mt)definesMethod(root(H),H :: Mh)definesV ariable(T, v,Association)understandsMessage(leafs(H),H :: Mh)uses(T, root(H),Multiplicity)invokes(T :: Mt,H :: Mh, v)

Como se pode ver, a definicao deste meta-padrao fundamental e parametrizada com osargumentos Multiplicity e Association. Estes permitem dotar a definicao de flexibilidadepara que seja possıvel usar-se como base para a definicao de varios meta-padroes similiares,por exemplo, 1:1 Connection metapattern e 1:N Connection metapattern (ver figura 4.2). Oargumento Multiplicity pode ter dois valores possıveis: single e multiple, e especifica quantasinstancias de classes hook sao referenciadas pela classe template T . O argumento Associatione usado para determinar se a referencia mantida pela classe template T e feita atraves de umavariavel de instancia ou atraves de um parametro formal. Por conseguinte, pode tomar doisvalores: variable e formal.

A referencia mantida pela classe template e usada por todos os templates para invocar oshooks na hierarquia de classes hook. Se esta referencia e mantida atraves de uma variavel deinstancia, todos os templates tem acesso a ela. No entanto, se a referencia e mantida por umparametro formal, entao deve ser possıvel passar este parametro para dentro dos templates paraque estes o possam usar para invocar os hooks, assim, devem fornecer um interface adequadopara o fazer.

Recursion fundamental metapattern

Este padrao e constituıdo por cinco participantes: uma classe template T , uma hierarquiade classes hook H, uma variavel de referencia v, um conjunto de templates T :: (M)h definidosna classe T e um conjunto de hooks H :: (M)h definidos na hierarquia H. Note-se que para


todos os metodos do conjunto T :: (M)h existe um metodo no conjunto H :: (M)h com a mesmaassinatura, daı os conjuntos terem o mesmo nome ((M)h).

Neste meta-padrao fundamental, uma instancia da classe template T pode referir apenasuma ou varias instancias de classes-folha da hierarquia de classes hook H. Estas instancias saoreferenciadas atraves da variavel v, definida na classe template T . Esta classe esta ela propriaincluıda na hierarquia de classes hook H, seja como classe raiz ou como uma classe-folha conc-reta. Adicionalmente, a classe raiz da hierarquia de classes hook H define todos os hooks comometodos abstractos e todas as classes-folha conhecem uma implementacao concreta para estes.Apesar de isto significar imediatamente que a classe T tambem conhece essa implementacaoconcreta, esta relacao e explicitamente incluıda na definicao. Por fim, a relacao invokes(r) eusada para denotar o facto de que os templates invocam recursivamente os hooks. Logo:

recursionFundamentalMP (T,H, T :: Mh,H :: Mh, v,Multiplicity, Association) em que:

participantes:

referenceV ariable(v)templateClass(T )hookhierarchy(H)templatemethods(T :: Mh)hookmethods(H :: Mh)

restricoes:

definesMethod(root(H),H :: Mh)definesV ariable(T, v,Association)understandsMessage(leafs(H),H :: Mh)inherits?(T, root(H))understandsMessage(T, T :: Mh)uses(T, root(H),Multiplicity)invokes(T :: Mt,H :: Mh, v)

Hierarchy fundamental metapattern

Este padrao compoe-se de cinco participantes: duas hierarquias H1 e H2, um unico templateH1 :: t, um conjunto de hooks H2 :: Mh e uma variavel de referencia v. A classe raiz da primeirahierarquia define o template t, o qual e redefinido (overridden) por cada classe-folha concretadesta hierarquia. Igualmente, a classe raiz da segunda hierarquia define os hooks H2 :: Mh, cujaimplementacao concreta e conhecida para todas as classes-folha da hierarquia. As instanciasdas classes da primeira hierarquia podem aceder a instancias de classes da segunda hierarquiaatraves da variavel de referencia v, sendo isto possıvel de duas maneiras: (1) definindo a variavelde referencia na classe raiz e, logo, acessıvel a todas as restantes classes da hierarquia ou (2)a variavel pode ser passada como argumento para dentro do template t que invoca os hooks.Cada template definido na hierarquia H1 invoca uma hook diferente, definido na hierarquia H2,reflectindo-se esta restricao na relacao invokes↔ entre templates e hooks. Por conseguinte:


hierarchyFundamentalMP (H1,H2,H1 :: t,H2 :: Mh, v,Multiplicity, Association) em que:

participantes:

referenceV ariable(v)templateHierarchy(H1)hookhierarchy(H2)templatemethods(H1 :: t)hookmethods(H2 :: Mh)

restricoes:

definesMethod(root(H1),H1 :: t)definesV ariable(leafs(H1), v, Association)understandsMessage(leafs(H1),H1 :: t)definesMethod(root(H2),H2 :: Mh)understandsMessage(leafs(H2),H2 :: Mh)uses(root(H1), root(H2),Multiplicity)invokes↔(H1 :: t,H2 :: Mh, v)

Creation fundamental metapattern

Este padrao consiste de tres participantes: duas hierarquias H1, H2 e um unico template t.Este metodo e definido na classe raiz da primeira hierarquia e existe uma implementacao conc-reta conhecida por todas as classes-folha da hierarquia. Para cada uma destas classes-folha,o template cria uma instancia de uma classe-folha diferente da segunda hierarquia, tal sendorepresentado pela relacao creates↔:

creationFundamentalMP (H1,H2,H1 :: t) em que:

participantes:

templateHierarchy(H1)hookhierarchy(H2)templatemethods(H1 :: t)

restricoes:

definesMethod(root(H1),H1 :: t)understandsMessage(leafs(H1),H1 :: t)creates↔(H1 :: t, leafs(H2))

Recorrendo a este modelo formal para definicao de meta-padroes, parte-se de uma basesolida para a representacao destes elementos de elevado nıvel de abstraccao, sendo mais facil asua deteccao e, como se vera a seguir, a representacao formal de padroes de desenho.


Figura 4.10: Mapeamento do padrao de desenho Composite segundo o meta-padrao fundamentalRecursion (adaptada de [Gamma 95]).

4.2.4 Reconhecimento de Padroes de Desenho

A extraccao automatica de padroes de desenho e uma tarefa bastante difıcil [Campo 97]. Comoum padrao de desenho nao impoe uma implementacao particular, mas apenas sugere umaabordagem, existem varias formas de o implementar. Instancias de padroes de desenho cujaimplementacao varie significativamente da abordagem sugerida correm o risco de nao seremdetectadas por uma ferramenta de extraccao. Mais, muitos padroes de desenho tem umaestrutura similar, variando apenas em questoes de semantica, como por exemplo os padroesStrategy e State, vistos na figura 2.5. Por conseguinte, uma ferramenta de extraccao automaticanao consegue aferir com total certeza qual dos padroes o utilizador pretendeu usar.

Por outro lado, inspeccionar em detalhe todas as classes e metodos de uma framework aprocura de um determinado padrao e uma tarefa algo dispendiosa, pelo que e muito mais facile rapido verificar se uma determinada especificacao de alto-nıvel se encontra implementada nocodigo, sem se preocupar com detalhes especıficos de implementacao.

O uso dos meta-padroes como base de especificacao alto-nıvel de padroes de desenho ofereceuma independencia dos detalhes de implementacao e uma formalizacao precisa que ajuda nadeteccao destes.

Apesar da formalizacao oferecida pelos meta-padroes, a representacao dos padroes dedesenho podera sempre ter ambiguidades e redundancias, dependendo de quem procede a essarepresentacao. No entanto, a simples constatacao da existencia dos meta-padroes ja e um passoimportante para ajudar no reconhecimento dos padroes de desenho, cabendo depois ao utilizadoraferir qual a instancia de padrao de desenho implementada sobre um determinado meta-padrao.

A tıtulo de exemplo, mostram-se de seguida alguns padroes de desenho retirados de[Gamma 95] representados usando o modelo formal proposto por Tourwe (seccao 4.2.3).


Composite

O padrao de desenho Composite traduz-se como uma instancia do meta-padrao fundamentalRecursion visto na seccao 4.2.3. Os papeis definidos para os elementos do padrao de desenhoterao de ser traduzidos para os elementos constantes no meta-padrao. Para ajudar a formalizacaodeste e dos restantes padroes de desenho, dois novos predicados sao introduzidos, seguindo asmesmas regras que os restantes predicados existentes no modelo formal:

isRoot ⊆ C × C Esta relacao verifica-se quando a primeira classe e raiz da hierarquia geradapela segunda classe.

isLeaf ⊆ C × C Esta relacao verifica-se quando a primeira classe e classe-folha da hierarquiagerada pela segunda classe.

Igualmente, para melhor entendimento de quais sao os participantes do padrao de desenho, asclasses passaram a ter a sua denominacao a comecar em letra maiuscula, ao inves de ser umaunica letra. Logo, uma formalizacao do padrao sera:

compositeDP (Composite, Component, Leaf) =⇒

isRoot(Component,H)isLeaf(Leaf,H)recursionFundamentalMP (Composite,H, Component :: Mh,H :: Mh, v, ”multi”, ”variable”)

Desta forma, os papeis dos elementos de Composite encontram correspondencia comos intervenientes da definicao formal do meta-padrao fundamental Recursion. O elementoComposite corresponde a classe template T na definicao do meta-padrao fundamental, o elementoComponent corresponde a raiz da hierarquia de classes hooks H e o elemento Leaf correspondea uma ou mais classes-folha da hierarquia de classes hook H. Atente-se as restricoes adicionaisrelativas aos parametros Multiplicity e Association, que passam a ter os valores ”multi”e”variable”para filtrar aquelas instancias do meta-padrao que realmente interessam. Estesmapeamentos podem ser vistos na figura 4.10.

Factory Method

O padrao de desenho Factory Method traduz-se numa instancia do meta-padrao fundamentalCreation, segundo a seguinte formalizacao:

factoryMethodDP (Creator, ConcreteCreator, Product, ConcreteProduct, factoryMethod) =⇒

isRoot(Creator,H1)isLeaf(ConcreteCreator,H1)isRoot(Product,H2)isLeaf(ConcreteProduct,H2)creationFundamentalMP (H1,H2,H1 :: factoryMethod)


Figura 4.11: Mapeamento do padrao de desenho Factory Method segundo o meta-padraofundamental Creation (adaptada de [Gamma 95]).

Por conseguinte, o elemento Creator e classe raiz da primeira hierarquia H1 enquanto queo elemento ConcreteCreator e classe-folha da mesma hierarquia. O elemento product e classeraiz da segunda hierarquia enquanto que o elemento ConcreteProduct e classe-folha da mesmahierarquia. Por fim, o elemento factoryMethod corresponde ao template H1 :: t na definicao dometa-padrao fundamental Creation. Estes mapeamentos podem ser vistos na figura 4.11.

State

O padrao de desenho State traduz-se numa instancia do meta-padrao fundamentalConnection, segundo a seguinte formalizacao:

stateDP (Context, State, ConcreteState) =⇒

isRoot(State,H)isLeaf(ConcreteState,H)connectionFundamentalMP (Context,H, Context :: Mt,H :: Mh, v, ”single”, ”variable”)

O participante Context corresponde a classe template T , sendo State a classe raiz dahierarquia de classes hook H e ConcreteState uma ou mais classes-folha da hierarquia de classeshook H. De notar que os parametros Multiplicity e Association sao preenchidos com os valores”single”e ”variable”visto a Context referir apenas uma instancia de State e a referencia a estaser feita atraves de uma variavel de instancia (state). Tal pode ser visto na figura 4.12.

Em suma, o reconhecimento de padroes de desenho depende em grande parte de umacorrecta formalizacao daqueles. Recorrer aos meta-padroes facilita essa formalizacao e permiterapidamente um mapeamento simples e coeso.


Figura 4.12: Mapeamento do padrao de desenho State segundo o meta-padrao fundamentalConnection (adaptada de [Gamma 95]).

Naturalmente que aspectos havera que serao demasiado dependentes do contexto e em queuma formalizacao a este nıvel de abstraccao nao e suficiente para representar univocamentetodos os padroes de desenho existentes ou conhecidos:

• Forte similaridade entre padroes. Basta ver exemplos de similaridade forte entre padroescomo o caso do State e Strategy, que podem ser vistos na figura 2.5;

• Sobreposicao de padroes. Casos dos padroes Factory e AbstractFactory onde o segundoe composto por instancias do primeiro, e Composite e Decorator onde o primeiro estacontido no segundo;

• Padroes nao se compoem de meta-padroes. Os casos dos padroes Singleton e Facade ondenao se encontram instanciados nenhum dos meta-padroes conhecidos, logo a abordagembaseada em meta-padroes nao ira detectar estas instancias.

Nestes casos, a formalizacao tera de recorrer a outros conceitos para eliminar estasredundancias, tais como analise dinamica de codigo.

No caso desta abordagem, fica a cargo do utilizador intervir no processo de recuperacaode desenho e aferir que classificacao dar as instancias de padroes de desenho encontradas. Noentanto, essa tarefa nao sera difıcil pois, a partir de instancias dos meta-padroes fundamentaise bastante linear aferir qual o padrao de desenho que se apresenta.

4.2.5 Producao de Documentacao

A problematica a volta da documentacao de frameworks tem sido um assunto abordado pordiversos autores presentes na literatura. Devido a sua complexidade uma framework e difıcil dedocumentar convenientemente. [Aguiar 03b] atribui as causas deste facto a quatro requisitos:

• Audiencias diferentes. As frameworks podem ser usadas de diferentes formas e por variaspessoas com perfis distintos. Existem quatro tipos de utilizadores de frameworks: os que


as seleccionam, os que desenvolvem aplicacoes a partir destas, os que as desenvolvem e osque desenvolvem outras frameworks. Para ter utilidade, a documentacao deve ter em contaos requisitos destes utilizadores em termos de tipo de informacao, nıvel de abstraccao edetalhe e ambito (se global ou local);

• Diferentes tipos de documentos. Para satisfazer as diferentes audiencias e requisitos, adocumentacao fornece varias vistas (estatica, dinamica, externa, interna) a diferentesnıveis de abstraccao (arquitectura, desenho, implementacao). Exemplos tıpicos de tiposde documentacao sao: overviews, exemplos de aplicacoes, cookbooks e recipes, padroes dedesenho, casos de uso, contractos, cadernos de desenho e manuais de referencia;

• Notacoes diferentes. Dependendo do aspecto concreto do documento, pode ser convenienteo uso de conteudos mistos representados sob diferentes notacoes: texto livre, textoestruturado, codigo-fonte, diagramas de objectos, imagens, especificacoes formais, etc.Alem disso, para assegurar uma boa navegabilidade, os conteudos devem estar mutuamenteligados por referencias, uma tarefa que requer o uso de ferramentas de apoio em prol daeficiencia e economia de recursos;

• Facil de usar. Toda esta rede complexa de documentos e conteudos deve ser apresentadaas diferentes audiencias de uma forma simples, para que os leitores nao se sintam perdidosaquando da sua utilizacao. Pretende-se que estes adquiram rapidamente o nıvel deconhecimento suficiente para proceder eficientemente com as suas tarefas de engenharia,sejam elas de reutilizacao, manutencao ou evolucao.

Como resultado desta complexidade de requisitos, o custo de produzir boa documentacao, semmetodos ou ferramentas bem definidas, pode ser bastante alto e, pior ainda, bastante arriscado.

Nexte contexto, [Johnson 92] afirma que, devido a fornecer uma abstraccao acima do nıveldas classes e objectos, os padroes de desenho sao uma forma natural de documentar frameworks,descrevendo o proposito desta, a razao por detras de decisoes de desenho e o seu ensino apotenciais utilizadores. [Beck 94, Gamma 95] corroboram, afirmando que os padroes de desenhosao particularmente bons na documentacao de frameworks porque capturam a experiencia dedesenho num nıvel de micro-arquitectura e contem informacao de como a flexibilidade se encontraincorporada na framework. Por seu lado, e como dito anteriomente, [Pree 95] certifica que,apesar de os meta-padroes mapearem conceitos de alto-nıvel de abstraccao mas com poucodetalhe de implementacao e, logo, serem menos apropriados para documentar directamente ospapeis dos elementos da framework, aqueles sao extremamente uteis para documentar os papeisdos elementos participantes nos padroes de desenho.

Respondendo a esta problematica, o processo proposto nesta dissertacao produz resultadosintermedios de relevancia para o utilizador da framework, a varios nıveis de abstraccao. Essesresultados tem visibilidade para aquele de duas formas: (1) visualizados graficamente durante oprocesso e (2) de uma forma mais persistente, sob a forma de documentacao.

Esta documentacao e produzida a todos os passos sucessivos de deteccao de elementosde desenho. Assim, desde logo, o utilizador tem possibilidade de utilizar essa informacao,escolhendo o nıvel de abstraccao e quantidade de informacao que pretende para optimizar asua aprendizagem da framework.

O processo visa gerar documentacao que abranja diversos formatos, dando-lhe flexibilidadepara abarcar diferentes domınios de conhecimento, alargando a sua utilidade e aproveitamento

4.3. A Abordagem em 4 Passos 67

noutros contextos. Exemplos de formatos possıveis sao UML [Object Management Group 03],Javadoc [Sun Microsystems 03], XSDoc [Aguiar 03a] e SVG [Ferraiolo 03].

4.3 A Abordagem em 4 Passos

Em conclusao, esta dissertacao propoe uma abordagem a recuperacao de desenho de umaframework, com o proposito de facilitar a sua (re)utilizacao, identificando os elementos que lheincorporam flexibilidade, a diferentes nıveis de abstraccao e detalhe, nomeadamente, templatese hooks, hot spots, meta-padroes e padroes de desenho.

O processo semi-automatico de engenharia reversa proposto e composto por varias fasesconsecutivas de analise do codigo-fonte e deteccao sucessiva dos varios elementos de desenhoda framework. Os resultados de uma fase sao passados para a seguinte, seguindo um estilo dearquitectura Pipes & Filters [Buschmann 96, Garlan 93].

Numa primeira fase, procede-se a analise do codigo-fonte, identificando os elementosrelevantes para posterior analise, convertendo-os para uma estrutura de alto-nıvel (AbstractSyntax Tree) mais facil de navegar e processar.

Num segundo passo, sao detectados os elementos basilares da flexibilidade da framework: ostemplates, pontos de invariabilidade e os hooks, pontos de variabilidade. Estes elementos saoagrupados, segundo uma heurıstica de minimizacao da redundancia e reducao da granularidade,em hot spots.

Num terceiro passo, os templates e hooks sao agrupados segundo a sua estrutura em classese relacionamento recıproco segundo um conceito de alto-nıvel de abstraccao denominado meta-padrao [Pree 95]. Neste passo, recorre-se a um modelo formal abstracto, segundo [Tourwe 02]para a representacao destes meta-padroes, com vista a facilitar a deteccao destes e eliminarvariantes de implementacao.

Num quarto e ultimo passo, analisam-se os meta-padroes detectados e, com a intervencao doutilizador (para eliminar redundancias e sobreposicoes), faz-se o reconhecimento de instanciasde padroes de desenho que estejam presentes no desenho da framework.

No final de cada um dos segundo, terceiro e quarto passos, e produzida documentacao queregiste os resultados obtidos na deteccao dos elementos de desenho correspondentes. Estadocumentacao e fornecida em varios formatos com vista a abranger uma maior audiencia deutilizadores.

Capıtulo 5

JFREEDOM — um plug-in para oEclipse

Apresentada a abordagem proposta para a recuperacao de desenho, este capıtulo aborda aferramenta de apoio a sua utilizacao. O estudo previo de ferramentas existentes (seccao3.2) revela que, do ponto de vista da reutilizacao de software, a informacao produzida ve-sedesprovida de grande utilidade pois apenas sao apresentados resultados ao nıvel dos padroes dedesenho e com diferentes graus de certeza.

Com a introducao de graus intermedios de complexidade e abstraccao, o utilizador pode,mesmo com resultados no final do processo (padroes de desenho) de grau variante de certeza,aproveitar os resultados intermedios, muito mais precisos, como ferramenta de apoio areutilizacao de software. Por conseguinte, a ferramenta proposta visa ser:

• integravel num ambiente de desenvolvimento de software;

• flexıvel, por forma a permitir configurar e estender a sua base de conhecimento para abarcarnovas de definicoes de padroes de desenho e outra informacao relevante ao processo derecuperacao de desenho;

• interactiva ate um determinado nıvel, permitindo ao utilizador intervir e controlar oprocesso de recuperacao de desenho;

• geradora de informacao visual util, seja sob a forma textual ou grafica, para que o utilizadorpossa imediatamente aferir a utilidade dos resultados.

Seguidamente sao apresentadas as tecnologias escolhidas para a implementacao daferramenta. Posteriormente, aborda-se a arquitectura da mesma, detalhando cada um dos seusmodulos constituintes e focando, no final, as suas limitacoes.

5.1 Tecnologias Utilizadas

Nesta seccao abordam-se as tecnologias utilizadas na implementacao da ferramenta de apoioa implementacao da abordagem. Apresentam-se as respectivas arquitecturas e funcionalidadesinerentes e as razoes que levaram a sua escolha.

69

70 5 JFREEDOM — um plug-in para o Eclipse

5.1.1 Eclipse

O consorcio Eclipse e uma comunidade de codigo-aberto1 cujos projectos visam fornecer umaplataforma extensıvel de desenvolvimento de software, juntamente com diversas frameworksaplicacionais. A plataforma Eclipse disponibiliza ferramentas e frameworks que abrangem todo ociclo de desenvolvimento de software, dando suporte a modelacao de arquitecturas, ambientes dedesenvolvimento para Java, C/C++ e outras linguagens, testes e desempenho, logica de negocio,aplicacoes cliente e desenvolvimento integrado. Esta plataforma e fomentada e apoiada por umlargo conjunto de instituicoes dos mais variados ambitos, desde fornecedores de tecnologia, auniversidades e institutos ligados a investigacao [Eclipse Foundation 05].

Filosofia e objectivos

No seu amago, a plataforma tem como objectivos principais, os seguintes [IBM Corporation 04]:

• O que se pretende e um nıvel de integracao que ”magicamente”agregue ferramentasdesenvolvidas separadamante ,num mesmo ambiente bem desenhado e concebido. Deveraser simples o suficiente para que ferramentas que ja existam possam facilmente seradaptadas a plataforma sem a necessidade de muito esforco ou de recorrer a um ”pe-de-cabra”;

• Deve ser aberta, de tal forma que os utilizadores podem seleccionar ferramentas do melhorfornecedor, podendo este ter uma palavra a dizer no desenvolvimento da plataformasubjacente;

• Deve ser de facil compreensao, no entanto, robusta o suficiente para que a integracao denovas ferramentas nao implique um desenvolvimento extenso de codigo de integracao, ochamado ”codigo-cola”;

• Deve fornecer ferramentas que ajudem na automatizacao das tarefas mais banais.

• Deve ser estavel o suficiente que permita o desenvolvimento de ferramentas de nıvel eexigencia industriais.

• Deve ser util o suficiente para que a propria plataforma possa ser desenvolvida recorrendoa ela mesma.

Pela sua construcao, a plataforma nao fornece uma grande quantidade de funcionalidadesso por si. O grande valor acrescentado esta naquilo que encoraja: o desenvolvimento rapido defuncionalidades integradas, baseadas num modelo de plug-ins.

O Eclipse fornece um modelo comum de interface com o utilizador para interagir com asferramentas desenvolvidas. Foi concebido para correr em varios sistemas operativos, estandorobustamente integrado com cada um deles. As ferramentas ou plug-ins podem usar as API s2

portaveis do Eclipse e executar as suas funcionalidades, sem diferencas, nos varios sistemasoperativos.

1do ingles, open-source2Application Programming Interface, uma biblioteca de classes e/ou funcoes que permitem implementar

funcionalidades dentro de um ou varios domınios de conhecimento

5.1. Tecnologias Utilizadas 71

No nucleo do Eclipse esta uma arquitectura para a identificacao dinamica, carregamento eexecucao de plug-ins. A plataforma lida com toda a logıstica de encontrar e correr o codigo-fontecerto. Com um interface com o utilizador comum, cada plug-in apenas tem de se preocupar comas suas tarefas especıficas.

Arquitectura

A plataforma Eclipse define uma arquitectura aberta por forma a que quem desenvolve plug-ins se possa concentrar exclusivamente na sua area de especialidade. Esta arquitectura assentanum modelo de ”bancada de trabalho comum”ou common workbench onde se podem integrarferramentas do ponto de vista do utilizador final. Estas ferramentas (plug-ins) ”ligam-se”aworkbench atraves de pontos (”hooks”) bem definidos denominados pontos de extensao ouextension points. Um plug-in nao e mais do que um pacote estruturado de codigo-fonte e/oudados que contribuem com funcionalidades para o sistema. Estas funcionalidades podem serbibliotecas de codigo, extensoes da plataforma ou ate documentacao. Por seu lado, um plug-inpode definir novos pontos de extensao a outros plug-ins.

A propria plataforma e construıda sobre camadas sucessivas de plug-ins, cada um estendendoas funcionalidades da plataforma, ligados a pontos de extensao dos plug-ins de nıvel inferior, edefinindo eles proprios pontos de extensao para eventuais novas funcionalidades (plug-ins). Estemodelo de extensao permite a quem desenvolve plug-ins acrescentar uma variedade de novasfuncoes as ja existentes de base na plataforma. Os recursos que cada ferramenta utiliza saocoordenados por um modelo comum a todos denominado common platform resource model eque facilita a gestao daqueles.

O SDK3 do Eclipse inclui a plataforma basica composta por ferramentas de escrita enavegacao no codigo (Workspace), gestao de trabalho em equipa (Team), documentacao de ajuda(Help), desenvolvimento de interfaces graficas (JFace, SWT ) e operacoes em tempo de execucao(Platform Runtime). Adicionalmente, incluı duas ferramentas de extrema importancia para odesenvolvimento de plug-ins: O JDT, Java Development Tools que implementa um ambientede desenvolvimento completo em Java e o PDE, Plug-In Developer Environment que acrescentaferramentas especializadas que apoiam o desenvolvimento de plug-ins e extensoes. Estas duasferramentas nao so servem um proposito util como tambem sao excelentes exemplos de comonovas ferramentas podem ser integradas na plataforma e estende-la. Esta arquitectura pode servista na figura 5.1.

5.1.2 Java e o JDT

A escolha do Eclipse como plataforma de desenvolvimento de ferramentas e de integracao dasmesmas teve, para alem deste aspecto, outro que tambem contribuiu para a sua escolha: O JavaDevelopment Tools, ou, JDT. Esta ferramenta permitiu abordar a primeira fase do processo derecuperacao de desenho, ou seja, a analise de codigo, de uma forma rapida e eficiente.

Da sua composicao constam diversas ferramentas ou plug-ins, passıveis de serem utilizadose estendidos, nomeadamente:

• Core. Ferramenta que define toda a infraestrutura que nao tenha a ver com a interfacegrafica com o utilizador. Entre outras funcionalidades, realcam-se duas: (1) um modelo que

3Software Development Kit, um pacote de ferramentas que permite o desenvolvimento de software


Figura 5.1: Arquitectura da plataforma Eclipse (retirada de [IBM Corporation 04]).

permite navegar atraves da arvore de sıntaxe abstract (Abstract Syntax Tree) do codigo-fonte e que define abstraccoes para os elementos do codigo desde packages a unidades decompilacao, classes, metodos, atributos, etc. e (2) uma infraestrutura de pesquisa indexadaque permite encontrar elementos no codigo-fonte, mapeados segundo o modelo anterior;

• UI. Ferramenta que define toda a infraestrutura de interface com o utilizador, contribuindocom diversas vistas sobre o projecto Java (Package View, Type Hierarchy View, JavaOutline View, etc.) bem como o editor de codigo, com diversas funcionalidades de edicaoe visualizacao;

• Debug. Ferramenta que implementa funcionalidades de depuracao de codigo em tempo deexecucao. E construıdo em cima do motor de depuracao de codigo da plataforma, o quale independente da linguagem-alvo.

Com a capacidade de facil e rapidamente criar uma infraestrutura que permitisse pesquisarelementos na arvore de sıntaxe abstracta do codigo-fonte, e sem outra ferramenta gratis decodigo-aberto conhecida com semelhante potencial, a escolha do Eclipse e do JDT foi consideradaa melhor opcao e tambem a mais acessıvel. Esta escolha teve como efeito colateral, o Java, comolinguagem de desenvolvimento.

5.1.3 JQuery

Necessidades

Com a definicao de um modelo formal para a representacao dos meta-padroes, era necessarioimplementar uma heurıstica que aplicasse essas restricoes na pesquisa dos elementos necessariosa identificacao das estruturas que agrupassem templates e hooks em meta-padroes.

Se a infraestrutura de pesquisa do JDT era mais do que suficiente para encontrar elementos denıvel de abstraccao baixo (como os templates e hooks) e agrupa-los em hot spots, mais complicada

5.1. Tecnologias Utilizadas 73

Figura 5.2: Vista do plug-in JQuery.

e a tarefa de pesquisar elementos de alto nıvel de abstraccao como o sao os meta-padroes. Alemdo mais, representados segundo um modelo formal bastante generico, o esforco de mapeamentode todas as hipoteses que se encaixassem no modelo seria bastante dispendioso.

Entre as varias alternativas possıveis estudadas [Filho 99, Mitchell 03, Jang 03], considerou-se como a mais interessante o JQuery [Volder 04b], tambem este um plug-in para o Eclipse eque se adequou ao problema em maos.

Plug-in

Segundo o seu autor, Kris de Volder, o JQuery e uma ferramenta de pesquisa de codigo-fonteJava que assenta em perguntas formuladas atraves de uma linguagem de interrogacao. Aposa seleccao de um conjunto de pacotes de codigo java (working set), um utilizador do JQuerypode definir as suas perguntas (queries) recorrendo a essa linguagem de interrogacao, sendo-lhe os resultados apresentados segundo uma estrutura em arvore navegavel (ver figura 5.2).Igualmente, o utilizador pode escolher de uma lista de perguntas pre-definidas e executa-las oumodifica-las a medida das suas necessidades. Elementos individuais na arvore tambem podemser alvo de uma pesquisa ou interrogacao. O utilizador pode especificar como pretende que osresultados sejam organizados na arvore atraves de um simples editor da ordem das variaveis depesquisa.


TyRuBa

A linguagem de interrogacao utilizada para formular as perguntas e uma linguagem logicasemelhante ao Prolog, e baseia-se no TyRuBa.

O TyRuBa [Volder 04c] e uma linguagem de programacao em logica implementada emJava. O seu proposito inicial era o da geracao de codigo Java, por exemplo, de padroesde desenho [Volder 03]. A sua genese provem do trabalho de doutoramento do autor doJQuery, Kris De Volder, para a experimentacao de uma nova nocao de type-oriented logic metaprogramming. O nome TyRuBa e uma acronimo de Type Rule Base. No entanto, o sistemanao tem funcionalidades especıficas que o restrinja apenas a esta nocao, mas apresenta-se comouma linguagem de programacao em logica generica com algumas peculiaridades que facilitam amanipulacao de codigo Java, fomentadas com o proposito da geracao de codigo.

Pela sua generalidade, o TyRuBa pode ser usado nao so em aplicacoes de geracao de codigo,mas tambem noutro tipo de aplicacoes que lidem com o processamento de codigo Java, como e ocaso do JQuery. Consequentemente, a linguagem de interrogacao do JQuery e definida como umconjunto de predicados que operam sobre factos gerados pelo TyRuBa e que tem a sua origemnum pre-processamento da arvore de sıntaxe abstracta segundo o modelo de dados fornecidopelo JDT.

A sua aplicabilidade na implementacao do processo de recuperacao de desenho e substancialna medida em que a definicao dos meta-padroes assenta num modelo formal. Por conseguinte,se esses formalismos puderem ser traduzidos em regras e predicados de uma linguagem deprogramacao em logica (caso do TyRuBa), o motor de inferencia da mesma fornecera todosos resultados possıveis que validem aquelas regras ou predicados. Desta forma, estamos acobrir todos as ocorrencias possıveis de instancias de meta-padroes existentes no codigo-fonte.Tal e possıvel pois esta-se a inferir sobre uma base de conhecimento composta por factos querepresentam elementos da arvore de sıntaxe abstracta, segundo o modelo de dados do JDT.

Visto que o JQuery baseia toda a sua pesquisa neste princıpio, e uma solucao adequada paraa analise e pesquisa sobre o codigo-fonte.

Extensıvel

Para alem de permitir a definicao de novas pesquisas ao codigo-fonte, o JQuery permite umadefinicao mais persistente de regras e predicados atraves de um conjunto de ficheiros existentes,ou, se se preferir, a criacao de novos ficheiros de regras, indicando-se posteriormente quais aquelesque o JQuery deve carregar aquando da sua execucao.

Estas novas regras e predicados recorrem a uma sıntaxe definida pelo TyRuBa e que permitedefinir qual o nome, tipo de argumentos (segundo o modelo de dados do JDT) e qual amultiplicidade dos resultados, i.e. se se pretende que um determinado argumento tenha umou mais resultados. Um novo predicado pode invocar outros predicados, quer definidos peloutilizador, quer constantes da biblioteca de predicados fornecida a partida pelo JQuery e quepode ser consultada em [Volder 04a].

A sıntaxe do TyRuBa e muito semelhante ao Prolog, realcando-se as seguintes diferencas:

• As variaveis comecam sempre pelo caracter ?, por exemplo, ?X, ?List, ?variavel. Sendoque o caracter ? sozinho corresponde ao caracter do Prolog, com o mesmo significado dedon’t care;

5.2. Arquitectura 75

• As constantes distinguem-se das variaveis, pela omissao do caracter ?;

• O TyRuBa nao suporta operadores infixos;

• A sıntaxe para o mapeamento de termos e diferente.

Para uma melhor compreensao da sıntaxe do TyRuBa aconselha-se a consulta do sıtioreferenciado em [Volder 04d]. Um exemplo da declaracao de um predicado pode ser visto deseguida:

staticMethod :: MethodMODES

(F) IS NONDETEND

Este bloco informa o TyRuBa de que existe um predicado de nome staticMethod, cujoargumento e um Method (segundo o modelo de dados do JDT) e quando o argumento naoesta determinado ou resolvido (representado pelo (F) que quer dizer ”Free”), pode haver maisdo que um resultado (NONDET, que significa Non Deterministic, ou seja, nao determinıstico).

De seguida, basta declarar o corpo do predicado:

staticMethod(?M) :- method(?M), modifier(?M, static).

Esta regra diz que o predicado staticMethod e verdadeiro quando o seu argumento (?M) eum metodo (verificado pelo predicado method) e tem um modificador static (verificado peloargumento modifier).

5.2 Arquitectura

A escolha da denominacao JFREEDOM, como nome do plug-in que foi desenvolvido relaciona-secom o ambito da abordagem e do seu lema: a utilizacao de meta-padroes como um conceito degrande utilidade para a recuperacao de padroes de desenho em frameworks, realcando os factoresligados a flexibilidade destas e que fomentam a sua reutilizacao. JFREEDOM e acronimo paraJava Framework Reverse enginEEring of Design Over Metapatterns.

Partindo de uma abordagem de recuperacao de desenho constituıdas por fases consecutivas,a implementacao da ferramenta visou a concretizacao destas fases, dividindo-se ela propria emmodulos independentes mas fortemente interrelacionados. Estes modulos sao:

• Modulo de analise e pesquisa do codigo-fonte. Este e o modulo que permite pesquisar ocodigo-fonte a procura dos elementos com relevancia para a recuperacao de desenho;

• HotSpotter. Modulo que agrupa templates e hooks em hot spots;

• Repositorio de regras e definicoes. Base de conhecimento onde estao definidos formalmenteas regras e restricoes que permitem representar os meta-padroes e padroes de desenho paraefeitos de procura e deteccao dos mesmos no codigo;

• Detector de meta-padroes. Modulo responsavel por detectar instancias de meta-padroesno codigo-fonte;


Figura 5.3: JFREEDOM: Arquitectura do plug-in.

• Reconhecedor de padroes de desenho. Modulo responsavel por aferir a possıvel presenca depadroes de desenho no codigo (a partir dos meta-padroes).

Nesta seccao, aborda-se em mais detalhes cada um dos modulos constituintes da ferramenta.Um visao geral desta arquitectura pode ser vista na figura 5.3.

5.2.1 Modulo de Analise e Pesquisa do Codigo-Fonte

Recorrendo as tecnologias abordadas na seccao 5.1, o modulo de analise e pequisa de codigo-fonteassenta a sua implementacao em duas vertentes:

1. Utiliza o motor de pesquisa de codigo e respectivo modelo de dados fornecido pelo JDT.Foi criada uma pequena infraestrutura de interaccao com o JDT para filtrar elementos,nomeadamente metodos e classes, com vista a utilizar nos modulos seguintes, em especialno HotSpotter.

2. Utiliza a infraesturura desenvolvida pelo JQuery/TyRuBa que assenta na formulacao deperguntas a uma base de dados atraves de uma linguagem de interrogacao. Esta base dedados e composta por factos mapeados sobre o modelo de dados do JDT. Esta vertentesera utilizada pelo modulo de deteccao de meta-padroes e, posteriormente tambem pelomodulo de reconhecimento de padroes de desenho.

Por conseguinte, este modulo foi desenvolvido sob duas aproximacoes distintas, causadaspor necessidades diferentes dos modulos subsequentes. Ambas as vertentes serao utilizadas peloprocesso de recuperacao de desenho implementado pela ferramenta.


Figura 5.4: Arquitectura do modulo HotSpotter.

5.2.2 HotSpotter

Pode-se dizer que o HotSpotter foi o ponto de partida que despoletou a ideia para o trabalhoconstante desta dissertacao. O seu nascimento, advindo de uma cadeira de mestrado4, lancou omote para o desenvolvimento de uma abordagem de recuperacao de desenho.

Na altura, o HotSpotter [Flores 05] tinha o objectivo de detectar templates e hooks e agrupa-los em hot spots segundo a heurıstica ja abordada na seccao 4.2.2. Recorreu-se desta forma atecnologia de pesquisa de codigo fornecida pelo JDT e desenvolveu-se um plug-in para o Eclipseque, utilizando essa heurıstica, detecta hot spots em qualquer projecto desenvolvido em Java.Paralelamente, foi desenvolvida uma outra implementacao da mesma heurıstica recorrendo aJavaML [Badros 00, Aguiar 04] como linguagem de mapeamento do codigo Java, e utilizandoXSL [World Wide Web Consortium 05] para processar essa representacao e pesquisar e agruparos templates e hooks. Esta implementacao paralela serviu como base de verificacao dos resultadosobtidos pelo plug-in. A figura 5.4 mostra um diagrama representativo do funcionamento internodo HotSpotter.

Surgindo a ideia para o desenvolvimento da abordagem de recuperacao de desenhoconstante desta dissertacao, partiu-se para a sua implementacao dando seguimento a filosofia dedesenvolvimento da plataforma Eclipse, ou seja, estender a plataforma com novas funcionalidadespelo acrescento de novas ferramentas. Consequentemente, decidiu-se manter o HotSpotter comoum plug-in, integrando o restante processo de recuperacao de desenho num novo plug-in, destafeita o JFREEDOM. O seu forte interrelacionamento faz com que se considere o primeiro ummodulo do segundo, pois contribui para a implementacao da abordagem global.

Para o desenvolvimento do HotSpotter, a tecnologia oferecida pelo JDT era mais do quesuficiente para atingir os objectivos, logo nao se procurou outras alternativas. Assim, a interaccaodeste modulo com o anterior (analise e pesquisa de codigo) faz-se atraves do uso da infraestruturade interface com o JDT. Apesar do JQuery ter aparecido mais tarde, durante o desenvolvimentodo trabalho, a migracao do HotSpotter para usar esta nova tecnologia revelava-se morosae infrutıfera para os objectivos finais do trabalho, e nao iria trazer benefıcios acrescidos erelevantes. Por tal razao, manteve-se o HotSpotter na sua primeira versao.

A utilizacao do HotSpotter e bastante simples, bastando seleccionar qual o projecto, oupacote de codigo (working set) que se pretende analisar. Findo o processo automatico de analise,deteccao e agrupamento dos templates e hooks, a ferramenta apresenta os resultados em arvorepara mais facil navegacao por parte do utilizador. O utilizador pode, a qualquer altura da

4trabalho no ambito da cadeira de Arquitectura de Sistemas de Software, do mestrado em EngenhariaInformatica da Faculdade de Engenharia da Universidade do Porto


Figura 5.5: Vista da ferramenta HotSpotter.

navegacao nos resultados, visualizar o codigo-fonte correspondente aos hot spots encontrados,bastando para tal seleccionar o metodo correspondente. A figura 5.5 mostra uma vista daferramenta, apos o processamento do codigo-fonte do JUnit.

5.2.3 Detector de Meta-Padroes

O passo seguinte na abordagem de recuperacao de desenho prende-se com a deteccao deinstancias de meta-padroes no codigo-fonte. Depois da identificacao dos templates e hooks peloHotSpotter, ter-se-ia de agrupar estes segundo os meta-padroes.

Como ja foi referido anteriormente, a implementacao de toda uma heurıstica para detectar

Figura 5.6: Arquitectura interna do modulo de deteccao de meta-padroes.


elementos de alto-nıvel e formalmente definidos (como o estavam os meta-padroes) seriadispendiosa apenas com o recurso ao JDT. Com o aparecimento do JQuery, este problemapassou a ser de mais facil implementacao, pois o uso de um motor de inferencia sobre uma basede factos permite, atraves do uso de predicados formais, obter resultados rapidamente.

Por conseguinte, para a implementacao deste modulo, abandonou-se a aproximacao usandodirectamente o JDT e convergiu-se para o uso do JQuery, que esta construıdo sobre o modelode dados do JDT.

Em contacto com o autor do JQuery, Kris de Volder, foi facultado o codigo-fonte daferramenta e a liberdade total para o adaptar e reutilizar ao desenvolvimento do JFREEDOM.O estado do codigo do JQuery nao era o ideal para o adaptar a uma nova ferramenta, pois estenao foi desenvolvido para tal. Foi com algum esforco que se analisou o codigo e se identificaramos pontos de flexibilidade e sobre os quais se teria de actuar para adaptar a ferramenta aos novosrequisitos, ou seja, ao desenvolvimento do JFREEDOM. Com uma ferramenta de recuperacao dedesenho orientada para a reutilizacao, esta tarefa teria sido muito mais facil e rapida. Espera-seque o JFREEDOM possa ajudar noutras ocasioes similares.

Identificados os pontos de actuacao sobre o codigo do JQuery, tentou-se ser o menosintrusivo possıvel, criando-se uma camada de interface com o motor de inferencia do JQuerye reaproveitando o interface grafico deste, que ja se adequava as necessidades de apresentacaovisual dos resultados.

Consequentemente, o processo de deteccao de meta-padroes consiste na interrogacao da basede factos do JQuery (construıda a priori por este), sobre os elementos do codigo-fonte quesatisfacam as regras e predicados definidos para cada meta-padrao. Estas regras e predicadossurgem da formalizacao daqueles atraves da linguagem TyRuBa e constantes do moduloRepositorio de regras e definicoes. Pode-se ver na figura 5.6 a arqutectura interna do modulo.

Teve-se o cuidado de definir os predicados representativos dos meta-padroes com variaveisde resultado nao determinıstico (NONDET, segundo a sıntaxe do TyRuBa), ou seja, com apossibilidade de haver varios resultados para o mesmo predicado. Desta forma, obtem-se todosos casos que validem o predicado, ou seja, todas as instancias de meta-padroes.

A interface grafica do JFREEDOM e simples e facil de navegar, pois recorre a elementos deinterface graficos bastante conhecidos. O conceito assenta num conjunto de separadores (tabs),cada um pertencente a um conjunto de pacotes de codigo a analisar (working sets), previamenteseleccionados. Cada separador apresenta os resultados do processo de recuperacao de desenhosob a forma de uma arvore de elementos, onde o utilizador pode navegar sobre estes e executaroutras accoes. Estas accoes incluem a consulta de documentacao relativa aos meta-padroes epadroes de desenho candidatos para cada meta-padrao, assim como visualizar o codigo-fonterelativo aos elementos constituıntes dos meta-padroes (classes, metodos, etc).

O modo de despoletar este processo no JFREEDOM assenta nos seguintes passos (assume-seque o plug-in esta a correr na plataforma Eclipse):

1. Seleccionar um pacote de codigo a pesquisar (working set). Pode-se criar um novo,seleccionando os projectos ou pacotes de codigo existentes na plataforma (tal e feitorecorrendo a um wizard que a propria plataforma Eclipse possui). Isto cria um novoseparador;

2. Lancar o processo de engenharia reversa, atraves do botao respectivo ou do menu decontexto sob o separador presentemente visıvel ou seleccionado;


Figura 5.7: Vista da ferramenta JFREEDOM apos a deteccao de meta-padroes sobre o codigodo JUnit.

3. Aguardar pelo termino do processo de deteccao automatica de meta-padroes para podernavegar na arvore de resultados.

A figura 5.7 mostra uma vista do JFREEDOM, apos a deteccao de meta-padroes sobre ocodigo-fonte do JUnit.

5.2.4 Identificador de Padroes de Desenho

O modulo de reconhecimento de padroes de desenho baseia o seu funcionamento na deteccaoprevia de meta-padroes. Apos esta fase, o utilizador pode, a partir das instancias de meta-padroes encontrados no codigo, aferir quais os candidatos a padroes de desenho que mais seenquadram nas instancias encontradas.

Para cada um dos cinco meta-padroes fundamentais, existem padroes de desenho possıveisde serem mapeados com aqueles. O modulo mostra quais sao esses padroes de desenho, cabendoao utilizador aferir por inspeccao de codigo quais aqueles que mais se aplicam a cada instanciade meta-padrao descoberta. Nesta fase, os padroes de desenho sao os constantes de [Gamma 95].

Pela seleccao, atraves do menu de contexto, destes padroes de desenho, o utilizador podevisualizar a documentacao associada a de cada padrao de desenho, segundo [Gamma 95], comose pode ver na figura 5.8. Os padroes de desenho que podem ser candidatos relativamente acada instancia de meta-padrao fundamental sao listados na tabela 5.1.

No futuro, pretende-se que o modulo, recorra a definicao formal dos padroes de desenho


Figura 5.8: Consulta de documentacao relativa aos padroes de desenho candidatos apos deteccaode meta-padroes sobre o codigo do JUnit.

Meta-padrao Padrao de Desenho (GoF)Connection Builder, Prototype, Bridge, Flyweight, Com-

mand, Memento, State, StrategyHierarchy Adapter, Proxy, Iterator, Mediator, Observer,

VisitorRecursion Composite, Decorator, Interpreter, Chain of

ResponsibilityCreation Factory, Abstract FactoryUnification Template Method

Nao se aplicam os padroes de desenho Facadee Singleton

Tabela 5.1: Correspondencia entre os cinco meta-padroes fundamentais e os padroes de desenho(GoF) que os podem instanciar.


baseados em meta-padroes, bastando para isso, acrescentar essas definicoes ao repositorio deregras e definicoes. Dessa forma, este modulo torna-se flexıvel para englobar toda e qualquerdefinicao de padrao de desenho e nao so os constantes de [Gamma 95].

5.2.5 Repositorio de Regras e Definicoes

Ambos os modulos de deteccao de meta-padroes e reconhecimento de padroes de desenho,recorrem ao repositorio de regras e definicoes. Este contem as representacoes, segundo omodelo formal abordado na seccao 4.2.3, dos meta-padroes e padroes de desenho necessariaspara proceder a sua recuperacao.

Este repositorio e implementado atraves de um conjunto de ficheiros de texto onde estaodefinidos factos, regras, predicados e restricoes, recorrendo a linguagem definida pelo TyRuBa.

Um dos melhores exemplos e a definicao formal dos meta-padroes fundamentais utilizadosna deteccao de instancias dos mesmos. Tome-se como exemplo, o unification metapattern cujaformalizacao foi vista na seccao 4.2.3 e que e repetida a seguir:

unificationFundamentalMP (H,H :: Mt,H :: Mh) em que:

participantes:

hookhierarchy(H)templatemethods(H :: Mt)hookmethods(H :: Mh)

restricoes:

understandsMessage(root(H),H :: Mt)definesMethod(root(H),H :: Mh)understandsMessage(leafs(H),H :: Mh)invokes(H :: Mt,H :: Mh, self)

Esta formalizacao foi entao convertida para o TyRuBa e colocada num ficheiro de regras,automaticamente carregado durante o arranque do JFREEDOM. A sıntaxe do predicado e aseguinte:

unificationFundamentalMP :: Type, Callable, CallableMODES

(F,F,F) IS NONDETEND

unificationFundamentalMP(?Root, ?Mt, ?Mh) :-root(?Root),leafs(?Root, ?Leafs),understandsMessage(?Root,?Mt),definesMethod(?Root,?Mh),understandsMessage(?Leafs, ?Mh),invokesSelf(?Mt, ?Mh).

Esta definicao, segundo a sıntaxe do TyRuBa, declara que o predicado

5.3. Limitacoes 83

unificationFundamentalMP e composto por tres argumentos, sendo o primeiro do tipo Type,ou seja, e uma classe ou interface, o segundo e terceiros do tipo Callable, ou seja, um metodoou construtor. Todos os argumentos sao variaveis livres (F,F,F), ou seja, nao precisam de estarinstanciadas a chamada do predicado, e cujo resultado e nao determinıstico, ou seja, pode havermais do que uma solucao (por forma a cobrir todas as instancias possıveis que validem estepredicado).

Faz-se uso dos restantes predicados para completar a definicao do meta-padrao, pois estestambem foram previamente definidos segundo as regras definidas pelo modelo formal e que sepodem visualizar nas figuras 4.6, 4.7, 4.8, 4.9 na seccao 4.2.3. A tıtulo de exemplo, pode-se verde seguida a formalizacao em TyRuBa do predicado understandsMessage:

understandsMessage :: Type, CallableMODES

(F,F) IS NONDETEND

understandsMessage(?Class, ?Callable) :-hasMethod(?Class,?Callable,?FromType),class(?FromType),NOT(modifier(?Callable,abstract)).

Por conseguinte, o predicado understandsMessage verifica se a classe ?Class conhece(hasMethod) um metodo ?Callable atraves da classe ?FromType. Esta ultima nao podeser uma classe de interface, logo a afericao de que class(?FromType) pois tem de ter umaimplementacao concreta do metodo e o proprio metodo ?Callable nao pode ser abstracto(NOT(modifier(?Callable,abstract)).

Para uma listagem dos restantes predicados implementados no ambito da formalizacaodos meta-padroes e padroes de desenho, aconselha-se a consulta do apendice A. Todosestes predicados sao conteudo de um ficheiro de regras denominado jfreedom.rub que eautomaticamente carregado para o motor de inferencia do JQuery e sobre o qual, posteriormente,o JFREEDOM procede a pesquisa e deteccao dos elementos de desenho.

5.3 Limitacoes

O JFREEDOM e caracterizado por algumas limitacoes, principalmente causadas pelas limitacoesproprias do JQuery e do TyRuBa. Nesta seccao, abordam-se algumas dessas limitacoes e a suaproblematica inerente.

5.3.1 Identificacao de Estruturas Genericas

A formalizacao dos meta-padroes fundamentais tem como uma das suas condicoes, determinarse uma classe refere uma ou mais instancias de uma outra (normalmente se a classe templaterefere uma ou mais instancias da classe hook). Esta restricao e implementada pelo predicadouses utilizado nas definicoes formais dos meta-padroes. O mesmo predicado, recorre a um outrodenominado usesInField, que por sua vez recorre ao predicado associationOf, sendo esteultimo que verifica qual a associacao entre duas classes5.

5Todos estes predicados podem ser consultados no apendice A.1


Na abordagem para a criacao deste ultimo predicado, identificaram-se as situacoes em queuma classe A pode referenciar uma outra B segundo uma determinada multiplicidade. Estassituacoes sao:

1. A classe A tem uma variavel de instancia ou atributo que e do tipo da classe B. Nestecaso, e facil constatar que a classe A refere uma e so uma instancia da classe B.

2. A classe A tem mais do que uma variavel de instancia ou atributo do tipo da classe B.Facilmente se constata que existe mais do que uma referencia para instancias da classe B.

3. A classe A tem uma variavel de instancia ou atributo que e um array (tambem denominadovector ou variavel indexada) para instancias da classe B. Aqui e igualmente facil deconstatar de que a classe A pode referir mais do que uma instancia da classe B. A incertezaesta no caso do vector ter apenas um elemento durante todo o seu tempo de vida da classe.Assume-se que o potencial de haver mais do que uma referencia para a classe B e suficientepara atestar a multiplicidade.

4. A classe A tem uma variavel de instancia ou atributo que e um contentor generico parainstancias de qualquer classe. Aqui reside o principal problema de afericao da associacaoentre duas classes.

De facto, a situacao 4 e uma questao problematica de resolver de uma forma simples, flexıvele eficaz. O conceito de contentor generico de instancias surgiu ja ha algum tempo nas linguagensorientadas por objectos e, por conseguinte, tambem no Java. Esta-se a falar de classes comoVector, ArrayList ou Stack. Genericamente, todas as classes ou interfaces que descendam deduas super-interfaces: Collection e Map.

Varias tentativas de solucionar o problema foram abordadas:

• Uma delas prendia-se com tentar aferir qual o tipo do atributo da classe em questaoe inspeccionar se aquelas interfaces (Collection e Map) eram seus ascendentes na suahierarquia de tipos. Tal solucao nao seria possıvel senao com a presenca do codigo-fontedo proprio Java, pois, quer o JDT ou o JQuery nao alargam a sua pesquisa para dentro docodigo nativo do proprio Java. Estar sempre a incluır o codigo nativo do Java em todasas pesquisas constituia um requisito demasiado pesado para as necessidades em causa;

• Outra solucao seria criar um predicado que guardaria todas as classes e interfacesconhecidos que pudessem ser contentores genericos de instancias e que validaria caso otipo de uma classe estivesse nessa lista de tipos. Esta abordagem pareceu demasiadogrosseira e muito pouco flexıvel pois bastaria o utilizador criar uma classe da sua autoriaque descendesse ou implementasse qualquer uma das outras para o predicado nao validaressa classe. Por outro lado, bastaria uma nova versao do Java mudar os nomes destasclasses e o predicado deixaria de ser eficaz;

• Provalvemente a abordagem que neste momento se adeque mais seja recorrer a intervencaodo utilizador. No caso de existir uma incerteza quanto ao tipo de um determinadoatributo, o utilizador interviria e classificaria esse atributo como contentor de mais doque uma instancia de uma determinada classe. Essa clasificacao seria posteriormenteanotada e inserida na base de factos sobre o codigo e os predicados poderiam recorrer aessa informacao para filtar a sua pesquisa. Como se esta perante uma abordagem semi-automatica, a intervencao do utilizador seria natural nestes casos. O objectivo e ajudar omais possıvel.

5.3. Limitacoes 85

Pretende-se como trabalho futuro, adaptar esta ultima solucao para resolver esta questao.

5.3.2 Identificacao de Invocacao por Variavel ou Argumento

Outra questao levantada pelo modelo formal e aferir se um determinado metodo e invocadopelo metodo de uma classe atraves de uma sua variavel de instancia ou atributo ou atravesde um parametro passado para dentro do metodo invocador. Esta-se a falar do predicadodefinesVariable e tambem do invokes.

Esta preocupacao de diferenciar entre os dois casos assenta na generalizacao da formalizacaoe na sua natureza de alto-nıvel de abstraccao. Desta forma, abrange-se duas formas possıveis deimplementacao dos meta-padroes. A formalizacao vista na seccao 4.2.3, e proposta por Tourweem [Tourwe 02] visava a geracao de codigo e, por conseguinte, estas definicoes eram bastanteimportantes. No caso de deteccao de instancias de meta-padroes, a pesquisa pode ser feitaatraves da afericao da invocacoes dos metodos das classes independentemente da forma comosao feitas. Se um metodo da classe A invoca um metodo da classe B entao de alguma formaelas interrelacionam-se, seja por uma variavel de instancia ou um parametro formal. Do pontode vista da deteccao, apenas esta interrelacao e importante.

Em suma, esta limitacao cree-se um falso problema ao nıvel da deteccao dos meta-padroes,mas serviu para esclarecer o facto de predicado com o definesVariable nao terem sido utilizadosna formalizacao com o TyRuBa. Possıvelmente no posterior refinamento das definicoes dopadroes de desenho se possa incluir esta restricao, ate la, considera-se superflua.

5.3.3 Requisitos de Memoria

O exagerado consumo de memoria do plug-in deve-se em grande parte ao JQuery, pelo facto destemanter um subconjunto da base de factos sempre em memoria. Quanto maior o pacote de codigoa pesquisar, mais memoria o JQuery necessita para manter a base de factos. Adicionalmente,o JQuery mantem em cache resultados de pesquisas anteriores para que futuras pesquisas naoexijam tanto tempo de processador. E possıvel, apesar de nao recomendado, modificar o tamanhoda memoria cache que o motor do JQuery usa para armazenar partes da sua base de factos.

5.3.4 Proliferacao de Ficheiros da Base de Factos

O JFREEDOM recorre a tecnologia do JQuery para efectuar as suas pesquisas. Por sua vez oJQuery recorre ao TyRuBa como tecnologia de interrogacao a base de factos sobre o codigo-fonte.O motor do TyRuBa cria uma quantidade consideravel de ındices sobre os factos constantes nabase de factos para optimizar as pesquisas e diminuir o tempo de execucao. Para tal, sao criadosficheiros de tamanho reduzido por forma a que o sistema de paginacao de memoria do TyRuBafuncione convenientemente. O efeito disto e a proliferacao de uma grande quantidade de ficheirosde pequena dimensao em disco. Os criadores do TyRuBa decidiram que os ganhos em velocidadede execucao das pesquisas sao mais importantes que a utilizacao conveniente do espaco em disco.Por propagacao, o JFREEDOM assume a mesma postura.


5.4 Caracterısticas principais do JFREEDOM

O JFREEDOM e um plug-in para o Eclipse que visa assistir o utilizador de uma framework aconhecer melhor o desenho desta, sobretudo os pontos de flexibilidade sobre os quais tem deactuar para a adaptar ao seu problema concreto. Esta contribuicao para a eficaz reutilizacaode codigo assenta numa abordagem de recuperacao do desenho da framework baseada naidentificacao sucessiva de elementos de flexibilidade de alto-nıvel, nomeadamente hot spots, meta-padroes e padroes de desenho. Atraves de uma interface simples e facil de usar, o utilizador podevisualizar estes elementos de uma forma rapida e directa, navegando numa arvore de resultados econsultando documentacao sobre os mesmos. Com base numa formalizacao alto-nıvel, o processoavanca por diversos modulos sucessıvos:

• Analise e pesquisa de codigo, onde o codigo e processado numa base de factos segundo omodelo de dados do JDT e interrogado usando o TyRuBa;

• HotSpotter. Usando o motor de pesquisa do JDT, sao identificados os templates e hookspresentes no codigo e agrupados em hot spots;

• Detector de meta-padroes, onde o codigo e pesquisado com o TyRuBa, usandoformalizacoes daqueles e onde os resultados sao apresentados como instancias dos cincometa-padroes fundamentais;

• Reconhecedor de padroes de desenho, onde o utilizador pode aferir manualmente quais ospadroes de desenho candidatos para cada instancia de meta-padrao encontrada e consultardocumentacao sobre cada uma para auxiliar na sua tarefa.

A qualquer altura o utilizador pode visualizar o codigo-fonte correspondente aos resultadosobtivos pela ferramenta. Desta forma, a ferramenta apresenta informacao importante e utilpara a consciencializacao do desenho da framework por parte do utilizador. Apesar de algumaslimitacoes, a ferramenta mostra-se possuidora das seguintes caracterısticas:

• integravel num ambiente de desenvolvimento de software. O seu formato de plug-in permiteintegra-la na plataforma de desenvolvimento Eclipse;

• flexıvel, pois permitir estender a sua base de conhecimento para abarcar novas de definicoesde padroes de desenho e, possivelmente, outra informacao relevante ao processo derecuperacao de desenho;

• interactiva permitindo ao utilizador intervir na afericao final dos padroes de desenhocandidatos;

• geradora de informacao visual util, sob a forma de arvore de resultados sob a qual outilizador pode navegar e visualizar o codigo correspondente, para alem de documentacaosobre os elementos de desenho recuperados.

Pensa-se que o JFREEDOM mostra possuir utilidade para ser usada por potenciais(re)utilizadores de codigo.

Capıtulo 6

Caso de Estudo e Experimentacao

Apos a construcao da ferramenta JFREEDOM, numa tentativa de implementar a abordagem derecuperacao de desenho constante desta dissertacao, aplicou-se a ferramenta a uma frameworkcujo desenho ja e conhecido por forma a verificar e validar os resultados obtidos e aferir averdadeira eficacia e eficiencia daquela, bem como a sua utilidade.

Para tal, recorreu-se ao JUnit, uma framework para implementacao de testes unitarios. Estecapıtulo, introduz a framework, proposito e desenho e apresenta os resultados obtidos com oJFREEDOM.

6.1 JUnit

O JUnit [Gamma 03b] e uma framework de codigo-aberto utilizada para implementar e executar,de uma forma automatica e repetitiva, testes unitarios de codigo. Apresenta-se como umainstancia da arquitectura xUnit [Beck 03]. A framework foi originalmente desenvolvida porErich Gamma e Kent Beck, e inclui nas suas funcionalidades:

• Assercoes para testar resultados esperados;

• Agrupamentos de testes (Test fixtures) para partilhar dados de testes comuns;

• Series de testes (Test suites) para facil organizacao e execucao de testes;

• Interface grafico e textual para a execucao dos testes.

6.1.1 Objectivos

Segundo os seus autores [Gamma 03a], o JUnit aborda a questao da implementacao de testesde uma forma pragmatica olhando numa optica de desenvolvimento de software.

Eles defendem que se um programa nao tem um teste automatizado para a verificacao dassuas funcionalidades, entao assume-se que o programa nao funciona. Tal aparenta ser maisseguro que a certeza dada por um programador de que o programa funciona agora e sempre.Isto quer dizer que um programamdor nao termina o seu desenvolvimento apos implementar asfuncionalidades e depurar o codigo de erros, mas sim apos ter igualmente implementado testesque demonstrem que o programa funciona.

87

88 6 Caso de Estudo e Experimentacao

No entanto, as pressoes de tempo relegam para segundo plano a escrita e implementacoes detestes, vista como um suplemento entrangulador do desenvolvimento, preferindo-se confiar naperıcia e qualidade do programador.

Por conseguinte, o primeiro objectivo e o de desenvolver uma framework na qual se depositao mınimo de esperanca que um programador a va realmente utilizar para escrever testes. Aframework tera de utilizar ferramentas conhecidas para que o tempo de aprendizagem sejacurto. Tera de exigir o mınimo trabalho possıvel, necessario para escrever um novo teste. Terade eliminar o duplicar de esforcos.

Dito desta forma, faz parecer que bastaria escrever expressoes num depurador de codigo epronto, mas tal nao e suficiente para escrever testes convenientemente. Assegurar que o codigofunciona no presente, nao assegura que funcionara no minuto seguinte, apos a integracao numsistema, ou daqui a uns anos, quando o programador ja nao estiver no projecto.

Esta preocupacao leva ao segundo objectivo do JUnit, que passa pela criacao de testes queretenham a sua validade ao longo do tempo. Alguem, outro que nao o programador original doteste, tera de ser capaz de (re)executar o teste e interpretar o seu resultado. Devera ser possıvelcombinar testes de varios autores e executa-los em conjunto, sem incompatibilidades ou perigode interferencia.

Por fim, e como terceiro objectivo, devera ser possıvel adaptar testes anteriores para criartestes novos. Criar uma inicializacao ou aspecto de um teste e algo dispendioso pelo que aframework deve permitir reutilizar estes aspectos para criar e executar testes diferentes.

6.1.2 Arquitectura

A arquitectura do JUnit foi desenvolvida por forma a atingir os objectivos descritos no pontoanterior, e para isso, os seus autores recorreram a uma aplicacao sucessiva de padroes de desenhopara resolverem os seus problemas. Um visao geral da arquitectura inicial do JUnit pode servista na figura 6.1, bem como um desdobramento nos passos de aplicacao dos padroes de desenho.

Os mesmos autores afirmam que esta arquitectura, bem como a forma como foi construıda,revelou algumas conclusoes:

• Discussao com padroes util. O uso de padroes de desenho para discutir o domınio doproblema revelou-se bastante valiosa, tanto para o desenvolvimento da framework, comoforma de ensinar e explicar o seu funcionamento a terceiros;

• Densidade de padroes. Existe uma grande densidade de padroes a volta da classe centralde abstraccao da framework, TestCase. Arquitecturas com uma grande densidade depadroes sao faceis de usar mas difıceis de mudar. E comum em frameworks com algumamaturidade encontrar-se uma grande densidade de padroes em redor das abstraccoes chaveda arquitectura. O contrario devera ocorrer em frameworks com pouca maturidade, ouseja, uma baixa densidade de padroes de desenho. Apos descobrir qual o problemaa resolver, e possıvel proceder a ”compressao”da solucao, levando a um aumento dadensidade de padroes de desenho onde, de facto, eles produzem o maior efeito e rendemos melhores benefıcios;

• Auto-aplicabilidade. Logo apos terem desenvolvido as funcionalidades mınimas de teste,os autores aplicaram a framework a ela propria, ou seja, usaram-na para codificar os

6.1. JUnit 89

Figura 6.1: Modelo de desenho do JUnit anotado com os padroes de desenho (retirada de[Gamma 03a]).

testes que a verificavam e validavam. Tal revelou-se de grande valor para que o restantedesenvolvimento da arquitectura prosseguisse sem grandes problemas e com a certeza deque novas alteracoes nao destruiriam o ja implementado;

• Interseccao ao inves de uniao. Quando se desenvolvem frameworks, existe a tentacaode incluir todas as funcionalidades possıveis, para que esta seja o mais util possıvel. Noentanto, fartura nao significa riqueza. Um utilizador tem de decidir se usa ou nao aframework: quantas menos funcionalidades, mais facil e de usar. O JUnit foi desenvolvidocom isto em mente e, por conseguinte, implementa apenas aquelas funcionalidades basicasessenciais que permitem a execucao de testes: (1) executar conjuntos de testes, (2) isolara execucao de cada teste e (3) poder executa-los automaticamente. Cendendo a tentacaode acrescentar algumas funcionalidades, os autores tiveram o cuidado de as colocar numpacote a parte (test.extensions), das quais e exemplo a classe TestDecorator, quepermite a execucao de codigo adicional antes e depois de um teste.

A arquitectura vista na figura 6.1 esta presente no JUnit, apesar de na versao em quese fez a experimentacao (3.8.1) esta ja teve algumas alteracoes com vista a introduzir novasfuncionalidades. No entanto, as funcionalidades base mantem-se, tendo as alteracoes sido feitasa baixo-nıvel por forma a serem transparentes para os antigos e novos utilizadores da framework.


6.2 Experimentacao

Ao aplicar o JREEDOM e a abordagem de recuperacao de desenho por este implementada,obtiveram-se os resultados esperados, tendo em conta as limitacoes da ferramenta. No total, oprocesso de engenharia reversa detectou:

• 1 instancia da recursion fundamental metapattern;

• 28 instancias da connection fundamental metapattern;

• 1 instancia da hierarchy fundamental metapattern;

• 10 instancias da creation fundamental metapattern;

• 21 instancias da unification fundamental metapattern.

Atendendo a que a analise detalhada de cada uma destas instancias requeriria bastanteespaco nesta dissertacao, abordar-se-ao apenas as instancia de maior relevancia e interesse parademonstrar as qualidades e vantagens da abordagem proposta.

6.2.1 Padrao: Template Method

Reconhecer instancias do padrao de desenho Template Method e o mesmo que descobrirtemplates, sendo que estes invocam hooks. No caso de se mapear estes padroes recorrendo ameta-padroes, a base reside no unification fundamental metapattern, pois espera-se que existaum template que invoque hooks localizados na mesma classe e que classes descendentes podemredefinir para moldar o comportamento do processo as suas necessidades (ver figura 6.2). Umexemplo de um Template Method conhecido no JUnit pode ser visto na figura 6.3.

A instancia de meta-padrao que anteve esta instancia de padrao pode ser visualizada comoresultado do processo do JFREEDOM na figura 6.4.

Igualmente na classe TestCase existe o metodo run(TestResult) que segundo a arquitecturade base tambem e um Template Method. No entanto a sua implementacao foi modificada paraja nao invocar directamente metodos na mesma classe, apesar de o fazer indirectamente viaoutras classes. As funcionalidades mantem-se, mas para acomodar outras, a implementacao debase evoluiu deixando de assentar no meta-padrao unification fundamental metapattern. Noentanto, a deteccao deste meta-padrao em classes ditas ”irmas”, leva a inspeccionar, por partedo utilizador, as restantes para verificar se o padrao tambem se aplica aquelas.

6.2.2 Padrao: Factory Method

O padrao de desenho Factory Method (ver figura 6.5) tambem se encontra na arquitectura actualdo JUnit (ver figura 6.6.)

Este padrao de desenho assenta no meta-padrao creation fundamental metapattern, cujainstancia surge nos resultados provenientes do JFREEDOM, como ilustra a figura 6.7.

6.2. Experimentacao 91

Figura 6.2: Estrutura do padrao de desenho Template Method (retirada de [Gamma 95]).

Figura 6.3: Instancia do padrao Template Method no JUnit.

Figura 6.4: Deteccao de uma instancia do meta-padrao unification fundamental metapattern queindicia a existencia de um padrao de desenho Template Method.


Figura 6.5: Estrutura do padrao de desenho Factory Method (retirada de [Gamma 95]).

Figura 6.6: Instancia do padrao Factory Method no JUnit.

Figura 6.7: Deteccao de uma instancia do meta-padrao creation fundamental metapattern queindicia a existencia de um padrao de desenho Factory Method.

6.2. Experimentacao 93

Figura 6.8: Estrutura do padrao de desenho Decorator (retirada de [Gamma 95]).

Figura 6.9: Instancia do padrao Decorator no JUnit.

6.2.3 Padrao: Decorator

Como e referido na seccao 6.1.2, existe uma instancia do padrao de desenho Decorator (figura6.8) implementado pela classe TestDecorator (ver figura 6.9).

Este padrao de desenho tem como base o meta-padrao recursion fundamental metapatterne a deteccao da respectiva instancia pelo JFREEDOM pode ser vista na figura 6.10.

6.2.4 Padrao: Composite

Este exemplo serve para mostrar uma das limitacoes da ferramenta ao nıvel da deteccao decontentores genericos de instancias, como previamente abordado na seccao 5.3.1.

Como se pode ver pela arquitectura base do JUnit (figura 6.1) existe o padrao de desenhoComposite (figura 2.3), e engloba as classes Test (cujo papel e de Component), TestSuite (cujopapel e de Composite) e TestCase assim como qualquer outra classe que descenda de Test (cujopapel e de leaf ).

Este padrao de desenho assenta sobre o meta-padrao recursion fundamental metapattern, asemelhanca de Decorator, visto na seccao anterior.


Figura 6.10: Deteccao de uma instancia do meta-padrao recursion fundamental metapattern queindicia a existencia de um padrao de desenho Decorator.

A razao pela qual este meta-padrao nao e detectado pelo JFREEDOM prende-se com asua limitacao em nao conseguir (ainda) identificar atributos ou variaveis do tipo ”contentorgenerico”. Neste caso particular, o atributo fTests da classe TestSuite que faz referencia amais do que uma instancia de Test. Desta forma, como este atributo nao e tido em consideracao(apenas referencias simples e vectores de tipos definidos), o predicado que representa o meta-padrao em questao nao reconhece esta relacao. A figura 6.11 mostra um trecho do codigo-fonteda classe TestSuite onde se pode ver que a declaracao do atributo fTests diz que este edo tipo Vector, uma classe contentor generica, descendente de Collection. Como este e oatributo utilizado para referenciar as instancias de Test, o predicado definido para detectar estemeta-padrao falha.

6.3 Analise dos Resultados

Pela analise dos resultados da aplicacao do JFREEDOM ao JUnit, retiram-se as seguintesconclusoes:

• Aspectos positivos

– Afunilamento das areas a aferir flexibilidade. Com a deteccao dos meta-padroesfundamentais, o utilizador passa a ter realcadas as areas de flexibilidade da framework.De antemao, o utilizador sabe que em redor destes elementos se encontram, nao sopadroes de desenho, mas tambem os pontos de actuacao e de configuracao onde poderaactuar para reutilizar convenientemente o desenho e codigo da framework;

– Intervencao rapida e directa do utilizador. Com a consulta imediata do codigo-fonte,aliado a interface de pesquisa do proprio ambiente de desenvolvimento, rapidamenteo utilizador consegue identificar e analisar todos os elementos constantes de uma

6.3. Analise dos Resultados 95

Figura 6.11: Fragmento de codigo-fonte da classe TestSuite onde se mostra o uso de um contentorgenerico para referenciar instancias de outras classes.

qualquer instancia de meta-padrao detectada e aferir qual o padrao de desenho quepode (ou nao) estar implementado;

– Consulta de documentacao util. Aliado a navegacao e pesquisa, o utilizador podeconsultar documentacao de forma a clarificar o significado e estrutura relativa a umqualquer padrao. Basta para tal, seleccionar uma opcao do menu de contexto de umqualquer resultado e escolher qual o padrao cuja documentacao pretende consultar.Esta documentacao ajuda a perceber como se enquadram, na arquitectura interna dopadrao de desenho, os elementos que foram recuperados pela ferramenta.

• Aspectos menos positivos

– Contentores genericos. A limitacao da ferramenta relativamente a deteccao decontentores genericos faz com que alguns meta-padroes nao aparecam nos resultados,ou seja, nao sejam detectados. Tal restringe as possibilidades de reconhecer eventuaispadroes de desenho (como e o caso do Composite);

– Falsos candidatos. Os resultados apresentam algum falsos candidatos que, aposinspeccao rapida do utilizador, sao detectados. Apesar de nao se poder eliminaresses falsos candidatos da arvore de resultados, seria desejavel marca-los como tal,para nao confundir tanto a navegacao;

– Ordenacao dos resultados. A composicao dos resultados, ou seja, a ordem doselementos individuais a cada meta-padrao e boa, mas nem sempre e a adequada.Apesar da consulta da documentacao esclarecer quais os papeis de cada elemento,seria de bom tom dar mais informacao na propria arvore de resultados.

De uma maneira geral, a ferramenta ajudou na consciencializacao das areas de flexibilidadedo JUnit, com potencial para melhorar. A visualizacao do codigo-fonte, facilmente navegavel,permitiu eficazmente aferir quais os candidatos a padroes de desenho que, de facto, o eram. Os


resultados em forma de meta-padroes mostraram uma visao alto-nıvel do desenho e contribuırampara que fosse mais rapido e directo a compreensao do desenho da framework.

Capıtulo 7

Conclusoes

O proposito no desenvolvimento de uma framework esta na reutilizacao do seu desenho e codigo.A consolidacao de um conjunto de aspectos ligados a experiencia e conhecimento no ambito dodesenvolvimento de software, dentro de um determinado domınio de problemas, e concretizadaatraves da criacao de uma framework que englobe todos esses aspectos.

Como pedras basilares de construcao das frameworks, evidenciadoras da sua maturidade,estao os padroes de desenho. Estes elementos trazem vantagens em varios ambitos, seja naplanificacao de um modo de desenhar software consolidado em boas praticas, seja na transmissaode experiencia e conducao da aprendizagem da framework.

Uma framework bem construıda e bem documentada pode ser significativamente mais facil deusar. Documentar convenientemente uma framework nao e facil, nem trivial, por razoes de variaordem, entre elas a disparidade de perfis de utilizador daquela e a conveniente representacao dosconceitos de alto-nıvel de abstraccao que a compoem.

No seu amago, uma framework tem de ser flexıvel. A sua flexibilidade e imputada pelautilizacao dos padroes de desenho na concepcao da sua arquitectura. A separacao entre ospontos de flexibilidade (frozen spots) e os pontos de configurabilidade (hot spots) dita o moteao redor da construcao do desenho de uma framework. Na maior parte dos casos, estes aspectosnao estao explıcitos ou nao sao conhecidos pelo potencial utilizador.

Uma framework e um produto complexo, devido ao seu alto-nıvel de abstraccao. Aliado amas praticas de desenvolvimento, documentacao e manutencao, a informacao vital para que umutilizador possa eficazmente reutilizar uma framework perde-se ou torna obscura e insuficiente.Se ja era difıcil utilizar uma framework, com o tempo, esta tarefa torna-se morosa e dispendiosa,exigindo uma re-aprendizagem.

E importante ter novamente a nocao do desenho da framework, sobretudo das areas deflexibilidade para que haja uma percepcao mais rapida dos pontos de actuacao sobre os quaisse podera configurar a framework para se adequar ao problema em questao.

7.1 Principais Contribuicoes

Esta dissertacao propos uma abordagem de recuperacao dos elementos de desenho queincorporam a flexibilidade de uma framework, nomeadamente hot spots, meta-padroes e padroesde desenho. Atraves de um processo de engenharia reversa, composto por passos sucessivos de

97

98 7 Conclusoes

recuperacao de elementos de crescente nıvel de abstraccao, a ferramenta JFREEDOM auxiliana deteccao daqueles elementos e assim facilita a aprendizagem da framework.

As principais vantagens desta abordagem sao:

• Forte componente formal. Todas as definicoes e representacoes dos elementos de desenhoassentam sobre um modelo formal pre-definido e previamente estudado para o efeito, edotam todo o processo de clareza, homogeneizacao e consolidacao;

• Producao de resultados intermedios uteis. Ao inves de um processo automatico derecuperacao, com um passo unico, onde se pretende partir do codigo-fonte e obter padroesde desenho (agregadores de todos os elementos de flexibilidade e seus contextualizadores),a abordagem produz resultados intermedios de relevancia para o utilizador. Desta forma,logo cedo o utilizador pode ganhar a consciencia de onde estao e para onde convergem asareas de flexibilidade e configurabilidade da framework, sem ter de esperar pelos resultadosobtidos no final do processo. Estes tem, muitas vezes, um grau de certeza insatisfatorio,devido ao seu alto-nıvel de abstracao e, logo, mais difıceis de detectar;

• Producao de uma ferramenta semi-automatica de auxılio. Com a disponibilizacao de umaferramenta semi-automatica, integravel, flexıvel e extensıvel, o utilizador ve a sua tarefamais facilitada, obtendo mais rapidamente os resultados intermedios uteis e acelerando asua aprendizagem da framework;

• Controlo do processo por parte do utilizador. Este controlo permite ao utilizador definirqual o grau de abstraccao que pretende visualizar nos resultados. Esta liberdade permiteque, varios perfis de utilizadores possam escolher qual o tipo de processo que pretendem eo que mais de adapta aos seus requisitos.

O mote geral da abordagem e: ajudar. Da experimentacao e dos resultados obtidos, conclui-se que esta abordagem cumpre os seus objectivos e ajuda o potencial utilizador da frameworka recuperar o conhecimento sobre o seu desenho e a tirar partido da sua qualidade mais util: aflexibilidade.

7.2 Trabalho Futuro

A abordagem proposta e a ferramenta implementada tem diversos aspectos que necessitam dotrabalho futuro de expansao e dos quais se destacam os seguintes:

• Refinar a abordagem de recuperacao de desenho para que o ultimo passo de reconhecimentode padroes de desenho possa ser feito recorrendo a definicoes formais daqueles. Tal implicaque mais padroes de desenho sejam formalizados segundo o modelo formal, sendo esteestendido caso seja necessario, por exemplo, para abranger padroes de desenho que naotenham por base meta-padroes (e.g. casos de Singleton e Facade);

• Construir um repositorio de definicoes formais de padroes de desenho facil de utilizar eestendido de forma cooperativa atraves da intervencao de varias fontes, disponibilizando-seo repositorio a comunidade de potenciais interessados.

7.2. Trabalho Futuro 99

• Eliminar as limitacoes da ferramenta relativamente a identificacao de estruturas”contentor”genericas para que aquelas nao sejam redutoras no domınio de resultados. Paratal, adoptar a solucao em que o utilizador intervem anotando quais aquelas estruturas quesao, de facto, contentores genericos;

• Homogeneizar e integrar todos os modulos da ferramenta, nomeadamente o HotSpotterque neste momento tem o formato plug-in;

• Implementar a geracao de varios tipos de documentacao nos quais os resultados dasdiversas fases do processo podem ser concretizados. Existe ja um projecto no sentidode produzir documentacao no formato XSDoc [Aguiar 03a]. Outros formatos emdesenvolvimento envolvem UML, Javadoc e SVG;

• Imputar mais actuacao do utilizador sobre o processo de recuperacao de desenho,nomeadamente na eliminacao de redundancias, falsos candidatos e a possibilidade deenriquecimento de codigo com anotacoes;

• Melhorar e estender a interface de navegacao nos resultados, fornecendo funcionalidadesde configuracao da sua apresentacao (ordem pela qual aparecem os elementos constituintesdas abstraccoes recuperadas, ocultacao/mostra de resultados pouco relevantes, etc),gravacao/carregamento de recuperacoes previamente efectuadas, pesquisas independentessobre determinados elementos recuperados, etc;

Resta salientar a importancia da engenharia reversa como o processo que permitiu analisarum sistema de software complexo, como o sao as frameworks, extraır informacao sobre o seudesenho e funcionamento, de forma a facilitar a sua compreensao, utilizacao, manutencao emelhoria.

Apendice A

Predicados definidos para oJFREEDOM

Este apendıce contem a definicao, segundo a sıntaxe do TyRuBa, dos predicados desenvolvidospara a formalizacao dos meta-padroes fundamentais utilizados no processo de recuperacao dedesenho, a qual foi abordada na seccao 4.2.3. Este conteudo e o constante do ficheiro de textojfreedom.rub, onde se definem as regras carregadas durante o arranque do plug-in JFREEDOMe que servem para interrogar a base de factos construıda pelo JQuery sobre o codigo-fonte.

Nao foram formalizadas todas as regras e restricoes constantes do modelo formal abordadona seccao 4.2.3 e constantes das figuras 4.6, 4.7, 4.8, 4.9 , mas todos aquelas que foram sendonecessarias para a definicao dos predicados formais representativos dos meta-padroes.

Aconselha-se o leitor a estar familiarizado com a sıntaxe do TyRuBa que pode consultar em[Volder 04d], bem como com os predicados pre-definidos pelo JQuery e que estao disponıveispara consulta em [Volder 04a].

101

102 A Predicados definidos para o JFREEDOM

A.1 Predicados de Relacao Entre os Participantes do ModeloFormal

hierarchyF

hierarchyF :: =Type,[=Type]MODES

(B,F) IS NONDETEND

hierarchyF (?C1,[]) :- NOT(subtype(?C1,?)).hierarchyF (?C1,[?C2|?R]) :- subtype(?C1,?C2),hierarchyF (?C2,?R).

root

root :: TypeMODES

(F) IS NONDETEND

root(?X) :- (class(?X) ; interface(?X)),NOT (EXISTS ?Super : subtype+(?Super,?X),class(?Super)).

definesMethod

definesMethod :: Type, CallableMODES

(F,F) IS NONDETEND

definesMethod(?X,?Y) :- (class(?X) ; interface(?X)), (method(?X,?Y) ;(method(?X, ?M), strongLikeThis(?Y, ?M))).

invokes

invokes :: Callable, CallableMODES

(F,F) IS NONDETEND

invokes(?M1, ?M2) :- method(?M1),method(?M2),(calls(?M1,?M2,?L) ;(calls(?M1, ?M3, ?L), strongLikeThis(?M2, ?M3))).

A.1. Predicados de Relacao Entre os Participantes do Modelo Formal 103

invokesSelf

invokesSelf :: Callable, CallableMODES

(F,F) IS NONDETEND

invokesSelf(?M1, ?M2) :- invokes(?M1,?M2),method(?Type,?M1),method(?Type,?M2).

invokesRecursively

invokesRecursively :: Callable, CallableMODES

(F,F) IS NONDETEND

invokesRecursively(?M1, ?M2) :- invokes(?M1, ?M2),strongLikeThis(?M1, ?M2).

invokesSingle

invokesSingle :: Block, CallableMODES

(F,F) IS NONDET// SEMIDET used here because the meaning of this// predicate tells us that there can be at most one Callable// that fits in argument 2.

END

invokesSingle(?caller,?called) :- method(?caller),(UNIQUE ?called : calls(?caller,?called,?)).

createsSingleInstance

createsSingleInstance :: Callable, TypeMODES

(F,F) IS NONDETEND

createsSingleInstance(?caller, ?class) :- constructor(?constructor),constructor(?class, ?constructor),

(method(?caller) ; initializer(?caller) ; constructor(?caller)) ,(UNIQUE ?constructor : constructorCall(?caller, ?constructor, ?)).


rootHierarchy

rootHierarchy :: Type, [Type]MODES

(F,F) IS NONDETEND

rootHierarchy(?X, ?XH) :- (class(?X) ; interface(?X)),hierarchyF(?X,?H), equals(?XH,[?X|?H]).

leafs

leafs :: Type, TypeMODES

(F,F) IS NONDETEND

leafs(?Root, ?Leaf) :- root(?Root),(class(?Leaf) ; interface(?Leaf)),subtype*(?Root, ?Leaf),NOT (EXISTS ?Child : subtype+(?Leaf,?Child)).

understandsMessage

understandsMessage :: Type, CallableMODES

(F,F) IS NONDETEND

understandsMessage(?Class, ?Callable) :-hasMethod(?Class,?Callable,?FromType),

class(?FromType),NOT(modifier(?Callable,abstract)).

hasAncestor

hasAncestor :: Type, TypeMODES

(B,F) IS NONDET(F,B) IS NONDET

END

hasAncestor(?C1, ?C2) :- subtype+(?C2, ?C1).

A.1. Predicados de Relacao Entre os Participantes do Modelo Formal 105

Estes predicados foram criados como uma tentativa de implementar a restricao uses, que dita seuma determinada classe referencia uma ou varias instancias de uma outra classe. As limitacoesassociadas a estes predicados foram ja abordadas na seccao 5.3.1.

instanceField

instanceField :: Type, FieldMODES

(F,F) IS NONDET(F,B) IS SEMIDET

END

instanceField(?C,?f) :- class(?C),field(?C,?f),NOT(modifier(?f,static)).

arrayOf

arrayOf :: Type,TypeMODES

(B,F) IS SEMIDETEND

arrayOf(?arrayRep::RefType,?elementRep::RefType) :-string_append(?elementRep,"[]",?arrayRep).

associationOf

associationOf :: Type,Type,MultiplicityMODES

(B,F,F) IS SEMIDETEND

associationOf(?C,?C,Single<>) :- class(?C);interface(?C).

associationOf(?T,?C,Multi<>) :- arrayOf(?T,?E), associationOf(?E,?C,?).


usesInField

usesInField :: Type, Type, Field, MultiplicityMODES

(F,F,F,F) IS NONDET(F,F,B,F) IS SEMIDET

END

usesInField(?C,?usedC,?f,?m) :- instanceField(?C,?f),type(?f,?usedT),associationOf(?usedT,?usedC,?m).

uses

TYPE Multiplicity= Single // This means a single reference exists (could possibly be 0)| Multi // This means multiple references may exist (in an array or multiple

// fields.

TYPE Single AS <>TYPE Multi AS <>

uses :: Type, Type, MultiplicityMODES

(F,F,F) IS NONDET(B,B,F) REALLY IS SEMIDET

END

uses(?C,?usedC,?m) :- usesInField(?C,?usedC,?,?m),(UNIQUE ?f : usesInField(?C,?usedC,?f,?)).

uses(?C,?usedC,Multi<>) :- usesInField(?C,?usedC,?,?),NOT(UNIQUE ?f : usesInField(?C,?usedC,?f,?)).

A.2. Predicados que Mapeam os Meta-Padroes Fundamentais 107

A.2 Predicados que Mapeam os Meta-Padroes Fundamentais

unificationFundamentalMP

unificationFundamentalMP :: Type, Callable, CallableMODES


unificationFundamentalMP(?Root, ?Mt, ?Mh) :-root(?Root),leafs(?Root, ?Leafs),understandsMessage(?Root,?Mt),definesMethod(?Root,?Mh),understandsMessage(?Leafs, ?Mh),invokesSelf(?Mt, ?Mh).

connectionFundamentalMP

connectionFundamentalMP :: Type, Type, Multiplicity, Callable, CallableMODES

(F,F,F,F,F) IS NONDETEND

connectionFundamentalMP(?T, ?H, ?Multiplicity, ?Mt, ?Mh) :-understandsMessage(?T, ?Mt),root(?H),definesMethod(?H, ?Mh),leafs(?H, ?LH),understandsMessage(?LH,?Mh),invokes(?Mt, ?Mh),uses(?T, ?H, ?Multiplicity).


recursionFundamentalMP

recursionFundamentalMP :: Type, Type, Multiplicity, CallableMODES

(F,F,F,F) IS NONDETEND

recursionFundamentalMP(?T, ?H, ?Multiplicity, ?Mh) :-root(?H),definesMethod(?H, ?Mh),

leafs(?H, ?LH),understandsMessage(?LH, ?Mh),

understandsMessage(?T,?Mh),invokesRecursively(?Mh, ?Mh),uses(?T, ?H, ?Multiplicity),hasAncestor(?T,?H).

hierarchyFundamentalMP

hierarchyFundamentalMP :: Type, Type, Multiplicity, Callable, CallableMODES

(F,F,F,F,F) IS NONDETEND

hierarchyFundamentalMP(?H1, ?H2, ?Multiplicity, ?t, ?Mh) :-root(?H1),definesMethod(?H1, ?t),leafs(?H1, ?LH1),understandsMessage(?LH1, ?t), root(?H2),definesMethod(?H2, ?Mh),leafs(?H2, ?LH2),understandsMessage(?LH2, ?Mh),uses(?H1, ?H2, ?Multiplicity),invokesSingle(?t, ?Mh).

A.3. Predicados que Mapeam Padroes de Desenho 109

creationFundamentalMP

creationFundamentalMP :: Type, Type, CallableMODES


creationFundamentalMP(?H1, ?H2, ?t) :- root(?H1),definesMethod(?H1, ?t),leafs(?H1, ?LH1),understandsMessage(?LH1, ?t),leafs(?H2, ?LH2),createsSingleInstance(?t, ?LH2).

A.3 Predicados que Mapeam Padroes de Desenho

Apesar de ainda nao serem usados pelo modulo de reconhecimento de padroes de desenho, algunspadroes de desenho foram mapeados com o TyRuBa. No futuro, novas definicoes formais depadroes de desenho existirao e serao acrescentadas a estas.

compositeDP

compositeDP :: Type, TypeMODES

(F,F) IS NONDETEND

compositeDP(?Component, ?Composite) :-recursionFundamentalMP(?Composite,?Component, Multi<>, ?).

Bibliografia

[Abadi 96] M. Abadi & L. Cardelli. A theory of objects. Springer-VerlagNew York, Inc., 1996.

[Agerbo 98] E. Agerbo & A. Cornils. How to preserve the benefits ofDesign Patterns. Proceedings of the OOPSLA98 Conference,ACM Press, pages 134–144, 1998.

[Aguiar 03a] A. Aguiar, G. David & M. Padilha. XSDoc: an ExtensibleWiki-based Infrastructure for Framework Documentation. InE.Pimentel, N.R.Brisaboa and J.Gomez, editors, JISBD,pages 11–24, 2003.

[Aguiar 03b] Ademar Aguiar. Framework Documentation - A MinimalistApproach. PhD thesis, FEUP, 2003.

[Aguiar 04] A. Aguiar, G. David & G. Badros. JavaML 2.0: Enrichingthe Markup Language for Java Source Code. XATA - XML:Aplicacoes e Tecnologias Associadas conference proceedings,Porto, 2004.

[Albin-Amiot 01] H. Albin-Amiot & Y.-G. Gueheneuc. Meta-modeling designpatterns: Application to pattern detection and code synthesis.Proceedings of the 1st ECOOP workshop on AutomatingObject-Oriented Software Development Methods, October2001.

[Alexander 77] C. Alexander, S. Ishikawa & M. Silverstein. A PatternLanguage. 1977.

[Alexander 79] C. Alexander. The timeless way of building. OxfordUniversity Press, 1979.

[Arnold 89] R.S. Arnold. Software Restructuring. In Proceedings of theIEEE 77, numero 4, April 1989.

[Arnold 93] R.S. Arnold. A Road Map Guide to Software ReengineeringTechnology. Software Engineering, IEEE Computer SocietyPress, 1993.

[Badros 00] G. Badros. JavaML: A Markup Language for Java SourceCode. 9th International World Wide Web Conference, 2000.

111

112 Bibliografia

[Balanyi 03] Z. Balanyi & R. Ferenc. Mining Design Patterns from C++Source Code. ICSM ’03: Proceedings of the InternationalConference on Software Maintenance, page 305, 2003.

[Beck 94] K. Beck & R. Johnson. Patterns Generate Architectures.Proceedings of the ECOOP’94 Conference, 1994.

[Beck 97] K. Beck. Smalltalk best practices patterns. Prentice Hall,1997.

[Beck 99] K. Beck. Extreme programming explained : Embracechange. Addison-Wesley, 1999.

[Beck 03] Kent Beck. Simple Smalltalk Testing : with patterns, 2003.URL: http://www.xprogramming.com/testfram.htm.

[Biggerstaff 89] T.J. Biggerstaff. Design Recovery for Maintenance andReuse. Computer, pages 36–49, Julho 1989.

[Biggerstaff 96] T.J. Biggerstaff & C. Richter. Reusability framework,assessment and directions. IEEE Software, pages 41–49,March 1996.

[Boehm 87] B.W. Boehm. Improving software productivity. IEEESoftware, pages 43–57, 1987.

[Booch 94a] G. Booch. Designing an application framework. Dr.DobbsJournal, vol. 19(2), 1994.

[Booch 94b] G. Booch. Object-oriented analysis and design withapplications. Benjamin/Cummings, 1994.

[Bosch 99] J. Bosch, P. Molin, M. Mattsson & P. Bengston. Object-oriented frameworks - problems and experiences. BuildingApplication Frameworks - Object-Oriented Foundations ofFramework Design, pages 55–82, 1999.

[Brown 96] Kyle Brown. Design reverse-engineering and automateddesign pattern detection in Smalltalk. PhD thesis, NorthCarolina State University, 1996.

[Budinsky 96] F.J. Budinsky, M.A. Finnie, J.M. Vlissides & P.S. Yu.Automatic Code Generation From Design Patterns. ObjectTechnology, 1996.

[Baumer 97] D. Baumer, G. Gryczan, R. Knoll, C. Lilienthal, D. Riehle& Zullighoven. Framework development for large systems.Communications of the ACM, 1997.

[Buschmann 96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad &M. Stal. Pattern oriented software architecture - a system ofpatterns. John Wiley and Sons, 1996.

Bibliografia 113

[Butler 98] G. Butler, P. Grogono & F. Khendek. A reuse caseperspective on documenting frameworks. Proceedings of Asia-Pacific Software Engineering Conference (December 1-4,1998, Taiwan), IEEE Computer Society Press, Los Alamitos,CA, pages 94–101, 1998.

[Campo 97] M. Campo, C. Marcos & A. Ortigosa. Framework Compre-hension and Design Patterns: A Reverse Engineering Ap-proach. Proceedings of the 9th International Conferenceon Software Engineering and Knowledge Engineering, pages338–348, 1997.

[Canfora 92] G. Canfora, A. Cimitile & U. de Carlini. A logic-basedapproach to reverse engineering tools. IEEE Transactions onSoftware Engineering, vol. 18(12), pages 1053–1064, 1992.

[Chambers 92] C. Chambers. The Design and Implementation of theSelf Compiler, an Optimizing Compiler for Object-OrientedProgramming Languages. PhD thesis, Computer ScienceDepartment, Stanford University, 1992.

[Chikofsky 90] E.J. Chikofsky & J.H. Cross. Reverse Engineering andDesign Recovery: A Taxonomy. IEEE Software, vol. 7(1),pages 13–19, 1990.

[Cockburn 01] A. Cockburn. Agile software development. Addison-WesleyProfessional, 2001.

[Coplien 92] J. Coplien. Advanced c++ programming styles and idioms.Addison-Wesley, 1992.

[Corporation 05] Microsoft Corporation. Microsoft .NET Technology, 2005.URL: http://partner.microsoft.com/ productssolutions/net.

[Cotter 95] S. Cotter & M. Potel. Inside taligent technology. Addison-Wesley, 1995.

[Dusink 95] E.M. Dusink & J. van Katwijk. Reuse dimensions. ACMSIGSOFT Proc. of the Symposium on Software ReusabilitySSR’95, vol. 20, pages 137–149, 1995.

[Eclipse Foundation 05] Inc. Eclipse Foundation. The Eclipse Project, 2005. URL:http://www.eclipse.org.

[Eden 96] A. Eden, J. Gil & A. Yehudai. A Formal Language for DesignPatterns. Technical Report WUCS-97-07, WashingtonUniversity, 1996.

[Eden 98] A. Eden, Y. Hirschfield & A. Yehudai. LePUS - A DeclarativePattern Specification Language. Technical Report 326/98,Deparment of Computer Science, Tel Aviv University, 1998.

114 Bibliografia

[Eden 99] A. Eden, J. Gil, Y. Hirschfield & A. Yehudai. Towards aMathematical Foundation For Design Patterns. TechnicalReport 1999-004, Deparment of Information Technology,Uppsala University, 1999.

[Eden 00] A. Eden. Precise Specification of Design Patterns and ToolSupport in Their Application. PhD thesis, Department ofComputer Science, Tel Aviv University, 2000.

[Edwards 92] S.H. Edwards. Towards a model of reusable softwaresubsystems. 5th Annual Workshop On Software Reuse,WISR’92, 1992.

[Fayad 97] M.E. Fayad & D.C. Schmidt. Object Oriented applicationframeworks. Communications of the ACM, vol. 40(10), pages32–38, 1997.

[Fayad 99] M.E. Fayad, D.C. Schmidt & R.E. Johnson. Buildingapplication frameworks - object-oriented foundations offramework desing. John Wiley and Sons, 1999.

[Ferraiolo 03] J. Ferraiolo, F. Jun & D. Jackson. Scalable vector graphics(SVG) 1.1 specification. W3C recommendation. URL:http://www.w3.org/TR/SVG11, January 2003.

[Filho 99] Carlos Figueira Filho. JEOPS - The Java Em-bedded Object Production System, 1999. URL:http://www.di.ufpe.br/ jeops/v1/.

[Flores 05] N. Flores, D. Soares, H. Ferreira & M. Rodrigues. HotSpot-ter: a JavaML-based approach to discover Framework’sHotSpots. XATA - XML: Aplicacoes e Tecnologias Asso-ciadas conference proceedings, Braga, February 2005.

[Fowler 99] Martin Fowler. Refactoring: Improving the design of existingprograms. Addison-Wesley, 1999.

[Frakes 94] W.B. Frakes & J.M. Morel. An empirical study ofrepresentation methods for reusable software components.IEEE Trans. On Software Engineering, vol. 20(8), pages 617–630, 1994.

[Gamma 93] E. Gamma, R. Helm, R. Johnson & J. Vlissides. DesignPatterns: abstraction and reuse of object-oriented design.Proceedings of the ECOOP’93 Conference, 1993.

[Gamma 95] E. Gamma, R. Helm R.and Johnson & J. Vlissides. Designpatterns - elements of reusable object-oriented software.Addison-Wesley, 1995.

[Gamma 03a] E. Gamma & K. Beck. JUnit: A cook’s tour, 2003. URL:http://junit.sourceforge.net/doc/ cookstour/cookstour.htm.

Bibliografia 115

[Gamma 03b] E. Gamma & K. Beck. The official JUnit home page., 2003.URL: http://junit.org.

[Garlan 93] D. Garlan & M. Shaw. An Introduction to Software Archi-tecture. Advances in Software Engineering and KnowledgeEngineering, vol. I, 1993.

[Group 05] Object Management Group. Common Object Request BrokerArchitecture, 2005. URL: http://www.omg.org.

[Heuzeroth 03] D. Heuzeroth, T. Holl, G Hogstrom & W. Lowe. AutomaticDesign Pattern Detection. Proceedings of the 11th IEEEInternational Workshop on Program Comprehension, pages93–103, 2003.

[IBM Corporation 04] IBM Corporation. Eclipse platform help, Version: 3.0.2Build id: 200503110845, 2004.

[Jacobson 91] I. Jacobson & Lindstrom. F. Re-engineering of old systems toan object-oriented architecture. In OOPSLA, pages 340–350.ACM, 1991.

[Jacobson 99] E.E. Jacobson & Nowack P. Frameworks and Patterns: Ar-chitectural Abstractions. Building Application Frameworks- Object-Oriented Foundations of Framework Design, pages29–86, 1999.

[Jang 03] Minsu Jang. Bossam Rule Engine, 2003. URL:http://mknows.etri.re.kr/bossam/docs/ bossam.html.

[Johnson 88] R.E. Johnson & B. Foote. Designing Reusable Classes.Journal of Object Oriented Programming, vol. 1(2), pages22–35, 1988.

[Johnson 92] R. Johnson. Documenting frameworks using patterns.Proceedings of the OOPSLA’92, pages 63–76, 1992.

[Kang 99] B.-K Kang & J.M. Bieman. A Quantitive Framework forSoftware Restructuring. Journal of Software Maintenance11, 1999.

[Karlsson 95] E.A. Karlsson. Software reuse. a holistic approach. JohnWiley and Sons, 1995.

[Keller 99] S.R. Keller, R. Schauer & P. Page. Pattern-based reverseengineering of design components. Proceedings of 21thConference on Software Engineering, pages 226–235, 1999.

[Kramer 96] C. Kramer & L. Prechelt. Design Recovery by AutomatedSearch for Structural Design Patterns in Object-OrientedSoftware. Proceedings of the Working Conference on ReverseEngineering, pages 208–215, 1996.

116 Bibliografia

[Krueger 92] C.W. Krueger. Software Reuse. In ACM Computing Surveys,volume 24, pages 131–183. June 1992.

[Martin 96] R. Martin. The Open Closed Principle. C++ Report, 1996.

[Mattsson 99] M. Mattsson & J. Bosch. Composition problems, causesand solutions. Building Application Frameworks - Object-Oriented Foundations of Framework Design, pages 467–487,1999.

[McIlroy 68] M.D. McIlroy. Mass Produced Software Components. InPeter Naur & Brian Randell, editeurs, Report on the NATOSoftware Engineering Conference, pages 138–155. NATOScience Commitee, Garmisch, Germany, October 1968.

[Mens 04] T. Mens & T. Tourwe. A Survey of Software Refactoring.Ieee Transactions On Software Engineering, vol. 30, no. 2,pages 126–139, February 2004.

[Meyer 88] B. Meyer. Object-oriented software construction. Prentice-Hall, 1988.

[Microsystems 05] Sun Microsystems. Java 2 Platform, Enterprise Edition,2005. URL: http://java.sun.com/j2ee.

[Mili 95] H. Mili, F. Mili & A. Mili. Reusing Software: Issues and Re-search Directions. Software Engineering, vol. 21, no. 6, pages528–562, 1995. citeseer.ist.psu.edu/ mili95reusing.html”.

[Mitchell 03] Ian Mitchell. Simple Inference Engine, 2003.URL: http://www.theserverside.com/patterns/thread.tss?thread id=21562.

[Moser 96] S. Moser & O. Nierstrasz. The effect of object-orientedframeworks on developer productivity. Computer, vol. 29(9),pages 45–51, 1996.

[Niere 02] J. Niere, W. Schafer, J.P. Wadsack, L. Wendehals &J. Welsh. Towards Pattern-Based Design Recovery. ICSE’02: Proceedings of the 24th International Conference onSoftware Engineering, pages 338–348, 2002.

[Object Management Group 03] Object Management Group. Unified Modeling Language,2003. URL: http://www.omg.org/uml.

[Opdyke 92] W.F. Opdyke. Refactoring: A Program Restructuring Aidin Designing Object-Oriented Application Frameworks. PhDthesis, Univ. of Illinois at Urbana-Champaign, 1992.

[Philip 95] T. Philip & R. Ramsundar. A Reengineering Framework forSmall Scale Software. Software Engineering Notes, vol. 20,no. 5, pages 51–55, December 1995.

Bibliografia 117

[Prechelt 98] L. Prechelt & B. Unger. A Series of Controlled Experimentson Design Patterns: Methodology and Results. Proceedingsof Softwaretecknik’98, GI Conference, Paderborn, pages 53–60, 1998.

[Pree 95] Wolfgang Pree. Design patterns for object-oriented softwaredevelopment. Addison-Wesley / ACM Press, 1995.

[Prieto-Dıaz 91] R. Prieto-Dıaz. Making software reuse work: An implemen-tation model. ACM Sigsoft, vol. 16, no. 3, pages 61–68, 1991.

[Prieto-Dıaz 93] R. Prieto-Dıaz. Status Report: Software Reusability. IEEESoftw., vol. 10, no. 3, pages 61–66, 1993.

[Rekoff Jr. 85] M.G. Rekoff Jr. On Reverse Engineering. IEEE Trans.Systems, Man, and Cybernetics, pages 244–252, 1985.

[Rich 89] Ch. Rich & R.C. Walters. Formalizing reusable softwarecomponents in the Programmer’s Apprentice. SoftwareReusability. Volume II - Applications and Experience, vol. 2,pages 313–344, 1989.

[Schauer 99] R. Schauer. Hotspot Recovery in Object-Oriented Softwarewith Inheritance and Composition Template Methods. ISCM,1999.

[Schmid 95] H.A. Schmid. Creating the Architecture of a ManufactoringFramework by Design Patterns. Proceedings of the OOP-SLA’95, pages 370–394, 1995.

[Schmidt 99] D.C. Schmidt. Why Software Reuse has Failed and How toMake It Work for You. C++ Report Magazine, January1999.

[Schultz 00] U. Schultz, J. Lawall, C. Consel & G. Muller. SpecializationPatterns. Proceedings of the 15th IEEE InternationalConference on Automated Software Engineering, pages 197–206, 2000.

[Seemann 98] J. Seemann & J.W. Gudenberg. Pattern-based design recov-ery of java software. Proceedings of the 6th ACM SIGSOFTinternational symposium on Foundations of Software Engi-neering, New York, pages 10–16, 1998.

[Seidewitz 93] E. Seidewitz, B. Balfour, S.S. Adams, D.M. Wade &B. Cox. Developing software for large-scale reuse (panel). InOOPSLA ’93: Proceedings of the eighth annual conferenceon Object-oriented programming systems, languages, andapplications, pages 137–143. ACM Press, 1993.

[Shaw 96] M. Shaw & D. Garlan. Software architecture - perpectiveson an emerging discipline. PH, 1996.

118 Bibliografia

[Smith 03] J. Smith & D. Stotts. SPQR: Flexible automated designpattern extraction from source code. Proceedings of the18th IEEE International Conference on Automated SoftwareEngineering, 2003.

[Smolarova 97] M. Smolarova & P. Navrat. Software Reuse: Principles,Patterns, Prospects, 1997.

[Sommerville 00] I. Sommerville. Software engineering. Addison-Wesley, 6thEdition, 2000.

[Steyaert 96] P. Steyaert, C. Lucas, K. Mens & T. D’Hondt. Reuse con-tracts: managing the evolution of reusable assets. In OOP-SLA ’96: Proceedings of the 11th ACM SIGPLAN confer-ence on Object-oriented programming, systems, languages,and applications, pages 268–285. ACM Press, 1996.

[Sun Microsystems 03] Sun Microsystems. Javadoc Tool Homepage, 2003. URL:http://java.sun.com/j2se/javadoc/.

[Szyperski 98] C. Szyperski. Component software: beyond object-orientedprogramming. ACM Press/Addison-Wesley Publishing Co,1998.

[Tokuda 95] L. Tokuda & D. Batory. Automated Software Evolution viaDesign Pattern Transformations. Proceedings of the 3rdInternational Symposium on Applied Corporate Computing,1995.

[Toufik 01] T. Toufik & D.C.L. Ngo. Why and How Should PatternsBe Formalized. Journal of Object-Oriented Programming(JOOP), 2001.

[Tourwe 99] T. Tourwe & W. Meuter. Optimizing Object-Oriented Lan-guages Through Architectural Transformations. Proceedingsof the 8th International Conference on Compiler Construc-tion, pages 244–258, 1999.

[Tourwe 02] T. Tourwe. Automated support for framework-based softwareevolution. PhD thesis, Vrije Universiteit Brussel, 2002.

[Tracz 88] W. Tracz. Software Reuse Myths. In ACM SoftwareEngineering Notes, volume 13, pages 17–21. 1988.

[Tracz 94] W. Tracz. Software reuse myths revisited. In ICSE ’94:Proceedings of the 16th international conference on Softwareengineering, pages 271–272. IEEE Computer Society Press,1994.

[Tracz 95] W. Tracz. Third International Conference on SoftwareReuse. Summary. ACM Sigsoft, vol. 20, no. 2, pages 21–25, 1995.

Bibliografia 119

[Volder 99] K. Volder. Implementing Design Patterns as DeclarativeCode Generators. 1999.

[Volder 03] Kris Volder. Implementing Design Patterns as DeclarativeCode Generators. Department of Computer Science. TheUniversity of British Columbia., 2003.

[Volder 04a] Kris Volder. Built-in JQuery Specific TyRuBa predicatesand rules, 2004. URL: http://www.cs.ubc.ca/labs/spl/projects/jquery/documentation/appendix2.html.

[Volder 04b] Kris Volder. JQuery Tool Homepage, 2004. URL:http://www.cs.ubc.ca/labs/spl/ projects/jquery.

[Volder 04c] Kris Volder. TyRuBa Homepage, 2004. URL:http://tyruba.sourceforge.net.

[Volder 04d] Kris Volder. TyRuBa languange reference, 2004. URL:http://tyruba.sourceforge.net/tyruba language reference.html.

[Wang 04] W. Wang & V. Tzerpos. DPVK - An Eclipse Plug-In toDetect Design Patterns in Eiffel Systems. Proceedings ofEclipse Technology eXchange 2004, Barcelona, March 2004.

[Weide 91] B.W et al. Weide. Reusable software components. Advancesof Computers, vol. 33, pages 1–65, 1991.

[Whittle 95] B. Whittle. Models and languages for component descriptionand reuse. ACM SIGSOFT Software Engineering Notes,vol. 20(2), pages 76–87, 1995.

[Wirfs-Brock 90] R. Wirfs-Brock, B. Wilkerson & L. Wiener. Designingobject-oriented software. PH, 1990.

[World Wide Web Consortium 05] World Wide Web Consortium. XSL website., 2005. URL:http://www.w3.org/Style/XSL/.

engenharia reversa de padroes em˜ arquitecturas reutilizaveis´ · o processo de engenharia...

Documents