Sumrio

1 Introduo

1.1. Motivao

1.2. Definio do Problema

1.3. Objetivo e Organizao do Trabalho

2 Trabalhos Relacionados

2.1. Rational Data Architecture

2.2. Artigos Diversos

12

2.2.1. Towards The Reverse Engineering of UML Sequence Diagrams (Briand,

2004)

12

2.2.2. A study on the current state of the art in tool-supported UML-based static
reverse engineering (Kollmann, 2004)

14

2.2.3. A reverse engineering methodology to reconstruct hierarchical data flow

diagrams for software maintenance

15

2.2.4. Extracting Entity Relationship Diagram from a Table-based Legacy

Database

17

2.2.5. Inverse Transformation of Software from Code to Specification

18

2.3. Frameworks para gerao de diagramas

19

2.3.1. Eclipse Modeling Framework (EMF)

19

2.3.2. Graphviz

21

2.4. Ferramentas Utilizadas

22

2.4.1. Visual Library

22

3 A Ferramenta Dependencies Viewer

25

3.1. O Metamodelo

25

3.2. A linguagem de Representao

27

3.2.1. Metadados de configurao

27

3.2.2. Metadados de modelo

31

3.3. Instalao e uso da ferramenta

35

3.4. Modelo

36

3.4.1. O processo de desenvolvimento

37

3.4.2. Subversion

37

3.4.3. Issue tracker

38

3.4.4. Maven

38

3.4.5. Test Driven Development

39

3.5. Funcionalidades

40

3.5.1. Escolher uma entidade

42

1
Introduo

1.1.
Motivao
Um sistema de software est sempre evoluindo para se adequar a
modificaes em prticas de negcio organizacionais. Aps diversas evolues e
modificaes, tanto o software quanto a sua documentao tornam-se difceis de
entender. Quanto mais difcil entender um sistema, mais os desenvolvedores
se focam na modificao do software, diminuindo a confiabilidade de
documentao existente, dificultando mais ainda a tarefa de manuteno. Alm
da manuteno, a evoluo torna-se uma tarefa complexa. Isso acarreta, no
final, em um aumento de custo em qualquer artefato produzido a partir do
software original, seja este aumento proveniente de um atraso, ou mesmo da
necessidade de adicionar mais recursos humanos ao projeto, devido alta
complexidade que acarreta a baixa produtividade do grupo.
Para se efetuar uma manuteno em um software, importante que o
desenvolvedor faa uma anlise de impacto da mudana [Sommerville 2007].
Anlise de impacto se entende como a identificao das potenciais
conseqncias de uma alterao e a ao de estimar o que se deve ser alterado
para realizar esta modificao. Uma anlise de impacto envolve verificar se
outras partes do software devem ser modificadas por conta de uma manuteno,
buscando minimizar os efeitos colaterais de uma mudana [Wilde and Huitt
1992; Queille et al. 1994].
Para se fazer uma anlise de impacto necessrio ter uma
representao da estrutura do sistema [Queille et al. 1994]. Porm, a
documentao existente sobre um sistema legado tende a perder a
confiabilidade ao longo do tempo. Para contornar este problema, pode-se
recuperar a estrutura do sistema utilizando engenharia reversa, que se preocupa
em recuperar a representao arquitetural do sistema a partir do cdigo fonte,
permitindo seu entendimento e modernizao [Chikosfky and Cross 1990].

Ser que fcil encontrar uma ferramenta para realizar tal tarefa?
Imaginando que se trata de uma linguagem antiga, ou de um sistema com pelo
menos cinco anos de existncia e em evoluo constante, e que teve uma alta
rotatividade de desenvolvedores. Como fazer uma anlise de impacto confivel?
Alm disso, como gerar automaticamente modelos coerentes com o que est
implementado? Esta dissertao visa abordar um pedao deste problema.

1.2.
Definio do Problema
O Laboratrio de Engenharia de Software da PUC-Rio (LES) conduz vrios
projetos na rea de engenharia reversa. Um, em especial, foi o motivador do
trabalho proposto neste documento. O projeto envolve a documentao e testes
de um software (produzido por uma organizao externa ao LES) controlador de
estoque para os produtos produzidos pela Petrobrs, como leos e Gs Natural
Veicular (GNV). Alm de um aplicativo, ele pode ser considerado um ambiente
de integrao para diversos outros artefatos, pois possibilita uma interface de
comunicao que permite a outros produtos, produzidos por qualquer fbrica de
software, consultar e alterar dados de sua base.
Como este software foi iniciado h mais de sete anos, no existia a
facilidade atual para criao de servios distribudos, como a tecnologia de
webservice. A soluo adotada foi o uso de procedures no SGBD Oracle. Toda a
inteligncia do modelo de negcios ficou implementada no banco de dados. Na
interface foi definida uma camada simples, que chama as procedures e
apresenta o resultado retornado.
A meta principal do projeto desenvolvido pelo LES era gerar
documentaes e casos de testes para essas procedures, utilizando tcnicas de
engenharia reversa. O objetivo primrio desta documentao era facilitar o
entendimento do banco de dados para fins de manuteno. Ento, duas frentes
de trabalho foram iniciadas: de criao de testes e de documentao.
No caso dos testes, tecnologicamente no houve problemas para o seu
desenvolvimento. Foram utilizados frameworks em Java que possibilitaram a
criao de testes de unidades para as procedures. O grande problema
encontrado era o entendimento do ambiente necessrio para a execuo das
procedures. Elas possuem uma rvore de chamadas complexa, alm de usar
constantemente tabelas temporrias como meio de comunicao entre si. Isto
adicionou um grau extra de complexidade, pois, para cada procedure a ser

executada, todas as tabelas temporrias das quais elas dependem deveriam

estar corretamente preenchidas. Com o passar do tempo, percebeu-se que as
dvidas que surgiam estavam relacionadas necessidade de documentao
dos sistemas.
Para gerar a documentao, foi feito uma anlise do que j havia sido
documentado e como poderia ser o processo de atualizao destes artefatos.
Uma categoria de documentos produzidos, porm defasados, chamou a ateno
pela capacidade de atender as necessidades dos desenvolvedores e dos
testadores. Eram documentos do Word que continham o cdigo das procedures.
Para cada trecho de cdigo fonte, havia comentrios feitos em caixas de texto,
como

por

exemplo:

Popula

com

parmetros:

temp_cenarios_rel,

temp_produtos_rel. As dependncias e chamadas s outras procedures, ou

informaes deste gnero, eram descritas nestes comentrios. Na Figura abaixo,
mostrado um trecho do documento original.

Figura 1: Documento original produzido pelo desenvolvedor

O documento acima quase sempre se encontrava desatualizado, devido

dificuldade de sua manuteno. Apesar disto, ele era muito consultado,
principalmente por desenvolvedores recm contratados e pelos analistas de
testes, que precisavam entender o funcionamento da rvore de chamadas das
procedures para poder produzir testes eficazes.

O fato acima levantou um questionamento: ser que no haveria um

diagrama que fosse capaz de informar visualmente tudo o que estava descrito
em forma de texto no documento? Alm disto, no haveria uma ferramenta
capaz de ger-lo automaticamente?

1.3.
Objetivo e Organizao do Trabalho
O objetivo inicial desta dissertao era produzir um artefato que
conseguisse gerar uma documentao que satisfizesse as necessidades
expostas na sesso 1.2. So elas: Anlise de impacto para fins de manuteno,
e o entendimento do workflow de chamadas das procedures para auxiliar o
desenvolvimento de testes, manuteno e evoluo do sistema.
Com a evoluo dos estudos sobre o problema exposto na sesso anterior,
o objetivo desta dissertao tambm evoluiu, pois foi percebida a possibilidade
de fazer mais do que simplesmente atender o problema apresentado. O objetivo
se

transformou

em:

Prover

uma

base

para

gerao

de

diagramas

comportamentais de sistemas escritos em qualquer linguagem, alm de fornecer

um arcabouo de visualizao de diagramas baseado em metadados, que
minimiza o trabalho de quem deseja desenvolver um artefato para realizar
engenharia reversa. Alm disso, ela tem como meta documentar a experincia e
o conhecimento adquirido de um estudo de caso que partiu de um grande
volume de cdigo escrito em uma linguagem de difcil reengenharia para um
gerador automtico de workflow de chamadas.
Foi feito um estudo relativo aos trabalhos existentes na literatura e no
mercado que pudessem auxiliar na construo de um artefato que consiga
atender o objetivo acima. Este estudo apresentado no captulo 2. Ele mostrou
a carncia de existncia de uma ferramenta que conseguisse suprir estas
necessidades, no apenas para a linguagem PLSQL mas para diversas outras
que, por estarem em desuso, ou por terem poucos adeptos, possuem escassos
instrumentos para engenharia reversa de sistemas nelas escritos. No captulo 3
apresentada uma ferramenta que tem como meta minimizar esse problema.
Devido ao fato de ser orientada a metadados, esta ferramenta precisou de uma
API grfica com a mesma caracterstica, para que seja possvel a gerao de
diagramas visuais. Devido complexidade das APIs existentes foi desenvolvido
um framework de visualizao grfica discutido no captulo 4. No captulo 5
apresentado o estudo de caso que motivou o surgimento desta dissertao, e

como ele fez uso dos artefatos desenvolvidos por ela. Alm disso, feito uma
avaliao do resultado produzido em comparao com as necessidades prticas
do estudo de caso. Por ultimo, no captulo 6, vem a concluso da dissertao,
com o comentrio final e os trabalhos futuros.

2
Trabalhos Relacionados

Este documento um estudo sobre algumas solues, abordagens e

tcnicas existentes na literatura para a gerao de um diagrama comportamental
para linguagens estruturadas.
Entende-se como linguagem estruturada a linguagem que permite a
quebra

do

programa

em

blocos.

Cada

pedao

pode

ser

compilado

separadamente, e todos eles agem isoladamente um dos outros. Eles trabalham

em conjunto cada vez que uma parte necessita da outra. Exemplos de
linguagens estruturadas so C, C++ e Pascal.
O problema foi atacado a partir de trs ticas diferentes: A primeira buscou
projetos que chegassem perto de uma soluo completa. A segunda focou em
encontrar abordagens para o problema da engenharia reversa de um cdigo,
sem necessariamente olhar para a camada de exibio. E uma terceira
abordagem focou em buscar uma soluo para o problema da exibio dos
dados obtidos atravs da engenharia reversa. O foco neste caso era a camada
de visualizao apenas.
Foram procurados trabalhos relacionados na Internet, e os mais relevantes
so descritos neste documento. Para cada um existe um breve resumo da
abordagem utilizada e uma crtica sobre a soluo proposta.
Alm disto, foram citados alguns projetos e tecnologias que no possuem
uma ligao direta com o problema apresentado, porm servem como base para
uma possvel soluo.

2.1.
Rational Data Architecture
A motivao inicial do trabalho foi gerar um diagrama de comportamento
de uma procedure escrita na linguagem SQL. Pensando nisto, foi feito um
estudo para verificar em que nvel esto as ferramentas para manipulao e
desenvolvimento de banco de dados. No foi encontrada nenhuma capaz de
produzir o diagrama esperado. Procurando em fruns de internet e em
referncias encontradas no site de busca Google, o Rational Data Architect (IBM,

2008) estava sempre muito bem cotado, citado constantemente como um dos
melhores ambientes existentes para este tipo de desenvolvimento. Como era
necessria uma anlise profunda de uma ferramenta com esta finalidade, a
escolha foi natural. O estudo foi realizado em uma verso temporria fornecida
pela IBM.
O Rational Data Architect, RDA, um software pertencente plataforma
de desenvolvimento da IBM. Ele parte do conjunto de produtos para
gerenciamento de informaes da empresa. O RDA compatvel com vrios
sistemas de gerenciamento de banco de dados (SGBD), como o DB2, Sybase,
Oracle, SQL Server, entre outros. Ele se integra com os outros produtos da
marca Rational, como o Rational RequisitePro, para controle de requisitos, e o
ClearCase, para controle de verso. O propsito principal do produto prover
um ambiente de desenvolvimento para tarefas relacionadas a banco de dados,
como criao de tabelas e procedures entre outros. A sua principal caracterstica
fornecer um meio de transformar um modelo UML (Unified Modeling
Language) em um modelo lgico e vice-versa. Alm disto, representa uma
ferramenta importante no trabalho de documentao e engenharia reversa de
banco de dados.
Como dito anteriormente, o RDA compatvel com outros produtos da
Rational. Como exemplo de ganho derivado disto, pode-se citar a tarefa de
gerenciamento de requisitos e gerencia de configurao. Toda funcionalidade
mapeada no RequisitePro poder ser associada a um elemento do modelo
lgico, que por sua vez est relacionado por um mapeamento de transformao
a um diagrama UML. No final da ponta, este ainda poder estar associado com o
arquivo que representa determinada Classe na linguagem utilizada. Alm disto,
todos estes modelos e diagramas esto versionados no ClearCase. O cenrio
anterior apenas uma demonstrao da capacidade que este ambiente Rational
oferece.
Partindo do tradicional problema da existncia de sistemas legados ou sem
documentao, ele prov um gerador de modelos fsicos a partir de uma simples
conexo JDBC com um banco de dados. Alm deste tradicional modelo, outras
trs variaes so apresentadas, como: Modelo de domnio, Modelo de glossrio
e Modelo lgico. Basicamente, em cada um destes diferentes modelos, existe
uma alterao nos elementos grficos apresentados. O modelo lgico, por
exemplo, se aproxima muito de um MER. Vale lembrar que a qualquer momento
pode-se gerar um script para alterar ou criar o banco de dados a partir de um
modelo, ou faz-lo diretamente usando a conexo da prpria ferramenta.

Ainda no contexto de software legado, uma funcionalidade muito til a

ajuda na migrao da estrutura e dos dados de um banco para a sua verso
mais nova. possvel fazer uma funo de mapeamento de uma verso para a
outra, e automaticamente a converso feita. Alm disto, ele consegue
comparar dois bancos diferentes, gerando um relatrio com todos os campos
variantes.
Caso o DBA seja usado para uma conexo com um banco DB2,
disponibilizada uma ferramenta para desenvolvimento de Procedures. O editor
de texto colore o corpo do cdigo de acordo com a sintaxe da linguagem
utilizada no banco DB2. No modo de debug esto presentes todas as
tradicionais funcionalidades de um ambiente de depurao, como inspeo de
contedo de variveis e opo de reiniciar a execuo de um ponto especfico.
Esta funcionalidade no est disponibilizada para outros gerenciadores de banco
de dados, como era o caso do projeto do LES que usava Oracle.
Por ltimo, vale ressaltar que existem dezenas de outras pequenas
funcionalidades, como a importao e exportao de modelos para o formato
ERwin, rastreamento de dependncias de tabelas, gerao de scripts filtrados
para atualizaes de bancos de uma verso especfica para outra, entre outros.
O RDA se mostrou uma tima ferramenta para documentao. A sua
capacidade de gerao de diferentes tipos de modelos mostrou-se realmente
potente. A ateno e importncia dada s funcionalidades de engenharia reversa
motivaram a continuao da dissertao, pois ressaltou a importncia de um
aplicativo que auxilie na manuteno e especificao de bancos legados. Est
claro no uso desta ferramenta que o problema desta dissertao realmente
existe, pois a interface chama a ateno a todo o momento para opes de
engenharia reversa. Apesar disto, ela reforou a idia que a questo motivadora
deste documento no est disponvel nas ferramentas conhecidas do mercado.
O RDA um sistema complexo, caro e compatvel com os seus concorrentes. O
nico suporte dado a procedures uma ferramenta de debug para usurios do
banco de dados DB2. Em nenhum momento so lembradas e disponibilizadas
opes para a engenharia reversa deste artefato.
Outros bancos de dados tambm possuem ferramentas prprias para
desenvolvimento de procedures. Porm, resumidamente, pode-se dizer que a
ajuda fornecida pelo estudo da ferramenta foi corroborao da importncia de
um trabalho como este aqui apresentado e a constatao da no ateno dada
pelas ferramentas comerciais para o problema.

2.2.
Artigos Diversos

2.2.1.
Towards The Reverse Engineering of UML Sequence Diagrams
(Briand, 2004)
So

comuns,

hoje

em

dia,

ferramentas

que

analisam

cdigo,

principalmente se escrito na Linguagem JAVA, para gerar diagramas UML.

O objetivo do artigo definir uma metodologia para gerar, atravs de
engenharia reversa, um diagrama de seqncia partindo do rastreamento da
execuo de um cdigo. A parte conceitual pouco explorada, dando assim
mais nfase prtica e a exemplos.
Foi feita uma anlise detalhada de algumas outras tcnicas parecidas,
levantando vantagens e desvantagens delas em determinadas situaes. Pelo
menos com relao aos defeitos, h uma preocupao de no repetir os erros
das concorrentes. Segundo o panorama apresentado, percebe-se claramente a
vantagem de usar a metodologia do artigo. Um exemplo disto que nenhuma
das concorrentes exibe condicionais no diagrama de seqncia gerado,
diferentemente da nova soluo proposta.
A estratgia utilizada consiste basicamente em instrumentar o cdigo,
execut-lo e analisar os dados obtidos do rastreamento para gerar o diagrama
final. O ltimo passo feito com a ajuda de dois metamodelos. O primeiro
adaptado da UML e representa o modelo de construo dos artefatos presente
em um diagrama de seqncia. O outro um esquema genrico para armazenar
e organizar as informaes obtidas do rastreamento, como: que mtodo
chamado por quem, as condicionais e iteradores presentes, etc. O cdigo
executado preenche o modelo de rastreamento em que, com a aplicao de
algumas regras de transformao, produzido um modelo de diagrama.
O artigo deixa claro que no tem por objetivo mostrar como gerar um
diagrama de seqncia do modelo de diagrama apresentado. Isto porque ele
considera fcil, alm de no ser este o objetivo do trabalho, e sim facilitar e servir
de infra-estrutura para uma ferramenta CASE, por exemplo. Com relao s
regras de mapeamento, elas so simples e servem no s para transformao
de modelos, como tambm para validao dos diagramas gerados por
ferramentas que seguem esta metodologia.

No final apresentado um estudo de caso em que esta metodologia foi

aplicada. A instrumentao do cdigo foi feita dinamicamente por um aplicativo
escrito em linguagem de script, e o cdigo instrumentado era baseado num
software escrito por outro grupo que produziu tambm um diagrama de
seqncia na fase de especificao, podendo ser assim comparado com o
diagrama gerado pela engenharia reversa. Foi observado um resultado
satisfatrio do experimento, com a nica diferena sendo um maior grau maior
de detalhamento do diagrama gerado, como era de se esperar, pois ele
representa uma viso fiel da execuo.
O artigo tem como ponto forte os modelos apresentados. O modelo de
usado no rastreamento genrico o suficiente para ser utilizado por qualquer
linguagem orientada a objetos, alm de estruturada, sendo adaptvel para
tcnicas que utilizam analise esttica de cdigo. Alm disto, as regras
apresentadas parecem ser realmente corretas e funcionais.
Como ponto fraco est o estudo de caso. No foi mostrado como
instrumentar o cdigo para gerar o modelo de rastreamento. Isto no aparenta
ser uma tarefa fcil, ainda mais com instrumentao gerada automaticamente.
Lembrando tambm que o cdigo tem que ser alterado para que a metodologia
funcione. Existem tcnicas em que isto no necessrio, como as que se
utilizam ferramentas de apoio a debug. E mesmo instrumentado, no foi
comentado como ler todas as entradas da tabela de rastreamento e produzir o
modelo em questo.
Apesar de estar bem fundamentada, a sesso de trabalhos relacionados
no comenta a fundo tcnicas de anlise esttica, como a utilizada pelo software
Together1. Falta uma comparao de vantagens e desvantagens da opo de
uso de rastreamento em detrimento a leitura esttica do cdigo. Uma vantagem
clara o seu uso em linguagens em que o comportamento da classe pode ser
alterado dinamicamente, tendo assim instncias de objetos distintos com
comportamentos diferentes, como acontece com a linguagem Ruby.

2.2.2.
A study on the current state of the art in tool-supported UML-based
static reverse engineering (Kollmann, 2004)
Como citado no artigo da sesso 2.2.1, a UML surgiu e rapidamente se
tornou padro para representao e especificao de sistemas orientados a
objetos.
1

www.togethersoft.com

O objetivo do artigo comparar o modelo gerado por quatro diferentes

ferramentas atravs da tcnica de engenharia reversa, com anlise esttica do
cdigo. Cada ferramenta, indiferente do fabricante ou preo, fornece uma
interpretao nica para um mesmo cdigo fornecido como entrada. Exemplo
disto a modelagem de relacionamentos, como agregao. So estas
funcionalidades bsicas, e as diferentes interpretaes, que este artigo visa
comparar.
As ferramentas escolhidas foram: Together, Rational Rose 2, IDEA3 e
FUJABA4. As duas ltimas so ferramentas acadmicas, desenvolvidas em
projetos de pesquisa, sendo a IDEA um pouco mais conhecida atualmente,
devido ao seu plug-in para a IDE de desenvolvimento IntelliJ 5. Apesar de no
ser to recente, o artigo ainda bastante atual, dado que nos ltimos anos o
foco da evoluo destas ferramentas foi principalmente a usabilidade e
integrao com novas IDEs, como o Eclipse e o Netbeans.
A avaliao foi feita examinando apenas o diagrama de classe gerado e os
critrios utilizados foram: nmero de classes, nmero de associaes, deteco
de interfaces, multiplicidades e regras de nomenclaturas. Foi escolhido um
sistema interno para servir de caso de estudo, e no final os diagramas gerados
eram comparados por uma ferramenta desenvolvida pelos autores do artigo.
Esta ferramenta recebe como entrada arquivos XMI (gerados por todas as
ferramentas utilizadas no estudo) e produz uma listagem das diferenas
existentes entre dois diagramas.
Com

respeito

funcionalidades

bsicas,

todas

as

ferramentas

conseguiram cumprir o seu papel. As diferenas existentes entre os nmeros

encontrados so justificadas pela poltica utilizada pela ferramenta, o que na
prtica no representa um problema, desde que exista um comportamento
padro e o usurio possa esperar que o resultado o leve em conta.
Nas funcionalidades avanadas, como reconhecimento de multiplicidade
de relacionamentos e deteco de interfaces, por exemplo, houve uma
discrepncia grande das ferramentas comerciais e das ferramentas acadmicas.
Isto influencia muito o resultado final, pois o entendimento da lgica da aplicao
fica muito prejudicado, principalmente para reconhecimento de padres de
projeto.
2

www.rational.com

http://idea-uml.qarchive.org/

www.fujaba.de

www.jetbrains.com/idea/

O artigo teve sucesso ao comparar o diagrama gerado, porm tem como

ponto fraco no explorar outras caractersticas e outros modelos da UML
suportados. Foi ignorado o diagrama de seqncia, por exemplo.
No foi comentada a capacidade de gerao do cdigo atravs do modelo.
E, principalmente, a maior falha do artigo foi no comentar a capacidade das
ferramentas de adaptar o diagrama depois de uma mudana drstica ou
refatoramento. Este ponto costuma ser problemtico em ferramentas case.
Em nenhum momento foi evidenciada alguma capacidade de adaptao da
mquina de gerar diagramas pelo programador. Isto porque certamente no
uma funcionalidade disponvel. No possvel utilizar estas ferramentas como
um arcabouo, que permita reescrever parte de um cdigo, ou algum script
numa linguagem proprietria, por exemplo, para adaptar ou reaproveitar as
funcionalidades existentes para alguns casos especiais. Resumidamente, as
ferramentas apresentadas no se mostraram extensveis.
O artigo serviu para confirmar que as ferramentas CASE comerciais
tendem a estar um passo frente das ferramentas acadmicas, alm de reforar
que nenhuma delas disponibiliza pontos de extenso para customizaes de
comportamento, ou reutilizaes de cdigo.

2.2.3.
A reverse engineering methodology to reconstruct hierarchical data
flow diagrams for software maintenance
O artigo (Benedusi, 1989) descreve a metodologia utilizada para gerar um
diagrama de fluxo de dados a partir de um cdigo escrito na linguagem Pascal.
Dos artigos encontrados, o que se aproxima mais do objetivo final deste
documento.
Na primeira metade do artigo so discutidos conceitos genricos da rea
de engenharia reversa. Ele apresenta quais so as estruturas da linguagem que
podem ser extradas para o diagrama automaticamente, porm sem entrar em
detalhes ou dar exemplos. Fica restrito ao campo conceitual. Ele comenta, por
exemplo,

que

nem

todo

conhecimento,

decises

experincias

implementadas no cdigo podem ser automaticamente extradas. Mesmo com a

afirmao anterior, dito que sempre se pode melhorar e aproveitar as
informaes obtidas. Este tipo de discusso perdurou durante metade do artigo,
claramente para justificar as decises tomadas na soluo utilizada. Um exemplo
disto foi o comentrio de que baseado na experincia dos autores, uma
metodologia de engenharia reversa deve ser guiada pelo documento a ser

produzido e pelo artefato de entrada, num processo que, resumidamente, se

inicia com a anlise do documento desejado e termina com o diagnstico do que
se pode retirar das informaes de partida, gerando uma regra de
transformao. Isto o reflexo da soluo proposta.
Na segunda metade do artigo foi apresentada a regra de transformao
utilizada para gerar um DFD a partir de um cdigo Pascal. O primeiro passo a
gerao de um Structure Chart (SC). Isto nada mais do que um grafo em que
os mtodos so vrtices e as chamadas entre eles so arestas. Alm disto,
outras informaes bsicas so necessrias, como as variveis utilizadas nas
chamadas. Feito isso, basta aplicar algumas regras e no final gerado um DFD
perfeito. Estas regras so fceis de serem aplicadas, apesar de serem de difcil
entendimento, devido complexidade existente do texto escrito usando um
padro mais voltado para a matemtica. A primeira regra, por exemplo, fala que
todo n folha, que s possui arestas entrando, vira um processo no ltimo nvel
do DFD gerado. Alm destas, outras regras so fornecidas para definio do que
seria considerado um depsito de dados, entidade externa e os parmetros
passados nos fluxos de dados. Ao final, realmente foi mostrado que foi possvel
atingir o objetivo inicial.
Como dito anteriormente, em nenhum momento houve uma preocupao
em generalizar o processo para outros casos parecidos. O foco sempre foi
Pascal com DFD. A linguagem de entrada poderia ser apenas um detalhe na
aplicao modelo desenvolvida, se fosse produzido um framework para
transformao de SCs em DFDs. Apesar disto, as regras apresentadas podem
ser utilizadas em outras linguagens facilmente. Tambm no foi apresentada
nenhuma estrutura ou modelo de dados utilizado para ajudar a fazer a
transformao. So operaes complexas e, com certeza, iria ajudar caso
algum quisesse seguir o mesmo caminho.

2.2.4.
Extracting Entity Relationship Diagram from a Table-based Legacy
Database
Este artigo (Yeh et al., 2005) relata um trabalho sobre extrao de um
modelo de entidades e relacionamentos (MER) a partir da leitura das
informaes presentes no banco de dados.
Ele descreve sucintamente, sem entrar em detalhes prticos, um processo
genrico para Engenharia Reversa de Banco de Dados (ERBD). Este processo

consiste basicamente em trs passos: preparao do projeto, extrao dos

dados e por ltimo conceitu-los.
A preparao do projeto consiste simplesmente em obter e preparar os
artefatos a serem utilizados, como arquivos DDL, scripts de criao de banco,
entre outros. O segundo passo o mais complicado, pois engloba uma
heurstica de extrao dos dados, que pode ser simples ou complexa,
dependendo do nvel de detalhe e padronizao do material recolhido no
primeiro passo. neste momento que todos eles sero agrupados e sintetizados
em uma estrutura computacional para dar incio ao ltimo processo, que
justamente a gerao do modelo de entidades e relacionamentos, por exemplo.
Abaixo, este processo detalhado especificadamente para o trabalho realizado
pelo grupo.
Percebeu-se que no haveria condio de se extrair toda a semntica
necessria apenas olhando para o banco de dados, pois muitas das vezes os
nomes dos campos, assim como os nomes das tabelas no eram coerentes com
o domnio da aplicao. Para resolver isto, na fase de preparao foi feito um
mapeamento de formulrios com os valores preenchidos. Preenchiam-se os
formulrios do sistema com seus respectivos valores de teste. A fase de
preparao era a ao descrita acima, junto com a extrao dos esquemas das
tabelas com os dados para um meta-modelo. Este meta-modelo consiste em
algumas tabelas descritivas genricas, nas quais todo o banco de dados
resumido e convertido para este novo esquema. Isto permite um padro na hora
de leitura dos dados, independente do modelo fsico real.
Feita a preparao, a extrao dos dados realizada atravs de uma
heurstica de correlao entre os dados obtidos do formulrio e os dados obtidos
da tabela. So apresentadas em detalhes as regras usadas para tal. No final so
descobertas as tabelas e os atributos do modelo de domnio, assim como as
chaves primrias e chaves estrangeiras.
O prximo passo o mais fcil. Com todas as informaes devidamente
mastigadas, s resta a escolha do estilo final do MER, como o modo de tratar
um relacionamento N para N, por exemplo. No final, um diagrama praticamente
pronto gerado. S restam ajustes finos de nomenclatura que esto
devidamente documentados.
Apesar de curto, o artigo colaborar muito com alguns pontos importantes
na dissertao. O primeiro deles o modo de escrita utilizada para descrever o
processo de engenharia reversa. Foi possvel notar um estilo acadmico de
descrever os fatos, que servir de exemplo para alguns tpicos adotados nesta

dissertao. Nisto se inclui o modo como foi dividido o processo de trabalho. Os

trs passos adotados facilitam a organizao do raciocnio, alm de ser um
timo processo a ser seguido, o que permite mais facilmente a definio de um
cronograma e as tarefas a realizar.
Alm do processo de trabalho, a idia da criao de um meta-modelo do
primeiro passo (preparao dos dados) para o segundo (extrao dos dados), de
modo a facilitar o trabalho deste ltimo, ser utilizada. S assim era possvel
montar um meta-ambiente que fosse indiferente s fontes obtidas no primeiro
passo. Assim no era rgido que a leitura inicial fosse feita no contexto de
Procedures de banco de dados, ou em um cdigo C++.

2.2.5.
Inverse Transformation of Software from Code to Specification
Como transcrito do prprio artigo (Sneedm, 1988): Este documento
descreve o esquema suportado por ferramentas automticas para transformao
reversa do cdigo para especificao pelo processo de engenharia reversa.
Na prtica, ele no apresenta nenhuma tcnica ou metodologia para fazer
a transformao e sim conceitos bsicos, porm essenciais para quem quer
realizar um trabalho nesta rea, principalmente com linguagens estruturadas, j
que ele foi escrito para este tipo de tecnologia. Pelo fato de ter sido produzido no
final da dcada de 80, so usados muitos termos e situaes que esto em
desuso atualmente, com exceo de desenvolvedores que do manuteno, ou
programam mdulos, para sistemas antigos. Um exemplo disto o uso de
arquivos fsicos para armazenarem dados e informaes ao invs de
gerenciadores de banco de dados.
Um software apresentado como contendo trs nveis de abstrao com
objetivos distintos: Conceitual, Lgica e Fsica. O primeiro a viso da rede de
entidade com seus atributos e seus relacionamentos. O segundo a viso da
organizao dos dados e o terceiro uma viso mais baixo nvel, perto da
implementao, chegando perto de um pseudocdigo.
So apresentados alguns conceitos bsicos, como motivos para se realizar
a engenharia reversa, afirmaes, como a que diz que mais fcil alterar
programas com modelos conceituais existentes, e regras para se ter uma boa
especificao. A especificao dividida em duas categorias: especificao de
dados e do programa. Estas categorias so subdivididas em outras
subcategorias. O cdigo ento partilhado em grupos de elementos, como

arquivos de execuo, arquivos de armazenamento de dados, entre outros. No

final so apresentadas regras de mapeamento, que na verdade servem como
um guia de boas prticas para derivar uma subcategoria da especificao de um
grupamento originado do cdigo. So regras que esto no campo conceitual.
Isto porque no so apresentados modelos reais de especificaes a serem
produzidos e sim categorias de artefatos e as regras que mapeiam o cdigo para
elas.
O artigo muito til para arrumar os conceitos, apesar de ser um tanto
datado. Com ele possvel expressar mais facilmente o objetivo e que tipo de
artefato se deseja produzir quando se est imaginando um processo ou
programa para engenharia reversa. Talvez, por isso, seja citado por praticamente
todos os outros artigos referenciados anteriormente, tornando-se obrigatrio ser
lido.

2.3.
Frameworks para gerao de diagramas
Existem alguns produtos que possuem objetivos semelhantes parte
deste documento que objetiva a criao de um framework para diagramao de
grficos. Segue abaixo os principais.

2.3.1.
Eclipse Modeling Framework (EMF)
EMF (Eclipse Foundation, 2008) um framework Java para tratar
aplicaes que fazem uso de modelo, como digramas de classes, diagramas de
estados, entre outros. Basicamente, o foco do projeto so linguagens orientadas
a objeto e modelos definidos na UML. Com isso fcil criar um editor ou um
diagrama com opes de arrasto de elementos e outras funcionalidades tpicas
de ferramentas case, como gerao de cdigo.
A entrada para a criao dos modelos pode ser feita de vrias formas,
desde arquivos XML at classes escritas na linguagem Java. Isto permite que
outras aplicaes consigam se integrar facilmente a ela. Na prtica basta entrar
com os dados do diagrama em um editor bsico fornecido pelo framework que
possvel obter facilmente algo parecido com a figura abaixo.

Figura 2: Exemplo de um diagrama gerado com a EMF

Caso queira fazer um aplicativo para gerar diagramas de seqncia a partir

de cdigo Java, por exemplo, basta criar um interpretador que leia o cdigo e
gere os metadados necessrios para criar o diagrama. O trabalho de gerar os
dados seria o mais complicado, pois o EMF se encarregaria de exibir o
diagrama. Porm, j no to confortvel quando se deseja adicionar aes
especficas, como dois cliques em uma classe. Todas estas aes so
chamadas seguindo o modelo tradicional de eventos do Java. No existe um
modelo de iterao, em que seja permitido configurar no mesmo XML o modelo
e as aes sobre ele. Isto dificulta um pouco a criao de algo genrico
acoplado a um aplicativo de terceiros.
As facilidades citadas para criao de elementos UML comeam a
desaparecer quando se deseja usar outros modelos, como um DFD, por
exemplo.
Outro ponto crtico no ser possvel usar o EMF fora do ambiente
Eclipse. Para utiliz-lo necessrio obrigatoriamente ser um plug-in da IDE
citada. Em parte, isto se justifica pelo fato dele usar por baixo o GEF para pintar
os elementos na tela, o que obriga por tabela o uso do SWT. Ou seja, no
possvel criar uma aplicao Swing fora do Eclipse e fazer uso do GEF. Isto
restringe e muito o publico alvo do framework.

O EMF se mostrou um timo framework para criao de plug-ins para o

Eclipse com o objetivo de manipular editores de modelos orientados a objetos,
provenientes de engenharia reversa ou no, e gerar cdigos na linguagem Java.
Qualquer coisa fora deste contexto j comea a se tornar de difcil manipulao.
Como so poucos, seno nulos, os concorrentes e frameworks com objetivos
semelhantes, ele deve sempre ser levado em considerao em projetos que
envolvam engenharia reversa e gerao de diagramas.

2.3.2.
Graphviz
Graphviz (AT&T, 2008) um projeto de cdigo aberto para visualizao de
grafos. Na figura abaixo possvel ver um exemplo de um diagrama produzido
pelo produto.

Figura 3: Diagrama gerado pelo Graphviz

Ele no se prope em ser uma alternativa a programas como o Visio, da

Microsoft. Isto por que no existe um editor amigvel para gerar o diagrama. Ao
invs disto, utilizado um arquivo de texto simples escrito na linguagem
Dot(AT&T, 2008).
Dot foi desenvolvida pelo projeto para ser uma linguagem voltada para a
criao de grficos. O segredo da linguagem ser simples e de fcil
aprendizado. No necessrio saber programar nem conhecer informtica para
conseguir escrever um grfico utilizando ela.

O Graphviz no um software, e sim um projeto que engloba diversas

tecnologias e ferramentas focadas na visualizao de grafos. Existem vrios
aplicativos, como o que transforma um arquivo escrito em Dot para uma imagem
SVG, ou mesmo Postscript. O mais conhecido, porm, o que permite a
visualizao direta do arquivo, sem a necessidade de gerar imagens
intermedirias.
Para visualizao ele uma tima ferramenta, pois possvel modificar
completamente o layout do grafo, com customizao de cores e imagens dos
ns, o que torna ele capaz de exibir diagramas complexos, como um DFD.
O seu ponto fraco no ser possvel interferir no diagrama gerado. Ele
fornece a disposio dos ns, e no permitido alterar isto. Entretanto, o
algoritmo utilizado muito bom e consegue arrumar os ns numa disposio
aceitvel. Alm disto, ele esttico, no possvel utiliz-lo dentro de uma
aplicao maior com um modelo de iterao dinmico, como abrir uma janela ao
selecionar um n, por exemplo.
As limitaes acima impedem o projeto de ser usado em uma ferramenta
com o foco em engenharia reversa, pois os diagramas gerados por estes
produtos nem sempre so fieis ao que o usurio deseja ter como documento
final. Ento a necessidade de alterao e customizao dinmica faz com que o
Graphivz no seja uma boa alternativa, dado que existem opes melhores para
estes casos, como o EMF.

2.4.
Ferramentas Utilizadas

2.4.1.Visual Library
Para exibio do diagrama no Framework apresentado no captulo 4, foi
usada a API de desenho Visual Library (Netbeans, 2008). Visual Library a
prxima gerao de bibliotecas para manipulao grfica. Esta frase, exposta
no site principal do projeto, mostra bem o quo poderosa . Ela foi concebida
inicialmente como parte da IDE de desenvolvimento Netbeans. A sua criao foi
motivada pelos diversos mdulos que exigiam manipulao de diagramas e
grficos. Seguem como exemplo duas telas da IDE que usa a biblioteca grfica.

Figura 4: Desenvolvimento mvel e criao de aplicativos SOAP

Na Figura 4, esquerda visualizada a ferramenta de criao de

aplicativos voltados ao mercado de aparelhos portteis, como celulares e PDAs.
direita um exemplo do mdulo de desenvolvimento de aplicativos SOAP,
como Webservices. Alm destes dois, existe o mdulo de diagramao e
gerao de documentos UML, que tambm lana mo desta tecnologia. Como
pode ser observado, uma necessidade interna fez nascer a Visual Library.
Ela de cdigo aberto como comum em artefatos ligados ao projeto
Netbeans, podendo ser alterada e usada gratuitamente em todas as situaes,
sem restries.
O seu uso no est limitado a aplicativos internos IDE. Qualquer
processo Java, sem nenhuma restrio de mquina ou ambiente de
desenvolvimento, pode aproveitar suas funcionalidades.
Basicamente o que a ferramenta faz auxiliar na criao de softwares que
utilizam diagramas em sua interface grfica. Todo o trabalho de criar conexo
entre os elementos, organizar o layout e editar as posies de todos os artefatos
apresentados pode ser realizado sem nenhuma dificuldade prtica. O modo de
programar muito parecido com o Swing, o que facilita quando existe um
conhecimento prvio da API de desenho default do Java. Alm disto, intuitivo e
rpido. Todo o estilo dos diagramas, assim como o comportamento dos seus
elementos na interface, so altamente customizveis. Existe uma configurao
padro, e programaticamente possvel mud-la.
Neste trabalho, esta API foi de fundamental importncia. Ela diminuiu o
tempo de desenvolvimento da gerao dos diagramas, alm de fornecer um
acabamento profissional ao projeto. Vale lembrar que ela no facilita a gerao
do diagrama propriamente dito, e sim a implementao de uma ferramenta que
objetive isso. Diferente do EMF (Captulo 2.3.1), ele apenas uma API, e no
uma aplicao.
Para compar-la com outras ferramentas do gnero, podemos citar o GEF,
do projeto Eclipse. O objetivo exatamente o mesmo, porm com um grau de

complexidade maior. Por ser mais antiga, muito das suas dificuldades de uso
foram retiradas pela Visual Library, que possui em sua API elementos similares
aos do GEF, alm de outras referncias que deixam ntido de onde veio a
inspirao do projeto. O desenvolvimento deve ser feito usado a API Grfica
SWT, que menos conhecida que o Swing. Alm disto, mesmo sendo cdigo
aberto, difcil de baixar e compilar. Perde-se muito tempo ao tentar fazer isto. A
Visual Library, com o cdigo na mo, instantnea. Esta caracterstica dificulta
no momento de entender como ela funciona internamente, exerccio fundamental
no uso de recursos avanados.

3
A Ferramenta Dependencies Viewer

Como visto anteriormente, para programas escritos na linguagem Java,

existe uma infinidade de ferramentas capazes de fazer a engenharia reversa. Os
diagramas gerados, em geral, so baseados na notao UML. Para a exibio
do comportamento e chamadas da aplicao, normalmente utilizado o
diagrama de seqncia.
Ao procurar produtos similares para outras linguagens, foi diagnosticada
uma carncia existente no mercado. No existe software pago ou grtis que faa
isso de forma adequada para um programa escrito em PL/SQL, por exemplo. E
aumentando o universo, podemos dizer o mesmo para as linguagens Pascal,
Cobol, Fortran, entre outras. O objetivo da ferramenta Dependencies Viewer
fornecer informaes similares a encontrada no diagrama de seqncia para
qualquer tipo de linguagem, ou pelo menos que facilite este objetivo

3.1.
O Metamodelo
Na prtica, a tarefa de produzir um diagrama comportamental para
softwares escritos em qualquer linguagem muito difcil, seno impossvel, visto
que impraticvel a implementao de um analisador sinttico genrico o
suficiente para conseguir interpretar todas as idiossincrasias existentes num
conjunto finito, porm grande, de linguagens.
Para solucionar este problema, a ferramenta Depedencies Viewer segue o
modelo elaborado mostrado abaixo:

Figura 5: Esquema de funcionamento da ferramenta

Como pode ser visto acima, a ferramenta tem como ponto de extenso um
meta-modelo que representa a rvore de chamadas e as informaes
necessrias para exibir o diagrama. Para flexibilizar este ponto, o usurio da
ferramenta deve complement-la com a implementao de um analisador
especfico para a linguagem escolhida. Na prtica esta complementao no
algo complexo, visto no ser necessria a produo de um parser para toda a
gramtica da linguagem em questo, mas somente para alguns pontos chaves,
como chamadas de mtodos, que podem ser feitas atravs de um simples
programa usando expresso regular, por exemplo. No estudo de caso discutido
no captulo 5 mostrado um exemplo deste processo ocorrendo.
Ao ser completada com as informaes provenientes do parser
implementado pelo usurio, a ferramenta est pronta para ser usada. Ela
fornece uma interface completa para sua utilizao e o usurio interage com ela
configurando como deve ser o diagrama final produzido pela ferramenta, Estas
funcionalidades sero detalhadas melhor na sesso 3.5.
Os metadados fornecidos pelo usurio podem ser divididos em duas
categorias: Dados de modelo e Dados de configurao:
Os dados de modelo informam a composio da rvore de chamadas, ou
seja, indica a referncia entre os elementos, e comentrios que porventura se
desejam exibir na ferramenta. Um exemplo disto, que no estudo de caso,
existiam comentrios no estilo Java doc6 no incio de cada procedure que eram
de fundamental importncia para o entendimento do funcionamento do sistema.
Alm disso, era necessrio exibir os parmetros de entrada e sada, pois
auxiliavam na compreenso da procedure pelos desenvolvedores.
Os dados de configurao servem para auxiliar a ferramenta no modo
como ela deve se apresentar ao usurio. Caso no queira usar o diagrama
padro, possvel, por exemplo, alterar a forma como exibido na tela o
diagrama final. Isso prov uma flexibilidade grande ferramenta. Alm disso,
possvel modificar a existncia, ou no, de alguns menus e funcionalidades.
Estas configuraes podem ser suficientes para produzir duas ferramentas
diferentes entre si, tendo como nico ponto divergente o arquivo de
configurao.
Os arquivos de metadados so na verdade o corao da ferramenta. Eles
so lidos por ela atravs do formato de arquivos textuais escritos numa
6

Java Doc uma ferramenta desenvolvida pela SUN Microsystems para gerar

documentao de API no formato HTML. Em: HTTP://java.sun.com /j2se/javadoc/

linguagem de representao especificadamente feita para isso. Nas sesses a

seguir, a linguagem de representao ser apresentada.

3.2.
A linguagem de Representao
Para o funcionamento da ferramenta, existem dois tipos de dados que
precisam ser configurados: Os metadados de configurao, e os metadados de
modelo. Embora estas informaes pudessem ser passadas para a ferramenta
atravs de uma API de programao, foi decidido que, para tanto, seriam
utilizados arquivos de configurao. O motivo desta escolha est no fato de
facilitar a integrao com outras ferramentas que no esto necessariamente
escritas em Java. Estas ferramentas poderiam ter como sada direta os arquivos
de configurao prontos, o que simplificaria o seu uso. Um exemplo disto pode
ser encontrado no captulo 5, que relata um estudo experimental.

3.2.1.
Metadados de configurao
Abaixo segue uma gramtica abstrata definindo a linguagem de
configurao. Terminais esto em negrito e no terminais esto em itlico.
Caracteres literais so apresentados entre aspas simples, Parnteses, ( e ),
indica um grupo necessrio. Colchetes, [ e ], indicam grupos opcionais. Barra
vertical, | , separa alternativa.

Cdigo 1: Gramtica da linguagem de configurao

As palavras application, edge e menu so palavras reservadas e

identificam um elemento de configurao, juntamente com o Node, idenficado
por um ID_NODE.
Um ID_NODE define o identificador de um Node. Nas prximas sesses
ser discutido o que um Node. Obrigatoriamente um ID_NODE deve estar
entre aspas duplas e formato pelos caracteres alfanumricos, o que no caso
de ASCII corresponde a [A-Za-z0-9]. No pode haver espao.
Um ID_ATTR tem uma formao praticamente idntica ao ID_NODE,
diferenciando-se pelo fato de no ser escrito entre aspas.

A regra de definio de um value a mesma de um ID_NODE

adicionando-se o fato de poder conter os caracteres espao ( ), undescore (_)
e hfen (-), que no existem em um ID_NODE.
Abaixo segue um exemplo de um arquivo escrito nesta linguagem. Este
arquivo foi feito para funcionar com a ferramenta da avaliao experimental.

Cdigo 2: arquivo dependenciesViewer.config da avaliao experimental

Cada elemento (Node, Menu, Edge ou Application) possui o seu objetivo e

uma listagem prpria de atributos e valores possveis. Nas prximas sesses isto
ser discutido.

3.2.1.1.
Node
Um n representa um tipo de objeto do modelo de negcio que a aplicao
est inserida. Por exemplo, num diagrama de classe, um n poderia ser a
representao de uma classe. Na linguagem proposta, possvel identificar um

Node quando o nome do elemento no for uma das palavras reservadas e/ou
estiver escrito entre aspas duplas. No exemplo dado, classe.
Na linguagem possvel configurar atributos de visualizao do n, regras
de formao, e quais so as informaes de detalhes. Abaixo segue uma tabela
com trs colunas: Nome do atributo, composio e descrio. A coluna
composio indica se o atributo multivalorado ou no. Caso positivo, na coluna
de descrio tem o detalhamento do significado destes vrios valores.
Nome
id

Label
Shape

Detail

Composio
Sim

Descrio
Indica a lei de formao do identificador do
objeto. No exemplo do diagrama de classes,
uma classe no indexada apenas pelo seu
nome, pois podem existir duas classes
homnimas, porm em pacotes diferentes. O
que as diferenciam e as tornam nicas a
composio do nome do pacote com o nome
da classe. Tem que haver, porm, uma
contraposio no arquivo de modelo, que
deve seguir, sempre que referenciar um
objeto deste tipo, a lei de formao
configurada aqui.
Exemplo:
Arquivo de configurao: id={package,
nome)
Arquivo
de
modelo:
br.pucrio.les.NomeClasse
No
Indica qual a String que representa o nome
deste tipo na tela.
No
Indica como ser a apresentao visual
deste elemento. Pode ser umas das formas
padro da ferramenta (table, process) ou
uma
classe
que
especialize
IInstanceShapeEnum (Sesso 4.1.1)
No
Indica quais so as informaes de
detalhes do elemento. No exemplo do
diagrama de classes, poderia ser um
Javadoc. Nos arquivos de modelo, por
exemplo, quando for dada entrada de um
detalhe
deste
objeto,
dever
estar
especificado como sendo uma informao de
Javadoc.
Tabela 1: Atributos do elemento Node.

3.2.1.2.
Edge
Este elemento serve para configurar como ser a representao visual da
relao de dois ns. A configurao default uma linha reta cheia direcionada.

Nome
Source
Target
LineStyle

LineSize
SourceTerminato
r

Composio
No
No
No

Descrio
Elemento de origem
Elemento de destino
Indica o estilo da linha que representa o
relacionamento. Os valores possveis so:
TRACED: Para linhas pontilhadas
DRASHED: Linhas que possuem um ponto
seguido de um trao pequeno reto.
CONTINUOUS: Linha cheia. o valor
default, caso no seja informado nada, ou um
valor invlido

No
No

Tamanho da grossura da linha

Representa como ser apresentado o incio
da reta. Deve ser um ITerminatorEnum
(Sesso 4.3)
TargetTerminator
No
Representa como ser apresentado o fim
da reta. Deve ser um ITerminatorEnum
(Sesso 4.3)
Tabela 2: Atributos do elemento Edge.

3.2.1.3.
Menu
Um elemento de menu especifica, na verdade, uma funcionalidade de
busca a partir de um tipo de Node. Mais adiante esta funcionalidade ser
explicada de modo mais claro (Sesso 3.5.1). O importante, agora, saber que
todos os relacionamentos so traduzidos internamente para um grande grafo,
onde cada n do grafo pertence a um tipo especfico, configurado pelo elemento
Node. Esta funcionalidade, ento, abre uma busca por um objeto a partir de um
tipo especfico, para que seja apresentado na tela um subgrafo do grafo maior.

Nome
Title
Node

Columns

Elements

Invisible

Visible

Composio
No
No

Descrio
Ttulo da janela principal da funcionalidade.
Especifica qual o tipo de objeto que ser buscado
nesta funcionalidade. Tem que estar configurado um
elemento Node, onde o ID_NODE deste elemento
igual ao valor desta propriedade.
Sim
um par de valores, especifica as colunas que
sero
exibidas,
que
obrigatoriamente
so
identificadores do n em questo, sendo o primeiro
valor o identificador, e o segundo a Label de
visualizao. Por exemplo, no caso do diagrama de
classes, ter uma entrada no arquivo com
columns={package, Pacote} e outra com
columns={name, Nome da Classe}. Este atributo
poder ser repetido quantas vezes forem os
identificadores do n, sendo apenas uma vez para
cada identificador. A ordem de escrita no arquivo a
ordem de ordenao das colunas na tabela de
busca.
Sim
Um objeto de um tipo pode referenciar um objeto de
outro tipo. Num DFD, por exemplo, um processo
pode ter uma ligao com uma entidade externa.
Este atributo serve para que na interface aparea
um checkbox que desliga e liga, no diagrama final
apresentado, a opo de visualizar estes outros
tipos relacionados com o Node configurado. Os
valores deste atributo so ID_NODE dos outros tipos
de ns.
Sim
ID_NODE dos outros tipos de Node que vem
desligado por padro. Com o atributo acima,
possvel reverter essa configurao, habilitando o
checkbox do n invisvel, que neste caso, vem
desabilitado.
Sim
Atributo anlogo ao de cima, diferenciando-se pelo
fato de vir ligado, e no desligado, por padro.
Tabela 3: Atributos do elemento Menu.

3.2.1.4.
Application
Este elemento serve para configurar atributos da aplicao como um todo.
Nome
Title
Files

Composio
No
Sim

Descrio
Ttulo da janela principal do programa
Nome dos arquivos de modelo. Sero lidos apenas
os arquivos que estiverem o nome como valor deste
atributo.
Tabela 4: Atributos do elemento Application

3.2.2.
Metadados de modelo
Basicamente, so duas as informaes passadas pela configurao de
modelo: a cadeia de relacionamentos, informando quem se relaciona com quem,

com os seus possveis esteretipos e os detalhes daquele objeto, que podem

ser apenas um comentrio ou um conjunto deles.
Abaixo segue a gramtica usada na modelagem dos dados. Ela muito
parecida com a gramtica anterior, porm apresenta algumas diferenciaes.

Cdigo 3: Gramtica da linguagem de modelo

Um ID_OBJECT deve seguir a regra de formao do identificador do Node

especificado no arquivo de configurao. No diagrama de classe, o nome da
classe especificado como sendo pacote mais o nome, ou seja, a composio
de duas informaes. Um ID_OBJECT deve seguir este formato, sendo escrito
na seguinte estrutura: todas as strings identificadoras devem estar entre aspas
separadas pelo caractere ponto (.). No exemplo do diagrama de classe, poderia
ser: br.puc-rio.inf.les.NomeDaClasse .
Uma string um texto livre escrito entre aspas duplas. Caso ela tenha em
sua composio o caractere aspas duplas, ele deve ser escapado por uma barra
invertida (\).
O ID_NODE especificado nesta gramtica deve existir no arquivo de
configurao primeiro.
Similar a um ID_NODE, um ID_DETAIL deve existir como um valor do
atributo detail do elemento Node.
Esta linguagem pode estar escrita em diversos arquivos. A nica regra o
fato de ser preciso informar, no arquivo de configurao, os nomes dos arquivos
de modelo.
Nas sesses a seguir so detalhados os dois tipos de dados passados
pela linguagem de modelo.

3.2.2.1.
Relacionamentos
O modo de informar a ferramenta quais so os objetos de determinados
tipos e como eles se relacionam atravs de um arquivo de configurao escrito
na linguagem acima.

Figura 6: Relacionamento entre uma procedure e uma tabela estereotipado

Cdigo 4: Exemplo de cdigo gerador da imagem acima

No exemplo acima, o Cdigo 4 responsvel pela entrada da informao

de modelo gerador da Figura 6. Como o exemplo didtico, apenas uma linha
de relacionamento foi includa, porm poderiam ter inmeras linhas, que elas
seriam refletidas do mesmo modo no diagrama exibido. No exemplo dado,
usado um qualificador logo aps o operador de relacionamento (->). Neste
caso, a string informada exibida no meio da seta de relacionamento. Caso
tivesse um estereotipo escrito no incio da linha, este seria apresentado no inicio
da seta de relacionamento, perto do n de origem. Ao contrrio, se estivesse no
final da linha, ele seria exibido no fim do relacionamento, perto do elemento
destino, neste caso perodo_carga_planab.
Um relacionamento, do ponto de vista do aplicativo, sempre
unidirecional. No Cdigo 4, apresentado um relacionamento do tipo de
elemento Procedure com o tipo Table. Visualmente, caso no se queria
direcionar a linha de ligao dos elementos, preciso, no arquivo de
configurao, dizer que o relacionamento acima no possui terminador no objeto
destino. Isto passar a idia, para o usurio que esteja utilizando a aplicao, de
ser bidirecional.

3.2.2.2.
Detalhes
Um detalhe pode ser qualquer informao. Um elemento pode conter
diversos tipos de detalhes diferentes, que so separados e exibidos
categorizados na interface da ferramenta. O Cdigo 5 um exemplo de dado
que passado para a ferramenta gera a informao exibida na Figura 7.

Figura 7: Exemplo de visualizao de detalhes

Cdigo 5: Cdigo responsvel por gerar a Figura 7.

No exemplo dado, uma procedure pode possuir dois tipos de detalhes

diferentes: Inputs e Outputs. Estes tipos devem estar configurados primeiro no
arquivo de configurao, para que aqui, no arquivo de modelo, seja informado o
contedo dos detalhes e quais so os objetos aos quais ele pertence.

3.3.
Instalao e uso da ferramenta
O primeiro passo colocar os arquivos de configurao na mesma pasta
do

JAR

ProcedureDependency-1.0.jar

http://code.google.com/p/meta-designer/),

ou

adicionar

(localizado
a

pasta

em:
onde

se

encontram os arquivos no classpath do sistema operacional. A ferramenta utiliza

essas duas heursticas para ler os metadados. O nome do arquivo de
configurao deve ser dependenciesViewer.config.
Para utilizar o aplicativo, necessrio ter instalado a mquina virtual do
Java, na verso 1.4 (http://java.sun.com), ou mais recente. Aps sua instalao,
possvel executar o Jar ProcedureDependency-1.0.jar (localizado em:
http://code.google.com/p/meta-designer/) atravs da seguinte linha de comando,
onde o driver E corresponde a pasta onde se encontra o aplicativo
E:\java -jar ProcedureDependency-1.0.jar
Uma outra alternativa, no Windows, clicar com o boto direito no Jar, e
selecionar a opo Open With->Java Platform SE binary (Figura abaixo).

Figura 8: Execuo do jar no windows

3.4.
Modelo

Figura 9: Diagrama de classe simplificado da ferramenta

Na Figura 9 apresentado um diagrama de classes simplificado para fins

didticos do modelo da ferramenta. Ao ler os arquivos de configurao e modelo,
toda a rvore de chamadas traduzida para um grafo. Isto facilita na hora de
caminhar por ele e selecionar os ns que devem ser exibidos. A classe Node
um n do grafo, e possui um ou vrios outros ns relacionados a ela. Cada
entrada nesta associao representa uma aresta.
Um grafo possui um NodeConfiguration, que so as caractersticas
definidas no arquivo de configurao. Esta classe origem de um Edge que
possui outro NodeConfiguration como destino. Um Edge guarda as informaes
de metadados do relacionamento de dois ns.
Estas duas ltimas classes so os metadados que orientam a criao do
grafo. Elas guardam as informaes necessrias para visualizar o diagrama no
framework apresentado no captulo 4.
A classe detail organiza as informaes de detalhes de um n. Tambm
configurada no arquivo de metadados, pelo atributo detail de um Node (sesso
3.2.1.1).
Os metadados de Menu so interpretados e aplicados no momento de
inicializao do sistema, no precisando ser guardados no modelo apresentado
acima.

3.4.1.
O processo de desenvolvimento
Apesar de possuir apenas um nico recurso humano alocado para o
desenvolvimento da ferramenta, algumas precaues foram tomadas para dar
um mnimo de qualidade ao produto final gerado. Estas medidas foram
essenciais para que, no final, uma ferramenta estvel e garantidamente testada
fosse disponibilizada para qualquer usurio interessado. A inteno era no
produzir um software apenas para o estudo de caso desta dissertao, e sim um
artefato que pudesse ser utilizado fora do mbito acadmico. Nas prximas
sesses seguem algumas prticas adotadas no desenvolvimento.

3.4.2.
Subversion
Trabalho em equipe no um problema de diviso e conquista apenas.
um problema de diviso, conquista e integrao (Beck & Andres, 2004). Apesar
de, como dito anteriormente, ser desenvolvido por um nico programador, foi
tomada a precauo de utilizao de uma ferramenta que possibilita o trabalho
em grupo. Isto garante que, ao precisar da entrada de mais pessoas no projeto,
o processo de desenvolvimento no ser alterado. Alm disso, as ferramentas
que fazem este tipo de controle de integrao realizam tambm o controle de
verso dos artefatos desenvolvidos. Isto vital para garantir certa liberdade e
organizao ao desenvolvedor. O programador sabe que ao fazer determinada
alterao, e esta se propagar negativamente para o restante da aplicao, ele
pode, por exemplo, recuperar a verso que no continha este problema,
comparar e identificar aonde ocorreram as alteraes que incluram o bug7. Foi
usado, para esta finalidade, o Subversion.
Subversion uma aplicao open source para controle de verses.
Tambm conhecido como SVN, o Subversion foi feito especificamente para ser
um substituto moderno para o CVS 8. Isso significa que o Subversion trata
problemas que no so resolvidos pelo CVS e possui conceitos mais
7

Um Bug qualquer defeito encontrado em um programa de computador. A

palavra um anglicismo, e traduz literalmente como inseto.

8

Do ingls Concurrent Versions System, o CVS implementa um sistema de

controle de verses. Ele observa todo o trabalho e todas as alteraes em um conjunto

de arquivos e permite que vrios desenvolvedores colaborem entre si (de forma
totalmente separada

amadurecidos de controle de verses de arquivos e projetos. Por esse motivo, o

uso do SVN recomendado ao invs do CVS.

3.4.3.
Issue tracker
Como ser visto no captulo que fala sobre o estudo de caso, o processo
de anlise de requisito foi iterativo e incremental. Primeiro foi desenvolvida uma
verso da ferramenta especfica para os interesses do projeto do LES. Ao final,
ela foi evoluda para a sua atual fase. Na primeira fase, os bugs e as
necessidades de evolues foram cadastradas num sistema controlador de
tarefas, fornecido gratuitamente pelo Google, chamado Google Code9. Isto deu
agilidade ao processo, visto que o usurio, ou a pessoa que estava querendo
uma alterao na ferramenta, no precisa ficar se comunicando por email e
esperando uma resposta. Bastava abrir ferramenta, cadastrar o seu pedido e
acompanhar a evoluo do estado da tarefa.
O Google Code tambm permite que o desenvolvedor cadastre o tempo
estimado de cada tarefa, e o tempo real de desenvolvimento. Isso permite o
controle fino sobre as tarefas e o andamento do projeto. Como o projeto foi
desenvolvido sem um compromisso comercial, e com certa liberdade de
requisitos e prazos, este processo no foi utilizado no desenvolvimento desta
ferramenta.

3.4.4.
Maven10
O Maven uma ferramenta que est ganhando constantemente espao no
ambiente de desenvolvimento Java. Alm de controlar o processo de construo
de um software, o Maven oferece uma abordagem abrangente para gerenciar
projetos de software. Desde a compilao at a distribuio, incluindo
documentao e colaborao entre a equipe, o Maven oferece as abstraes
necessrias para encorajar o reuso e diminuir muito do trabalho para fazer os
builds de um projeto (Massol & Van Zyl, 2006).
No projeto, o Maven foi importante para automatizar a compilao e o
controle de dependncias do aplicativo. Isso foi de extrema relevncia, pois
como o projeto no usa o conceito de integrao contnua, era possvel, ao final
9

http://code.google.com

10

http://maven.apache.org/

de cada dia de trabalho, rodar o build que compila, executa os testes e gera o
instalador. Ele garante que o instalador s disponibilizado, se todos os testes
unitrios escritos estiverem rodando e passando. Isso fornece um mnimo de
qualidade ao processo.
Alem de automatizar o build, no projeto, o Maven responsvel por gerar a
documentao da API e um relatrio de cobertura de cdigo.

3.4.5.
Test Driven Development
Todo cdigo produzido sem testes, , por natureza, um cdigo legado
(FOWLER, 99). Esta afirmativa foi a diretriz bsica para todo o desenvolvimento
do projeto. O teste uma ferramenta til para garantir uma boa qualidade do
cdigo, e dar conforto ao desenvolvedor para realizar as devidas evolues,
correes e refatoraes. Existem vrias tcnicas de testes, e neste trabalho foi
usado Test Driven Development (TDD).
Tambm conhecida como programao ou desenvolvimento em que se
escreve um teste primeiro, TDD uma abordagem incremental que envolve a
criao de um caso de teste anteriormente implementao do cdigo
necessrio para que este passe. Depois disso, o teste executado para provar
que este realmente falha. Usando o conceito de design simples (do ingls simple
design11) o mtodo implementado de forma a fazer com que o teste de unidade
passe. Uma vez que isso acontea, o programador usa o refactoring para limpar
o cdigo e mant-lo sob as regras de design simples. Esses passos so feitos
sucessivamente, at que cada funcionalidade esteja pronta.
Ao final do desenvolvimento, verificou-se atravs de relatrios de
coberturas de cdigo (Sesso 3.4.4) que em mdia 80% do cdigo se encontram
11

Simple Design um princpio de XP e quer dizer que o design de um mtodo,

classe ou sistema deve ser o mais simples possvel. Por exemplo, se um cliente
concordar que na primeira verso apenas o usurio "teste" com a senha "123" vai ter
acesso a todo o sistema, somente o cdigo exato para que esta funcionalidade seja
implementada deve ser escrito. Preocupaes com sistemas de autenticao e
restries de acesso no importam neste momento. Um erro comum, no entanto, por
parte dos programadores confundir cdigo simples com cdigo fcil de escrever.
Cdigo fcil de escrever todo aquele que escrito sem preocupaes de design. Nem
sempre este tipo de cdigo levar soluo mais simples de design. Esse entendimento
fundamental para o bom andamento de XP. Por isso, todo cdigo fcil de escrever
deve ser identificado e substitudo atravs de refactoring por cdigo simples.

testado. Os 20% que no possuem testes, so classes de interface, onde a

produo de testes requer outras abordagens no utilizadas neste trabalho.

Figura 10: Relatrio de testes de um pacote especfico.

3.5.
Funcionalidades
O objetivo principal do aplicativo gerar visualmente diagramas de
dependncias para as informaes fornecidas pelos metadados de modelo. Para
isso, a ferramenta possui uma srie de outras funcionalidades que servem como
meio para se alcanar o objetivo final.

Figura 11: Imagem da tela principal do programa.

Na Figura 1 apresentada a tela de abertura do programa, primeiro

contato do usurio com o aplicativo. Esta tela foi retirada da ferramenta
configurada para rodar no estudo de caso.
No caso do aplicativo configurado acima, o boto 1 o responsvel por
abrir a opo de gerar um diagrama a partir de uma procedure. O boto 2 abre o
diagrama de dependncias a partir de uma tabela, na ordem contrria,
mostrando todas as procedures que referenciam aquela tabela. Estas duas
funcionalidades so originadas pela modelagem de configurao (sesso 3.2.1)
definida pelo usurio. No aplicativo acima, foram modelados dois tipos de
instncia de negcio, a procedure e a tabela. Simultaneamente, o arquivo de
configurao foi preparado para suportar buscas a partir dos dois objetos. Isto se
refletiu na interface atravs destas duas funcionalidades.
O boto 3 exporta o diagrama exibido no momento para uma imagem fora
do sistema. Finalmente, os controles indicados por 4 so responsveis pela
navegao no diagrama atravs dos ns. Segue abaixo um detalhamento de
cada uma destas funcionalidades.

3.5.1.
Escolher uma entidade

Figura 12: Tela que abre ao seleciona o boto de abrir procedure

Como dito anteriormente, toda a rvore e chamadas de todas as entidades
montada em forma de um grafo. Esta funcionalidade serve, ento, para gerar
um subgrafo a partir de uma entidade de modelo configurada. Este subgrafo,
posteriormente, transformado no diagrama procurado. A gerao deste grafo
menor essencial, pois no teria como produzir um diagrama legvel se toda a
rvore de chamadas fosse traduzida em uma nica imagem.
A existncia desta funcionalidade est condicionada a uma configurao
especfica dos metadados, j comentada anteriormente. Na ferramenta do
estudo de caso, existem duas buscas por entidades, a busca pelas procedures,
como pode ser visto na Figura 12, e a busca a partir de uma tabela. Porem, num
sistema que possui cinco entidades, poderia haver cinco botes de busca para
gerar um subgrafo a partir do objeto da entidade escolhido.
Na tela acima, o campo de texto serve para que o usurio digite uma
palavra-chave, que automaticamente usada para filtrar as linhas da tabela,
retirando aquelas que no possuem nenhuma entrada do texto digitado. O filtro
feito on the fly, sem necessidade de apertar nenhum boto ou ao especial. A
tabela, por sua vez, mostra todas as informaes de identificao da entidade,
no caso da procedure, pacote e nome.
O boto Ok se inicia desabilitado e s liberado quando o usurio
selecionar uma entrada na tabela. Ao ser acionado, ele imediatamente some
com o dilogo e exibe o diagrama, destacando visualmente o n que foi
escolhido como ponto de partida.

Os campos de marcar ao lado do campo de texto servem para customizar

a gerao do subgrafo a partir do objeto selecionado. Observe a figura abaixo:
A
B
C

F
D
E

Figura 13: Exemplo de grafo

Na Figura acima, pode-se ver um exemplo de grafo. Imaginando que cada

bola um objeto de uma entidade, podendo ser uma procedure ou uma tabela,
no modelo de negcio exemplificado, entende-se melhor as opes de
customizao existentes. A opo de origem monta um subgrafo do objeto
selecionado para frente. A opo de destino monta o grafo inverso, ou seja, do
objeto selecionado para trs. Ver tabela habilita ou no a exibio das
referncias s tabelas. Neste exemplo s existe tabelas e procedure, porem,
caso existisse tambm view, por exemplo, haveria uma opo Ver View. A
opo de indireo limita apenas ao primeiro ou a todos os nveis.
Seguem alguns exemplos, pensando sempre no caso do usurio
selecionar a procedure C. Ao marcar Origem apenas, o subgrafo extrado o
C->D->E. Caso seja escolhida a opo de Destino, so selecionados os
vrtices A ->B -> C. Ento, com os dois marcados, alm da indireo, o subgrafo
fica A->B->C->D->E. Se a Indireo no estiver selecionada, ser exibido
apenas o primeiro nvel, no caso B->C->D. Repare que, neste caso, o vrtice
F nunca ir ser adicionado no grafo de C, pois ele no pertence rvore direta
de chamadas deste ltimo. As regras apresentadas acima servem para qualquer
busca de qualquer entidade, pois no final todos os objetos, indiferente ao seu
tipo, so vistos do mesmo modo pelo algoritmo de gerao de subgrafos, ou
seja, so meros vrtices de um grafo.

3.5.2.
Navegao
Na funo explicada na sesso anterior, o usurio define como ser
apresentado visualmente o diagrama final. Para isso, ele escolhe um elemento
da tabela e no diagrama exibido ele destacado, para indicar que ele o ponto
de partida para o grafo gerado. Aps a gerao do diagrama, comum o usurio
querer navegar por um dos ns relacionados, seja para fazer uma anlise de
impacto, seja para verificar quais elementos sero alterados. Esta funcionalidade
pode ser vista atravs da opo exibida na figura abaixo.

Figura 14: Imagem da funcionalidade de navegao

Para acess-la basta clicar com o boto direito do mouse no elemento que
ser a base do novo diagrama gerado. Este herdar todas as configuraes
feitas para o diagrama original. Na verdade, como se o diagrama atual fosse
originado do boto disponvel na interface do programa, do mesmo modo que o
diagrama anterior, tendo como nica diferena o n base do grafo.
Com as constantes navegaes, o usurio pode, atravs da opo 4 da
Figura 11, voltar para o diagrama anterior ou, caso j tenha feito isso, prosseguir
para o diagrama que se apresentava na tela.
Esta funcionalidade fornece muita agilidade ao processo de entendimento
do modelo gerado e a anlise de impacto que a ferramenta proporciona, visto
que dado a complexidade da rvore de chamadas, nem sempre possvel exibir
todos os nveis numa nica imagem.

3.5.3.
Detalhamento
As funcionalidades de escolha de entidade e navegao so muito teis
para a anlise de impacto. A funcionalidade de exibio de detalhamento
vantajosa para a manuteno do sistema, pois auxilia facilita no entendimento do
mesmo.

Assim como a busca por entidade, esta funcionalidade precisa ser inserida
no arquivo de configurao do sistema, como visto na sesso 3.2.1. Alm disso,
precisa ter entrada nos metadados de modelo, visto na sesso 3.2.2. Com tudo
corretamente configurado, basta ir ao n escolhido e clicar com o boto direito,
como pode ser visto na figura abaixo.

Figura 15: Opo de exibio de detalhes

Ao selecionar esta opo, exibido um dilogo como o da tela abaixo.

Figura 16: Dialogo com os detalhes do elemento.

Este dilogo pode ser qualquer informao que o configurador da

ferramenta queira passar, desde um simples javadoc, at as entradas e sadas
de uma procedure, como no exemplo acima. Basta informar para a ferramenta
via metadados.

3.6.
O diagrama gerado
Como pode ser visto anteriormente, possvel desenvolver uma
ferramenta que faz um desenho customizado dos elementos, e integr-la junto
ao Dependencies Viewer via metaconfiguraces. Isto permite customizaes.
Porm, ele fornece dois shapes bsicos baseados no Diagrama de Fluxo de
Dados, ou DFD. O diagrama final produzido parecido com o exibido na Figura
abaixo.

Figura 17: Exemplo de um diagrama gerado

Diagrama de Fluxo de Dados (DFD) uma das ferramentas mais usadas

de modelagem funcional de sistemas, e pode ser entendido como uma rede que
ilustra como circulam os dados no seu interior. Um DFD um diagrama baseado
em etapas, com aumento gradativo de detalhes. Ele utiliza o princpio da
modularizao e da hierarquizao.
Basicamente so quatro elementos que formam o DFD:
Entidades Externas: So categorias lgicas de objetos ou pessoas que
representam origem ou destino de dados, e, que acionam um sistema e/ou
recebem informaes. Existem fora da fronteira do sistema. Podem ser, por
exemplo, pessoas, sistemas ou unidades departamentais.

Figura 18: Entidade Externa

Fluxos de dados: so o meio por onde os dados e as informaes

trafegam. Modelam a passagem de dados. A seta indica o sentido do fluxo e tem
o nome do fluxo associado. No possvel o fluxo de entidade para entidade,
entidade para deposito de dados, deposito de dados para deposito de dados, e
assim por diante, pois sempre deve envolver algum Processo.

Figura 19: Fluxo de dados

Processos: So mdulos do sistema. So atividades que transformam e

fazem uso do fluxo de dados. Modificam as informaes que entram para fluxo
de sadas. Cada processo tem um nome nico.

Figura 20: Processo

Depsito de Dados: So locais onde os dados so armazenados, como

arquivos fsicos, tabelas gerenciadas por um SGBD, etc. Como o processo,
possui um nome nico.

Figura 21: Depsito de dados

O motivo de mencionar este modelo que o diagrama default gerado

normalmente ser uma modificao do DFD, dado que a ferramenta suporta
nativamente as suas representaes. A fundamentao principal o amplo
conhecimento da ferramenta pelos analistas, servindo assim de um timo
instrumento de comunicao, vital num processo de desenvolvimento [Aktas,
1987]. Apesar de o argumento anterior ter se enfraquecido ao longo dos anos
devido ao apogeu da UML e afins, pensando no usurio final da soluo
apresentada para o problema levantado na motivao deste documento,
continua fortssimo. Isto porque o foco so linguagens estruturadas, e no existe
um diagrama mais conhecido e utilizado para model-las.
Ao invs do DFD, outros diagramas foram pensados como alternativas
para a base do projeto proposto. Um exemplo o diagrama de seqncia, e que
amplamente difundido na comunidade. Ele permite descrever diferentes
processos que ocorrem no sistema, modelando a troca de mensagens (ou
eventos) entre os objetos deste mesmo sistema. Com as devidas modificaes,
ele seria um timo candidato a ser base do novo diagrama. Uma vantagem em
relao ao DFD o fato de ele modelar, na sua essncia, a ordem e seqncia
em que os eventos ocorrem. A sua principal desvantagem a falta de
escalabilidade. Ele foi feito para modelar apenas um processo ou caso de uso. A
tela fica muito poluda quando colocado num contexto global, devido a sua forma
rgida de ser apresentado, com as linhas verticais e processos na parte superior.
O DFD prov maior flexibilidade na organizao do layout, gerando uma melhor
distribuio e conseqentemente melhor entendimento da mensagem a ser
passada.

4
O framework Grfico

A ferramenta Depencies Viewer precisava de uma API de desenho grfico

para poder gerar os seus diagramas. Esta API tem que ser obrigatoriamente
orientada a metamodelos, para conseguir trabalhar junto com a ferramenta e
fornecer a flexibilidade buscada. Alm disto, outra caracterstica essencial a
predisposio para atender as demandas necessrias de um produto voltado
para engenharia reversa. Entre as principais, est a capacidade de interferncia
humana no grfico gerado. Seja arrumando o diagrama, seja atravs de
interaes para disparar funcionalidades customizadas, como a funo de
navegao e exibio dos detalhes da ferramenta mostrada no captulo anterior.
Esta ltima caracterstica eliminou a possibilidade de utilizao de diversos
frameworks grficos, como o Graphviz.
Como visto na sesso 2.3, foi feita uma anlise no mercado para descobrir
quais os produtos que poderiam atender a esta demanda. So diversos os
frameworks para criao e exibio de diagramas, porm nenhum atendeu
plenamente aos requisitos desejados.
Para criar um visualizador de diagramas, so vrias as possibilidades,
entre elas Grappa, JHotDraw e JGraph. Todos estes produtos so APIs que
facilitam o desenvolvimento de editores. Apesar disto, na prtica eles so uma
evoluo a camada grfica de desenho da linguagem Java. O tempo de
aprendizado muito alto.
O EMF (Eclipse Foundation, 2008) o framework que chega mais perto do
que se espera obter. Ele tambm orientado a meta-dados, e a partir disto,
consegue-se gerao de editores e cdigo. So dois, porm, os seus problemas.
O primeiro a curva de aprendizado. Implementar o bsico com ele
relativamente simples. Porm, ao comear a adicionar complexidade ao projeto,
como mudar o formato padro do diagrama gerado, percebe-se que isso
demanda um longo tempo de aprendizado. Alm disto, outra grande limitao
que para utiliz-lo obrigatrio o uso dentro do Eclipse, seja ele como ambiente
de desenvolvimento, ou standalone. Isto uma barreira a se considerar, dado
que em Java, a grande maioria dos projetos usa a interface grfica Swing.

Devido a todas estas limitaes, foi decidido pelo desenvolvimento de um

framework grfico prprio, que funciona pelo conceito de meta-modelo,
permitindo ao usurio programar em um nvel mais alto de abstrao. Esse nvel
elevado de abstrao necessrio para capacitar o usurio a pensar no seu
domnio, e no em detalhes de implementao, como desenhar um crculo com
um texto no meio.
O produto grfico desenvolvido nesta dissertao pode ser considerado
uma API, e no um aplicativo completo, pois no possui uma interface principal,
precisa ser inserido dentro de outro programa.

4.1.
O metamodelo
Surgiu ento, inspirado no Talisman [Staa, 2002], a idia de desenvolver
um framework prprio.

Figura 22: Esquema bsico de funcionamento

A base de instncia contm todos os objetos que constituem as

informaes que devem ser mostradas na forma de diagrama. So dados dos
objetos ligados ao modelo de negcio do software que utiliza o framework. Os
dados aqui esto relacionados com a base de descrio.
Na base de descrio so guardados os objetos relacionados com a
apresentao e as regras de negcio que tratam disso. So armazenadas as
definies que restringem e especializam a base de instncia.
Num diagrama de fluxo de dados (DFD), por exemplo, um processo pode
se ligar a outro processo, ou a uma entidade externa. Esta, porm, no pode se
ligar a outra entidade externa. Na base de descrio ficam armazenadas estas
regras e restries. Exemplificando com um aplicativo de e-commerce. O DFD
poderia conter um processo Comprar que se relaciona com outro processo
Entregar. Na base de instncia se armazenam as informaes destes dois

processos, como seus nomes e identificadores, alm de suas relaes e a

definio dele como sendo do tipo Processo. Na base de descrio, est
configurado como ser apresentado visualmente os dados dos objetos que so
do tipo Processo. Caso o usurio tentasse criar um relacionamento entre duas
entidades externas neste diagrama, o framework iria criticar e no deixaria. Isto
acontece por que as informaes da base de instncia esto ligadas e
restringidas pela regras de definies da base de descrio.

Figura 23: Mesma base de instncia e diferentes bases de descrio

Na figura acima, apresentado um exemplo visual de como a base de

descrio interfere na representao do diagrama. O exemplo serve tambm
para acentuar as diferenas das bases. O lado esquerdo e o lado direito na
imagem apresentam diferentes diagramas que compartilham a mesma base de
instncia. Isto significa que possuem as mesmas informaes de modelos. Isto
pode ser observado pelos dados lidos nos diagramas. Apesar disto, apresentam
diferentes representaes. O da esquerda circular com borda grossa em azul e
fundo vermelho. O da direita se mostra oval, com borda fina em vermelho e
fundo cinza. Estas diferentes representaes so causadas pelo fato de
possurem uma base de descrio diferente.

4.1.1.
Modelagem da base de descrio

Figura 24: Diagrama de classes da base de descrio12

Na figura acima, podemos observar um diagrama de classes do

metamodelo utilizado. ele que orienta a apresentao do diagrama na tela.
O InstanceDecriptor responsvel por descrever uma classe de
instncias.

Imaginando

um

diagrama

como

um

grafo,

uma

instncia

analogamente poderia ser considerada um vrtice. Num diagrama de classes,

por exemplo, um InstanceDescriptor descreveria como seria a apresentao
visual da classe, quais cones seriam exibidos ao lado do nome do atributo, entre
outros. Ao existirem duas classes distintas num diagrama, na verdade so duas
instncias que referenciam um mesmo InstanceDescriptor.
Similarmente,

RelationshipDescriptor

descreve

uma

classe

de

relacionamentos, tanto o comportamento como a apresentao visual. No

exemplo do diagrama de classes, existiria, possivelmente, um descritor para os
relacionamentos do tipo Associao. Uma particularidade deste objeto que ele
recebe sempre dois objetos do tipo InstanceDescriptor, representando a
instncia de origem e a instncia de destino. Isto define o comportamento de
quais instncias ele pode se relacionar.
O DiagramDescriptor descreve as classes de instncias que faro parte de
um determinado tipo de diagrama. Isto serve para limitar e definir claramente o
perfil de um diagrama. No exemplo do diagrama de classes, s existiria o

12

Adaptado de: Staa, A.v.; Software and knowledge base specification for

Talisman; preliminary report.

descritor

de

instncia

Classe

os

descritores

de

relacionamentos

Associao, Dependncia e Herana.

Tanto os descritores de instncia quanto os de relacionamentos possuem
Attributes, que so atributos dos descritores, aos quais as instncias ou
relacionamentos concretos do valor individualmente. No diagrama de classes, o
ttulo, nome dos mtodos, entre outros, seriam Attributes.
Um InstanceDescriptor se relaciona com a classe Shape para definir o
formato da apresentao de uma instncia. Ele deve relacionar-se com
exatamente um Shape. Um shape a classe responsvel por agrupar as
informaes necessrias para renderizar uma instncia. Entre os seus atributos
esto

cor

da

borda,

cor

de

fundo,

tamanho

da

borda

um

InstanceShapeEnum. Esta ltima uma classe, que encapsula, pelo padro de

delegao, o renderizador concreto, ou seja, a classe que na prtica
responsvel por desenhar a instncia na tela.
Um Attribute pertencente a um InstanceDescriptor, para um determinado
Shape, possui informaes especificas para a sua exibio. Isto permite que um
Attribute possa ser renderizado de modo diferente de outro, caso seja esta a
vontade. Alm disto, permite tambm que um mesmo Attribute tenha exibies
diferentes em Shapes diferentes.
Entendendo que um relacionamento exibido como uma linha entre duas
instncias, um TerminatorDescriptor descreve a forma de exibio do incio e do
final desta linha. Por isto que um RelationshipDescriptor possui dois
relacionamentos

com

TerminatorDescriptor

no

diagrama

de

classe

apresentado. E anlogo ao Shape, ele possui um relacionamento com a classe

TerminatorShapeEnum, que pelo padro de delegao, o responsvel pelo
desenho na tela propriamente dito.
A classe InstanceDescriptor se relaciona com a classe Class de Java. Isto
se d para possibilitar a ligao com o modelo de negcios do usurio.
possvel descrever qual objeto do modelo aquela instncia representa, alm de
descrever o comportamento grfico.

4.1.2.
Modelagem da base de instncia

Figura 25: Diagrama de classe da base de instncia

Na sesso 4.1.1 foi apresentada a organizao da base de descrio.

Nesta sesso ser discutida a criao de uma base de instncia.
Muito mais simples que a base de descrio, ele composto apenas de
trs classes: Diagram, Instance e Relationship.
Um Diagram se relaciona com diversos Instance e definido por um
DiagramDescriptor. A conseqncia prtica disto, que ocorrer um erro ao
tentar adicionar uma instncia de um objeto de um tipo que no est no descritor
do diagrama. Isto limita o diagrama a ter apenas o comportamento esperado.
Uma classe Instance possui dois relacionamentos com a classe
Relationship. Um para definir o fato de ser a origem, e o outro para dizer que o
destino

do

relacionamento.

Recebe

no

seu

construtor

uma

classe

InstanceDescriptor, que define, conforme dito anteriormente, o comportamento e

informaes para exibir uma instncia. Com o mesmo objetivo, a classe
Relationship recebe uma instncia de RelationshipDescriptor. Caso a instncia
de origem ou de destino seja de um tipo diferente da configurada no descritor do
relacionamento, o relacionamento no criado e a visualizao abortada, com
o lanamento de uma exceo.
Uma instncia se relaciona com um Object Java. Isto define qual objeto
concreto do modelo do usurio se relaciona com determinada instncia do
diagrama. Vale ressaltar que ela respeita a regra pela qual o objeto em questo
deve ser obrigatoriamente do tipo configurado previamente no descritor da
instncia.

4.2.
API de Uso
Para usar o framework, a aplicao precisa definir primeiro a base de
descrio, a partir deste ponto criar as instncias concretas.

Na figura acima, pode-se observar duas instncias com um relacionamento

entre elas. Abaixo segue o cdigo comentado de como foi gerado o diagrama
acima.

Cdigo 6: Criao da base de descrio

Um detalhe a ser mencionado que no possvel adicionar atributos ao

descritor de relacionamento por que os nicos atributos possveis so o texto da
origem, o texto do destino e o texto central.

Esta uma restrio desta

implementao, porm o modelo permite evolues para que seja possvel uma
expanso mais adiante.
Abaixo segue cdigo referente criao das instncias reais.

Cdigo 7: Criao da base de Instncia

Outros tipos de Shape disponveis no momento so: CircleShapeEnum,

para desenhar um crculo, LabelShapeEnum, para exibir apenas um texto sem
nenhuma borda e OvalShapeEnum para exibir um formato oval.
O BoxShapeEnum, utilizado no exemplo, pode ser parametrizado para ser
renderizado na horizontal, ao invs do default exibido na imagem, que na
vertical. Alm disto, pode-se configurar para exibir ou no a diviso entre os
atributos. Isto serve para conseguir montar um quadrado normal ou uma borda
com o estilo de um diagrama de classe com o mesmo desenhador. Alm disto,
ele tambm recebe um parmetro para poder ter ou no o canto arredondado.
O usurio do framework pode desenvolver outro renderizador de formatos
livremente, bastando para isso criar uma classe em Java que implementa a

interface InstanceShapeEnum e pass-la como parmetro no construtor do

objeto Shape.

4.3.
Renderizao
A seguir, so apresentados alguns diagramas de seqncia que mostram
como implementada a renderizao.

Figura 26: Mtodo getView(Diagram diagram), responsvel por criar o diagrama

Na figura acima detalhado o mecanismo de criao do diagrama. Tudo

tem inicio pela classe Facade. Esta classe , como o prprio nome sugere, uma
interface de comunicao com o mundo externo implementado atravs do
padro de projeto Facade. Alm disto, ela tambm implementa o padro
Singleton.
Logo no incio do mtodo, um objeto da classe DelegateView criado.
Este, atravs da delegao, encapsula a verdadeira View, que simplesmente
um JPanel do Java, com a inteligncia especfica para a renderizao desejada.
Ele retornado com a chamada do mtodo getView() da classe Facade e pode
ser usado normalmente pela aplicao como um JComponent qualquer. A
DelegateView foi criada para isolar a aplicao da API grfica utilizada, pois a

View est completamente dependente dela sendo, inclusive, uma classe que
herda de outra da VisualLibrary. Entre as vantagens de utilizar esta tcnica, est
o fato de facilitar a troca da API grfica, caso tenha necessidade disto em algum
momento.
Aps ser criado e receber um diagrama, o DelegateView gera uma View e
nela adiciona os relacionamentos e instncias do diagrama recebido.
Posteriormente, chama mtodos responsveis por desenhar as instncias e os
relacionamentos. Estes mtodos so detalhados abaixo:

Figura 27: Mtodo drawInstances()

Na Figura 27, explicado o mtodo responsvel por desenhar as

instncias na tela. O loop maior sinaliza que o conjunto de mtodos chamado
para cada Instncia existente na classe View.
Ento, para cada objeto Instance existente, pega-se o seu Shape
associado, que est guardado no InstanceDescriptor da instncia. A partir do
Shape, adquiri-se o IShapeEnum que, como explicado anteriormente, serve para
encapsular a classe Drawer, responsvel de fato pelo desenho.

O mtodo

drawInstance(), recebendo a instncia a ser desenhada, chamado, e obtm,

para desenhar, o descritor da instncia em questo. Isto ocorre pelo fato deste
descritor ser o responsvel por guardar as informaes de interface, como cor
de fundo, cor da borda, entre outros. Diferentes objetos IShapeEnum desenham
bordas e formatos distintos.
Depois, para renderizar os atributos, necessria outra iterao, na qual
para cada atributo existente no descritor da instncia, obtido do Shape o seu
formatador e posteriormente o seu valor concreto, guardado na instncia
propriamente dita. Com isto em mos, basta chamar o mtodo responsvel por

desenhar um determinado atributo. O desenho de um atributo engloba exibir ou

no determinado cone antes do texto, exibir a fonte correta, com tamanho
correto, entre outros.

Figura 28: Mtodo drawRelationship()

Similar ao mtodo para desenhar instncias, cada relacionamento

exibido separadamente a partir de uma iterao no incio. Como desenhar um
relacionamento muito mais simples do que desenhar uma instncia, no foi
necessrio criar um mecanismo de delegao para o Drawer, pois toda a
informao obrigatria estava armazenada no descritor do relacionamento.
Ento a linha do relacionamento, ligando uma instncia outra, desenhada,
respeitando, obviamente, a cor configurada no descritor, assim como espessura,
hachura, entre outros.
Aps desenhar a linha principal, os terminadores so desenhados. Ele
possui

uma

arquitetura

parecida

com

IShapeEnum.

Existe

um

ITerminatorEnum que possui um TerminatorDrawer. Por ser mais simples, no

necessitava obrigatoriamente desta estrutura. Porm, mostrou-se necessria,
pois pode haver um mesmo desenhador de terminador para diferentes tipos,
como o tringulo cheio e o vazio. So dois tipos distintos com um mesmo
desenhador.

E os atributos so exibidos obtendo, para cada atributo dentro de uma

iterao, a partir do descritor, o seu formatador e, do relacionamento, o valor
concreto. S ento o atributo desenhado.

4.4.
Modelagem de Interao
Como dito anteriormente, o framework tem que estar pronto para atender
as necessidades de um software desenvolvido para engenharia reversa. Um
requisito fundamental permitir que haja interao do usurio com o diagrama
exibido. Para isso, o framework precisa possuir algum meio de comportar esta
funcionalidade.
Uma das premissas principais do framework ser de simples utilizao.
Para isso, o modelo de interao deveria ser algo natural ao desenvolvedor. A
Visual Library (API de apoio utilizada) possui uma interface para programao
rica. Isso se d pela quantidade de funes que ela predispe. Para obter a
coordenada de um simples clique do mouse, por exemplo, necessrio fazer
uma conta que leva em conta a escala de visualizao do diagrama.
Visando facilitar esse processo, foi criada a classe abstrata ActionAdapter.
Esta classe prov mtodos que facilitam a usabilidade da API. Alm disto, os
nomes dos mtodos foram mudados para se equiparar com a API grfica swing,
padro do Java, j que os originais eram diferentes.
Para interagir com o grfico, ento, basta o desenvolvedor especializar a
classe ActionAdapter, estender o mtodo de interao desejado, como
mousePressed() ou keyPressed(), e adicionar a nova classe no objeto da classe
Instance (sesso 4.1.2) que deve reagir a ao do usurio.
As funcionalidades de visualizao de detalhes (sesso 3.5.3) e
navegao (sesso 3.5.2) fazem uso deste modelo.

4.5.
O Processo de desenvolvimento e Instalao
A ferramenta foi desenvolvida nos mesmos moldes que o Dependencies
Viewer (Sesso 3.4.1). Foi usado test driven development em todos os pacotes
em que fosse possvel ser aplicado. Apenas as classes especificadamente
desenvolvidas para desenhar no tiveram cobertura de testes, pois precisariam
de outras tcnicas de testes, no abordada neste processo.

Para utilizar o framework dentro de uma aplicao desenvolvida em Java,

necessrio inserir o Jar meta-drawer-0.0.1.jar13 no classpath da aplicao.

13

http://code.google.com/p/meta-designer/

5
Avaliao experimental

5.1.
Cenrio
No captulo 1, sesso 1.2, foi apresentado o cenrio deste estudo de caso
que motivou esta dissertao. Fazendo uma recapitulao, tudo se iniciou numa
parceria entre o LES e o TecGraf, outro laboratrio da PUC-Rio, que desenvolvia
e dava manuteno a um software com cinco anos de existncia. Este sistema
possua toda a sua lgica de negcio escrita na linguagem PL/SQL do SGBD
Oracle. Havia 150.000 linhas de cdigo espalhadas em 340 procedures. A
interface de acesso era feita em Java, sendo esta uma camada muito fina,
apenas para exibir o retorno das procedures chamadas em cada funcionalidade
acessvel pelo usurio. Neste contexto, o LES teria basicamente duas funes
com esta parceria: desenvolver testes unitrios e documentar o sistema.
Com relao ao desenvolvimento de testes, no houve problemas
tcnicos. A grande dificuldade era o entendimento de como as procedures se
comunicavam e como funcionava o fluxo de chamadas.
A nica documentao existente era a exibida na Figura 1, que se tratava
de um documento Word com o cdigo copiado e caixas de textos com
explicaes

sobre

rvore

de

chamadas

daquela

procedure.

Esta

documentao apenas ajudava o entendimento do funcionamento daquela

procedure em especial, porm tinha uma srie de limitaes:

No existia este documento para todas as Procedures. Apenas

algumas eram assim documentadas.

A gerao do documento era feito manualmente. Logo, no existia

nenhuma garantia de estar atualizado.

No ajudava na anlise de impacto, pois no era possvel ter uma

viso de quem utilizava aquela procedure. Apenas quem ela
utilizava.

No tinha uma viso por tabela.

A rvore de chamadas era escrita por um ser humano. Estava

sujeita a falhas e erros de entendimento.

Surgiu, ento, inspirado nos problemas acima a idia de desenvolver um

aplicativo que conseguisse resolver as falhas na documentao existentes. Esta
concepo deu origem a esta dissertao.

5.2.
Processo
Como explicado anteriormente, a ferramenta necessita da entrada de
arquivos de metadados para funcionar plenamente

Figura 29: Processo de gerao da documentao automatizada

Toda a lgica de negcio estava armazenada em um sistema gerenciador

de banco de dados (SGBD) Oracle na forma de Procedure. Para fazer uso do
Dependency Viewer, era necessrio criar um parser para ler este SGBD e
produzir um arquivo de entrada na linguagem descritiva entendida pela
ferramenta. No incio cogitou-se a implementao de um compilador simples,
que teria como objetivo extrair a arvore de chamadas e as informaes
necessrias diretas do Oracle. Verificou-se, com o incio da implementao, que
isto seria uma tarefa rdua. Cada verso do Oracle tinha mudanas significativas
na gramtica da linguagem PL/SQL. Isto significava que a cada mudana de
verso, seria necessria uma adaptao para que a ferramenta funcionasse
corretamente. Devido a isso, e a maior facilidade de implementao, foi utilizada
a abordagem de extrao da informao atravs de padres lxicos.
Para tanto, era necessrio gerar um arquivo de texto com todo o cdigo do
software, extrado do Oracle. Foi utilizado, ento, o aplicativo SqlDeveloper
[Oracle 2009] para esta finalidade. Ele possui uma opo de exportar uma cpia
do banco para um arquivo texto.

Figura 30: Processo de recuperao do modelo

Como visto na figura acima, o processo de recuperao do modelo da

estrutura de software proposto possui as seguintes etapas:

Encontrar padres para a extrao de informaes (I): Consiste

em identificar o que precisa ser extrado do cdigo fonte e
encontrar padres lxicos que possibilite isso.

Gerar uma ferramenta para extrair do cdigo fonte os padres

criados (II): Este passo consiste em produzir um parser que
consiga interpretar os padres criados e gerar arquivos de entrada
para a ferramenta Dependency Viewer.

Gerar os modelos (III): Esta fase consiste basicamente em

alimentar a ferramenta, que ela se encarrega de gerar os modelos.
Foi facilitada pela existncia da mesma.

5.2.1.
Padres
Um padro deve buscar uma caracterstica no cdigo e deve ter um
objetivo especfico no processo de recuperao da estrutura. Neste trabalho, a
gerao de padres buscou encontrar os relacionamentos estruturais do
sistema, se baseando em um exame da sintaxe da linguagem PL/SQL, num
estilo de programao, e nos comandos SQL padro. Assim, foram criados cinco
padres:

Relacionamentos entre procedures.

Relacionamento entre procedures e tabelas

Relacionamento entre tabelas

Extrao de comentrios

Extrao de parmetros de entrada e sada da procedure

Depois da definio dos padres, desenvolveu-se uma srie de programas

para extra-los do cdigo fonte. Estes programas foram desenvolvidos na
linguagem AWK [Aho et al. 1988], que tem como principal objetivo a
transformao de arquivos. O AWK conta com recursos para encontrar padres
(pattern matching) e para manipulao de expresses regulares. Tais recursos
foram determinantes para o sucesso da minerao de relacionamentos descritos

nos padres. Desta forma, com base no cdigo (passado para um arquivo .txt) e
nos padres estabelecidos criaram-se programas em AWK que fizeram a
engenharia reversa, recuperando os dados necessrios. Os programas AWK
geram arquivos com os dados necessrios para se recuperar os modelos do
sistema. Estes arquivos so organizados um parser para que a ferramenta
Dependencies Viewer (Captulo 3) possa ler e apresentar toda a informao na
forma grfica.

Figura 31: Ligao dos padres com a ferramenta Dependency Viewer

Na Figura 31 mostrado um esquema de como funcionam os padres e

as suas relaes com a ferramenta. Cada padro traduzido numa ferramenta.
Estas rodam em cima de um arquivo textual contendo o cdigo fonte da
aplicao.

Este arquivo

foi extrado

do Oracle

atravs

do aplicativo

SqlDeveloper. Cada ferramenta produz um arquivo de sada que serve de

entrada para o Dependency Viewer.
Segue abaixo um detalhamento de cada padro

5.2.1.1.
Relacionamento entre procedures (I)
Para

reconhecimento

desses

relacionamentos

foi

necessrio

descobrir todos os pacotes e procedures existentes no cdigo PL/SQL. Para

tanto, fez-se: (i) a eliminao dos comentrios, tanto expressos com /* ... */

quanto com --; (ii) a busca de dados atravs dos seguintes padres:
PACKAGE/package, procedure e function, e; (iii) formatao dos dados
recuperados para que a lista de sada tivesse os pacotes e as suas
respectivas procedures. Aps a identificao dos pacotes e procedures, devese procurar os relacionamentos entre procedures, que so caracterizados
pelas seguintes expresses:

_pkg.<nome_proc2>: representa um relacionamento entre a

procedure que foi encontrada e a procedure referenciada no padro
_pkg.<nome_proc2>; Isto s possvel, pois todos os pacotes do
sistema terminam com o sufixo _pkg. uma regra imposta pelos
desenvolvedores do software, e no pela linguagem PL/SQL.

pacote.procedure: cada palavra do cdigo que atendesse a este

padro foi selecionada e comparada na listagem produzida
anteriormente em (iii). Se houver a ocorrncia na listagem ento
adiciona-se um relacionamento entre a procedure onde o padro foi
recuperado e a procedure da listagem.

Figura 32: Exemplo do padro I

5.2.1.2.
Relacionamento entre procedures e tabelas (II)
O padro definido para extrair estes relacionamentos verifica os
comandos que contm as expresses update, delete, from, join e insert.

Figura 33: Exemplo do padro II

5.2.1.3.
Relacionamento entre tabelas (III)
O padro para extrair estes relacionamentos verifica os comandos que
iniciam com alter table ou create table e que contm as expresses foreign key e
references.

Figura 34: Exemplo do padro III

5.2.1.4.
Comentrios das procedures (IV)
O padro para extrair os comentrios busca os caracteres de incio e fim
de comentrio dentro do PL/SQL (/* e */).

Figura 35: Exemplo do padro IV

5.2.1.5.
Parmetros de entradas e as sadas das procedures (V)
O padro para mostrar as entradas e sadas busca por: (i) sentenas
PACKAGE/package;

(ii)

comandos

iniciados

com

as

palavras-chaves

procedure ou function, e; (iii) comandos contendo as expresses in ou out.

Figura 36: Exemplo do padro V

5.2.1.6.
Prova de conceito
Para mostrar a aplicabilidade da abordagem, a ferramenta foi utilizada para
extrair o modelo da estrutura de um sistema legado de mdio porte, escrito em
PL/SQL. Nesta seo, ser mostrada a extrao de relacionamentos entre
procedures e entre procedures e tabelas e a gerao do grafo.
O Cdigo 8 mostra um trecho do cdigo da procedure update_scenarium
que possui um relacionamento com uma tabela cenrio.
procedure UPDATE_SCENARIUM
(...) is ...
begin
select ce.cena_nr_numero_cenario, ce.cena_dt_criacao
into scena_cd_id, creation_date
from cenario ce
where ce.cena_nr_numero_cenario = to_number(scenarium_id.identifier);
...
end;

Cdigo 8: Trecho 1 da procedure update_scenarium

O trecho marcado acima mostra o cdigo que indica um relacionamento

entre a procedure e uma tabela. A ferramenta encontra o cdigo a partir do
padro II e gera o trecho mostrado na Figura 37 no arquivo da estrutura.

Figura 37: Trecho gerado pela aplicao do padro II

Cdigo

mostra

um

trecho

do

cdigo

da

procedure

update_scenarium que possui um relacionamento com outras procedures.

procedure UPDATE_SCENARIUM
(...) is ...
begin
...
if open_stock.count > 0 then update_open_stock(open_stock);
end if;
if delivery.count > 0 then update_delivery(delivery);
end if;
...

if fcc_processing.count > 0 then ...

...
end;

Cdigo 9: Trecho II da procedure update_scenarium

O trecho marcado no cdigo acima mostra o cdigo que indica um

relacionamento entre a procedure e duas outras procedures (update_open_stock
e update_delivery). Estes trechos so encontrados pela ferramenta a partir do
padro I. O arquivo gerado (parcial) aps o processamento do cdigo est
mostrado na Figura 38 (se a procedure chamada vrias vezes ela se repete,
no entanto depois isto filtrado).

Figura 38: Trecho gerado pela aplicao do padro I

Depois de aplicar todos os padres, a ferramenta gera o seguinte grafo de

relacionamentos para a procedure update_scenarium (Figura abaixo).

Figura 39: Modelo da estrutura recuperado a partir da procedure update_scenarium

5.3.
Avaliao
Aps todo o processo e definies mostrados neste captulo, a ferramenta
Dependency Viewer ficou pronta para ser usada no projeto do LES. Uma
mudana na parceria levou o LES a assumir novas responsabilidades no projeto.
O laboratrio ficou responsvel no apenas pelo desenvolvimento de testes e
documentao, mas tambm pela manuteno das procedures. Isto ocorreu
num momento em que a pessoa responsvel por esta atividade, e a que mais
conhecia o domnio e o cdigo da aplicao, se desligou do projeto e da
empresa parceira. Neste contexto, o benefcio que a ferramenta Dependency

Viewer traria ganhou mais importncia e notoriedade, como pode ser visto pelo
depoimento de Alexandre Almeida, desenvolvedor do LES.
A anlise de impacto de mudanas em um sistema um fator delicado e
que deve ser bem mensurado. Nesse quesito a "ferramenta" foi de suma
importncia para nos ajudar na analise do impacto das mudanas com
segurana e rapidez. (Alexandre Almeida)
A ferramenta est sendo usada pela equipe de testes e manuteno do
sistema faz seis meses. Abaixo segue um resumo de alguns benefcios que ela
comprovadamente trouxe, e exemplos de cenrio de uso.

5.3.1.
Anlise de impacto de um procedure
A ferramenta Dependencies Viewer auxilia o desenvolvedor a fazer uma
anlise de impacto de um pedido de mudana. A figura Figura 40 mostra um
cenrio de uso da ferramenta. Imagine que um desenvolvedor, atendendo a um
pedido de mudana, saiba que ser necessrio modificar uma determinada
procedure (neste exemplo, chamada de get_scenarium). O desenvolvedor usa a
ferramenta para saber se existem outras procedures que chamam a procedure
em questo, encontrando a procedure open_scenarium (Figura 40.1). Neste
ponto, o desenvolvedor pode recuperar as procedures diretamente relacionadas
procedure open_scenarium (Figura 40.2).
Caso seja necessrio, o desenvolvedor pode verificar se existem outras
chamadas indiretas para a procedure. possvel, assim, visualizar toda a
hierarquia de chamadas opo Todos os nveis para open_scenarium
(Figura 40.3). Esta verificao apresenta diversos relacionamentos. O retngulo
cinza representa a procedure utilizada para a busca (na parte superior se tem o
nome do pacote e na parte inferior o nome da procedure). Alm da anlise dos
relacionamentos entre procedures, poder-se-ia analisar as tabelas associadas a
cada procedure impactada. Estes diagramas mostram um mapa da
implementao. Em alguns casos, tm-se muitos caminhos e, quando se tem
pouco conhecimento sobre o software, o esforo para a anlise bem maior.
Informaes associadas a cada procedure/tabela (semelhante a um Java.doc)
ajudam no entendimento das funes de cada um destes elementos.

Figura 40: Navegando para realizar a anlise de impacto para mudana numa procedure

5.3.2.
Anlise de impacto por tabela
Na sesso acima, foi mostrada a anlise de impacto a partir da viso de
uma procedure. comum tambm usar esta anlise a partir da viso de uma
tabela, e a ferramenta auxilia nisso. A Figura 41 mostra um cenrio de uso.
Imaginando ser preciso uma mudana na funo de permisso. Para isso, seria
necessrio alterar a tabela Permisso. Usando a ferramenta, descobrem-se
quais so as procedures que removem e inserem dados nesta tabela (Figura
41.1). Neste caso a procedure remove_folder remove dados, e a procedure
save_other_user_permissions insere dados. Apesar do nome das procedures
remeter s suas funes, estas informaes foram retiradas atravs do
esteretipo da ligao das procedures com as tabelas. O desenvolvedor pode,
tambm, ter uma viso de todas as procedures, ou outras tabelas, diretamente
relacionadas com a tabela Permisso (Figura 41.2).

Similar viso a partir de uma procedure, na Figura 41.3 possvel ter

uma viso global do mapa de implementao permitindo uma anlise de impacto
completa.

Figura 41: Navegando para realizar a anlise de impacto para mudana numa tabela

5.3.3.
Anlise de tabelas temporrias
Como dito anteriormente, toda a regra de negcio estava espalhada em
340 procedures. Um meio comum de comunicao entre elas, atravs de
passagem de parmetros por tabelas temporrias. Observe a Figura abaixo,
retirada da ferramenta Dependency Viewer. A tabela temp_cenarios um
exemplo

deste

caso.

initialize_stock_query,

Ela
que

criada

populada

chamada

pela

pela
outra

procedure
procedure

insert_scena_closing, que tambm l a tabela temporria temp_cenarios. Como

pode ser observado em destaque na Figura 42, este um tpico caso no qual
uma procedure cria e popula uma tabela temporria para outra procedure ler as
informaes mais adiante.
Imagine

que

desenvolvedor

esteja

alterando

procedure

initialize_stock_query, que cria a tabela temporria temp_cenarios. Passa pela

cabea dele mudar um campo desta tabela, ou at mesmo no mais cri-la, por
achar que no usada. Atravs da ferramenta, ele pode ver que esta tabela
lida por outras procedures do sistema, portanto possui o seu papel ativo e no
pode ser alterada sem uma anlise detalhada prvia.

Um outro cenrio de uso, imaginando o desenvolvedor dando

manuteno na procedure insert_scena_closing. Ele nota, em algum momento
do cdigo, que ela l informaes da tabela temporria temp_cenarios.
Percebe, alm disso, que estas informaes esto erradas. O desenvolvedor
teria que varrer todo o cdigo atrs da procedure que popula esta tabela. Com a
ferramenta estas informaes podem ser vistas rapidamente no diagrama
gerado.

Figura 42: Pedao do diagrama gerado para a tabela temp_cenarios

Este um cenrio de uso muito comum para a ferramenta, dado que so

muitos estes casos ao longo do sistema. Ela se mostrou til em ajudar nesta
anlise.

5.3.4.
Entendimento do Sistema
Imaginando um cenrio em que o desenvolvedor tenha que dar
manuteno na procedure create_view, porm no faz idia da razo da
existncia desta. Ele pode ir ferramenta Dependency Viewer e gerar o
diagrama da Figura 43.

Figura 43: Diagrama com a procedure create_view como referncia inicial.

Olhando a figura acima, ele reconhece outras procedures e as suas

funes. Percebe rapidamente que se trata de um cdigo que est relacionado

com estoque de produtos, e passa a ter mais segurana em fazer a alterao.

Este outro cenrio comum de uso confirmado, por depoimentos, como sendo
corriqueiro e parcialmente resolvido pela ferramenta.

5.3.5.
A meta-ferramenta
O estudo experimental focou em resolver o problema apresentado na
motivao desta dissertao. Para isso, foi preciso apenas realizar uma nica
customizao da ferramenta DependencyViewer. Toda a avaliao foi baseada
nesta instncia nica. Vale ressaltar, porm, que a ferramenta pode ser adaptada
para diversos outros domnios. Ela foi concebida para servir como metaambiente de visualizao para outros projetos voltados para a rea de
engenharia reversa.
Para poder provar a sua capacidade metamrfica e a sua versatilidade, foi
criada outra instncia de uso, com exatamente a mesma verso da ferramenta
usada no estudo de caso. A nica diferena entre as duas so os metadados de
configurao e as informaes de modelo.
Foi concebido um novo domnio de negcio baseado na avaliao
experimental existente. A ferramenta agora deve exibir apenas o modelo
relacional do banco de dados estudado, e toda a interface deve orientar o
usurio para deixa claro isto.
Fazendo um passo a passo de como customizar a ferramenta, a primeira
tarefa refazer o arquivo dependenciesViewer.config.

Cdigo 10: Novo arquivo de configurao

No Cdigo 10, apresentado como ficou o novo arquivo de configurao.

Como num modelo relacional a tabela exibida em um retngulo simples, foi

usado a classe BoxShapeEnum fornecida pelo framework grfico (sesso 4.2).

importante ressaltar que o usurio conhecendo bem a API do framework poderia
facilmente customizar o seu prprio desenhador.
O prximo passo a criao do arquivo de modelo. Foi gerado, ento, um
arquivo contendo todos os relacionamentos entre tabelas. Ele exibe como
esteretipos de origem e destino a chave estrangeira e o atributo identificador,
respectivamente. No cdigo abaixo mostrado parcialmente como fica este
arquivo.

Cdigo 11: Arquivo de modelo

O Cdigo 11 foi gerado a partir de uma adaptao das ferramentas criadas

para o estudo experimental.
Com estes dois arquivos prontos, a ferramenta est funcional dentro do
novo modelo de negcio.

Figura 44: Cara da nova instncia da ferramenta

Na Figura 44.1 apresentado como ficou o diagrama gerado pela nova

configurao da ferramenta. Na Figura 44.2 mostrada a tela de busca por uma
tabela.
Imaginando um cenrio de uso do aplicativo, o usurio pode, como mostra
a Figura 45.1, escolher uma tabela e gerar um diagrama completo. A maioria das
ferramentas que fazem este trabalho de engenharia reversa no fornece uma
opo de seleo de um subgrafo do diagrama maior gerado, portanto seria

realmente uma documentao difcil de ser entendida. Na Figura 45.2,

desmarcada a opo Todos os Nveis. Isto gera um diagrama menor, com o
centro sendo a tabela alvo do estudo. Com a opo de navegao, o usurio
pode facilmente navegar por grafos pequenos, que no fornecem uma viso
geral, porm provem um melhor entendimento do funcionamento do sistema,
devido simplificao do modelo. Esta opo no exclui ainda a possibilidade de
gerao do modelo completo e imprimi-lo, como fazem outras ferramentas do
gnero.

Figura 45: Anlise do modelo

Este caso prova que possvel gerar aplicaes funcionais para diferentes
domnios mudando apenas os arquivos de metadados.

6
Concluso

A manuteno de um sistema legado pode ser facilitada quando se aplica

algumas prticas de engenharia reversa. Uma delas a recuperao do modelo
de sua estrutura. Visando este nicho, este trabalho produziu como contribuio
uma meta-ferramenta capaz de exibir diagramas comportamentais ou qualquer
outro que venha a ser configurado nos seus arquivos de metadados. Para que
isso se tornasse uma realidade, era preciso um framework grfico tambm
orientado a metadados. Devido s dificuldades de encontrar um artefato que
pudesse ser usado com sucesso, foi desenvolvido um produto interno para este
objetivo.
A ferramenta foi aplicada com xito em um estudo experimental que
solucionou um problema encontrado por um projeto real, sem fins acadmicos.
Para atend-lo, este trabalho teve no apenas que desenvolver a ferramenta
citada, mas padres para o reconhecimento de procedures, tabelas e seus
relacionamentos no cdigo fonte, j que o domnio da aplicao era a linguagem
PL/SQL. No final de todo o trabalho, a ferramenta final customizada e aplicada
na avaliao experimental foi aprovada com louvor, e trouxe como contribuio
no s a recuperao do modelo da estrutura de um sistema legado, mas
tambm a capacidade de auxiliar o desenvolvedor na tarefa de anlise de
impacto de uma mudana.
Este trabalho proveitoso para as pessoas que possuem algum tipo de
sistema legado e que encontram dificuldades em achar ferramentas para a
prtica da engenharia reversa, para aqueles que precisam de um framework de
gerao de diagramas orientado a metadados, ou para os que simplesmente
querem olhar o estudo experimental e aprender com a experincia adquirida.

6.1.
Trabalhos Futuros
No captulo 4, foi apresentado o framework grfico desenvolvido para
atender a ferramenta Dependency Viewer (Captulo 3). Para sua utilizao,
necessrio

configurar

metadados

que

guardam

todas

as

regras

comportamentais dos objetos e de como eles interagem entre si. Essas

informaes seriam suficientes para a gerao de um editor de diagramas
orientado a metadados. Ele iria de encontro com a finalidade de prover uma API
grfica completa para projetos na rea de engenharia reversa. Nem sempre o
diagrama gerado o final, apesar de estar correto. comum haver alteraes
para, por exemplo, torn-lo mais legvel. um trabalho futuro o desenvolvimento
deste editor.
possvel, similar ao editor, desenvolver e aprimorar o framework para
que, no final, seja vivel a gerao de um esqueleto de cdigo til. Para isso,
haveria de ter evolues nos metadados existentes, principalmente no que diz
respeito a sua ligao com o modelo de dados, pois hoje um objeto grfico se
relaciona com um Object Java. Esta implementao atendeu as expectativas at
o momento, porm ele deve evoluir para virar uma composio de objetos, uma
vez que podem possuir uma variedade de atributos no conhecidos a priori,
alm de poder possuir instncias em uma variedade de diagramas
Com relao ferramenta Dependency Viewer, foi possvel atingir o
objetivo proposto para a avaliao experimental. Porm, necessrio aplic-la
em outros casos. A ferramenta customizada e populada atravs de metadados,
mas preciso por a prova esta customizao com mais exemplos e avaliaes
experimentais.
A avaliao experimental exporta no captulo 5 no foi apenas um caso
acadmico. Ela foi real, e aplicada num projeto grande. As procedures
homnimas, hoje, so tratadas pela quantidade de seus parmetros. Porm,
existem casos de procedures com o mesmo nome e o mesmo nmero de
atributos de entrada, que apesar de serem diferentes, so tratadas como iguais
pelo sistema. muito pequena a quantidade de vezes que isto ocorre, sendo na
prtica insignificante. Apesar disto, se fosse aplicado em outros sistemas escritos
em PL/SQL, poderia fazer diferena no resultado apresentado. Um trabalho
futuro tratar destes casos da forma correta, pelo tipo de parmetro, e no pela
quantidade.
Similar ao problema acima, alguns padres apresentados na avaliao
experimental foi desenvolvido em cima de regras e estilo prprio do projeto
especfico, e no da linguagem PL/SQL. desejvel o desenvolvimento de
outros padres que possam ser aplicados de forma genrica.

7
Referencias Bibliogrficas

Aho, A. V., Kernighan B. W. and Weinberger, P. J. (1988). The AWK

Programming Language, Addison Wesley.
AKTAS, A. Z. (1987). Structured Analysis and Design
Information Systems. Englewood Cliffs, NJ: Prentice-Hall.
AT&Ts
research
lab,
Graphviz,
Disponvel
http://www.graphviz.org/. Acessado em: 18 jun 2008

of
em:

BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace

Change. 2. ed. Addison Wesley Professional, 2004.
BENEDUSI, P.; CIMITILE, A.; DE CARLINI, U., A reverse engineering
methodology to reconstruct hierarchical data flow diagrams for
software maintenance, Software Maintenance, 1989., Proceedings.,
Conference, Out 1989
Borland
(2009).
Borland
Together.
Disponvel
em:
http://www.borland.com/br/ products/together/. Acessado em: 30 Mar
2009.
BRIAND, L.C et al. Towards The Reverse Engineering of UML
Sequence Diagrams. Reverse Engineering, 2003. WCRE 2003.
Proceedings. 10th Working Conference, Nov. 2003
Chikofsky, E. J. and Cross, J. H. (1990). Reverse engineering and
design recovery: a taxonomy. IEEE Software 7(1), p. 13-17.
ECLIPSE FOUNDATION, Eclipse Modeling Framework, Disponvel em:
http://www.eclipse.org/modeling/emf. Acessado em: 18 jun 2008
FOWLER, M.; et al. Refactoring: Improving the design of existing
code. Addison Wesley, 1999.
IBM (2009a). Rational Software Architect. Disponvel em:
http://www-01.ibm.com/
software/awdtools/architect/swarchitect/.
Acessado em: 30 Mar 2009.
IBM (2009b). Rational Data Architect. Disponvel em: http://www01.ibm.com/ software/awdtools/modelbundle/. Acessado em: 30 Mar
2009.
KOLLMANN, R et al, A study on the current state of the art in
tool-supported UML-based static reverse engineering, Reverse
Engineering, 2004. Proceedings. Ninth Working Conference, 2004

MASSOL, V.; VAN ZYL, J. Better Builds With Maven: How-to Guide
for Maven 2.0. Mergere Library Press, 2006.
NETBEANS
FOUNDATION,
Visual
Library,
Disponvel
http://graph.netbeans.org/. Acessado em: 18 jun 2008

em:

Oracle
(2009).
Oracle
SQL
Developer.
Disponvel
em:
http://www.oracle.com/ technology/products/database/sql_developer/.
Acessado em: 30 Mar 2009.
Queille, J., Voidrot, J., Wilde, N. and Munro, M. (1994). The impact
analysis task in software maintenance: a model and a case
study. In: Proceedings of the International Conference on Software
Maintenance, p. 234-242.
SNEEDM H.H; JANDRASICS, G., Inverse Transformation of software
from Code to Specification, Proceedings of Conference on Software
Maintenance, Austin, Texas, IEEE, 1988
Sommerville, I. (2007). Engenharia de Software, Pearson Education,
8th edition.
Wilde, N. and Huitt, R. (1992). Maintenance support for object
oriented programs. In: Proceedings of the International Conference
on Software Maintenance, p. 162-170.
YEH, D.; LI, Y., Extracting Entity Relationship Diagram from a
Table-Based Legacy Database, Software Maintenance and
Reengineering, 2005. CSMR 2005. Ninth European Conference , March
2005