9 C 960521 B 534 Ac 20 e 1

Padres de Software a partir da Engenharia
Reversa de Sistemas Legados

Rosana Teresinha Vaccare Braga
Orientador: Prof. Dr. Paulo Cesar Masiero
Dissertao apresentada ao Instituto de Cincias Matemticas e de
Computao - USP, como parte dos requisitos para a obteno do
ttulo de Mestre em Cincias - rea de Cincias de Computao e
Matemtica Computacional
USP - SO CARLOS
Novembro de 1998
Dedicoestetrabalho
a Deus
aoCirilo, aoThales eaoVitor
Agradecimentos
Ao Prof. Dr. Paulo Cesar Masiero pela orientao que me deu, sempre com muita ateno e
entusiasmo. Pelo direcionamento que deu pesquisa, to essencial para aproveitar ao mximo as
minhas potencialidades. Pela oportunidade de voltar pesquisa e poder associ-la prtica
profisssional.
Aos professores do ICMC pela acolhida calorosa depois de dez anos de afastamento da
Universidade.
Aos Profs. Drs. Norm Kerth e Ralph J ohnson pela recepo generosa que me deram na rea de
pesquisa em padres de software.
Prof. Dra. Rosngela Dellosso Penteado pela total disponibilidade na execuo de trabalhos
conjuntos e por sua amizade e ateno.
Ao Prof. Dr. Antonio Francisco do Prado pela oportunidade de ter contato com a mquina Draco-
Puc.
s alunas de graduao Fabiana Rocha, do ICMC e Tiemi Sakata, da UFSCAR, pelos trabalhos
de iniciao cientfica que contribuiram para as publicaes feitas durante a execuo deste
trabalho.
Aos mestrandos, doutorandos, pesquisadores e bolsistas do Laboratrio de Engenharia de
Software do ICMC pela amizade, ateno e auxlio na utilizao de mquinas e programas.
Aos colegas da Universidade de Franca pelo apoio e incentivo durante todo o programa de
mestrado.
Aos colegas do Senac So Carlos pelo incentivo que me deram para que eu pudesse contribuir
efetivamente na atividade de treinamento profissional em que esto empenhados e que so to
importantes para o desenvolvimento do pas.
s secretrias da ps-graduao pela ateno, pacincia e disponibilidade com que sempre me
atenderam.
s secretrias, bibliotecrias e funcionrios do ICMC que se mostraram sempre prestativos no
meu atendimento.
Fapesp pela bolsa de iniciao cientfica concedida durante meu curso de graduao que me
deu oportunidade de travar os primeiros contatos com a pesquisa e que abriram caminho para as
atividades aqui relatadas.
s empresas que me deram a oportunidade de exercer as minhas atividades profissionais na rea
de consultoria e desenvolvimento de sistemas.
Aos meus pais Miguel e Maria Teresa pela educao que me deram e pelo suporte aos meus
filhos durante minha ausncia.
Aos meus irmos Ailton e Anderson pela disposio e prontido com que sempre me atenderam
nas situaes imprevistas.
Ao Cirilo pelo companheirismo durante os momentos difceis, pela dedicao em me substituir
junto a nossos filhos durante muitas vezes neste perodo, pelo incentivo constante e pelas
sugestes na correo da ortografia desta dissertao. Ao Thales e ao Vitor pela compreenso da
importncia deste trabalho para mim.
Resumo
A execuo da engenharia reversa orientada a objetos de um sistema legado desenvolvido com
orientao procedimental usada como base para sua reengenharia, seguindo duas abordagens
diferentes. Na primeira, o sistema passa por reengenharia com mudana de orientao, por meio
de segmentao e, posteriormente, transformado para uma linguagem orientada a objetos de
forma semi-automtica. Na segunda, feito o reconhecimento de padres recorrentes de software
no modelo de objetos produzido pela engenharia reversa, para depois efetuar a reengenharia
utilizando esses padres. Os resultados obtidos por intermdio dessas duas abordagens podem ser
comparados quanto manutenibilidade, legibilidade e reuso. A verso original do sistema legado
escolhido para a realizao da experincia est implementado na linguagem Clipper e possui
cerca de vinte mil linhas de cdigo. Trata-se de uma oficina auto-eltrica e mecnica de veculos.
Para a engenharia reversa foi escolhido o mtodo Fusion/RE, sendo feita uma proposta para sua
evoluo, adicionando um maior detalhamento da etapa de abstrao do modelo de anlise do
sistema. Para mudana de orientao do paradigma de desenvolviemnto, de procedimental para
orientado a objetos, so propostas duas etapas adicionais a serem executadas aps a aplicao do
Fusion/RE: o projeto avante do sistema e a segmentao do programa legado. Indicaes sobre
como fazer a segmentao so fornecidas. A transformao do cdigo segmentado em Clipper
para J ava feita com auxlio da mquina Draco-Puc. Uma estratgia proposta para o
reconhecimento de padres a partir do modelo de objetos do sistema obtido pela engenharia
reversa. Por meio dela, instncias dos padres Type-Object, Association-Object, State Across a
Collection e Behaviour Across a Collection podem ser reconhecidas. Experincias de
implementao de alguns desses padres, em Delphi, so feitas.
Abstract
The object oriented reverse engineering of a legacy system, originally developed using the
procedural paradigm, is the basis for two different reengineering approaches. In the first, the
reengineering is done to change the implementation paradigm by segmentation, followed by the
semi-automatic transformation to an object oriented language. In the second, recurring patterns
are first recognized in the object model produced by the reverse engineering, and then the
reengineering is done adopting these patterns. Results obtained by these two approaches are
compared to assess their maintainability, legibility and reuse. The original version of the legacy
system used in this experience has about twenty thousand lines of Clipper code and refers to an
electric and mechanic car repair shop. For the reverse engineering phase the Fusion/RE method is
used, and a proposal is done for its evolution, adding features to detail its system analysis model
abstraction phase. To change the system orientation paradigm, from procedural to object-
oriented, two additional phases are proposed to be conducted after the application of the
Fusion/RE method: the forward design of the system and the legacy code segmentation. Hints
and rationales are supplied to conduct the code segmentaion. The code transformation from
segmented Clipper to J ava is done with support of the Draco-Puc machine. A strategy is
proposed for pattern recognition based on the system object model obtained through reverse
engineering. Through it, instances of Type-Object, Association-Object, State Across a Collection
and Behaviour Across a Collection patterns can be recognized. Delphi implementation
experiments of these patterns are done.
i
Sumrio
CAPTULO 1 INTRODUO .......................................................................................................... 1
1.1 CONSIDERAES INICIAIS............................................................................................................. 1
1.2 MOTIVAO................................................................................................................................. 2
1.3 OBJ ETIVOS ................................................................................................................................... 3
1.4 ORGANIZAO DA DISSERTAO................................................................................................. 4
CAPTULO 2 - RESENHA BIBLIOGRFICA.................................................................................. 6
2.1 - CONSIDERAES INICIAIS ............................................................................................................. 6
2.2 - ENTENDIMENTO DE PROGRAMAS.................................................................................................. 8
2.2.1 - Introduo............................................................................................................................. 8
2.2.2 - Contribuies Relevantes.................................................................................................... 11
2.2.3 - Concluses .......................................................................................................................... 16
2.3 - ENGENHARIA REVERSA............................................................................................................... 16
2.3.1 - Introduo........................................................................................................................... 16
2.3.3 - Concluses .......................................................................................................................... 23
2.4 - REENGENHARIA .......................................................................................................................... 24
2.4.1 - Introduo........................................................................................................................... 24
2.4.3 - Concluses .......................................................................................................................... 29
2.5 - PADRES..................................................................................................................................... 29
2.5.1 - Introduo........................................................................................................................... 29
2.5.3 - Concluses .......................................................................................................................... 41
2.6 - CONSIDERAES FINAIS.............................................................................................................. 41
CAPTULO 3 ENGENHARIA REVERSA..................................................................................... 43
3.1 CONSIDERAES INICIAIS........................................................................................................... 43
3.2 UM RESUMO DO FUSION/RE ...................................................................................................... 43
3.3 SOBRE A ABSTRAO DO MODELO DE ANLISE DO SISTEMA..................................................... 46
3.4 ESTUDO DE CASO....................................................................................................................... 47
3.4.1 - Recuperao da arquitetura do sistema legado.................................................................. 49
3.4.2 - Obteno do Modelo de Anlise do Sistema Atual ............................................................. 52
3.4.3 - Abstrao do Modelo de Anlise do Sistema...................................................................... 58
3.4.4 - Mapeamento MAS/MASA.................................................................................................... 69
3.5 CONSIDERAES FINAIS............................................................................................................. 71
CAPTULO 4 REENGENHARIA................................................................................................... 73
4.2 REENGENHARIA COM MUDANA DE ORIENTAO E SEM MUDANA DE LINGUAGEM.................. 73
4.2.1 Abordagem proposta .......................................................................................................... 73
4.2.2 Estudo de Caso................................................................................................................... 76
4.3 REENGENHARIA COM MUDANA DE LINGUAGEM........................................................................ 80
4.3.1 Sistema de Transformao utilizado .................................................................................. 81
4.3.2 Estudo de Caso................................................................................................................... 83
4.4 CONSIDERAES FINAIS............................................................................................................. 87
CAPTULO 5 - RECONHECIMENTO DE PADRES DE SOFTWARE..................................... 89
ii
5.2 PADRES RECORRENTES PARA SISTEMAS DE INFORMAO....................................................... 89
5.2.1 Padro Type-Object ........................................................................................................... 89
5.2.2 Padro Association-Object ................................................................................................ 91
5.2.3 Padro State across a collection........................................................................................ 92
5.2.4 Padro Behaviour across a collection ............................................................................... 92
5.3 UMA ESTRATGIA PARA RECONHECIMENTO DE PADRES........................................................... 94
5.3.1 Padro Type-Object ........................................................................................................... 94
5.3.2 Padro Association-Object ................................................................................................ 95
5.3.3 Padro State across a Collection....................................................................................... 96
5.3.4 Padro Behaviour across a collection ............................................................................... 96
5.4 ESTUDO DE CASO....................................................................................................................... 97
5.4.1 Reconhecimento dos padres no modelo de objetos do sistema legado............................ 97
5.4.2 Exemplo de implementao de padro............................................................................. 101
5.5 CONSIDERAES FINAIS........................................................................................................... 121
CAPTULO 6 CONCLUSES FINAIS E SUGESTES PARA NOVAS PESQUISAS .......... 122
6.1 CONSIDERAES INICIAIS......................................................................................................... 122
6.2 CONCLUSES GERAIS............................................................................................................... 122
6.3 CONTRIBUIES DESTE TRABALHO........................................................................................... 125
6.4 SUGESTES PARA FUTURAS PESQUISAS..................................................................................... 126
BIBLIOGRAFIA................................................................................................................................ 128
iii
Lista de Figuras
FIGURA 1.1 - ILUSTRAO DA ABORDAGEM DA DISSERTAO......................................................................................4
FIGURA 2.1 - RELACIONAMENTO ENTRE TERMOS [CHI 90].............................................................................................6
FIGURA 2.2 - RELACIONAMENTO ENTRE OS TPICOS DO CAPTULO.................................................................................8
FIGURA 2.3 - SISTEMA RECUPERADOR DE PROJ ETO BASEADO EM MODELO [BIG 89] ....................................................12
FIGURA 2.4 - METAMODELO INTEGRADO [MAY 95]....................................................................................................15
FIGURA 2.5 - INSTANCIAO DO PARADIGMA GOALS/MODELS/TOOLS [BEN 92].....................................................19
FIGURA 2.6 - DOCUMENTAO DE OBJ ETOS [SNE 95]..................................................................................................20
FIGURA 2.7 - PADRO ROLES-PLAYED (PAPIS DESEMPENHADOS) E EXEMPLO [COA 92].........................................31
FIGURA 2.8 - DIAGRAMA DO PADRO ABSTRACT FACTORY [GAM 93].....................................................................33
FIGURA 2.9 - EXEMPLO DO PADRO ABSTRACT FACTORY [GAM 93] .......................................................................34
FIGURA 2.10 - COREM E TIPOS DE PADRO BSICOS [GAL 96]...................................................................................36
FIGURA 2.11 - ARQUITETURA DO SISTEMA PAT [KRA 96]........................................................................................37
FIGURA 2.12 - DIAGRAMA DE INTERAO DOS PADRES [YOD 98].............................................................................40
FIGURA 3.1 - ESQUEMA DO FUSION/RE........................................................................................................................44
FIGURA 3.2 - PROCESSO DE TRANSIO DO MASA PARA O MAS...............................................................................46
FIGURA 3.3 - DIAGRAMA DA BASE DE DADOS..............................................................................................................49
FIGURA 3.4 - DESCRIO DE UM DOS ARQUIVOS DA BASE DE DADOS...........................................................................50
FIGURA 3.5 - DESCRIO DE UM DOS MDULOS DO SISTEMA, COM A RELAO CHAMA/CHAMADO POR......................51
FIGURA 3.6 - TRECHO DE UM PROGRAMA CLIPPER DO SISTEMA LEGADO.....................................................................52
FIGURA 3.7 - PARTE DOS MENUS DO SISTEMA LEGADO.................................................................................................52
FIGURA 3.8 - MOSA MODELO DE OBJ ETOS DO MASA.............................................................................................54
FIGURA 3.9 - PARTE DO MASA E PROCEDIMENTOS DO SISTEMA LEGADO...................................................................55
FIGURA 3.10 - MCVSA - MODELO DE CICLO DE VIDA DO SISTEMA ATUAL ................................................................56
FIGURA 3.11 - ESQUEMA PARA A OPERAO LANCAMENTO_PRIM_PARTE DO MOPSA............................................57
FIGURA 3.12 - MOS-1 MODELO DE OBJ ETOS DO MAS ETAPA 1...........................................................................60
FIGURA 3.17 - MOS-6A MODELO DE OBJ ETOS DO MAS ETAPA 6 PARTE A .......................................................66
FIGURA 3.18 - MOS-6B MODELO DE OBJ ETOS DO MAS ETAPA 6 PARTE B........................................................67
FIGURA 3.19 - PARTE DO MAS E MTODOS CORRESPONDENTES..................................................................................68
FIGURA 3.20 - MCVS - MODELO DE CICLO DE VIDA DO SISTEMA...............................................................................69
FIGURA 3.21 - ESQUEMA PARA A OPERAO ABRE_ORDEM_DE_SERVIO DO MOPS...............................................70
FIGURA 4.1 - ABORDAGEM PROPOSTA PARA REENGENHARIA COM MUDANA DE ORIENTAO....................................74
FIGURA 4.2 - EXEMPLO DE UM GRAFO DE INTERAO DE OBJ ETOS............................................................................76
FIGURA 4.3 - PROGRAMA SEGMENTADO CORRESPONDENTE OPERAO ABRE_ORDEM_DE_SERVIO.....................78
FIGURA 4.4 - ALGUNS MTODOS DO PROGRAMA SEGMENTADO..................................................................................79
FIGURA 4.5 - ATIVIDADES BSICAS PARA A CONSTRUO DOS DOMNIOS DE ORIGEM E DESTINO NO DRACO...............82
FIGURA 4.6 - CONSTRUO DOS DOMNIOS CLIPPER E J AVA NO DRACO [PEN 98B]......................................................85
FIGURA 4.7 - CDIGO J AVA RESULTANTE DA TRANSFORMAO, REF. OPERAO ABRE_ORDEM_DE_SERVICO......86
FIGURA 4.8 - ALGUNS MTODOS DO PROGRAMA TRANSFORMADO...............................................................................86
FIGURA 5.1 - PADRO TYPE-OBJ ECT [J OH 98].............................................................................................................90
FIGURA 5.2 - EXEMPLO DO TYPE-OBJ ECT [J OH 98]......................................................................................................90
FIGURA 5.3 - PADRO ITEM-DESCRIPTION [COA 92]....................................................................................................90
FIGURA 5.4 - EXEMPLO DO ITEM-DESCRIPTION [COA 92] ............................................................................................90
FIGURA 5.5 - PADRO ASSOCIATION-OBJ ECT [BOY 98]..............................................................................................91
FIGURA 5.6 - ASSOCIATION-OBJ ECT [BOY 98].............................................................................................................92
FIGURA 5.7 - PADRO STATE ACROSS A COLLECTION [COA 92]...................................................................................92
FIGURA 5.8 - EXEMPLO DO PADRO STATE ACROSS A COLLECTION [COA 92] .............................................................93
FIGURA 5.9 - PADRO BEHAVIOUR ACROSS A COLLECTION [COA 92] .........................................................................93
FIGURA 5.10 - EXEMPLO DO PADRO BEHAVIOUR ACROSS A COLLECTION [COA 92]...................................................93
FIGURA 5.11 - NOTAO USADA PARA EXPRESSAR PADRES EM UML........................................................................98
FIGURA 5.12 - RECONHECIMENTO DE PADRES ..........................................................................................................99
iv
FIGURA 5.13 - MODELO DE OBJ ETOS DETALHADO DO PADRO TYPE-OBJ ECT ..........................................................102
FIGURA 5.14 - ESQUELETO DA DECLARAO DA CLASSE CLASS DO PADRO TYPE-OBJ ECT..................................103
FIGURA 5.15 - ESQUELETO DE ALGUNS MTODOS DO PADRO TYPE-OBJ ECT ...........................................................104
FIGURA 5.16 - ESQUELETO DE UM DOS MDULOS DE DADOS DO PADRO TYPE-OBJ ECT...........................................105
FIGURA 5.17 - CDIGO SQL DE ALGUNS COMPONENTES DO MDULO DE DADOS CLASS......................................105
FIGURA 5.18 - MODELO DE OBJ ETOS DE UMA INSTNCIA DO PADRO TYPE-OBJ ECT................................................106
FIGURA 5.19 - CDIGO EM DELPHI REFERENTE DECLARAO DA CLASSE PEA ....................................................107
FIGURA 5.20 - CDIGO EM DELPHI REFERENTE DECLARAO DA CLASSE FABRICANTE.........................................108
FIGURA 5.21 - CDIGO EM DELPHI REFERENTE A ALGUNS MTODOS DO PADRO RECONHECIDO..............................109
FIGURA 5.22 - MDULO DE DADOS DA CLASSE PEA ................................................................................................109
FIGURA 5.23 - CDIGO SQL DE ALGUNS COMPONENTES DO MDULO DE DADOS PECA........................................110
FIGURA 5.24 - INTERFACE DA OPERAO DE CADASTRO DE PEAS...........................................................................111
FIGURA 5.25 - TRECHO DE CDIGO REFERENTE AO FORMULRIO DE CADASTRO DE PEAS.......................................111
FIGURA 5.26 - MODELO DE OBJ ETOS DA OUTRA INSTNCIA DO PADRO TYPE-OBJ ECT............................................112
FIGURA 5.27 - CDIGO EM DELPHI DA DECLARAO DAS CLASSES VECULO E TIPO DE VECULO............................113
FIGURA 5.28 - CDIGO EM DELPHI REFERENTE A ALGUNS MTODOS DA SEGUNDA INSTNCIA DO PADRO..............114
FIGURA 5.29 - MODELO DE OBJ ETOS PARA A OPERAO ABRE_ORDEM_DE_SERVIO..........................................115
FIGURA 5.30 - DEFINIO DA CLASSE ORDEMDESERVIO.....................................................................................117
FIGURA 5.31 - ALGUNS MTODOS DA CLASSE ORDEMDESERVIO.........................................................................118
FIGURA 5.32 - INTERFACE DO SISTEMA MOSTRANDO UM DOS MENUS ........................................................................119
FIGURA 5.33 - INTERFACE DA OPERAO DE ABERTURA DA ORDEM DE SERVIO.....................................................119
FIGURA 5.34 - TRECHOS DO CDIGO REFERENTE AO FORMULRIO DE ABERTURA DA ORDEM DE SERVIO..............120
v
Lista de Tabelas
TABELA 3.1 CORRESPONDNCIA ENTRE CLASSE DO MAS E ARQUIVOS DO MASA...................................................71
TABELA 3.2 CORRESPONDNCIA ENTRE CLASSES/ATRIBUTOS DO MAS E OS ARQUIVOS/CAMPOS DO MASA............72
TABELA 3.3 CORRESPONDNCIA ENTRE ALGUMAS OPERAES DO MAS E DO MASA.............................................72
TABELA 6.1 COMPARAO DOS RESULTADOS.........................................................................................................124
vi
Siglas Utilizadas
DAST Draco Abstract Sintax Tree
KB Knowledge Base Base de Conhecimento
MASA Modelo de Anlise do Sistema Atual
MAS Modelo de Anlise do Sistema
MOSA Modelo de Objetos do MASA
MOS Modelo de Objetos do MASA
MCVSA Modelo de Ciclo de Vida do Sistema Atual
MCVS Modelo de Ciclo de Vida do Sistema
MOpSA Modelo de Operaes do Sistema Atual
MOpS Modelo de Operaes do Sistema
1
CAPTULO 1 Introduo
1.1 Consideraes Iniciais
O desenvolvimento de sistemas a partir do zero , na maioria das vezes, mais difcil do
que quando existe algo pronto para ser usado como base. Por exemplo, em muitos sistemas de
informao pode-se aproveitar a estrutura geral de um programa existente, os mdulos para
montagem de menus, relatrios, consultas e a estrutura de insero, alterao e eliminao de
dados. Esse aproveitamento pode ser maior ou menor de acordo com o tipo de aplicao a ser
desenvolvida e de acordo com os sistemas prontos disponveis.
Ao longo de alguns anos de trabalho pode-se acumular inmeros mdulos, que podem
servir como base para elaborao de novos sistemas. Desenvolver sistemas dessa forma tem seus
problemas: na nsia de aproveitar algo j pronto, muitas vezes o sistema resultante no fica to
eficiente; existe a tendncia de colar remendo sobre remendo, produzindo sistemas difceis de
manter; as alteraes feitas so tantas que no resta nada do sistema original (nesse caso, talvez
tivesse sido melhor partir do zero); tambm difcil saber qual dos sistemas prontos seria a
melhor base para o novo sistema, devido falta de rigor na documentao.
Alm desse aproveitamento puramente de cdigo, seria desejvel aproveitar solues de
anlise e projeto, que exigiram bastante esforo para serem elaboradas e poderiam ser
reutilizadas em novos desenvolvimentos. Essas solues poderiam ser sintetizadas em padres,
sejam eles de anlise, de projeto ou de cdigo. Para criar esses padres nada mais natural do que
investigar sistemas prontos, em busca de trechos de cdigo que representem solues para
determinados problemas e que possam ser reutilizados no futuro. Deve-se estudar, ento, uma
forma de documentar esses padres, disponibilizando-os a quem possa interessar.
Padres de software podem se referir a diferentes nveis de abstrao no desenvolvimento
de sistemas orientados a objetos. Assim pode-se ter desde padres de anlise, em que esse nvel
bastante alto, passando por padres de projeto e indo at padres de cdigo. Coad [Coa 92]
apresenta padres de anlise bem gerais, teis principalmente no desenvolvimento de sistemas de
informao na rea empresarial. Gamma [Gam 95] apresenta padres de projeto de utilizao
bastante ampla que abrange sistemas os mais diversos, para vrias reas de aplicao. Fowler
[Fow 97] discute padres de anlise especficos para as reas de contabilidade, observaes e
2
medidas, finanas empresariais, referenciao de objetos, controle de estoque, planejamento,
comercializao de bens, negociao em bolsas de valores e negociao de lotes de papis, entre
outros.
1.2 Motivao
Minha formao acadmica enfatizou o uso do desenvolvimento estruturado de sistemas,
tanto com base nos dados como nos processos. Recebi uma bolsa de Iniciao Cientfica da
FAPESP, cujo plano de trabalho Estudo Comparativo de uma Abordagem Convencional com
uma Operacional para o Desenvolvimento de Sistemas de Informao levou preparao de
vrios relatrios tcnicos, entre os quais [Bra 86a] e [Bra 86b]. No primeiro foi usado o mtodo
J SD [J ac 83], que um mtodo estruturado com base nos dados e no segundo foi usado o mtodo
de Gane [Gan 83], que um mtodo estruturado com base nos procedimentos. Na poca, o J SD
era considerado uma abordagem operacional, enquanto que o mtodo de Gane era considerado
uma abordagem convencional. O trabalho de Masiero [Mas 88], mostra como o J SD pode ser
considerado como um mtodo orientado a objetos. Seu estudo motivou-me a saber mais sobre a
orientao a objetos, familiarizando-me com a bibliografia sobre esse assunto.
Durante cerca de dez anos de prtica profissional utilizei a anlise, projeto e programao
estruturados para o desenvolvimento de mais de vinte sistemas de informao. Esses sistemas
usaram bases de dados relacionais e foram desenvolvidos em linguagens como Dbase, Clipper,
FoxPro for Windows, Visual FoxPro e Access, em um total de aproximadamente 400.000 linhas
de cdigo.
Muitos desses sistemas foram feitos baseados em outros sistemas anteriormente por mim
desenvolvidos. Por exemplo, com base em um sistema para Controle de Estoque e Emisso de
Notas Fiscais de Produtos Agrotxicos, foi feito um sistema para uma Revendedora de
Motocicletas e Peas. Mais tarde, algumas partes desse sistema foram adaptadas para uma
Oficina Eletrnica de Reparos. A parte financeira do primeiro sistema por mim construdo foi
usada quase que integralmente em muitos outros sistemas. As bases de dados tambm possuem
diversos arquivos similares, aproveitando-se toda a idia de projeto.
Nessas atividades de reuso, deparei-me com todos os problemas citados na seo anterior.
Alguns sistemas ficaram ineficientes, com caractersticas desnecessrias para a aplicao
especfica; algumas adaptaes foradas dificultaram a manuteno; alguns mdulos ficaram
3
totalmente diferentes daqueles nos quais foram baseados; houve dificuldade em escolher qual o
melhor sistema para servir de base, devido similaridade dos mesmos e falta de documentao
explicando detalhadamente cada um. Pude sentir, tambm, dificuldades na manuteno desses
sistemas. Alguns deles foram feitos em pequenas equipes (analista e um ou dois programadores),
que nem sempre mantinham a documentao em ordem. Assim, muitos efeitos colaterais
ocorreram devido a pequenas alteraes, alm da constante dificuldade encontrada para localizar
a origem dos problemas que causaram a necessidade de manuteno. Diante disso, surgiu a
grande motivao para estudar uma forma de facilitar o reuso, no somente de trechos de cdigo,
mas tambm de conceitos de anlise e projeto, bem como de facilitar a manuteno dos sistemas.
Apesar dessa prtica profissional ter sido desenvolvida principalmente orientada a
procedimentos, foi usada orientao a objetos em outros trabalhos, como um relatrio tcnico do
ICMC [Bra 98a] e dois artigos em congressos internacionais [Pen 98a, Pen 98b] dos quais sou
co-autora.
Trata-se principalmente de execuo de engenharia reversa orientada a objetos em
sistemas legados desenvolvidos com orientao a procedimentos. Essa engenharia reversa foi
feita de acordo com um processo geral denominado Fusion/RE [Pen 95, Pen 96, Pen 96a e Pen
96b], que ser detalhado mais adiante. Esse processo baseado no mtodo Fusion [Col 94] para
desenvolvimento orientado a objetos.
1.3 Objetivos
Este trabalho prope uma abordagem alternativa usual, que descartar o cdigo antigo
quando se cogita de ampliar a funcionalidade de um sistema existente, com idade avanada e
desatualizado. O objetivo dessa abordagem reconhecer padres de software, sejam eles de
anlise, de projeto ou de cdigo, que sejam teis no reuso, na ampliao de funcionalidade e na
manuteno de sistemas. A base para esse reconhecimento a realizao de experimentos de
reengenharia de sistemas legados, mudando a orientao procedimental original para orientao
a objetos. D-se um enfoque maior para o domnio de sistemas de informao. A reengenharia
com mudana de linguagem feita tanto de forma automtica como de forma manual, obtendo-se
sistemas em linguagens orientadas a objetos. Uma comparao feita entre os sistemas obtidos
por transformao automtica de linguagem e por reengenharia manual com uso de padres.
4
A figura 1.1 ilustra a abordagem da dissertao. Aps a engenharia reversa do sistema
legado, obtm-se o Modelo de Anlise do Sistema, seguindo a orientao a objetos. Dois
caminhos so ento percorridos: primeiramente, o projeto avante e a segmentao do sistema
legado so realizados, aps os quais obtm-se o sistema segmentado, na linguagem
procedimental em que foi desenvolvido. Pode-se ento usar uma ferramenta para fazer a
transformao automtica para uma linguagem orientada a objetos. O caminho alternativo,
explorado depois, faz o reconhecimento de padres a partir do Modelo de Anlise do Sistema,
elaborando a seguir o projeto avante e implementando o sistema, manualmente, em uma
linguagem orientada a objetos. Durante esse processo, pode-se fazer uma busca por situaes em
que esses padres encontrados possam ser empregados, elaborando-se diretrizes para o
reconhecimento e uso de padres.
Figura 1.1 - Ilustrao da Abordagem da Dissertao
1.4 Organizao da Dissertao
Este trabalho est organizado como segue. No captulo 2 relatada a pesquisa
bibliogrfica feita sobre o assunto. No captulo 3 descrita a realizao da engenharia reversa em
um sistema legado de oficina auto-eltrica e mecnica de veculos. No captulo 4 descrita a
reengenharia desse sistema com mudana de orientao mas sem mudana de linguagem e,
Transformao
pela mquina
Draco
Projeto avante +
Implementao
Orientada a
Objetos +Padres
Projeto Avante+
Segmentao
Sistema
segmen-
tado
Sistema
orientado
a objetos
usando
padres
Sistema
Legado
Reengenharia com mudana de linguagem Reengenharia com mudana de orientao
Estratgia
para
reconhe-
cimento de
padres
Engenharia
Reversa
Modelo
de
Anlise
do
Sistema
Sistema
pseudo-
orientado
a objetos
(TAD)
Modelo
de
Anlise
com
padres
Reconhe-
cimento de
padres
Reengenharia com mudana de linguagem
5
posteriormente, a reengenharia com mudana de linguagem de Clipper para J ava. No captulo 5
estabelecida uma estratgia para reconhecimento de padres recorrentes, com base nos modelos
de anlise do sistema e feita uma experincia de reengenharia com mudana para linguagem
Delphi usando esses padres. O captulo 6 apresenta as concluses finais, sugerindo tambm
novas pesquisas que poderiam ser feitas nesta rea.
6
CAPTULO 2 - Resenha Bibliogrfica
2.1 - Consideraes Iniciais
A terminologia empregada na engenharia de software para referenciar as tecnologias de
anlise e entendimento de sistemas existentes apresentada por Chikofsky em [Chi 90], com o
objetivo de racionalizar termos que j esto em uso. Os termos definidos e relacionados so:
engenharia avante, engenharia reversa, redocumentao, recuperao de projeto, reestruturao e
reengenharia.
Figura 2.1 - Relacionamento entre termos [Chi 90].
Engenharia avante o processo tradicional de partir de um nvel de abstrao alto, de
requisitos do sistema, e chegar ao nvel fsico, de implementao do sistema. Restruturao a
transformao de uma forma de representao para outra no mesmo nvel relativo de abstrao,
preservando o comportamento externo do sistema (funcionalidade e semntica). Como exemplos
de reestruturao pode-se citar estruturao de programas e normalizao de dados. Engenharia
reversa, bem como duas sub-reas amplamente referenciadas, a saber, redocumentao e
recuperao de projeto, so definidas na seo 2.3. Reengenharia definida na seo 2.4. O
relacionamento entre os termos (figura 2.1) feito considerando-se que o ciclo de vida do
Redocumentao,
reestruturao
Engenharia
Reversa
Requisitos
( restries, objetivos,
regras de negcios)
Implementao
Engenharia Avante Engenharia Avante
Engenharia
Reversa
Reestruturao Reestruturao
Recuperao de
Projeto
Recuperao
de Projeto
Reengenharia Reengenharia
Projeto
7
software possui trs grandes etapas (requisitos, projeto e implementao) com claras diferenas
no nvel de abstrao. Requisitos tratam da especificao do problema, incluindo objetivos,
restries e regras de negcio. Projeto trata da especificao da soluo. Implementao trata da
codificao, teste e entrega do sistema em operao.
A figura 2.1 mostra claramente a direo seguida pela engenharia avante, do nvel mais
alto para o nvel mais baixo de abstrao. Mostra, tambm, que a engenharia reversa percorre
exatamente o caminho inverso, podendo utilizar-se da recuperao de projeto para aumentar o
nvel de abstrao. A reengenharia geralmente inclui alguma forma de engenharia reversa,
seguida de alguma forma de engenharia avante ou reestruturao. A redocumentao uma
forma mais fraca de reestruturao, permanecendo no nvel de implementao do sistema.
O entendimento de programas essencial para a manuteno e reuso de software.
Qualquer que seja a manuteno a ser feita no software haver a necessidade de primeiramente
entender o programa, para depois efetuar as alteraes. O mesmo ocorre no reuso. Um programa,
para ser reutilizado, deve ser primeiramente entendido a fim de verificar se h necessidade de
adapt-lo antes do reuso.
A engenharia reversa orientada a objetos pode ser feita em sistemas legados
desenvolvidos com orientao a procedimentos. Nela so recuperadas informaes com maior
nvel de abstrao do que o cdigo fonte, teis para o entendimento do sistema, ao mesmo tempo
em que o mesmo modelado segundo a orientao a objetos e preparado para uma futura
reengenharia.
A reengenharia com mudana de orientao, que transforma sistemas originalmente
procedimentais em sistemas orientados a objetos, deve ser feita aps a engenharia reversa citada
acima, que obtm modelos de anlise e projeto orientados a objetos, mudando tambm a
implementao para uma linguagem orientada a objetos.
Com padres de software, podem ser preservadas solues tanto de anlise, como de
projeto e implementao, teis em futuros desenvolvimentos. O estabelecimento e uso de
padres de software pode aumentar a produtividade, qualidade e custo do software.
Os grandes tpicos deste captulo so intimamente inter-relacionados, como mostra a
figura 2.2. O entendimento de programas (seo 2.2) uma fase essencial da engenharia reversa
(seo 2.3), que por sua vez a etapa inicial para se fazer a reengenharia (seo 2.4). Padres
(seo 2.5) so um recurso para reusabilidade, necessitando tambm da engenharia reversa e
8
consequentemente do entendimento de programas. Esses tpicos so explorados com maior ou
menor intensidade, de acordo com os objetivos pretendidos.
Figura 2.2 - Relacionamento entre os tpicos do captulo
A importncia de fazer uma resenha bibliogrfica envolvendo esses quatro tpicos est no
fato de que eles esto intimamente ligados com os objetivos propostos no ttulo da dissertao.
Padres devem ser estudados, pois devero ser reconhecidos facilmente. Engenharia reversa deve
ser explorada, pois durante ela que os padres sero identificados. O entendimento de
programas importante por ser uma parte essencial da engenharia reversa e a reengenharia por
ser um dos objetivos deste trabalho fazer a reengenharia do sistema legado adotando os padres
reconhecidos.
2.2 - Entendimento de Programas
2.2.1 - Introduo
Entender um programa significa poder explicar o programa, sua estrutura, seu
comportamento, seus efeitos e seus relacionamentos com o domnio de aplicao [Big 94]. O
entendimento de programas (ou, similarmente, a compreenso de programas) a construo de
uma estrutura semntica em diversos nveis de abstrao, para represent-los. Para isso, o
Padres
Reengenharia
Engenharia
Reversa
Entendimento
de Programas
Faz
parte da
a
primeira
etapa da
Podem ser
identificados
durante a
Podem ser
usados na
9
programador pode contar com o auxlio de seu conhecimento sinttico da linguagem de
programao e com seu conhecimento sobre o domnio da aplicao [Shn 79].
O nvel de abstrao em que um programa entendido pode ser alto (por exemplo, a
descoberta do qu o programa faz) ou baixo (por exemplo, o reconhecimento de seqncias
familiares de comandos). Ressalta-se que possvel ter uma compreenso de alto nvel mesmo
sem ter-se a compreenso de baixo nvel, e vice-versa [Shn 79].
A maneira mais elementar de obter conhecimento sobre um sistema por meio da leitura
do cdigo fonte, o que pode ser efetivo mas muito difcil devido grande quantidade de
informao contida no cdigo e dificuldade de extrair o conhecimento necessrio [Rob 91].
Assim, necessrio um instrumental para apoiar o entendimento de programas, que compreende
a criao de modelos cognitivos, a construo de ferramentas para ajudar o entendimento e a
realizao de estudos empricos sobre entendimento de programas.
Modelos cognitivos so criados para ajudar a entender como funciona o processo
cognitivo, ou seja, o processo de aquisio de conhecimento. O conhecimento do entendedor
de programas um elemento de grande importncia em um modelo de cognio, podendo ser
geral (por exemplo, conhecimento sobre o domnio de aplicao ou sobre um algoritmo) ou
especfico (por exemplo, conhecimento sobre a linguagem de programao ou estrutura de
dados). Alm disso, o nvel de experincia do especialista (no caso o programador ou analista de
sistemas), a forma de organizao do conhecimento (representao mental do entendimento) e a
eficincia na decomposio do problema (direo top-down ou bottom-up) so fatores que
influenciam diretamente no entendimento de programas.
Ferramentas para apoio ao entendimento de programas tm sido construdas,
compreendendo desde parsers de programao, que fazem, por exemplo, a anlise sinttica do
programa, produzindo informaes sobre a hierarquia de chamadas, at ferramentas mais
elaboradas, que se utilizam de bases de conhecimento e inteligncia artificial para inferir
possveis resultados.
Estudos empricos so uma forma de obter dados sobre o processo de cognio e valid-
lo. Esses estudos podem ser conduzidos de trs formas diferentes: observao, correlao e teste
de hipteses. A primeira observa o comportamento da maneira como ocorre no mundo real, por
exemplo o comportamento de programadores diante de situaes especficas. A segunda assume
que uma teoria tenha sido construda a partir dos estudos observacionais e tenta explorar o
relacionamento entre as variveis em questo. A terceira investiga causas e efeitos entre
10
variveis, a fim de validar uma teoria existente. Os estudos empricos levam em considerao,
tambm, o tamanho do cdigo fonte, linguagem de programao e o tipo de programador. Por
exemplo, pequeno refere-se a programas de menos de 900 linhas, mdio refere-se a
programas entre 900 e 40.000 linhas e grande acima de 40.000 linhas. Programadores podem
ser novios, estudantes de graduao e programadores profissionais [May 95] .
O principal motivo que leva necessidade de entender um programa que muitas regras
de negcios esto embutidas nos programas e no esto documentadas de forma explcita e
precisa em nenhum outro lugar. Essas regras de negcios so bens valiosos para as empresas e
muito difceis de serem captadas e redesenvolvidas [Nin 94].
O entendimento de programas tem algumas aplicaes de grande importncia na
Engenharia de Software, entre elas: a manuteno de software, o reuso e a recuperao de
projeto.
A manuteno de software a modificao de um produto de software, depois da entrega,
para corrigir falhas, melhorar o desempenho e outros atributos, ou para adaptar o produto a
mudanas de ambiente [Chi 90]. A manuteno s possvel aps o entendimento do programa,
para que possam ser localizados os problemas a serem tratados. Estima-se que 50-90% do tempo
de manuteno gasto com a compreenso de programas. Mesmo quando existe documentao,
o tempo gasto para estudo de cdigo trs vezes e meia maior do que o tempo gasto para estudo
da documentao [Rob 91].
O reuso, atividade que tem por finalidade reutilizar componentes de software
anteriormente desenvolvidos, envolve diretamente o entendimento de programas. Para reutilizar
partes de um software existente, necessrio primeiro entender detalhadamente essas partes, para
que seja avaliado seu potencial de reuso e para que sejam feitas as adaptaes necessrias para
torn-las componentes reutilizveis.
A recuperao de projeto, um subconjunto da engenharia reversa discutida posteriormente
na seo 2.3.1, deve reproduzir toda a informao necessria ao entendimento total de: o qu
um programa faz, como o faz e porqu o faz. Por intermdio dela so criadas abstraes de
projeto do sistema, a partir de uma combinao de cdigo, documentao existente (se
disponvel), experincia pessoal e conhecimentos gerais sobre os problemas e o domnio de
aplicao [Big 89].
A seo seguinte relata contribuies consideradas relevantes para o entendimento de
programas.
11
2.2.2 - Contribuies Relevantes
Shneiderman, em [Shn 79], apresenta um modelo cognitivo do comportamento do
programador, dividindo seu conhecimento em semntico e sinttico. O conhecimento semntico
consiste de conceitos gerais de programao independentes de linguagens especficas, enquanto
que o conhecimento sinttico mais preciso, detalhado e fcil de esquecer. O programador cria
representaes internas na resoluo de problemas tais como composio, compreenso,
depurao, modificao e aprendizagem do programa. Os componentes da memria humana so
utilizados de maneira distinta na resoluo de problemas. O conhecimento semntico e sinttico
do programador armazenado em sua memria de longo prazo. Esse conhecimento usado
como base na resoluo de problemas que envolvem novas informaes contidas na memria de
curto prazo. So relatados diversos experimentos empricos, cujas concluses levam
constatao de que a construo de uma estrutura semntica interna facilita a compreenso de
programas.
Soloway, em [Sol 84], trata da compreenso de programas por meio de experimentos
empricos, visando a determinar como esta afetada pela maior ou menor experincia de
programao de quem tenta obt-la. Quem tem maior experincia possui dois tipos de
conhecimento ausentes em quem tem menos: de planos de programas e de regras de raciocnio de
programas. Os primeiros so fragmentos de programas que constituem tpicas seqncias de
comandos que o programador tem experincia de uso em situaes anteriores, as segundas so
regras de bom senso comumente adotadas na prtica de programao. Programadores experientes
compreendem mais facilmente programas que tenham sido construdos com um determinado
plano e que no infrinjam tais regras. Tm dificuldade de compreender programas que no
tenham tais caractersticas. J os novatos no so afetados por essas diferenas.
Biggerstaff, em [Big 89], estabelece um processo bsico de recuperao de projeto,
composto de trs passos. O primeiro ajuda no entendimento de programas, identificando
estruturas de grande porte e associando-as com conceitos semnticos informais. O segundo ajuda
na alimentao e recuperao de bibliotecas de reuso. O terceiro aplica os resultados obtidos na
recuperao de projeto para descobrir candidatos a componentes de um sistema novo. Mostra a
importncia da utilizao de informaes informais, tais como comentrios e nomes de variveis
mnemnicos, e de um modelo do domnio, para a construo de abstraes conceituais do
projeto. Introduz as conexes associativas e os padres estruturais como um modo de formalizar
12
parcialmente as abstraes conceituais informais. As conexes associativas fazem a ligao
entre um conceito abstrato e o respectivo cdigo. Os padres estruturais definem os tipos de
estrutura de cdigo fonte que representam cada abstrao. Apresenta o primeiro prottipo do
DESIRE (Design Recovery), um sistema recuperador de projetos baseado em modelos, que
auxilia os engenheiros de software no entendimento de programas, mostrado na figura 2.3. O
sistema consiste de trs partes principais: um parser, um conjunto de funes de ps-
processamento e um sistema de hipertexto chamado PlaneText. O parser processa programas
em linguagem C e gera as parse trees, que so usadas pelos ps-processadores para produzir
um dicionrio contendo informaes e relacionamentos entre funes e itens de dados, alm de
associ-las a informaes informais (comentrios, por exemplo). O sistema de hipertexto exibe
os relacionamentos por meio de um browser, permitindo vises especficas em janelas
separadas, de acordo com a necessidade do usurio. O sistema oferece, tambm, queries pr-
definidas em Prolog, que ajudam na busca por padres.
Figura 2.3 - Sistema recuperador de projeto baseado em modelo [Big 89]
Robson, em [Rob 91], refora a idia de que a compreensibilidade de programas uma
parte vital do processo de manuteno. Comenta algumas teorias de compreenso de programas,
que modelam o processo de compreenso. Discute a dificuldade de entendimento de cdigo
13
apenas pela leitura, a qual diretamente dependente do tamanho e complexidade do programa.
Discute ainda outros fatores que afetam o entendimento de programas, tais como: estilo de
programao, modularizao, nomes de variveis, tabulao e comentrios. Descreve algumas
das tcnicas empregadas para automatizar a leitura de cdigo, categorizando-as em estratgias
estticas e dinmicas. Considera-as como auxiliares de baixo nvel ao processo de compreenso,
pois ajudam na compresso de pequenas unidades do programa, mas oferecem muito pouca ajuda
na determinao do projeto geral. As vantagens da automao so bvias na manuteno de
sistemas grandes nos quais nenhum dos mantenedores participou do desenvolvimento. A
engenharia inversa ou engenharia reversa considerada como auxiliar de alto nvel, porm ainda
precisa de muito trabalho para se tornar efetiva. As tcnicas de inteligncia artificial so
consideradas uma rea de pesquisa muito til compreenso de programas, porm pouco
exploradas.
Biggerstaff, em [Big 94], relaciona o entendimento de programas com o problema de
assimilao de conceito. Define como Problema de assimilao de conceito a descoberta de
conceitos que envolvem um grande conhecimento do domnio de informao e sua associao
com um programa ou contexto especfico, defendendo a idia de que no h algoritmo que
permita o reconhecimento desses conceitos com plena confiana. feita uma comparao entre
conceitos orientados programao, que podem ser derivados de forma dedutiva ou algortmica,
e conceitos orientados ao ser humano, que requerem um raciocnio razovel e exigem um
conhecimento prvio do domnio em questo. Sugere a utilizao de uma ferramenta para
recuperao de Projeto, o DESIRE, composto de um assistente ingnuo, que oferece servios
simples para apoiar a inteligncia humana e um assistente inteligente, que oferece uma
assistncia inteligente, por meio de um motor de inferncia baseado em Prolog e um
reconhecedor de padres baseado em conhecimento.
Ning, em [Nin 94], prope uma abordagem para recuperao de componentes reusveis,
na qual componentes funcionais de sistemas legados so reconhecidos, recuperados, adaptados e
reutilizados no desenvolvimento de um novo sistema. Essa recuperao requer profunda anlise e
entendimento do cdigo antigo. apresentado um conjunto de ferramentas chamado Cobol/SRE,
que ajuda no entendimento de programas por meio da segmentao de programas que,
basicamente, divide o programa em partes mais fceis de serem compreendidas por quem for
utiliz-las. O Cobol/SRE oferece recursos para demarcar os segmentos e posteriormente
empacot-los em mdulos independentes. Para a demarcao possvel englobar,
14
automaticamente, as linhas de cdigo afetadas por um perform, uma condio, o valor de uma
entrada ou sada. O empacotamento gera novos mdulos de programas, baseando-se nos
segmentos criados na demarcao, tornando o cdigo antigo mais modularizado e portanto mais
reusvel.
Mayrhauser, em [May 95], discute a compreenso de programas durante a manuteno e
evoluo do software. Subdivide a manuteno em adaptativa, aperfeioativa e corretiva,
detendo-se tambm no reuso e na alavancagem de cdigo (code leverage). Ressalta que, para
que o processo de entendimento de programas possa ser otimizado, necessrio que se
compreenda como os programadores entendem o cdigo, o que pode ser apoiado pelos modelos
de cognio. Identifica os elementos comuns aos modelos de cognio, a saber, o conhecimento,
o modelo mental e as caractersticas do especialista. Descreve vrios modelos de cognio de
cdigo, entre os quais: o modelo de Letovsky; o modelo de Shneiderman e Mayer [Shn 79]; o
modelo de Brooks; os modelos de fluxo de controle e o funcional, concebidos por Pennington; o
modelo Top-down, concebido por Soloway, Adelson e Ehrlich e o seu prprio modelo
integrado (figura 2.4). O modelo integrado considera trs componentes: o modelo do
programa, o modelo da situao e os planos de programao. No modelo do programa esto
consolidados o conhecimento do domnio do programa, isto , da estrutura de texto, dos planos e
das regras de raciocnio. No modelo da situao esto reunidos os conhecimentos do domnio do
problema, ou seja, o conhecimento funcional. Nos planos de programao constam os planos
estratgicos, tticos e de implementao, bem como regras de raciocnio. A cada um dos trs
componentes corresponde um processo de modelagem e um setor integrado na base de
conhecimento. No processo de entendimento h alternncia entre os trs modelos, de modo a
conseguir novos conhecimentos que tornam a alimentar a base de conhecimento. Esse modelo
permite tanto o entendimento top-down quanto o entendimento bottom-up, ou a mistura dos
dois.
Mayhauser apresenta tambm uma anlise comparativa quanto aos critrios estticos:
estruturas de conhecimento e representaes mentais; dinmicos e de experimentao, indicando
o grau de abstrao e dimenso da escala dos experimentos, bem como se o objetivo ganhar um
entendimento geral superficial ou parcial e mais aprofundado. Em [May 96], Mayrhauser refora
a parte experimental do trabalho, comprovando que os processos cognitivos atuam
simultaneamente em todos os nveis de abstrao, medida em que os programadores constrem
o modelo mental do cdigo.
15
Figura 2.4 - Metamodelo Integrado [May 95]
16
2.2.3 - Concluses
O entendimento de programas imprescindvel para o sucesso de diversas atividades da
engenharia de software, principalmente a manuteno, o reuso e a engenharia reversa. Um cdigo
s pode passar por alteraes depois de entendido. Um componente s pode ser reusado se for
entendido. Vises de um sistema em nveis de abstrao mais altos que o prprio cdigo s
podem ser produzidas aps o entendimento desse cdigo.
Uma forma de facilitar o entendimento de programas, cujo domnio de aplicao seja
totalmente desconhecido, utilizar conhecimento geral, como por exemplo proximidade de
comandos, separao por linhas em branco, similaridade entre smbolos formais e informais e
acoplamento de definies via smbolos em comum. Porm, nem todo programador utiliza-se
dos bons preceitos da programao. Isso tem que ser levado em conta quando se fazem estudos
empricos.
Entender um programa que contm implcitas regras de negcio valiosas e desconhecidas
por qualquer pessoa na empresa, pode ser um estmulo incomparvel a qualquer outro para o
avano da tecnologia de entendimento de programas. Muitas empresas que possuem programas
nessa situao fazem constantemente investimentos nessa rea.
A correspondncia entre conceitos orientados ao ser humano e trechos de cdigo nunca
ser totalmente automatizada, mas possvel apoio por computador, de utilidade para o
engenheiro de software. Acrescentando-se elementos por ele fornecidos para completar os
aspectos no atingidos pela automao, pode-se acelerar e simplificar de forma significativa o
entendimento de programas [Big 94]. Essa idia unnime em todos os trabalhos estudados.
2.3 - Engenharia Reversa
2.3.1 - Introduo
O termo engenharia reversa tem sua origem em anlise de hardware, na qual a prtica
de extrair projetos do produto final trivial. A Engenharia Reversa regularmente aplicada para
melhorar o produto de uma empresa a partir da anlise dos produtos do adversrio. Engenharia
Reversa o processo de desenvolvimento de um conjunto de especificaes para um sistema de
17
hardware complexo por exame de espcimes daquele sistema, de forma ordenada. [Rek 85].
Esse processo , em geral, conduzido por outro desenvolvedor, sem o benefcio de algum dos
desenhos originais, com o propsito de fazer um clone do sistema de hardware original.
No software, a engenharia reversa o processo de anlise de um sistema para identificar
seus componentes e inter-relacionamentos e criar representaes do mesmo em outra forma ou
num nvel mais alto de abstrao [Chi 90]. As informaes extradas do cdigo fonte via
engenharia reversa podem estar em diversos nveis de abstrao. Por exemplo, num baixo nvel
de abstrao tm-se representaes de projeto procedimental, subindo para informaes sobre a
estrutura de dados e de programa, modelos de fluxo de controle e de dados e chegando a modelos
entidade-relacionamento, que constituiriam o nvel de abstrao mais alto. O ideal seria ter um
nvel de abstrao o mais alto possvel [Pre 95].
A engenharia reversa deve produzir, preferencialmente de forma automtica, documentos
que ajudem a aumentar o conhecimento geral de sistemas de software, facilitando o reuso,
manuteno, teste e controle de qualidade de software. Alm disso, a engenharia reversa justifica
a necessidade de utilizar o conhecimento implementado em software antigo (ou legado) na
produo de software novo e ajustar software e documentao existentes a novos padres e
ferramentas introduzidos por novos mtodos e tecnologias de produo. Ressalte-se que
necessrio adicionar experincia pessoal e conhecimentos gerais a respeito do problema e do
domnio de aplicao informao extrada automaticamente do cdigo [Ben 92].
Existem diversas sub-reas da engenharia reversa: entendimento de programas (visto na
seo 2.1), redocumentao e recuperao de projeto. A redocumentao a criao de uma
representao alternativa de um programa, que seja equivalente e esteja no mesmo nvel de
abstrao. Alguns a consideram uma forma de restruturao. Seu objetivo recuperar
documentao que existiu ou deveria ter existido de um sistema alvo. A redocumentao pode
ser auxiliada por ferramentas automticas, tais como os pretty printers, que mostram a
listagem do cdigo de uma forma melhor; geradores de diagramas, que criam diagramas para
mostrar fluxo de controle a partir do cdigo e geradores de listagens de referncia cruzada. A
recuperao de projeto usa conhecimentos sobre o domnio de aplicao, informaes externas e
raciocnio, juntamente com observaes sobre o sistema em questo, para identificar abstraes
de nvel mais alto do que as produzidas diretamente pelo exame do sistema em si [Chi 90].
As duas maiores aplicaes da engenharia reversa so o reuso e a manuteno de
software. O reuso de software pode ser apoiado pela engenharia reversa tanto na identificao e
18
composio de componentes a partir de partes reutilizveis de sistemas existentes quanto na
elaborao da documentao dos novos sistemas compostos. A manuteno de software uma
tarefa difcil e por isso deve contar com a ajuda de uma documentao completa de todo o
processo de desenvolvimento. Nesse ponto, a engenharia reversa pode fornecer as vises em
diversos nveis de abstrao, permitindo a localizao dos componentes a serem mantidos, alm
de melhorar a compreensibilidade do software, pela documentao produzida.
As ferramentas de apoio engenharia reversa executam uma anlise ps-
desenvolvimento num programa existente. Existem ferramentas estticas, que usam o cdigo
fonte de um programa como entrada e extraem a arquitetura do programa, estrutura de controle,
fluxo lgico, estrutura de dados e fluxo de dados; e ferramentas dinmicas, que monitoram o
software em execuo e usam as informaes para construir um modelo comportamental do
programa [Pre 95].
Diversas ferramentas e mtodos tm sido propostos para apoiar a engenharia reversa. A
seo seguinte sumariza alguns deles.
Benedusi, em [Ben 92], define um paradigma de referncia, chamado
Goals/Models/Tools, para estabelecer processos de engenharia reversa capazes de gerar,
automaticamente, informaes e documentos de projeto, a partir do cdigo fonte. A fase Goals
analisa as razes pelas quais o processo de engenharia reversa deve ser estabelecido e define os
documentos a serem produzidos. A fase Models analisa os documentos a serem produzidos,
identifica as informaes e relacionamentos que podem ser extradas diretamente do cdigo e
que so direta ou indiretamente necessrias produo desses documentos, define os modelos de
programas que podem representar essas informaes e relacionamentos e define os algoritmos de
abstrao que permitiro que os documentos desejados sejam produzidos a partir desses modelos,
via o processo de engenharia reversa. A fase Tools define, adquire ou constri todas as
ferramentas de software necessrias produo dos documentos da engenharia reversa. dado
um exemplo de aplicao do paradigma (figura 2.5) a um caso real de reconstruo dos
documentos de projeto a partir de cdigo PASCAL. No exemplo, a fase Goals tem por
objetivo a produo de diagramas de estrutura, a fase Models usa expresses algbricas de
programas e tcnicas de fluxo de dados global e a fase Tools executada por um extrator
19
Pascal. Em [Ben 96], mostrado como a qualidade dos modelos obtidos pela engenharia reversa
pode ser melhorada quando, alm do cdigo fonte, da documentao de uso e da experincia
humana, utilizam-se os resultados de casos de teste que ocorrem durante a manuteno. Assim, a
anlise esttica pode ser complementada com a anlise dinmica.
Figura 2.5 - Instanciao do Paradigma Goals/Models/Tools [Ben 92]
Wong, em [Won 95], ressalta que, para sistemas grandes, o entendimento de aspectos
estruturais da arquitetura do sistema mais importante do que o entendimento de um
componente isolado qualquer. A redocumentao estrutural definida como uma engenharia
reversa dos aspectos arquitetnicos do software. Apresenta uma ferramenta, chamada Rigi,
para redocumentao estrutural de sistemas, que fornece um mtodo para identificar, construir e
documentar hierarquias de subsistemas em camadas. O Rigi possui trs componentes: o
Rigireverse, um sistema de parser; o Rigiserver, para armazenar a informao extrada do
cdigo fonte e o Rigiedit, um editor grfico interativo para manipular representaes de
programa. Para usar de forma efetiva a informao extrada pelo Rigi deve-se acrescentar o
conhecimento sobre o domnio especfico de aplicao. Isso feito por meio de scripts, que
permitem que o usurio escreva rotinas sob medida para atividades comuns, tais como extrao
de artifcios, apresentao de grficos e pesquisa e seleo de objetos. O Rigi foi testado em
Diagrama de
Estrutura
Expresso
Algbrica do
Mdulo
Matriz
Varivel /
Expresso
Extrator
PASCAL
Abstrator
SC1
Abstrator
SC2
Abstrator
SC3
Goals
Models
Tools
20
sistemas com mais de um milho de linhas de cdigo, confirmando que as vises produzidas
durante a redocumentao estrutural auxiliaram no entendimento desses sistemas legados.
Figura 2.6 - Documentao de objetos [Sne 95]
Sneed, em [Sne 95], apresenta uma abordagem para extrair documentao de projeto
orientada a objetos, automaticamente, a partir de programas existentes em COBOL. Comenta que
a migrao de sistemas legados em operao em "mainframes" para arquiteturas cliente/servidor
exige, na maioria das vezes, uma engenharia reversa seguida de reimplementao, sem mudana
de funcionalidade, que a noo de reengenharia proposta por Chikofsky [Chi 90]. Essa
migrao pode beneficiar-se da reusabilidade, interface grfica, comunicao inter-programas e
outras tcnicas modernas de programao proporcionadas pela orientao a objetos. Para isso,
Sneed prope uma abordagem que produz documentos de projeto compatveis com os vrios
mtodos de anlise orientada a objetos, como por exemplo Coad/Yourdon, Shlaer/Mellor ou
Rumbaugh. As etapas dessa abordagem, denotadas por retngulos na figura 2.6, so as seguintes:
Estruturas
Comuns
Descrio da
Interface
Definio da
Sequncia de
Execuo
Estruturas de
Dados
Seleo de
Objetos
Estruturas de
Procedimentos
Extrao de
Operaes
Especificao
de casos de
teste
Referncia
cruzada
Objetos
Mtodos
Mensagem
Doc.
Mtodos
Doc.
Interface
Doc.
Processos
Doc. casos
de teste
Doc.
Ref. cruzada
Doc.
Objetos
21
identificao de objetos, extrao de operaes, conexo dos objetos, re-especificao da
seqncia de operao e re-especificao de casos de uso. apresentada uma ferramenta,
chamada OBJ ECT-REDOC, projetada para analisar cdigo legado em COBOL e produzir
documentos de projeto orientado a objetos, tais como: rvores de objetos/atributos, grafos de
colaborao, rvores de condio, especificao de casos de teste e listas de referncia cruzada.
Penteado, em [Pen 95] e [Pen 96], apresenta um mtodo (posteriormente denominado
Fusion/RE) para engenharia reversa de sistemas legados, implementados sem usar a tecnologia
de orientao a objetos, com o objetivo de produzir o modelo de anlise orientado a objetos.
Baseia-se no mtodo Fusion para desenvolvimento orientado a objetos [Col 94], que rene
diversas tcnicas propostas por outros mtodos. A engenharia reversa feita em quatro passos,
que sero descritos na seo 3.2. Penteado faz um estudo de caso, aplicando seu mtodo a um
ambiente para edio e simulao de statecharts, chamado Statsim, desenvolvido no
ICMSC/USP. O estudo confirma a viabilidade de derivao de um modelo orientado a objetos
com base em uma implementao no orientada a objetos.
Dando continuidade ao trabalho apresentado em [Pen 95], Penteado utiliza, em [Pen 96a]
e [Pen 96b], mtricas para avaliao da qualidade da implementao atual e do esforo de
converso gastos na eventual reengenharia do sistema. Essas mtricas baseiam-se,
principalmente, nos procedimentos do sistema atual que contm anomalias e nos procedimentos
de implementao. Os procedimentos com anomalias so aqueles que fazem uso de mais de uma
classe. Ao serem convertidos, no novo sistema, exigem maior esforo, pois precisam ser
desmembrados em diversos mtodos de diversas classes. Os procedimentos de implementao
so aqueles relacionados interface, mdulo escalonador, etc. O fato deles existirem em grande
volume pode indicar grande esforo de converso, ao passo que se forem poucos pode significar
que a interface muito simples e deveria ser reformulada na reengenharia. So discutidas quatro
alternativas a serem seguidas aps a engenharia reversa do sistema: uso da documentao
produzida para facilitar a manuteno, melhoria da qualidade do sistema atual, desenvolvimento
do sistema por reengenharia e conservao da implementao atual, com aperfeioamentos
futuros realizados usando a orientao a objetos.
Hainaut, em [Hai 96], prope um processo para elicitao da estrutura na engenharia
reversa de bases de dados, que composto por dois processos principais. O primeiro cuida da
extrao da estrutura de dados, buscando reconstruir completamente o esquema lgico. O
segundo cuida da conceitualizao da estrutura de dados, visando a especificar as estruturas
22
semnticas desse esquema lgico na forma de um esquema conceitual. So relatados alguns
problemas encontrados na extrao da estrutura de dados, sendo que o maior deles descobrir e
explicitar as estruturas e restries que esto implementadas de forma implcita. Um exemplo
disso o problema da elicitao de chaves estrangeiras, que estudado mais profundamente para
ilustrar o mtodo proposto. apresentada uma ferramenta, chamada DB-MAIN [Hai 96a], que
um ambiente CASE programvel de propsito geral dedicado Engenharia de Aplicao de
banco de dados. Alguns de seus assistentes, dedicados elicitao de estruturas implcitas, so
tambm descritos.
Finnigan, em [Fin 97], prope um ambiente de apoio migrao de software, chamado
Software bookshelf, que prov meios de captar, organizar e gerenciar informaes sobre sistemas
legados. O ambiente possui trs componentes principais: o construtor, o bibliotecrio e o
patrocinador, responsveis por construir, alimentar e utilizar a bookshelf (estante de livros),
respectivamente. O construtor monta a arquitetura da bookshelf por meio de mecanismos
automticos de coleta, estruturao e armazenamento de informaes que satisfaam o
bibliotecrio. Para isso, utiliza-se de parsers, analisadores, conversores e visualizadores que
permitem que o bibliotecrio alimente o repositrio a partir de uma grande variedade de fontes
de informao. O bibliotecrio alimenta a bookshelf com informaes especficas de um
determinado sistema. Utiliza como fontes de informao os cdigos fonte e documentao
externa (disponvel em papel ou de forma eletrnica) tal como dados de teste, registro de
defeitos, informao arquitetural, registros de manuteno, etc. Ele deve selecionar os dados que
so teis ou no ao propsito especfico de reengenharia, sendo parcialmente auxiliado pelo
ambiente. O patrocinador um usurio final da bookshelf, podendo ser um desenvolvedor, um
gerente ou qualquer pessoa que precise de mais detalhes para fazer a reengenharia do cdigo
legado. Depois que a bookshelf estiver alimentada, o patrocinador pode editar o contedo
existente, adicionar notas e evidenciar pontos chave. Pode tambm acrescentar novas
informaes a partir das armazenadas no repositrio e da execuo de ferramentas de anlise e
visualizao do ambiente.
Armstrong, em [Arm 98], compara cinco ferramentas para recuperao da arquitetura de
sistemas legados: Rigi, Dali workbench, Software Bookshelf, CIA e SniFF+. O Rigi e o Sofware
Bookshelf so brevemente apresentados nesta mesma seo. O Dali workbench uma ferramenta
que ajuda na interpretao de dados extrados a partir de informaes arquiteturais, combinando-
os com outros dados j armazenados em um repositrio, usando o sistema de visualizao do
23
Rigi. O CIA uma base de dados relacional usada para extrair e armazenar informaes sobre
cdigo em C, juntamente com uma ferramenta de consulta e visualizao. O SNiFF um
ambiente de programao extensvel e escalonvel com recursos de parsing e recuperao de
informao. Todas as ferramentas comparadas so construdas para a linguagem C. Elas foram
analisadas com relao sua habilidade em efetuar a extrao de dados, a classificao e a
visualizao dos modelos. Trs sistemas reais foram utilizados na comparao, sendo que um
deles foi especialmente criado para causar dificuldades em parsers comuns. A capacidade de
extrao das ferramentas pde ser testada com relao chamada de rotinas de biblioteca
escondidas, variveis globais externas, recurso, compilao condicional, variveis locais e
funes com o mesmo nome, etc. A ferramenta SNiFF provou ser a melhor nesse quesito,
fornecendo um nvel de detalhe suficiente para a anlise arquitetural. A capacidade de
classificao das ferramentas, isto , de combinao de diversos fatos de baixo nvel em objetos
mais abstratos, foi tambm testada. Nesse quesito as ferramentas Software Bookshelf e Dali
mostraram alguma habilidade de abstrao para nveis mais altos. A capacidade de visualizao,
essencial para o entendimento da arquitetura do sistema, existe em todas as ferramentas
comparadas, havendo caractersticas espalhadas por todas elas que juntam formariam a
ferramenta ideal para visualizao.
2.3.3 - Concluses
A engenharia reversa de grande importncia na manuteno de sistemas, facilitando
tambm sua futura reengenharia. Unindo-se ao entendimento de programas, a engenharia reversa
produz excelentes resultados de grande utilidade para o engenheiro de software responsvel por
alteraes, reuso e evoluo do sistema. Quando os modelos por ela obtidos seguem o paradigma
da orientao a objetos, ainda mais vantagens so oferecidas, principalmente quanto facilidade
de reengenharia com mudana de orientao do sistema.
A engenharia reversa pode ser realizada com base nos diferentes mtodos para
desenvolvimento de sistemas, sendo facilitada quando o mtodo adotado apresenta transio
suave entre as fases de anlise e projeto e de projeto e implementao. Por exemplo, se projeto e
implementao possuem correspondncia natural, fica mais fcil caminhar no sentido contrrio,
como necessrio fazer na engenharia reversa. No mtodo Fusion para desenvolvimento de
sistemas orientados a objetos [Col 94], essa transio bastante suave, por isso o Fusion/RE
24
[Pen 96] usado com facilidade. Mesmo considerando que o sistema legado no foi
desenvolvido orientado a objetos, essa vantagem continua a existir. Deve-se lembrar tambm
que, no Fusion/RE, obtm-se os modelos de anlise sem passar pelos modelos de projeto.
2.4 - Reengenharia
2.4.1 - Introduo
A reengenharia tem por finalidade examinar e alterar um sistema existente para
reconstitu-lo em uma nova forma e depois implement-lo na nova forma [Chi 90]. A
reengenharia tem como objetivo principal melhorar a qualidade global do sistema, mantendo, em
geral, as funes do sistema existente. Mas, ao mesmo tempo, pode-se adicionar novas funes e
melhorar o desempenho [Pre 95]. Segundo J acobson [J ac 91], a reengenharia consiste da
engenharia reversa, seguida de mudanas no sistema (que podem ser mudanas de funcionalidade
ou mudanas de tcnica de implementao) e seguida da engenharia avante. Ou seja,
reengenharia o processo de criar uma descrio abstrata do sistema, elaborar mudanas em
alto nvel de abstrao e ento implement-las no sistema. De acordo com Sneed [Sne 95a], a
reengenharia engloba a reengenharia do procedimento empresarial, a reengenharia dos dados, a
reengenharia do software e a reciclagem (que produz componentes reusveis, de maneira anloga
ao processo de retirada de peas aproveitveis de um automvel abandonado).
Uma das grandes motivaes para aplicao da reengenharia a diminuio dos altos
custos de manuteno de sistemas, que devem-se a diversos fatores, discutidos por Wilkening em
[Wil 95]. A manuteno contnua faz com que a implementao fique inconsistente com o
projeto original, o cdigo torne-se difcil de entender e sujeito a erros, alm da documentao
desatualizada. As linguagens em que esses sistemas foram implementados esto ultrapassadas,
no havendo suporte por parte dos fabricantes nem tampouco programadores que as dominem,
alm de no haver ferramentas CASE que as suportem. Esses sistemas foram desenvolvidos
sem seguir os preceitos da engenharia de software, tendo, na maioria das vezes, um cdigo
desestruturado e difcil de entender. A alta rotatividade de funcionrios faz com que muita
informao seja perdida, diminuindo o conhecimento existente sobre o sistema.
25
Muitas empresas possuem programas ou sistemas passveis de reengenharia, mas deve-se
avaliar cautelosamente os prs e contras de efetu-la. Programas pouco usados, que no sofrem
mudanas, no compensam o custo da reengenharia. Programas que sofrem mudanas constantes
podem passar pela reengenharia como forma de manuteno preventiva, para evitar problemas
futuros. O custo para a reengenharia de um sistema pode ser compensado, a longo prazo, pela
melhoria da manutenibilidade e reuso.
A seo seguinte relata contribuies consideradas relevantes para a reengenharia,
preferencialmente aquelas cujo enfoque seja a mudana de paradigma para a orientao a objetos.
Nota-se que muitos artigos sobre reengenharia tratam, com mais destaque, ou de entendimento
de programas, ou de engenharia reversa ou de padres. Esses artigos foram discutidos nas sees
respectivas desses assuntos, como por exemplo [Nin 94] (seo 2.2.2) e [Gal 96] (seo 2.5.2).
Artigos importantes sobre reengenharia, como [Wel 95] e [Sem 95], no so aqui includos
porque no tratam especificamente da reengenharia com mudana de orientao.
J acobson, em [J ac 91], apresenta uma tcnica para efetuar a reengenharia de sistemas
legados, implementados em uma linguagem procedimental como C ou Cobol, obtendo sistemas
orientados a objetos. Mostra como fazer essa reengenharia de forma gradual, pois considera
impraticvel substituir um sistema antigo por um completamente novo (o que exigiria muitos
recursos). Considera trs cenrios diferentes: no primeiro se faz mudana de implementao sem
mudana de funcionalidade; no segundo se faz a mudana parcial da implementao sem
mudana de funcionalidade; e no terceiro se faz alguma mudana na funcionalidade. Apresenta
trs estudos de caso: um sistema de peas sobressalentes, um sistema de telecomunicaes e um
sistema de controle de trfego. Usa uma ferramenta Case especfica para orientao a objetos, o
ObjectOry. Nota-se que o autor no justificou o porqu de passar para a orientao a objetos,
tendo apenas usado o termo modernizao do sistema.
Markosian, em [Mar 94], reclama da falta de apoio computadorizado para a reengenharia
de sistemas, em contraposio grande proliferao de ferramentas CASE para desenvolvimento
de software novo. Diz que as ferramentas de transformao atuais so muito limitadas, sendo
difcil a adaptao a um projeto em particular. Aborda uma nova tecnologia para reengenharia,
que chama de tecnologia facilitadora (enabling technology), relatando resultados prticos
26
bastante animadores quanto produtividade da sua aplicao. A tecnologia facilitadora
consiste no rpido desenvolvimento de ferramentas para analisar e modificar, de forma
sistemtica, sistemas existentes. Deve ser usada em tarefas complexas de reengenharia, que
estejam sendo feitas mo ou com automatizao parcial. Usa como exemplo ilustrativo de
aplicao dessa tecnologia o sistema da Boeing Computer Services, que mantm muitos
sistemas legados grandes, como por exemplo um sistema de folha de pagamento com vinte e
dois anos e 650.000 linhas de cdigo Cobol. Explica detalhadamente o processo de
modularizao desse sistema, para torn-lo compatvel com tipos abstratos de dados. Usa para
efetuar essa modularizao duas ferramentas que incorporam a tecnologia facilitadora de
reengenharia, a Software Refinery
TM
e a REFINE/Cobol
TM
, da empresa Reasoning Systems. A
ferramenta Software Refinery foi usada para estender a ferramenta REFINE/Cobol a fim de
executar a modularizao. Essas ferramentas oferecem uma base de dados orientada a objetos
para modelar o software e suas informaes, uma linguagem de especificao executvel de
muito alto nvel, juntamente com um compilador, auxlio para depurao e uma biblioteca run-
time com utilitrios independentes de linguagem. Suas sadas so: o grafo de chamadas do
programa, anlise set/use, grafo de fluxo de controle e modelo de dados. O trabalho de
modularizao usando essas ferramentas mostrou-se produtivo, tendo-se detectado menos erros
do que na modularizao feita mo.
Sage, em [Sag 95], discute os possveis tipos de reengenharia que podem ser
considerados: reengenharia de produto, de processo e de gesto de sistemas. A reengenharia de
produto definida como sendo o exame, estudo, captao e modificao dos mecanismos
internos ou da funcionalidade de um produto ou sistema existente, para reconstitui-lo em uma
nova forma e com novas caractersticas, geralmente para desfrutar de vantagens de novas
tecnologias emergentes, mas sem maiores mudanas na funcionalidade e propsitos do sistema.
A reengenharia de processo o exame, estudo, captao e modificao dos mecanismos
internos ou da funcionalidade de um processo existente, ou ciclo de vida de engenharia de
sistemas, para reconstitui-lo em uma nova forma e com novas caractersticas funcionais e no
funcionais, geralmente para desfrutar de capacidades organizacionais ou tecnolgicas novas ou
desejveis, mas sem mudar o propsito inerente ao processo em si. A reengenharia de gesto de
sistemas o exame, estudo, captao e modificao dos mecanismos internos ou da
funcionalidade de processos e prticas de gesto de sistemas existentes em uma organizao,
para reconstitui-los em uma nova forma e com novas caractersticas, geralmente para desfrutar de
27
requisitos de competitividade organizacional emergentes, mas sem mudar o propsito inerente
organizao em si. Segundo Sage, qualquer que seja o tipo de reengenharia, sempre envolve um
ciclo de vida de trs fases: definio, desenvolvimento e disposio. Na primeira fase, so
definidos os objetivos da reengenharia, obtendo-se um conjunto de requisitos para a entidade a
passar pela reengenharia. Na segunda fase so determinadas as necessidades arquiteturais e
feito o projeto da entidade a passar pela reengenharia, que testada e avaliada. Finalmente, na
terceira fase, implementada a reengenharia da entidade, de forma operacional, garantindo-se
que a manuteno possa ter continuidade. Sage discute detalhadamente todos os tipos de
reengenharia, dando uma viso geral da literatura atual sobre o assunto. Cita os fatores que
devem ser levados em conta ao decidir pela reengenharia, os riscos que devem ser tratados
durante a mesma e os fatores para aumentar a chance de sucesso na reengenharia.
Wilkening, em [Wil 95], apresenta um processo para efetuar a reengenharia de sistemas
legados, aproveitando partes de sua implementao e projeto. Esse processo inicia-se com a
reestruturao preliminar do cdigo fonte, para fazer algumas melhorias no mesmo, como
remoo de construes no estruturadas, cdigo morto e tipos implcitos. A finalidade dessa
reestruturao preliminar produzir um programa fonte mais fcil de analisar, entender e
reestruturar. Em seguida, o cdigo fonte produzido analisado e so construdas representaes
do mesmo em nveis mais altos de abstrao. Com base nisso, pode-se prosseguir com os passos
de reestruturao, re-projeto e redocumentao, que so repetidos quantas vezes forem
necessrias para se obter o sistema totalmente reestruturado. Pode-se, ento, gerar o programa na
linguagem destino e dar seqncia aos testes que verificaro se a funcionalidade no foi afetada.
Wilkening apresenta a ferramenta RET, que automatiza parcialmente esse processo, sendo
portanto uma reengenharia assistida por computador. Essa ferramenta foi instanciada para
sistemas cuja linguagem original FORTRAN, e que aps a reengenharia so transformados,
automaticamente, para a linguagem ADA. Com a RET, o engenheiro de software no tem que se
preocupar com detalhes sintticos, como por exemplo as diferenas de sintaxe entre a linguagem
fonte e destino, podendo dar mais ateno a decises de projeto e implementao que requerem
ajuda humana.
Klsh, em [Klo 96], discute uma abordagem para reengenharia com mudana de
orientao, na qual aplica primeiramente a engenharia reversa para depois mudar a linguagem
para uma linguagem orientada a objetos. Esse trabalho uma continuao do trabalho de Gall
[Gal 95], no qual apresentado o mtodo COREM para transformao de programas, que refaz
28
sistemas de arquitetura procedimental, tornando-os orientados a objetos. Klsh justifica o uso da
orientao a objetos como forma de melhorar a manutenibilidade futura, devido a conceitos
como abstrao, encapsulamento e passagem de mensagens. contrrio utilizao de herana e
polimorfismo, por acreditar que esses conceitos complicam potencialmente as operaes de
manuteno. A abordagem proposta por Klsh possui quatro passos: recuperao de projeto,
modelagem da aplicao, mapeamento dos objetos e adaptao do cdigo fonte. No primeiro
passo so recuperados modelos do projeto, como por exemplo o diagrama entidade-
relacionamento. Esse transformado em um modelo reverso orientado a objetos da aplicao
(RooAM), que um modelo obtido de forma direta, sem considerar aspectos dinmicos como
servios e conexo de mensagens. No segundo passo construdo o modelo progressivo
orientado a objetos da aplicao (FooAM), usando-se algum dos mtodos disponveis para
anlise orientada a objetos. Nesse passo h interferncia de um especialista humano que seja
experiente no domnio de aplicao ou que tenha participado do desenvolvimento do sistema em
questo. No terceiro passo feita a correspondncia entre o RooAM e o FooAM, para resolver as
possveis ambigidades surgidas durante o passo de recuperao de projeto. No quarto passo
feita a adaptao da implementao procedimental para a arquitetura orientada a objetos. Klsh
concorda com a automatizao de partes do processo de reengenharia, mas acredita que seja
melhor uma abordagem hbrida, que use a assistncia automtica de uma ferramenta
computadorizada mas que, quando ela alcanar seus limites, conte com a interveno da
sabedoria humana para super-los.
Sneed, em [Sne 96], descreve um processo de reengenharia apoiado por uma ferramenta
para extrair objetos a partir de programas existentes em COBOL. Ressalta a predominncia da
tecnologia de objetos nos dias de hoje, principalmente em aplicaes distribudas com interfaces
grficas, questionando a necessidade de migrao de sistemas legados para essa nova tecnologia.
Identifica alguns obstculos reengenharia orientada a objetos, como por exemplo a
identificao dos objetos, a natureza procedimental da maioria dos sistemas legados, que leva a
blocos de cdigo processando muitos objetos de dados, a existncia de cdigo redundante e a
utilizao arbitrria de nomes. Assume como pr-requisitos para a reengenharia orientada a
objetos a estruturao e modularizao dos programas, alm da existncia de uma rvore de
chamadas do sistema. apresentado um processo de reengenharia orientada a objetos composto
de cinco passos: seleo de objetos, extrao de operaes, herana de caractersticas, eliminao
de redundncias e converso de sintaxe. A seleo de objetos feita com apoio da ferramenta,
29
mas o responsvel pela determinao dos objetos o engenheiro de software. A extrao de
operaes particiona o programa em subrotinas, removendo os segmentos referentes a um
determinado objeto e substituindo-os por envio de mensagens ao objeto no qual os dados locais
estiverem encapsulados.
2.4.3 - Concluses
Fazer ou no reengenharia em um sistema legado uma deciso que deve ser tomada com
muito cuidado. Sistemas que esto operando de forma satisfatria no devem ser
necessariamente substitudos, mesmo que os novos sistemas prometam ser melhores. Na
verdade, a melhora teria que ser significativamente grande para compensar o risco introduzido
[Sne 96].
A transformao de programas procedimentais em programas orientados a objetos no
trivial, requerendo interveno humana para escolher os objetos [Sne 96]. A quantidade dessa
interveno pode diminuir se houver integrao da reengenharia com padres predefinidos em
vrios nveis de abstrao, tais como padres do domnio de aplicao, padres de projeto ou
padres de linguagem [Klo 96].
Ferramentas de apoio reengenharia ajudam a diminuir o trabalho tedioso de
transformao de linguagens, deixando o engenheiro de software com tempo livre para tarefas
mais nobres.
2.5 - Padres
2.5.1 - Introduo
Segundo o dicionrio Aurlio [Fer 95], padro aquilo que serve de base ou norma para a
avaliao de qualidade ou quantidade; ou qualquer objeto que serve de modelo feitura de outro;
ou modelo, exemplo, prottipo, arqutipo. Essas definies aplicam-se a diversos campos, como
por exemplo na msica, na literatura, na arte, na psicologia, na costura, na decorao, no jogo de
xadrez e na aviao [Coa 92]. Na engenharia de software, desenvolvedores tm tentado encontrar
padres que venham ao encontro dos planos, algoritmos, estruturas de dados e idiomas
30
aprendidos no passado [Gam 95]. Padres tm sido usados para descrever solues para um
problema repetido de projeto [Vli 95], ou princpios de projeto que se mostraram teis no
desenvolvimento de software [Gal 96]. Estudos mostram que quando especialistas trabalham em
um problema particular raro que inventem uma nova soluo para atac-lo, completamente
diferente das j existentes. Diversas solues de projeto so por eles conhecidas, de acordo com a
prpria experincia ou a de outros profissionais. Quando confrontam-se com novos problemas,
freqentemente lembram-se de outros similares e reusam a soluo antiga, pensando em pares
problema/soluo. Esses pares podem ser agrupados em famlias de problemas e solues
similares, sendo que cada famlia exibe um padro tanto de problema quanto de soluo [Bus
97]. Projetistas familiarizados com certos padres podem aplic-los imediatamente a problemas
de projeto, sem ter que redescobr-los [Gam 95].
Os padres tm pelo menos dois propsitos: primeiro, fornecem exemplos a serem
seguidos e artifcios a serem copiados e posteriormente refinados ou estendidos. Segundo, eles
garantem uniformidade na estrutura do software. H, portanto, um considervel aumento de
produtividade no desenvolvimento e manuteno do software [Gal 96].
Padres de projeto so definidos como descries de objetos e classes que se
comunicam, os quais so ajustados para resolver um problema genrico de projeto, em um
contexto particular. Um padro de projeto identifica as classes e instncias participantes,
juntamente com seus papis, colaboraes e distribuio de responsabilidade [Gam 95]. Padres
de projeto podem ser considerados micro-arquiteturas reutilizveis que contribuem para a
arquitetura geral de um sistema [Gam 93]. Padres de projeto so definidos como cliches
adicionados de sugestes para seu devido uso na construo de software; eles embutem o
conhecimento do especialista, representando uma soluo para um problema comum de projeto e
podem ser reusados freqentemente e facilmente [Kra 96].
O processo de desenvolvimento de software orientado a objetos pode ser facilitado pelo
uso de padres de projeto. Eles proporcionam um vocabulrio comum para a comunicao entre
projetistas, criando abstraes num nvel superior ao de classes e instncias. A construo de
software reutilizvel incentivada, bem como o reuso do conhecimento de projeto obtido por
projetistas experientes. O tempo gasto para aprendizado de uma biblioteca de padres reduzido,
ajudando um novio a agir como um especialista [Gam 93].
31
Rich, em [Ric 90], define clichs como estruturas de programao ou algoritmos
comumente usados no desenvolvimento de sistemas. Aponta como vantagens do reconhecimento
automtico de clichs o aumento da facilidade de manuteno, documentao, evoluo,
otimizao e depurao de software. Alm disso, ajuda no estudo de como representar e usar o
conhecimento e experincia de programao. Apresenta o prottipo do Recognizer, uma
ferramenta que encontra, automaticamente, todas as ocorrncias de determinados tipos de clichs
em um programa e com base nisso, constri uma descrio hierrquica do programa. O
Recognizer possui um mdulo dependente da linguagem, que traduz o cdigo fonte para uma
representao grfica chamada Plan Calculus, produzindo uma rvore de projeto. Aponta
algumas caractersticas dos clichs que dificultam seu reconhecimento automtico, como a
variao sinttica e de implementao, a no contiguidade e a sobreposio de implementaes.
Mostra, depois, por meio de exemplos escritos na linguagem LISP, como o Recognizer supera
essas dificuldades.
Figura 2.7 - Padro Roles-played (papis desempenhados) e exemplo [Coa 92]
Coad, em [Coa 92], aborda o uso de padres na anlise orientada a objetos e no projeto
orientado a objetos. Define padres e d algumas dicas de como encontr-los, especialmente para
anlise e projeto orientados a objetos. Lembra que os mtodos orientados a objetos j destacam
Ator
Papel
datainicio
datafim
Papel 1 Papel 2
Pessoa
Nome
Telefone
Papel
data
Cliente
desconto
calcular valor desc.
Empregado
Nmero
32
certos padres de relacionamentos, como a generalizao-especializao, agregaes, associao
e mensagens. Diferencia padres de frameworks de aplicao, que so esqueletos de classes,
objetos e relacionamentos agrupados para construir aplicaes especficas. Define um padro
orientado a objetos como uma abstrao de uma dupla, tripla ou pequeno agrupamento de classes
que seja til muitas vezes no desenvolvimento orientado a objetos. Apresenta sete desses
padres, explicando-os de forma textual e por meio de uma figura, bem como dando um exemplo
ilustrativo e normas para utiliz-los. No final, d um exemplo de um modelo maior que usa seis
padres.
A figura 2.7 mostra um dos padres apresentados por Coad, o roles-played (papis
desempenhados). Outros de seus padres so mostrados na seo 5.2. Um objeto ator possui
atributos e servios que valem sempre, podendo, s vezes, desempenhar um ou mais papis. Para
cada papel pode haver especializaes, de acordo com os atributos e servios necessrios para
desempenh-lo. No exemplo, pessoa tem os atributos nome e telefone, mas pode, em um certo
instante, desempenhar o papel de cliente ou empregado. No caso de cliente, possui um atributo
extra, desconto, bem como um servio extra, calcular valor desconto. No caso de
empregado, possui um atributo extra, nmero.
Coplien, em [Cop 92], define idiomas e estilos de linguagem como recurso para aumentar
a expressividade de programas em C++e dar ao software uma estrutura melhor e mais eficiente.
Segundo ele, muitas tarefas de programao tornaram-se idiomticas e devem ser incorporadas
naturalmente funcionalidade do C++, dando a iluso de que fazem parte da linguagem.
Caractersticas do C++para obteno de blocos construtivos, como classes e funces-membro,
so largamente utilizadas na definio dos idiomas. A forma cannica ortodoxa um idioma
que define princpios e padres envolvidos no funcionamento de um objeto. Ela faz parte dos
idiomas que fazem com que uma classe se torne um tipo completo, sendo um padro a ser
seguido na implementao de qualquer classe. Um classe nessa forma contm sempre: um
construtor default, que trata da construo da classe quando um objeto definido sem
parmetros; um construtor copy, que cria um objeto baseado em uma cpia do parmetro de
entrada fornecido na chamada; um operador de atribuio, para transferir o contedo de um
objeto para outro objeto; e um destrutor, para liberar os recursos adquiridos pelo objeto durante
sua construo. Esse idioma deve ser usado sempre que objetos de uma classe precisarem ser
atribudos ou passados como parmetros (por valor) de uma funo e o objeto contiver ponteiros
33
para objetos contados por referncia, ou o destrutor da classe precisar executar um delete em
um objeto.
O idioma funo operador de membro usado para converter um tipo declarado pelo
usurio para um tipo nativo do C. O idioma classe manuseador/corpo (handle/body class)
usado para decompor uma abstrao complexa em classes menores e portanto mais fceis de
manusear. O idioma contagem referencial (reference counting) um caso particular desse
ltimo idioma, no qual a classe corpo contm um contador referencial manipulado pela classe
manuseador. Ele til quando so feitas cpias freqentes de um objeto grande ou complexo,
pois permite a cpia lgica, que menos dispendiosa. Outros idiomas so definidos por Coplien,
todos especficos da linguagem C++e num nvel de abstrao baixo como os citados acima.
Figura 2.8 - Diagrama do padro Abstract Factory [Gam 93]
Gamma, em [Gam 93, Gam 95], prope o uso de padres de projeto como um novo
mecanismo para registrar a experincia conseguida com projetos anteriores. Descreve como
expressar padres, sugerindo o uso de um gabarito (template) para estruturar informaes e
garantir uniformidade. Organiza os padres de projeto, categorizando-os em termos de jurisdio
e caracterizao. J urisdio o domnio sobre o qual um padro se aplica, podendo ser classe,
objeto ou composto. Caracterizao diz respeito a o qu o padro faz, podendo ser: padres
criativos, que tratam do processo de criao de objetos; padres estruturais, que lidam com a
composio de classes ou objetos e padres comportamentais, que caracterizam as formas pelas
quais classes ou objetos interagem e distribuem responsabilidade. Introduz um catlogo com
vinte e trs padres de projeto, explicando detalhadamente trs deles: o Abstract Factory, o
Strategy e o Wrapper. Relata sua experincia com padres no projeto e construo de dois
AbstractFactory
MakeProductA()
MakeProductB()
ConcreteFactory1
MakeProductA()
MakeProductB()
ConcreteFactory2
MakeProductA()
MakeProductB()
Return
new ProductA2
Return
new ProductA1
Generic ProductA Generic ProductB
ProductA1 ProductB1 ProductB2 ProductA2
34
sistemas, uma ferramenta de anlise financeira e uma ferramenta de manipulao de restries.
Observa que padres de projeto motivam os desenvolvedores a irem alm dos objetos concretos,
isto , eles objetivam conceitos do domnio do problema que no so to aparentes como objetos.
Comenta a similaridade de seu trabalho com o de Coad [Coa 92], ressaltando que os padres de
Coad so mais prximos da anlise que do projeto, pois surgem naturalmente na modelagem do
sistema. O nico padro que coincide o Broadcast, que o mesmo que seu padro
Observer.
Figura 2.9 - Exemplo do padro Abstract Factory [Gam 93]
A figura 2.8 mostra o diagrama que representa graficamente o padro Abstract
Factory. O diagrama baseado na notao OMT (Object Modeling Technique), qual
acrescentou-se o pseudo-cdigo dos mtodos. A classe AbstractFactory generaliza as
ConcreteFactories, que por sua vez do origem aos produtos especficos. Esses so por sua
vez generalizados pelas classes GenericProducts. A figura 2.9 mostra uma instanciao desse
padro a uma aplicao cuja interface contm janelas e barras de rolagem de dois tipos
diferentes: Motif e Open Look. Nesse caso, deseja-se que o cliente seja independente desses
tipos, isto , que o acesso s classes concretas seja feito apenas pela sua interface genrica (a
classe abstrata).
Vlissides, em [Vli 95], diferencia engenharia reversa de arquitetura reversa, dizendo
que a primeira analisa um sistema de software para recuperar seu projeto, enquanto a segunda
analisa diversos sistemas de software para recuperar projetos repetidos e o raciocnio envolvido
neles. Na verdade, usa arquitetura reversa como um termo mais ousado para o
desenvolvimento de padres de projeto, discutido em [Gam 95]. Mostra, inicialmente, um
Return
new J anelaMotif
Kit-J anela
CrieBarraRolagem()
CrieJ anela()
Kit-J anelaMotif
CrieBarraRolagem()
CrieJ anela()
KitJ anelaOpenWindow
CrieBarraRolagem()
CrieJ anela()
Return
new BarraRolagemOpenLook
J anela BarradeRolagem
J anelaMotif BarraRolagem
Motif
BarraRolagem
OpenWindow
J anelaOpen
Window
35
exemplo de padro de projeto tirado desse livro, mais especificamente o Strategy. Considera
que a reflexo a atividade mais importante na arquitetura reversa. Deve-se reservar um tempo
para refletir sobre os sistemas construdos, os problemas que surgiram e as solues encontradas
para resolv-los (ou no). Tudo deve ser anotado, pois esse ser o material bsico para extrao
de padres. Discute alguns princpios para a escrita de padres, recomendando, tambm, o uso de
um gabarito para uniformizar a estrutura da informao e facilitar a aprendizagem, comparao e
utilizao dos padres de projeto.
Budingsky, em [Bud 96], apresenta uma ferramenta para gerar cdigo automaticamente a
partir de padres de projeto de software, constituda de trs componentes: um apresentador, um
gerador de cdigo e um mdulo para estabelecer correspondncia entre os outros dois. O
apresentador usa pginas semelhantes s da Web para colocar disposio do usurio as
informaes sobre padres de software disponveis em [Gam 95]. O gerador de cdigo produz
fragmentos de cdigo semelhantes aos exemplos de cdigo que ilustram os padres em [Gam
95]. Cabe ao usurio escolher em cada caso de gerao de cdigo, qual alternativa de
implementao deseja adotar entre as mencionadas em [Gam 95], guiando-se pelos trade-offs
l mencionados. Para tornar esta escolha mais prtica, a ferramenta exibe esses trade-offs na
hora da escolha. O mdulo que estabelece correspondncia entre o apresentador e o gerador de
cdigo tem utilidade transparente ao usurio. A ferramenta permite maior flexibilidade para o
usurio de padres, que pode mudar decises de projeto e ter seu cdigo automaticamente
reescrito pela ferramenta, bastando para isso escolher os trade-offs correspondentes. Ao
usurio cabe fornecer informaes especficas da aplicao, de modo que o cdigo gerado seja
coerente com ela. A ferramenta tambm til para que se possa dominar a aplicao de padres
de software dinamizando a necessria experimentao que com eles deve ser realizada.
Gall, em [Gal 96], comenta a aplicao de padres na reengenharia, pela identificao e
utilizao de conceitos reusveis. Explica que o COREM, um mtodo por ele desenvolvido para
reestruturao arquitetural, atualmente requer a interveno de um especialista humano para
fornecer informaes perdidas que no podem ser recuperadas de forma automtica. Entretanto,
diz que est sendo feita uma extenso ao COREM, pela integrao de conceitos de padro ao
longo de alguns passos do processo, para reduzir essa interveno humana. Discute a utilizao
de padres na engenharia de software, em diversos nveis de abstrao, desde a anlise at a
codificao. Utiliza os exemplos de padres apresentados por Coad [Coa 92]. A figura 2.10
mostra as principais atividades no processo do COREM no contexto de camadas de abstrao. A
36
seta contnua representa a engenharia avante, enquanto que a seta pontilhada representa a
engenharia reversa. Gall lembra que o uso de padres orientados a objetos na engenharia avante
tm-se mostrado til e avalia sua adequao melhoria do processo de engenharia reversa. Para
isso, so propostas duas estratgias diferentes: busca por padres orientados a objetos no cdigo
fonte guiada pelos padres e guiada pelo cdigo fonte. A primeira, parte de um certo padro e
vasculha o cdigo, procurando sua ocorrncia. A segunda, parte das estruturas de dados presentes
no cdigo fonte e tenta fazer a correspondncia com padres existentes. Conclui que o
conhecimento semntico da aplicao necessrio, no sendo possvel a automao total. Porm,
uma ferramenta pode auxiliar o engenheiro de software, fazendo as tarefas montonas e
oferecendo uma interface sofisticada para o registro de conhecimento semntico da aplicao.
Figura 2.10 - COREM e tipos de padro bsicos [Gal 96]
Krmer, em [Kra 96], prope a recuperao de projeto pela busca automtica por padres
estruturais de projeto em software orientado a objetos. Afirma que a localizao de padres
estruturais de projeto, como Adapter, Bridge, Composite, Decorator e Proxy
(introduzidos por Gamma [Gam 95]), em software produzido sem uso explcito de padres, pode
melhorar sua manutenibilidade, porque pedaos maiores do software podem ser entendidos como
um todo. Apresenta uma ferramenta, o sistema Pat, que busca por instncias de padres de
projeto em software existente, implementado em C++. Resumidamente, a abordagem cria
representaes em PROLOG tanto dos padres quanto das informaes de projeto extradas do
Correspon-
dncia Modelos Reverso
orientado a objetos
da aplicao
Diagrama de
fluxo de dados
Modelos Progressi-
vo orientado a ob-
jetos da aplicao
Tabela de
modelos de
anlise
orientada a
objetos
Anlise
orientada a
objetos
Diagrama Entidade-
relacionamento
C++
Padres de Aplicao
Padres
de projeto
Padres de
Linguagem
Cdigo
fonte antigo
Cdigo
fonte novo
Requisitos
C
Projeto
orientado a
objetos
37
cdigo-fonte. Ento um motor de inferncia PROLOG faz a busca, necessitando de ps-
processamento manual para remover falsos positivos (instncias ilegtimas). A figura 2.11 mostra
a arquitetura do sistema Pat. Krmer utilizou a ferramenta CASE Paradigm Plus para fazer a
anlise estrutural do cdigo, obtendo nomes de classes, atributos, mtodos e propriedades,
relaes de herana, associao e agregao, embora com algumas limitaes. Avaliou quatro
programas aplicativos, sendo dois sistemas de comunicao e duas bibliotecas de classes
largamente usadas. Comparou os resultados obtidos quanto ao nmero de instncias verdadeiras
e preciso, tendo obtido preciso entre 14 e 50 por cento de padres identificados.
Figura 2.11 - Arquitetura do sistema Pat [Kra 96].
Campo, em [Cam 97], apresenta uma abordagem para engenharia reversa com base no
reconhecimento e visualizao de padres de projeto presentes em um dado framework. Fala das
vantagens do uso de frameworks no aumento de produtividade e qualidade do desenvolvimento
de software. Por outro lado, lembra que, para obter o benefcio mximo do reuso de frameworks,
necessrio entender o projeto interno de suas classes, a colaborao entre elas e a forma pela
qual instncias dessas classes colaboram em tempo de execuo. Esse entendimento uma tarefa
dispendiosa e demorada. Em frameworks complexos, desenvolvem-se estruturas de projeto
flexveis, para possibilitar adaptaes dinmicas. Essa flexibilidade acarreta projetos complexos,
difceis de entender e, consequentemente, difceis de reusar. O objetivo maior dos frameworks
o reuso do conhecimento que o projetista possui sobre o domnio de aplicao. A identificao
de padres de projeto embutidos na estrutura do framework importante para oferecer ao usurio
vises mais abstratas dessa estrutura, no nvel arquitetural. Facilita-se, assim, o reuso, sem
prejuzo do entendimento do programa. A abordagem proposta por Campo baseada no
framework Luthier, para construo de ferramentas para anlise e visualizao de aplicaes.
Diagramas
OMT dos
padres
Cdigo
fonte C++
Padro-para-
PROLOG
Projeto-para-
PROLOG
Anlise
estrutural
Regras PROLOG
Fatos PROLOG
Query
PROLOG
Candidatos
a instncia
de padres
38
Prolog usada na representao das regras para reconhecimento de padres, construo de
visualizaes de padres em potencial e explicaes sobre esses padres, e razes pelas quais
sugere-se sua presena no projeto.
Bosch, em [Bos 97], identifica quatro problemas encontrados na implementao de
padres de projeto usando linguagens de programao orientadas a objeto tradicionais. O
primeiro problema a identificao de padres de projeto no cdigo, pois quase sempre os
padres ficam perdidos durante a implementao, j que as linguagens de programao no
oferecem o conceito correspondente a padro. Assim, os padres ficam espalhados em partes de
um objeto ou mltiplos objetos. O segundo problema o auto-problema. Ele ocorre porque
objetos que j no mais existem podem ser referenciados quando uma mensagem passada
adiante e posteriormente delegada a outros objetos. O terceiro problema a limitao da
reusabilidade, pois a implementao do padro de projeto acaba misturando-o com o domnio de
aplicao, fazendo com que apenas o projeto possa ser reusado. O quarto problema a
sobrecarga de implementao, devido ao grande nmero de mtodos simples gerados, geralmente
com comportamento trivial. Para tentar resolver tais problemas, prope um modelo de objetos
em camadas, chamado LayOM, que uma linguagem orientada a objetos estendida. LayOM
permite a representao explcita de padres de projeto na linguagem de programao. Ilustra
como um padro de projeto pode ser implementado por camadas que encapsulam o objeto, de
forma que mensagens enviadas ou recebidas pelo objeto tenham que passar por essas camadas.
Essa abordagem aplicada a oito dos padres de projeto catalogados por Gamma [Gam 95].
Fowler, em [Fow 97], apresenta setenta e seis padres de anlise que refletem estruturas
conceituais de processos de negcios, ao invs de implementaes reais de software. Define
padro como uma idia que tem sido til em um contexto prtico e que provavelmente ser til
em outros. Diz que um padro, mesmo que ainda no tenha sido escrito, tem quatro partes
essenciais: o estabelecimento do contexto no qual ele til; o problema por ele endereado;
as foras que regem a formao da soluo; e a soluo que soluciona aquelas foras. Seus
padres so baseados em sua experincia pessoal de aplicao de modelagem orientada a objetos
a grandes sistemas de informao corporativos. Entre os padres por ele apresentados esto: o
Accountability, que define responsabilidades entre partes, como por exemplo contratos formais
ou informais; o Observation, para lidar com informaes qualitativas dos objetos; o
Measurement, para lidar com informaes quantitativas dos objetos; o Inventory e o Accounting,
que descrevem como uma rede de contas e regras de lanamento podem formar um sistema de
39
contabilidade; o Plan, para o planejamento e uso de recursos; o Contract e o Portfolio, para lidar
com comrcio de recursos, entre outros.
Martin, em [Mar 98], rene os melhores artigos sobre padres apresentados nas
conferncias PLop96 e EuroPLop96. Nesta seo alguns deles so resumidos. Segundo Martin,
os padres devem ser lidos, entendidos e incorporados ao modelo mental de projeto dos
desenvolvedores, para ento poderem ser utilizados quando um software especfico estiver sendo
projetado. Ressalta-se a importncia de saber aplicar o padro correto e de maneira correta, j
que os padres tm finalidade especfica e muitas vezes confundida por seus usurios. So
discutidos padres em diversos nveis de abstrao, desde os padres de padro, padres de
processo, padres arquiteturais e padres de anlise, at os padres de projeto e padres de
programao. Os padres de padro apresentam heursticas sobre a forma de apresentar padres.
Os padres de processo fornecem recomendaes sobre como conduzir as vrias fases de
desenvolvimento de software. Os padres arquiteturais definem propriedades globais do sistema,
ajudando na especificao da estrutura fundamental de um sistema de software. Os padres de
anlise e de projeto encontram-se distribudos em diversos sub-tipos, como os padres de
persistncia, padres de distribuio, padres de domnio especfico, padres de interface com o
usurio e padres de uso geral. Os padres de programao descrevem solues para problemas
especficos de programao, tornando o cdigo mais claro de entender, adaptar e modificar. Esse
trabalho refora a idia de que ainda existem muitos padres a serem descobertos, por exemplo
nos casos de padres de interface com o usurio e padres de distribuio.
J ohnson, em [J oh 98], descreve o padro Type-Object, mostrando sua aplicao a dois
sistemas: uma videolocadora e uma fbrica. Fornece o cdigo fonte em Smalltalk referente
implementao desses exemplos particulares, no qual pode-se entender o relacionamento entre as
classes que formam o padro. J ohnson apresenta diversas variaes na aplicao do padro,
como por exemplo o uso de Type-Objects aninhados ou recursivos, em que pode-se ver a
flexibilidade desse padro. Por outro lado, comenta as conseqncias de seu uso, como por
exemplo o aumento da complexidade do projeto e implementao e a gesto de referncias. O
padro Type-Object descrito na seo 5.2.
Boyd, em [Boy 98], descreve padres para representar a associao entre objetos em
sistemas de negcios. So eles: o padro Association-Object, o padro Customer Contact e o
padro 3-Level Order. O primeiro, descrito na seo 5.2, comumente encontrado em sistemas
de informao, j que representa algo que acontece em um ponto especfico do tempo associando
40
dois outros objetos. O segundo uma variao do primeiro, sendo uma associao mais
especfica entre um negcio e um cliente, porm envolvendo uma terceira classe, que
responsvel por controlar os diversos contatos feitos com o cliente e estabelecer regras de
contato. O terceiro uma srie de associaes de objetos, com uma estrutura para separ-los em
grupos de responsabilidades.
Figura 2.12 - Diagrama de Interao dos Padres [Yod 98]
Yoder, em [Yod 98], apresenta dez padres usados na implementao de objetos de
negcios, de forma que possam ser mapeados para bases de dados no orientadas a objetos. Esses
padres tentam amenizar a diferena existente entre objetos, que representam tanto dados quanto
comportamento, e bases de dados relacionais, que consistem de tabelas e relacionamentos. O
padro Persistence Layer fornece uma camada para fazer a correspondncia entre os objetos e
a base de dados. Essa camada o centro de interao com os demais padres, isolando o
desenvolvedor dos detalhes de armazenagem e recuperao de objetos. O padro CRUD
fornece as operaes bsicas utilizadas na persistncia de objetos, a saber: Create, para criar o
novo objeto na base de dados; Read, para ler objetos da base de dados; Update, para atualizar os
dados do objeto na base de dados; e Delete, para eliminar um objeto da base de dados. So
sugeridas tambm duas outras operaes que podem ser necessrias: LoadAllLike, para carregar
pode usar
cria
manipula mudanas
por meio de
fornece
conecta-se por
meio de
obtm nome de
tabelas com
manipula
transaes com
Attribute Mapping
Methods
OID
Manager
Transaction
Manager
Table
Manager
Connection
Manager
SQL Code
Description
Change
Manager
CRUD
Type
Conversion
Persistence
Layer
usa
mapeia
valores com
gera chaves
com
obtm nome de
tabelas com
41
todos os objetos que satisfazem uma dada condio e LoadAll, para carregar todos os objetos de
uma classe. O padro SQL Code Description usado para construir as chamadas SQL para a
base de dados. O padro Attribute Mapping Methods faz a correspondncia entre os valores na
base de dados e os atributos da classe e vice-versa. O padro Type conversion faz a
transformao de valores da base de dados para o tipo correspondente no objeto e vice-versa,
assegurando a integridade dos dados. O padro Change Manager acompanha as mudanas
efetuadas nos valores dos objetos para que fiquem consistentes com a base de dados. Ele
determina a necessidade de escrever ou no os valores para a base de dados. O padro OID
Manager gera chaves nicas para identificar os objetos durante uma insero. O padro
Transaction Manager fornece um mecanismo para manipular transaes ao salvar objetos. O
padro Connection Manager estabelece e mantm a conexo com a base de dados. O padro
Table Manager gerencia o mapeamento entre um objeto e suas tabelas e colunas na base de
dados. O diagrama da figura 2.12 mostra a interao entre esses dez padres, que juntos
estabelecem um mecanismo para mapear objetos persistentes para uma base de dados.
2.5.3 - Concluses
Os padres de projeto desempenham diversos papis no processo de desenvolvimento
orientado a objetos. Primeiro, eles fornecem ao projeto um vocabulrio comum. Segundo, eles
reduzem a complexidade do sistema, nomeando e definindo abstraes. Terceiro, eles constituem
uma base de experincia para construo de software reutilizvel. Por ltimo, eles atuam como
blocos construtivos a partir dos quais projetos mais complexos podem ser construdos [Gam 93].
Os padres de projeto documentam uma parte repetida de um projeto orientado a objetos
de forma que permitem seu entendimento e aplicao em um contexto particular. Com os
padres, pode-se discutir o projeto em um nvel de abstrao maior do que classes e objetos.
Assim, as informaes sobre o projeto podem ser divulgadas de forma mais rpida e precisa,
facilitando tanto o processo de projeto quanto a documentao [Vli 95].
2.6 - Consideraes Finais
42
Como os tpicos de interesse, conforme mencionado em 2.1, so intimamente inter-
relacionados, muitos trabalhos poderiam figurar em mais de uma das sees deste captulo. A
deciso de coloc-los numa certa seo foi subjetiva e determinada, no pelo assunto considerado
predominante pelo autor, mas pelo maior interesse apresentado, de acordo com os objetivos deste
trabalho mencionados em 1.3.
O entendimento de programas foi investigado exaustivamente, por ser de grande
importncia para a engenharia reversa de sistemas legados. A engenharia reversa foi bastante
explorada, porm considerou-se predominantemente o apoio fornecido pelo trabalho recente de
Penteado [Pen 96]. Na reengenharia foi dado enfoque especial a trabalhos que visavam
mudana de paradigma para orientao a objetos. Padres foram explorados de forma intensa,
principalmente visando descoberta de padres orientados a objetos a partir da engenharia
reversa de sistemas legados.
Apesar de no ter sido dado destaque em separado ao Reuso de Software, ele foi uma
preocupao sempre presente no contexto dos tpicos de interesse. O reuso uma das aplicaes
tanto de entendimento de programas, quanto de engenharia reversa e padres de software,
conforme destacado nas respectivas sees.
A reviso bibliogrfica evidenciou a importncia de padres para melhoria de qualidade e
produtividade das atividades de manuteno e reuso de software. Mostrou tambm sua
atualidade, havendo muitos trabalhos recentes enfocando esse assunto.
43
CAPTULO 3 Engenharia Reversa
Diante dos conhecimentos obtidos com o estudo da bibliografia mencionada no captulo
2, neste captulo d-se uma idia das pesquisas que desenvolvemos na rea de engenharia
reversa. Essas pesquisas referem-se sobretudo extenso da aplicao do Fusion/RE [Pen 96] ao
domnio de sistemas de informao. Seus resultados foram objeto do relatrio tcnico [Bra 98a],
de parte da seo 3 de [Pen 98 a] e da seo 3 de [Pen 98b]. Note-se que as aplicaes anteriores
[Pen 96a, Pen 96b] foram feitas a uma ferramenta chamada STATSIM para edio e simulao
de statecharts desenvolvida em linguagem C, que no pertence ao domnio de sistemas de
informao. Assim, na seo 3.2 feito um resumo do Fusion/RE. Na seo 3.3 apresentado o
detalhamento do processo de abstrao originalmente descrito em [Bra 98a]. Na seo 3.4
mostrado o estudo de caso no qual feita a aplicao da metodologia descrita nas sees 3.2 e
3.3 a um sistema legado do domnio de sistemas de informao. Na seo 3.5 so feitas as
consideraes finais deste captulo.
3.2 Um Resumo do Fusion/RE
O Fusion/RE [Pen 96a] um processo geral para efetuar engenharia reversa orientada a
objetos, tomando-se como ponto de partida sistemas desenvolvidos com orientao
procedimental, j citado no captulo 2. A figura 3.1 mostra o esquema do Fusion/RE e a seguir
seus quatro passos so descritos resumidamente, pois em [Pen95, Pen96] encontram-se mais
detalhes dos mesmos.
O primeiro passo da abordagem consiste na revitalizao da arquitetura do sistema com
base na documentao existente ou no cdigo fonte, caso no exista. Ao final desse passo, tem-se
uma lista de todos os procedimentos, com sua descrio e hierarquia de chamadas
(chama/chamado por).
O segundo passo tem por objetivo recuperar o Modelo de Anlise do Sistema Atual
(MASA). Nele elabora-se um pseudo Modelo de Objetos do sistema, identificando-se as classes
e seus relacionamentos, bem como seus atributos e procedimentos associados.
44
Figura 3.1 - Esquema do Fusion/RE
Observa-se que a maioria dos procedimentos do sistema legado contm anomalias, ou
seja, um mesmo procedimento lida com vrias classes. Para classificar os procedimentos, adota-
se a conveno: (c) para construtor, quando o procedimento altera a estrutura de dados e (o) para
observador, quando o procedimento somente consulta a estrutura de dados. Quando um
procedimento consulta e altera uma mesma classe ele classificado somente como (c). O sinal de
+associado s siglas (c) e/ou (o), representa que o procedimento consulta e/ou observa duas ou
45
mais estruturas de dados. Desse modo, os procedimentos anmalos podem ser classificados
como (oc), (o+c), (oc+) e (o+c+). Os procedimentos so classificados como (i) quando referem-
se ao tipo de implementao utilizada.
Aps a criao do modelo de objetos pode-se, opcionalmente, elaborar os cenrios. As
entradas e sadas do sistema necessitam de agentes para manipul-las e, sendo assim, deve-se
identificar esses agentes, observando-se o funcionamento do sistema e criando-se os cenrios.
Um cenrio uma seqncia de eventos fluindo entre agentes e o sistema com algum propsito.
Cada cenrio envolve agentes, as tarefas que eles querem que o sistema faa e a seqncia de
comunicao envolvida para que sejam feitas essas tarefas. Os cenrios auxiliam na elaborao
do Modelo de Ciclo de Vida e do Modelo de Operaes.
A seguir, define-se o Modelo de Ciclo de Vida do sistema, que retrata o seu
comportamento global, preocupando-se com a ordem cronolgica em que as operaes so
realizadas. Estas servem como base para a construo do Modelo de Operaes do Sistema, no
qual cada operao descrita de forma minuciosa, de acordo com um gabarito preestabelecido.
Na verdade, trata-se de um pseudo-modelo orientado a objetos, pois no atende s restries da
orientao a objetos.
O terceiro passo visa 1a criao do Modelo de Anlise do Sistema (MAS), dando
enfoque ao domnio da aplicao e no implementao. Os modelos de Objetos, de Ciclo de
Vida e de Operaes so abstrados daqueles construdos anteriormente, com alguns cuidados
adicionais, como por exemplo a mudana de nomes para outros mais significativos,
generalizao e especializao de classes. Os procedimentos sem anomalias geram mtodos
diretamente, enquanto os com anomalias devem ser desmembrados em diversos mtodos, de
modo que cada mtodo interaja com apenas uma classe.
O quarto passo faz o mapeamento do Modelo de Anlise do Sistema para o Modelo de
Anlise do Sistema Atual, descrevendo a relao entre eles. So mapeadas as classes, atributos e
mtodos do MAS para os elementos correspondentes do MASA, anotando-se possveis
incluses/excluses. Esse passo importante na futura manuteno e reuso do sistema, caso s se
faa a engenharia reversa.
Portanto, ao final do Fusion/RE dispe-se de um Modelo de Anlise do Sistema orientado
a objetos que pode ser utilizado na reengenharia do sistema, seja para mudana de linguagem,
seja para mudana do paradigma de implementao ou seja ainda para aperfeioamento da
funcionalidade.
46
3.3 Sobre a abstrao do Modelo de Anlise do Sistema
No Fusion/RE, aps a execuo dos passos 1 e 2, feita a abstrao do Modelo de
Anlise do Sistema, baseada no Modelo de Anlise do Sistema Atual. Muitas dificuldades
podem surgir ao fazer essa abstrao de forma direta. O detalhamento desse passo de abstrao
foi sugerido para contornar essas dificuldades [Bra 98a] e ilustrado na figura 3.2. Considera-se
que o Modelo de Objetos do Sistema Atual (MOSA) foi construdo na fase 2 do Fusion/RE e est
disponvel durante o processo de detalhamento.
Figura 3.2 - Processo de Transio do MASA para o MAS
Inicialmente feita a abstrao do Modelo de Objetos do Sistema. Essa abstrao feita
em seis etapas, produzindo diversos modelos intermedirios, denominados MOS-1 a MOS-
6.
Na primeira etapa elaborado o MOS-1. Os pseudo-relacionamentos existentes no
MOSA so transformados em relacionamentos, removendo-se os atributos das classes cujo nico
objetivo era fazer o relacionamento entre tabelas, ou seja, as chaves estrangeiras so removidas.
Na segunda etapa elaborado o MOS-2. Nele, algumas tabelas do MOSA so
transformadas em relacionamentos. Classes do MOS-1 que no contm atributos, ou que contm
apenas um atributo fraco, podem ser transformadas em relacionamentos. Considera-se como
atributo fraco aquele que no identifica unicamente o objeto da classe, podendo ser repetido em
diversos objetos. Tais classes so tipicamente tabelas do MOSA com duas chaves estrangeiras e
nenhum ou apenas um atributo. Outra caracterstica marcante dessas classes que cada uma das
chaves estrangeiras faz a ligao da classe com outra classe por intermdio de um
MASA
Modelo de Objetos -
MOSA
Modelo de Ciclo de
Vida - MCVSA
Modelo de Operaes -
MOpSA
MAS
Modelos de Objetos
MOS-1 a MOS-6
Modelo de Ciclo de
Vida - MCVS
Modelo de Operaes
MOpS
47
relacionamento com cardinalidade muitos para um. No caso de haver um atributo na classe
sendo eliminada, o relacionamento dever carreg-lo.
Na terceira etapa elaborado o MOS-3. Nessa etapa so identificadas as agregaes e
especializaes de classes. Agregaes podem ser criadas sempre que uma classe englobar
outras. Especializaes podem ser criadas para isolar em uma superclasse os atributos e mtodos
comuns a diversas subclasses.
Na quarta etapa elaborado o MOS-4. Nele acrescentam-se as entradas mais relevantes e
os agentes externos que interagem com o sistema, estabelecendo seus limites.
Na quinta etapa elaborado o MOS-5, que mostra as sadas do sistema, bem como os
agentes externos que as manuseiam.
Na sexta etapa elaborado o MOS-6, no qual so generalizados os nomes de classes,
atributos e relacionamentos referentes ao MOS-4 e MOS-5. O objetivo dar nomes mais
significativos, de acordo com o domnio de aplicao.
Vale observar que essas etapas so mais apropriadas para sistemas desenvolvidos com
bases de dados relacionais, podendo ser modificadas ou condensadas dependendo da aplicao.
Aps a abstrao do Modelo de Objetos do Sistema deve ser feita a abstrao dos
Modelos de Ciclo de Vida e de Operaes. No caso do Modelo de Ciclo de Vida, faz-se a
mudana de nomes para outros mais significativos. Tambm podem ser efetuadas mudanas na
seqncia em que as operaes so invocadas ou no seu agrupamento dentro do ciclo de vida do
sistema. No caso do Modelo de Operaes, os esquemas devem ser revistos de maneira a
referenciar as classes do MOS ao invs do MOSA. Os nomes de atributos e operaes tambm
devem ser adaptados de acordo com os novos modelos de objetos e de ciclo de vida.
3.4 Estudo de Caso
O sistema utilizado como exemplo neste trabalho foi originalmente desenvolvido na
linguagem Clipper 5.0, possuindo aproximadamente vinte mil linhas de cdigo. Possui vinte e
cinco tabelas do tipo dbf, relacionadas por chaves estrangeiras.
Trata-se de um sistema real de Oficina Auto-eltrica e Mecnica que controla os servios
executados em uma oficina de veculos, fazendo tambm o controle de estoque das peas
utilizadas e do seu ressuprimento. O cliente vai at a oficina para solicitar a realizao de
servios em seu veculo, sendo que um cliente pode ter diversos veculos. O mesmo veculo pode
48
voltar oficina diversas vezes, sendo preparada, em cada uma delas, uma Ordem de Servio
distinta. Essa Ordem de Servio contm os dados do cliente, do veculo e dos reparos a serem
feitos.
Quando o veculo consertado, a Ordem de Servio completada, registrando-se as
peas utilizadas e a mo-de-obra executada. Muitas vezes o reparo pode exigir peas no
existentes no estoque, que so adquiridas fora da oficina mecnica e tambm fazem parte da
Ordem de Servio. O registro dessas peas importante para o gerente da oficina, pois elas so
candidatas a serem estocadas no futuro. Os possveis tipos de veculos devem ser cadastrados
pelo sistema, pois so utilizadas tabelas para cobrana de servios, tanto eltricos como
mecnicos, de acordo com o tipo de veculo. A venda de peas em estoque diretamente no balco
tambm realizada, sendo que nesse caso no aberta nenhuma ordem de servio.
FABRICAN
TEMPREP
TIPOVEIC CLIENTES CLIVEIC
CODMOBRA
CONTAREC
OSPECAS VENDAS
PECAS ITEMVEND
ORDSERV OSMOBRA
EMPREGAD
OUTPECAS
VEICOMP
PECACOMP COMPONEN
VEIPECA
FORNEC COMPRAS
CONTAPAG
TIPORAMO
RAMOFORN
ITEMCOMP
49
Figura 3.3 - Diagrama da Base de Dados.
3.4.1 - Recuperao da arquitetura do sistema legado
O sistema em questo j possua uma documentao razovel [Oli 91], constituda da
descrio detalhada da base de dados, da relao chama/chamado por e de um manual do
usurio [Bra 90]. A figura 3.3 mostra o diagrama entidade-relao da base de dados, que foi
usado no desenvolvimento do sistema legado.
A figura 3.4 ilustra a documentao complementar do diagrama, detalhando, para cada
arquivo, seus campos com as respectivas caractersticas, seus ndices e os programas que com ele
interagem. Na figura esto mostrados os detalhes do arquivo ORDSERV, que pode ser visto na
parte superior da figura 3.3.
A figura 3.5 mostra um dos mdulos que fazem parte da relao chama/chamado por,
na qual para cada mdulo existente no sistema h uma descrio de sua funcionalidade, os
arquivos lidos e/ou alterados, as rotinas chamadas e as rotinas que o chamam. No caso
especfico, refere-se ao mdulo OSTELA1, que consta na parte inferior da figura 3.4 como um
dos programas que alteram o arquivo ORDSERV. Note-se que essa interao de OSTELA1
com ORDSERV tambm est indicada na figura 3.5, em que ORDSERV indicado como
um dos arquivos lidos e/ou alterados pelo mdulo OSTELA1.
A figura 3.6 contm um trecho do cdigo fonte, em Clipper, do mdulo OSTELA1,
com cada linha numerada para futuras referncias. Algumas linhas pouco significativas para a
lgica do programa foram omitidas, tendo sido colocadas reticncias em seu lugar.
A figura 3.7 mostra parte dos menus do sistema legado, nos quais est indicado, direita,
o nome do mdulo que executado quando cada opo do menu selecionada. Por exemplo,
OSTELA1 executado quando as opes 1-Lanamento, 1-Ordem de Servio e 1-
Lanamentos 1 parte so selecionadas em seqncia.
Ao realizar a revitalizao da arquitetura do sistema legado, correspondente ao primeiro
passo do Fusion/RE, notou-se que essa documentao no estava atualizada. Por exemplo, na
figura 3.5 consta como rotina chamada por OSTELA1 apenas LOGOTIPO. Mas, na figura
3.6 nota-se que outras rotinas, tais como AVISO (linhas 29, 47, 80 e 99), BUSCLI (linha 28)
e IMPOS1 (linha 104), tambm so chamadas. Outra falha encontrada foi com relao aos
arquivos CONTAPAG e CONTAREC, que constam da figura 3.3, mas o cdigo fonte faz
50
referncia apenas a um arquivo CONTAS, que sequer consta do diagrama da base de dados. Os
arquivos VTREP e EQUIVPEC no constam do diagrama da figura 3.3, embora sejam
importantes na funcionalidade do sistema e constem da descrio de arquivos. Alm disso, os
nomes de arquivos, procedimentos, campos e ndices muitas vezes so pouco significativos, ora
por problemas de limitao do Clipper, ora por descuido do programador.
+======================================+
| ESTRUTURA DO ARQUIVO ORDSERV .dbf |
+======================================+
ORDEM DE SERVIO
+-------------------------------------------------------------------------+
| Nro | Nome do | Tipo | Nro de | Descrio |
| Campo | Campo | do Campo | Caract.| |
+=========================================================================+
| 1 | OSNRO | NUMERICO | 5 | NUMERO DA ORDEM DE SERVICO |
| 2 | DATAENTRA | DATA | 8 | DATA DE ENTRADA DA ORD. SERVICO |
| 3 | DATACOMPRA | DATA | 8 | DATA DA COMPRA DAS PECAS P/GAR. |
| 4 | CODCLIENTE | NUMERICO | 5,0 | CODIGO DO CLIENTE |
| 5 | NROVEICULO | NUMERICO | 4,0 | NUMERO DO VEICULO DO CLIENTE |
| 6 | SERVAEX1 | CARACTER | 60 | SERVICOS A EXECUTAR - PARTE 1 |
| 9 | ORCAMENTO | CARACTER | 1 | INDICADOR DO ORCAMENTO (S/N) |
| 10 | DATAPROM | DATA | 8 | DATA PROMETIDA PARA ENTREGA |
| 11 | HORAPROM | DATA | 8 | HORA PROMETIDA PARA ENTREGA |
| 12 | CONDPAG | CARACTER | 15 | CONDICOES DE PAGAMENTO |
| 13 | PRECOTOT | NUMERICO | 11,2 | PRECO TOTAL COBRADO |
| 14 | DESCONTO | NUMERICO | 11,2 | DESCONTO CONCEDIDO |
| 15 | DESPEXTRA | NUMERICO | 11,2 | DESPESAS.EXTRAS INCLUSAS |
+-------------------------------------------------------------------------+
ARQUIVOS DE INDICE
CLIORDSE.ntx --> CODCLIENTE
ORDSERV .ntx --> OSNRO
Programas que o leem:
ALTCAREC ELICAREC INDEXACA INSCAREC QUITCARE
Programas que o alteram:
OSTELA1 OSTELA2
Figura 3.4 - Descrio de um dos arquivos da base de dados.
Com base na metodologia resumida nas sees 3.2 e 3.3 e usando esse sistema legado, foi
conduzida a engenharia reversa cujos passos so descritos a seguir.
--------------------------------------------------------------------------
Mdulo Fsico: OSTELA1
Descrio: PRIMEIRA TELA DA ORDEM DE SERVICO
Arquivos apenas lidos:
Arquivos lidos e/ou alterados: CLIENTES CLIVEIC ORDSERV TIPOVEIC
Rotinas chamadas: LOGOTIPO
Rotinas que o chamam: LANCAMEN
51
Figura 3.5 - Descrio de um dos mdulos do sistema, com a relao chama/chamado por.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
* Nome do programa: OSTELA1.PRG
DO LOGOTIPO
SELECT 2
USE ORDSERV INDEX CLIORDSE, ORDSERV
SELECT 6
USE CLIENTES INDEX CODCLI, NOMECLI
SELECT 7
USE CLIVEIC INDEX CLICODVE
SELECT 8
USE TIPOVEIC INDEX CODVEIC, MARCVEI,
MARCTIP
SELECT 2
SET ORDER TO 2
GO BOTTOM
gravou=.f.
codcli =" "
nrov =0
imp =" "
nrord =OSNRO +1
dtent =DATE()
mv =SPACE(15)
tv =SPACE(30)
@ 6, 15 SAY "Lancamento da 1a. Parte da Ordem de
Servico"
@ 7, 15 SAY '"""""""""" "" """ """"" "" """"" "" """""""'
@ 9, 5 SAY "Data de Entrada:"
@ 9, 22 GET dtent PICTURE "@E"
@ 9, 48 SAY "O.S.Nro:"
@ 9, 56 SAY nrord PICTURE[99999]
@ 10, 5 SAY "Codigo do Cliente:"
@ 10, 24 GET codcli PICTURE [99999] when buscli()
DO AVISO WITH " <99999>- Cliente nao Cadastrado
<0>Abandonar"
READ
codcli=val(codcli)
IF lastkey()#27 .and. codcli <>0
nro_os=nrord
SELECT CLIENTES
SET ORDER TO 1
SEEK codcli
IF .NOT. FOUND()
GO BOTTOM
codcli =CODCLIENTE +1
dtmov =DATE()
APPEND BLANK
REPLACE CODCLIENTE WITH codcli
REPLACE DATAMOV WITH dtmov
DO AVISO WITH "Digite os Dados do Novo Cliente"
novo ="S"
ELSE
DO AVISO WITH "Verifique os Dados do Cliente,
Modificando se Necessario"
novo ="N"
ENDIF
ok ="N"
DO WHILE ok ="N"
@ 11, 5 SAY "Cliente:"
IF novo ="S"
@ 11, 14 GET NOME PICTURE REPL ("!",30)
ELSE
@ 11, 14 SAY NOME PICTURE REPL ("!",30)
ENDIF
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
@ 12, 5 SAY "Endereco:"
@ 12, 15 GET ENDERECO PICT REPL ("!",30)
@ 12, 53 SAY "Bairro:"
@ 12, 62 GET BAIRRO PICTURE REPL ("!",15)
. . .
@ 14, 30 SAY "Servicos a Executar"
@ 15, 30 SAY '"""""""" " """"""""'
serv1 =SPACE(60)
serv2 =SPACE(60)
serv3 =SPACE(60)
orcam =" "
dtpro =CTOD(" / / ")
horapro =SPACE(5)
@ 17, 7 GET serv1 PICTURE REPLICATE ("!",60)
@ 20, 7 SAY "Orcamento (S/N) :"
@ 20, 26 GET orcam PICT [!] VALID orcam $ "SN"
@ 21, 7 SAY "Prometido para as horas"
@ 21, 23 GET dtpro PICT "@E" VALID dtpro>=dtent
@ 21, 37 GET horapro PICTURE [!!!!!]
READ
grava =" "
DO AVISO WITH ga
cl =COLUNA(ga)
@ 24, cl GET grava PICT [!] VALID grava $ "GA"
READ
IF grava ="G"
. . .
SELECT ordserv
APPEND BLANK
REPLACE OSNRO WITH nrord
REPLACE DATAENTRA WITH dtent
REPLACE CODCLIENTE WITH codcli
REPLACE NROVEICULO WITH nrov
REPLACE SERVAEX1 WITH serv1
REPLACE ORCAMENTO WITH orcam
REPLACE DATAPROM WITH dtpro
REPLACE HORAPROM WITH horapro
gravou=.t.
men ="Imprime 1a. Parte da Ordem de Servico?
(S/N) ===> <>"
DO AVISO WITH men
cl =COLUNA(men)
@ 24, cl GET imp PICTURE [!] VALID imp $ "SN"
READ
IF imp ="S"
DO IMPOS1
ENDIF
ENDIF
ENDIF
ENDIF
CLOSE DATABASES
RETURN
52
Figura 3.6 - Trecho de um programa Clipper do sistema legado
Figura 3.7 - Parte dos menus do sistema legado
3.4.2 - Obteno do Modelo de Anlise do Sistema Atual
Apesar dos defeitos constatados na documentao existente do sistema legado, com base
nos resultados do passo de revitalizao da arquitetura, foi possvel construir o Modelo de
Objetos do Sistema Atual (MOSA) mostrado na figura 3.8. Pode-se observar que todas as tabelas
presentes no diagrama da base de dados da figura 3.3 foram transformadas em classes no MOSA
da figura 3.8. Os relacionamentos entre as classes tambm foram mantidos. Foram acrescentados
1-LANAMENTOS {LANCAMEN}
===============
1-ORDEM DE SERVIO {MENUOS}
1-LANAMENTO 1 PARTE {OSTELA1}
2-LANAMENTO 2 PARTE {OSTELA2}
3-LANAMENTO TOTAL {OSTELA}
4-MODIFICAO 1 PARTE {MODOS1}
5-MODIFICAO 2 PARTE {MODOS2}
6-CANCELAMENTO DA O.S. {CANCELOS}
2-COMPRAS {MENUCOM}
1-PEDIDO DE PEAS {MENUPP}
1-INSERO {INSEPEPE}
2-MODIFICAO {ALTPEPE}
3-ELIMINAO {ELIPEPE}
2-COMPRAS DE PEAS {MENUCE}
1-INSERO {INSECE}
2-MODIFICAO {ALTPCE}
3-ELIMINAO {ELICE}
3-VENDAS DE PEAS POR BALCO {MENUVEND}
1-INSERO {INSECVE}
2-MODIFICAO {ALTCVE}
3-ELIMINAO {ELICVE}
4-CONTAS A PAGAR {CONTASPA}
1-INSERO {INSCAPAG}
2-MODIFICAO {ALTCAPAG}
3-ELIMINAO {ELICAPAG}
4-QUITAO {QUITCAPG}
5-CONTAS A RECEBER {CONTASPA}
1-INSERO {INSCAREC}
2-MODIFICAO {ALTCAREC}
3-ELIMINAO {ELICAREC}
4-QUITAO {QUITCARE}
53
ao MOSA as classes que estavam faltando no diagrama da figura 3.3, VTREP e EQUIVPEC,
conforme explicado na seo 3.4.1.
54
Figura 3.8 - MOSA Modelo de Objetos do MASA
*
*
rel-21
*
rel-23
1
rel-6
rel-10
*
1
1
rel-19 *
1
* rel-15
1
1 *
rel-18
1
rrel-12
rel-11
rel-13
rel-14
*
1
1
*
*
*
rel-30
1
1
1
rel-26
*
rel-29
1
rel-25
1
*
*
*
*
*
1
*
0..1
*
1
rel-8
*
1
rel-5
* 1
rel-7
*
rel-9
*
1
*
1
1
*
*
*
*
rel-20
* *
1 1
rel-34
*
1
rel-31
rel-28
0..1
rel-4
*
rel-22
*
1
1
rel-33
*
1
*
* 1
1
*
rel-27
1
*
rel-3
rel-2
Ordserv
osnro
codcliente
nroveiculo
dataentra
Clientes
codcliente
nome
Cliveic
codcliente
nroveiculo
codveiculo
placa
Ospecas
osnro
codbarra
codoutpeca
quantidade
precotot
Osmobra
osnro
codmobra
codemp
preco
Empregad
codemp
nome
1
Tipoveic
codveiculo
marca
tipo
Outpecas
codoutpeca
descricao
codfabric
custounit
Pecas
codbarra
descricao
codfabric
eletmec
custounit
qtest
Contarec
osnro
nrovenda
datavenc
parcela
valor
Vendas
nrovenda
codcliente
codempreg
data
Itemvend
nrovenda
codbarra
quantidade
precounit
rel-24
rel-32
Fabrican
codfabric
nome
rel-1
Codmobra
codmobra
descricao
Componen
componente
descricao
Compras
nrocompra
nropedido
codfornec
dataped
datacomp
situacao
Itemcomp
nrocompra
codbarra
quantidade
precounit
Fornec
codfornec
nome
Ramoforn
codfornec
codramo
Contapag
numero
datavenc
parcela
valor
Temprep
codmobra
codveiculo
tempo
Vtrep
codmobra
codveiculo
quantvt
Pecacomp
componente
codpeca
*
rel-16
*
*
rel-17
Veicomp
componente
veiculo
Veipeca
codbarra
veiculo
Tiporamo
codramo
descricao
Equivpeca
codpeca1
codpeca2
55
Ao invs da notao do mtodo Fusion, preconizada em [Col 94], os Modelos de Objetos
so aqui representados utilizando a notao UML (Unified Modeling Language) [Eri 98, Fow
98], que plenamente compatvel. Vale observar que, na UML, o modelo equivalente ao Modelo
de Objetos denominado Diagrama de Classes. A UML foi adotada por suportar a
representao de padres de software, que necessria no captulo 5.
Alguns acrscimos de notao foram feitos. Entre esses pode-se mencionar o uso de
linhas tracejadas para denotar os pseudo-relacionamentos, o uso de palavras sublinhadas para
denotar atributos que so chaves estrangeiras e o uso de palavras em negrito para denotar
atributos que so chave primria da classe. Por exemplo, Ordserv tem o pseudo-
relacionamento rel-29 com Ospecas, devido existncia da chave estrangeira osnro em
Ospecas. Por motivos de falta de espao, foram colocados nas classes apenas os atributos mais
significativos. Por exemplo, dos quinze campos do arquivo ORDSERV que constam da figura
3.4, apenas quatro atributos constam na classe Ordserv da figura 3.8. Maiores detalhes dessa
obteno do MASA podem ser encontrados em [Bra 98a]. Note-se que l usada a prpria
notao do Fusion.
Figura 3.9 - Parte do MASA e Procedimentos do Sistema Legado
56
Terminada a construo do MOSA, possvel analisar alguns procedimentos do sistema
legado a fim de detectar a ocorrncia de anomalias, conforme descrito na seo 3.2. A figura 3.9
ilustra dois procedimentos do sistema legado, Ostela1 (P1) e Altveic (P2), classificados
respectivamente como c+e c, nos quais pode-se observar claramente a ocorrncia de anomalias
em P1, j que ele l e/ou altera quatro classes. No trecho de cdigo mostrado na figura 3.6
possvel constatar algumas dessas anomalias, como por exemplo a alterao da classe Clientes
(linhas 41 a 43).
lifecycle Auto-eltrico e Mecnica:=(Lanamentos | Relatrios | Consultas |
Manuteno_de_arquivos | Manuteno_de_tabelas | Impressos )*
Lanamentos =(lancamento_prim_parte . [#Ordem_Servio_impressa]) |
(lanamento_seg_parte . [#Relat_servios_executados]) |
modificao_prim_parte | modificao_seg_parte | cancelamento_os |
insero_pedido | modificao_pedido | eliminao_pedido |
insero_compra | modificao_compra | eliminao_compra |
insero_vendas | modificao_vendas | eliminao_vendas |
insero_conta_a_pagar | alterao_conta_a_pagar |
eliminao_conta_a_pagar | quitao_conta_a_pagar |
insero_conta_a_receber | alterao_conta_a_receber |
eliminao_conta_a_receber | quitao_conta_a_receber)
Relatrios =(rel_ord_serv_pendentes | rel_ord_serv_do_ms | rel_pecas_estoque_critico
| rel_pecas_em_estoque | rel_precos_por_fabricante | rel_equivalencia_entre_pecas
| rel_pecas_por_componente | rel_pecas_adquiridas_fora | rel_pedidos_pendentes
| rel_pedidos_pendentes_por_fornecedor | rel_compras_ms | rel_itens_cancelados
| rel_vendas_ms | rel_contas_a_pagar | rel_contas_a_receber | rel_balanco_mensal
| rel_cliente_ord_alfabet | rel_cliente_por_entidade | rel_fornecedor_ord_alfabet
| rel_fornecedor_por_ramo | rel_fabricante | rel_empregado | rel_componentes
| rel_veiculos | rel_mao_de_obra | tabela_sugestao_precos
| tabela_servicos_eletricos | tabela_servicos_mecaNicos)
Consulta =( cons_peca_letra_inicial | cons_peca_fabricante | cons_peca_codigo_barras |
cons_peca_codigo_original | cons_equivalencia_peca | cons_estatistica_custos |
cons_fornecedores | cons_vendas | cons_empregados | cons_compras |
cons_componentes | cons_clientes )
Manuteno_de_arquivos =( insero_pecas | alterao_pecas | eliminao_peas |
insero_fornecedores | alterao_fornecedores | eliminao_fornecedores |
insero_empregados | alterao_empregados | eliminao_empregados |
insero_clientes | alterao_clientes | eliminao_clientes |
insero_fabricantes | alterao_fabricantes | eliminao_fabricantes |
insero_componentes | alterao_componentes | eliminao_componentes |
insero_mo_de_obra | alterao_mo_de_obra | eliminao_mo_de_obra |
insero_veculos | alterao_veculos | eliminao_veculos )
Manuteno_de_tabelas =(tabela_sugesto_de_preos | insero_tabela_valor_trabalho |
alterao_tabela_valor_trabalho | eliminao_tabela_valor_trabalho |
insero_tabela_tempo_reparo | alterao_tabela_tempo_reparo )
eliminao_tabela_tempo_reparo)
Impressos = (cheques | duplicatas | ord_servico | termo_garantia
| recibo| cancelamento_protestos | carta_cancelamento | vales
| etiq_cod_barra_por_fornecedor | etiq_cod_barra_por_peca
| etiq_cod_barra_por_compra | etiq_cod_barra_pecas_miudas | etiq_por_estantes
| etiq_clientes | etiq_pessoa_juridica | etiq_pessoa_fisica | etiq_cli_por_entidade
| etiq_clientes_desejados | etiq_clientes_duplicatas | etiq_fornecedores )
Figura 3.10 - MCVSA - Modelo de Ciclo de Vida do Sistema Atual
57
Na figura 3.10 mostrado o Modelo de Ciclo de Vida do Sistema Atual (MCVSA),
obtido com base nos menus do sistema legado e no cdigo fonte. Comparando a figura 3.7 com a
figura 3.10, pode-se observar que a opo 1-Lanamento da figura 3.7 deu origem ao smbolo
no-terminal Lanamentos da figura 3.10. Qualquer uma das opes de lanamento pode ser
executada a qualquer momento dentro do ciclo de vida do sistema. Assim, foram criadas
operaes representando cada uma dessas opes, sendo permitida a execuo de qualquer uma
delas por meio de um | (operador ou).
Na figura 3.11 mostrado um dos esquemas do Modelo de Operaes do Sistema Atual
(MOpSA), correspondente ao lanamento da primeira parte da ordem de servio. A elaborao
desses esquemas baseou-se no cdigo fonte do sistema legado e tambm na execuo da opo
correspondente operao nos menus do sistema legado. Por exemplo, na figura 3.6 um
programador Clipper poderia facilmente reconhecer os trechos referentes gerao do nmero
nico de ordem de servio (linhas 10 a 12 e 17) e criao de um novo cliente (linhas 34 a 43),
que so tarefas especificadas na clusula Result do esquema da figura 3.11. Esquemas para
outras operaes podem ser encontrados em [Bra 98a].
Operation : lanamento_prim_parte
Description : "Faz o lanamento da primeira parte da Ordem de Servio "
Reads : Supplied : Data_entr : char , Orcam : int , Serv_a_exec : char ,
Dt_entrega : char , Hora_entrega : char
Changes : new cli : Clientes,
new os : Ordserv ,
new veic : Cliveic
new mod : Tipoveic
Sends : Oficina {Ordem_de_Servio_Impressa }
Result : " Uma new os foi criada
Um nmero nico de os foi gerado
os.dataentra foi iniciada com Data_entr
os.orcamen foi iniciada com Orcam
os.servex1 foi iniciada com Serv_a_executar
os.dataprom foi iniciada com Dt_entrega
os.horaprom foi iniciada com Hora_entrega
Se o cliente ainda no estava cadastrado
ento um new cli foi criado
Se era a primeira vez que o veiculo estava sendo consertado
ento um new veic foi criado
Ordem_de_Servio_Impressa (Ordem de Servio) foi enviada oficina
Se o modelo de veculo ainda no estava cadastrado
ento um new mod foi criado"
Figura 3.11 - Esquema para a operao lancamento_prim_parte do MOpSA
58
3.4.3 - Abstrao do Modelo de Anlise do Sistema
O passo de abstrao do MAS foi feito utilizando o processo de detalhamento proposto
em [Bra 98a] e descrito na seo 3.3, ao invs do processo recomendado em [Pen 96a]. As
diversas etapas da abstrao efetuada so mostradas a seguir, englobando as transies do MOSA
para o MOS, do MCVSA para o MCVS e do MOpSA para o MOpS.
Na figura 3.12 mostrado o MOS-1, obtido na primeira etapa, no qual os pseudo-
relacionamentos existentes no MOSA da figura 3.8 foram transformados em relacionamentos,
removendo-se os atributos das classes cujo nico objetivo era fazer o relacionamento entre elas.
Por exemplo, da classe Cliveic foram removidos os atributos codcliente e codveiculo, cuja
funo era relacion-la s classes Clientes e Tipoveic, respectivamente. Dessa forma, os
pseudo-relacionamentos entre elas (rel-1 e rel-4), que eram denotados por linhas tracejadas,
tornaram-se relacionamentos, denotados por linhas contnuas.
Na segunda etapa do processo de detalhamento, diversas classes foram eliminadas, alm
de modificar os relacionamentos existentes. A figura 3.13 mostra o MOS-2 obtido. As
classes Ramoforn, Pecacomp, Veipeca e Veicomp, que aparecem na figura 3.12, foram
eliminadas de forma direta. O fato delas terem ficado sem atributo algum aps a primeira etapa
forneceu a indicao de que sua utilidade era apenas de ligao entre duas outras classes. As
classes Temprep e Vtrep foram analisadas cuidadosamente por possurem apenas um
atributo. Como esse atributo no identifica unicamente um elemento da classe, ele pde ser
transferido para o relacionamento resultante entre Tipoveic e Codmobra. Isso representado
no modelo da figura 3.13 pelos rtulos junto classe Codmobra com os nomes desses atributos
(tempo e quantvt, respectivamente).
A classe Equivpec foi eliminada com base no conhecimento sobre o domnio da
aplicao. O arquivo do MOSA Equivpec possui atributos codpeca1 e codpeca2 (ver
figura 3.8). Estudando o problema em questo e os procedimentos responsveis por alimentar
esse arquivo, deduz-se que esses atributos representam um auto-relacionamento da classe
Pecas, indicando que a pea cujo cdigo codpeca1 equivalente pea cujo cdigo
codpeca2. Adotou-se a conveno de dar o prprio nome da classe sendo excluda ao
relacionamento resultante aps sua excluso.
Na terceira etapa do processo de detalhamento foram criadas agregaes envolvendo as
classes Ordserv, Ospecas e Osmobra, as classes Vendas e Itemvend e as classes
59
Compras e Itemcomp. A figura 3.14 mostra o MOS-3 obtido nessa etapa. Duas
especializaes foram identificadas: nas classes Peas e Outpecas, originando a superclasse
Pea e nas classes Contarec e Contapag, originando a superclasse Conta. Os atributos
comuns s subclasses foram devidamente transferidos para a superclasse recm criada.
*
*
rel-21
*
rel-23
1
rel-6
rel-10
*
1
1
rel-19 *
1
* rel-15
1
1 *
rel-18
1
rrel-12
rel-11
rel-13
rel-14
*
1
1
*
*
*
rel-30
1
1
1
rel-26
*
rel-29
1
rel-25
1
*
*
*
*
*
1
*
0..1
*
1
rel-8
*
1
rel-5
* 1
rel-7
*
rel-9
*
1
*
1
1
*
*
*
*
rel-20
* *
1 1
rel-34
*
1
rel-31
rel-28
0..1
rel-4
*
rel-22
*
1
1
rel-33
*
1
*
* 1
1
*
rel-27
1
*
rel-3
rel-2
Ordserv
osnro
dataentra
Clientes
codcliente
nome
Cliveic
nroveiculo
placa
Ospecas
quantidade
precotot
Osmobra
preco
Empregad
codemp
nome
1
Tipoveic
codveiculo
marca
tipo
Outpecas
codoutpeca
descricao
custounit
Pecas
codbarra
descricao
eletmec
custounit
qtest
Contarec
datavenc
parcela
valor
Vendas
nrovenda
data
Itemvend
quantidade
precounit
rel-24
rel-32
Fabrican
codfabric
nome
rel-1
Codmobra
codmobra
descricao
Componen
componente
descricao
Compras
nrocompra
nropedido
dataped
datacomp
situacao
Itemcomp
quantidade
precounit
Fornec
codfornec
nome
Ramoforn
Contapag
datavenc
parcela
valor
Temprep
tempo
Vtrep
quantvt
Pecacomp
*
rel-16
*
*
rel-17
Veicomp
Veipeca
Tiporamo
codramo
descricao
Equivpeca
60
Figura 3.12 - MOS-1 Modelo de Objetos do MAS Etapa 1
* *
veipeca
veicomp
*
*
* *
equivpec
*
rel-23
1
rel-6
1
* *
vtrep
temprep
*
rel-30
1
1
1
rel-26
*
rel-29
1
rel-25
1
*
*
*
*
*
1
*
0..1
*
1
rel-8
*
1
rel-5
* 1
rel-7
*
ramoforn
*
*
*
1
1
* pecacomp
*
rel-34
* 1
rel-31
rel-28
0..1
rel-4
*
rel-22
*
1
1
rel-33
*
1
*
* 1
1
*
rel-27
1
*
rel-3
rel-2
Ordserv
osnro
dataentra
Clientes
codcliente
nome
Cliveic
nroveiculo
placa
Ospecas
quantidade
precotot
Osmobra
preco
Empregad
codemp
nome
1
Tipoveic
codveiculo
marca
tipo
Outpecas
codoutpeca
descricao
custounit
Pecas
codbarra
descricao
eletmec
custounit
qtest
Contarec
datavenc
parcela
valor
Vendas
nrovenda
data
Itemvend
quantidade
precounit
rel-24
rel-32
Fabrican
codfabric
nome
rel-1
Codmobra
codmobra
descricao
Componen
componente
descricao
Compras
nrocompra
nropedido
dataped
datacomp
situacao
Itemcomp
quantidade
precounit
Fornec
codfornec
nome
Contapag
datavenc
parcela
valor
Tiporamo
codramo
descricao
quantvt tempo
61
62
*
*
*
*
*
1
*
0..1
*
*
1 1
rel-8
rel-8a
*
1
rel-5
1 0..1
refere-se a
*
*
1
1
rel-7a
rel-7
*
*
ramoforn
*
*
*
*
*
*
veicomp
*
veipeca
*
*
pecacomp
* *
*
*
temprep
rel-34
vtrep
*
1
rel-31
rel-28
0..1
equivpec
*
*
1
rel-4
*
rel-23
* 1
1
rel-33
*
1
*
* 1
1
* rel-26
1
*
rel-3
rel-2
Ordserv
osnro
dataentra
Cliente
cocliente
nome
Cliveic
nroveiculo
placa
Ospecas
quantidade
precotot
Osmobra
preco
Peca
descricao
custounit
precovenda
Empregad
codemp
nome
1
Tipoveic
codveic
marca
tipo
Outpecas
Cdigo
Pecas
codbarra
qtest
Conta
datavenc
parcela
valor
Vendas
nrovenda
data
Itemvend
quantidade
precounit
rel-24
rel-1
Contarec
Contapag
Fabrican
codfabric
nome
rel-1
Codmobra
codmobra
descricao
Componen
componente
descricao
Pedido
nropedido
data
situao
Itens do pedido
quantidade
precounit
Compra
nrocompra
data
valor
Itemcomp
quantidade
precounit
Fornec
codfornec
nome
Ramo
codramo
descrico
quantvt tempo
63
Durante a elaborao do MOS-3 percebeu-se que a classe Compras, do MOS-2,
englobava tambm os pedidos feitos ao fornecedor. Assim, resolveu-se acrescentar mais uma
classe ao MOS-3 que cobrisse esse aspecto, denominada Pedido. Foi tambm necessrio
acrescentar a classe Itens do pedido para tratar dos itens constantes do pedido. Os atributos que
antes constavam da classe Compras foram distribuidos entre as classes resultantes, Compra e
Pedido, de acordo com seu significado semntico. Isso pode ser observado comparando-se a
figura 3.13 com a figura 3.14. Nota-se tambm que foi acrescentado o relacionamento refere-se
a entre Compra e Pedido, j que a compra feita aps o pedido ter sido atendido pelo
fornecedor. Outros detalhes importantes tiveram que ser cuidados, por meio de minucioso exame
do cdigo fonte. Por exemplo, ao fazer a especializao deve-se examinar os relacionamentos
das subclasses com as demais classes, para descobrir se eles devem ser mantidos na subclasse ou
se podem ser transferidos para a superclasse. Assim, os relacionamentos rel-26 e rel-27 do
MOS-2 puderam ser fundidos no relacionamento rel-26 do MOS-3, j que peas trocadas na
ordem de servio podem ser tanto as adquiridas fora quanto as em estoque. Da mesma forma os
relacionamentos rel-22 e rel-23 do MOS-2 puderam ser fundidos no relacionamento rel-23
do MOS-3, j que ambos os tipos de pea possuem fabricante. J os relacionamentos rel-24 e
rel-8 foram mantidos ligados classe Pecas, pois peas vendidas no balco ou compradas do
fornecedor referem-se somente s peas em estoque.
Na quarta etapa do processo de detalhamento foi criado o MOS-4, mostrado na figura
3.15. Nele foram acrescentadas algumas entradas mais relevantes do sistema e os agentes
externos que com ele interagem, estabelecendo seus limites. Esses agentes so o atendente e o
gerente da empresa. O atendente necessrio porque o sistema no do tipo self-service.
Existe um atendente intermedirio, que faz os lanamentos no computador e recebe alguns
relatrios de sada. Outros relatrios mais sofisticados so entregues ao gerente, que os analisa e
toma suas decises. Como existem muitas operaes nesse sistema, foram explicitadas apenas as
mais relevantes. Por exemplo, conveniente explicitar o papel do atendente de abrir e fechar
uma ordem de servio. Todavia, ao surgir um novo tipo de veculo haveria necessidade de incluir
tempo de reparo e/ou valor de trabalho correspondente, o que seria feito pelo gerente. O mesmo
aconteceria quando aparecesse um fornecedor novo, um empregado novo, etc. Operaes desse
tipo no foram modeladas.
64
*
*
*
*
*
1
*
0..1
*
*
1 1
rel-8
rel-8a
*
1
rel-5
1 0..1
refere-se a
*
*
1
1
rel-7a
rel-7
*
*
ramoforn
*
*
*
*
*
*
veicomp
*
veipeca
*
*
pecacomp
* *
*
*
temprep
rel-34
vtrep
*
1
rel-31
rel-28
0..1
equivpec
*
*
1
rel-4
*
rel-23
* 1
1
rel-33
*
1
*
* 1
1
* rel-26
1
*
rel-3
rel-2
Ordserv
osnro
dataentra
Cliente
cocliente
nome
Cliveic
nroveiculo
placa
Ospecas
quantidade
precotot
Osmobra
preco
Peca
descricao
custounit
precovenda
Empregad
codemp
nome
1
Tipoveic
codveic
marca
tipo
Outpecas
Cdigo
Pecas
codbarra
qtest
Conta
datavenc
parcela
valor
Vendas
nrovenda
data
Itemvend
quantidade
precounit
rel-24
rel-1
Contarec
Contapag
Fabrican
codfabric
nome
rel-1
Codmobra
codmobra
descricao
Componen
componente
descricao
Pedido
nropedido
data
situao
Itens do pedido
quantidade
precounit
Compra
nrocompra
data
valor
Itemcomp
quantidade
precounit
Fornec
codfornec
nome
Ramo
codramo
descrico
quantvt tempo
:Atendente
:Atendente
:Atendente
:Gerente
:Atendente
lana
abre/fecha
lana
faz
quita
faz
65
Na quinta etapa do processo de detalhamento foi elaborado o MOS-5, mostrado na figura
3.16. Esse modelo mostra algumas sadas do sistema, bem como os agentes externos que as
manuseiam. Por exemplo, o gerente acompanha o relatrio de ordens de servios pendentes e o
relatrio de peas com estoque crtico, o atendente utiliza a relao de clientes e o mecnico
recebe a ordem de servio impressa. Como pode ser visto na figura 3.10 existem inmeros
relatrios e impressos nesse sistema que dariam origem a classes no modelo de objetos.
Entretanto, por motivos de falta de espao, apenas alguns deles foram colocados no modelo,
principalmente os mais significativos para o sistema.
Na sexta etapa do processo de detalhamento os nomes de classes, atributos e
relacionamentos foram mudados para outros mais significativos dentro do domnio de aplicao.
Foram tambm acrescentados alguns atributos s classes que tinham sido ignorados nos modelos
anteriores por questes prticas. O resultado dessas etapas est presente nos modelos
apresentados nas figuras 3.17 e 3.18, que juntos formam o Modelo de Objetos do Sistema
(MOS).
*
* *
1
Clientes
Ordserv
Cliveic
Peca
rel-1
rel-3
1
*
*
Relao de Pecas
Em ordem
alfabtica
Por cdigo de
barras
Por localizao
Por fabricante
Estoque crtico
Relatrio de Ordens
de servio
pendentes
:Gerente
usa
usa
*
*
Ordemde servio
impressa
usa
*
*
:Mecnico
Relao de Clientes
Em ordem
alfabtica
Por entidade
:Atendente
usa
*
acompanha
enviada a
utiliza
acompanha
66
*
*
*
*
*
1
*
0..1
*
*
1 1
uma
uma
*
1
gera
1 0..1
refere-se a
*
*
1
1
feito a
feita a
*
*
trabalha com
*
*
*
*
*
*
adapta-se a
*
adapta-se a
*
*
faz parte do
* *
*
*
temvalor
de trabalho
de acordo
com
feitopor
temtempo
de reparo de
acordo com
*
1
obedece
executadapor
0..1
equivalente a
*
*
1
de um
*
feitapor
* 1
1
gera
*
1
*
* 1
1
* uma
1
*
atendidopor
procura
Ordemde Servio
Nro da Ordem Serv.
Data de entrada doveic.
Defeitos apresentados
Preo total
Data de sada doveic.
Cliente
Cdigo
Nome
Endereo
Telefone
RG/ins.est.
DataNascto
Veculo de cliente
Nro sequencial
Placa
Pea da Ordemde Serv.
Quantidade
Preo
Mo-de-obra da
Ordemde Serv.
Preo
Pea
Descrio
Custo unitrio
Preo de venda
Empregado
Cdigo
Nome
Endereo
Especialidade
1
Tipo de veculo
Cdigo
Marca
Tipo
Pea adquirida fora
Cdigo
Local da compra
Pea do estoque
Cdigo de barra
Qtde emestoque
Localizao
Conta
Data de vencimento
Nro da parcela
Valor
Nro do cheque
Situao
Atendimentopor balco
Nro do Atendimento
Data
Valor Total
Pea vendida
Quantidade
Preo Unitrio
uma
gera
Conta a Receber
Duplicata emitida?
Nro da duplicata
Conta a Pagar
Fabricante
Cdigo
Nome
possui
Tipo de mo-de-obra
Cdigo
Descrio da mo-de-obra
Componente
Cdigo
Descrio
Pedido
Nro do Pedido
Data
Situao
Pea pedida
Quantidade
Preo unitrio
Compra
Nro da Compra
Data
Valor total
Nome do vendedor
Valor do ICMC
Pea comprada
Quantidade
Preo unitrio
Desconto unitrio
Fornecedor
Cdigo
Nome
Fax
Nome do vendedor
Ramo
Cdigo
Descrio
:Atendente
:Atendente
:Atendente
:Gerente
:Atendente
lana
abre/fecha
lana
faz
quita
faz
tempo quantvt
Figura 3.17 - MOS-6a Modelo de Objetos do MAS Etapa 6 Parte A
67
Figura 3.18 - MOS-6b Modelo de Objetos do MAS Etapa 6 Parte B
Para comprovar essa melhoria de nomes obtida no MOS-6, pode-se consultar a tabela 3.1,
apresentada na seo 3.4.4, que faz a correspondncia entre as classes do MAS e os arquivos do
MASA. A tabela 3.2 mostra alguns nomes de atributos que tambm foram alterados. Vale
ressaltar que algumas classes e relacionamentos foram includos nos modelos com o nome
definitivo, visto que quando da sua incluso j se conhecia mais sobre o domnio de aplicao.
Terminada a construo do MOS, o cdigo fonte dos procedimentos com anomalias
detectadas no passo dois pode ser analisado de forma a identificar os mtodos de cada classe que
seriam necessrios para resolver essas anomalias. A figura 3.19 mostra parte do MAS e os vinte e
quatro mtodos identificados na operao Ostela1. Esses mtodos foram identificados
examinando o cdigo fonte da operao do sistema legado e subdividindo em mtodos os trechos
que possuem anomalias. Cada mtodo atribudo classe qual faz referncia, como pode ser
observado na figura 3.19. Cabe ressaltar que, nessa etapa, os mtodos so apenas identificados,
mas no feita a separao fsica do cdigo. Essa separao cuidada durante a reengenharia
com mudana de orientao, que vista na seo 4.2.
*
* *
1
Cliente
Ordemde
Servio
Veculo de
Cliente
Pea do
estoque
possui
atendido
por
1
*
*
Relao de Pecas
Em ordem
alfabtica
Por cdigo de
barras
Por localizao
Por fabricante
Estoque crtico
Relatrio de Ordens
de servio
pendentes
:Gerente
usa
usa
*
*
Ordemde servio
impressa
usa
*
*
:Mecnico
Relao de Clientes
Em ordem
alfabtica
Por entidade
:Atendente
usa
*
acompanha
enviada a
utiliza
acompanha
68
Figura 3.19 - Parte do MAS e mtodos correspondentes
Para completar a elaborao do MAS, os Modelos de Ciclo de Vida e de Operaes
foram abstrados a partir dos respectivos modelos do MASA. A figura 3.20 mostra o Modelo de
Ciclo de Vida do MAS (MCVS) e a figura 3.21 mostra um dos esquemas do Modelo de
Operaes do MAS (MOpS), mais especificamente para a operao Abre_Ordem_de_Servio.
Comparando o MCVSA (figura 3.10) ao MCVS (figura 3.20), nota-se que os nomes das
operaes foram substitudos por outros mais significativos e as operaes foram agrupadas de
forma diferente, de modo que possam ser encontradas com mais facilidade de acordo com seu
significado semntico. Quanto ao Modelo de Operaes do MAS, foi feita a adaptao dos
nomes e atributos das classes de acordo com o novo Modelo de Objetos, preservando a
funcionalidade e interface do sistema. Exemplos da correspondncia entre o MAS e o MASA
podem ser vistos na seo 3.4.4.
69
Figura 3.20 - MCVS - Modelo de Ciclo de Vida do Sistema
3.4.4 - Mapeamento MAS/MASA
Graas ao nvel de detalhamento com que foi feita a transio do MASA para o MAS, a
realizao deste passo foi facilitada. Sua finalidade, conforme explicado na seo 3.2,
estabelecer a correspondncia entre o Modelo de Anlise do Sistema, que considera
principalmente o domnio de aplicao e no a implementao fsica atual e o Modelo de Anlise
do Sistema Atual, feito com base na estrutura de dados do sistema legado. Essa correspondncia
importante, pois no caso de no ser conduzida a reengenharia do sistema, ela ser utilizada
durante o processo de manuteno.
lifecycle Auto-eltrico e Mecnica:=
(Lanamento | Atualizao_arquivos | Impresso | Consulta )*
Lanamento =(abre_ordem_de_servio . [#Ordem_Servio_impressa]) | modifica_ord_serv |
elimina_ord_serv | (fecha_ordem_de_servio . [#Relat_servios_executados]) |
insere_atendimento_balco | altera_atendimento_balco | elimina_atendimento_balco
| insere_compra | altera_compra |elimina_compra | insere_pedido | altera_pedido |
elimina_pedido |insere_conta_a_pagar | insere_conta_a_receber |
altera_conta_a_pagar | altera_conta_a_receber | elimina_conta_a_pagar |
elimina_conta_a_receber | quita_conta_a_pagar | quita_conta_a_receber )
Atualizao_arquivos =( insere_peca | insere_cliente | insere_fabricante | insere_fornecedor |
insere_empregado | insere_tipo_veiculo | insere_valor_de_trabalho |
insere_tempo_de_reparo | insere_componente | insere_mao_de_obra |
altera_peca | altera_cliente | altera_fabricante | altera_fornecedor |altera_empregado |
altera_tipo_veiculo | altera_valor_de_trabalho | altera_tempo_de_reparo |
altera_componente | altera_mao_de_obra |elimina_peca | elimina_cliente |
elimina_fabricante | elimina_fornecedor | elimina_empregado | elimina_tipo_veiculo |
elimina_valor_de_trabalho | elimina_tempo_de_reparo | elimina_componente |
elimina_mao_de_obra | atualiza_tabela_sugestao_de_precos )
Impresso =(rel_ord_serv_pendentes | rel_ord_serv_do_ms | rel_pecas_estoque_critico
| rel_pecas_em_estoque | rel_precos_por_fabricante | rel_equivalencia_entre_pecas
| rel_pecas_por_componente | rel_pecas_adquiridas_fora | rel_pedidos_pendentes
| rel_pedidos_pendentes_por_fornecedor | rel_compras_ms | rel_itens_cancelados
| rel_vendas_ms | rel_contas_a_pagar | rel_contas_a_receber | rel_balanco_mensal
| rel_cliente_ord_alfabet | rel_cliente_por_entidade | rel_fornecedor_ord_alfabet
| rel_fornecedor_por_ramo | rel_fabricante | rel_empregado | rel_componentes
| rel_veiculos | rel_mao_de_obra | rel_sugestao_precos | rel_servicos_eletricos
| rel_servicos_mecanicos | cheques | duplicatas | ord_servico | termo_garantia
| recibo| cancelamento_protestos | carta_cancelamento | vales
| etiq_cod_barra_por_fornecedor | etiq_cod_barra_por_peca
| etiq_cod_barra_por_compra | etiq_cod_barra_pecas_miudas | etiq_por_estantes
| etiq_clientes | etiq_pessoa_juridica | etiq_pessoa_fisica | etiq_cli_por_entidade
| etiq_clientes_desejados | etiq_clientes_duplicatas | etiq_fornecedores )
Consulta =( cons_peca_letra_inicial | cons_peca_fabricante | cons_peca_codigo_barras |
cons_peca_codigo_original | cons_equivalencia_peca | cons_estatistica_custos |
cons_fornecedores | cons_vendas | cons_empregados | cons_compras |
cons_componentes | cons_clientes )
70
Operation : abre_ordem_de_servio
Description : " D entrada em uma ordem de servio "
Reads : Supplied : Data_entr : char , Orcam : int , Serv_a_exec : char ,
Dt_entrega : char , Hora_entrega : char
Changes : new cli : Cliente,
new os : Ordem de Servio ,
new veic : Veculo de Cliente
new mod : Tipo de Veculo
Sends : Oficina {Ordem_de_Servio_Impressa }
Result : " Uma new os foi criada
Um nmero nico de os foi gerado
os.Data Entrada foi iniciada com Data_entr
os.Oramento foi iniciada com Orcam
os.Servios a executar foi iniciada com Serv_a_executar
os.Data Entrega foi iniciada com Dt_entrega
os.Hora Entrega foi iniciada com Hora_entrega
Se o cliente ainda no estava cadastrado
ento um new cli foi criado
Se era a primeira vez que o veiculo estava sendo consertado
ento um new veic foi criado
Ordem_de_Servio_Impressa (Ordem de Servio) foi enviada oficina
Se o modelo de veculo ainda no estava cadastrado
ento um new mod foi criado"
Figura 3.21 - Esquema para a operao abre_ordem_de_servio do MOpS
A tabela 3.1 indica a correspondncia entre as classes do MOS e os arquivos do sistema
legado. Nela pode-se perceber os arquivos eliminados durante a abstrao, bem como as classes
includas durante a mesma. O processo de detalhamento efetuado com base em [Bra 98a] permite
que se saiba exatamente em que etapas foram eliminados ou includos cada um dos componentes
do MOS.
A tabela 3.2 mostra a correspondncia entre o MAS e o MASA para as classes Veculo de
Cliente e Ordem de Servio e seus atributos. Pode-se observar nessa tabela os atributos
eliminados durante a abstrao, mais especificamente durante a etapa 1 do processo de
detalhamento.
A tabela 3.3 mostra a correspondncia entre algumas operaes do MAS e do MASA.
Nesse caso, houve apenas uma melhora nos nomes das operaes. No houve incluso ou
excluso de operaes, pois a funcionalidade do sistema foi mantida.
71
Tabela 3.1 Correspondncia entre classe do MAS e arquivos do MASA
Classe do MAS Arquivo do
MASA
Atendimento por balco
Cliente
Componente
Compra
Conta
Conta a Pagar
Conta a Receber
Empregado
Fabricante
Fornecedor
Mo-de-obra da Ordem de Serv.
Ordem de Servio
Pea
Pea adquirida fora
Pea comprada
Pea da Ordem de Serv.
Pea do estoque
Pea pedida
Pea vendida
Pedido
Ramo
Tipo de mo-de-obra
Tipo de veculo
Veculo de cliente
-
-
-
-
-
-
-
Vendas
Contarec
Componen
Compras
-
Contapag
Contarec
Empregad
Fabrican
Fornec
Osmobra
Ordserv
-
Outpecas
Itemcomp
Ospecas
Pecas
-
Itemvend
-
Ramo
Codmobra
Tipoveic
Cliveic
Equivpec
Pecacomp
Ramoforn
Temprep
Veipeca
Veicomp
Vtrep
3.5 Consideraes Finais
A aplicao do Fusion/RE ao domnio de sistemas de informao mostrou que nesse
domnio h algumas facilidades, quanto engenharia reversa dos dados, decorrentes
principalmente do uso de tabelas normalizadas no sistema legado. Por outro lado, quanto aos
procedimentos, a abstrao dos mtodos foi facilitada, j que o sistema legado foi desenvolvido
em uma linguagem de nvel mais alto.
O detalhamento do passo de abstrao torna mais ameno o uso do Fusion/RE, que
anteriormente exigia um salto maior entre o passo de elaborao do Modelo de Anlise do
Sistema Atual e o do Modelo de Anlise do Sistema.
72
Tabela 3.2 Correspondncia entre classes/atributos do MAS e arquivos/campos do MASA
MAS MASA
Modelo de Objetos
Classe: Veculo de Cliente
Arquivo
Cliveic
Atributos Campos do Arquivo
-
-
Placa
Cidade
Quilometragem
Nro de meses
Nro sequencial
codcliente
codveiculo
placa
cidade
hskm
meses
nroveiculo
Modelo de Objetos
Classe: Ordem de Servio
Arquivo
Ordserv
Atributos Campos do Arquivo
Nro da Ordem Serv.
-
-
Data de entrada do veic.
Defeitos apresentados
Preo total
Data de sada do veic.
osnro
codcliente
nroveiculo
dataentra
servaex1, servaex2, servaex3
precotot
datacompra
Tabela 3.3 Correspondncia entre algumas operaes do MAS e do MASA
MAS MASA
Abre_Ordem_de_Servio
Fecha_Ordem_Serv
Insere_Compra
Insere_pea
Insere_pedido
Altera_pedido
Elimina_pedido
Lanamento_prim_parte
Lanamento_seg_parte
Insero_compra
Insero_pea
Insero_pedido
Alterao_pedido
Eliminao_pedido
Conforme se ver nos prximos captulos, essa engenharia reversa efetuada bsica tanto
para a reengenharia, descrita no captulo 4, quanto para o reconhecimento de padres, feito no
captulo 5.
73
Captulo 4 Reengenharia
A engenharia reversa por si s j traz grandes benefcios quanto manutenibilidade do
sistema, j que so criados modelos em nveis mais altos de abstrao. Porm, para que esses
benefcios possam ser plenamente usufrudos, o cdigo fonte do sistema deve ser compatvel
com os modelos de anlise e projeto. Isso pode ser conseguido de duas formas: por segmentao
do sistema legado, mantendo a linguagem de programao original, ou por reengenharia com
mudana de linguagem. A primeira alternativa discutida na seo 4.2, na qual feita a
reengenharia com mudana de orientao e sem mudana de linguagem. A segunda alternativa
apresentada na seo 4.3, na qual a reengenharia com mudana de linguagem, pressupondo que a
de mudana de orientao j tenha sido feita, discutida. Na seo 4.4 apresentam-se as
consideraes finais deste captulo.
4.2 Reengenharia com mudana de orientao e sem mudana de linguagem
4.2.1 Abordagem proposta
Nesta seo prope-se uma abordagem para transformar cdigo originalmente orientado a
procedimentos para cdigo com as caractersticas da orientao a objetos. A linguagem de
programao mantida durante essa transformao. Essa abordagem foi tratada em [Pen 98a] e
ilustrada na figura 4.1. Aps a obteno dos modelos de anlise pelo Fusion/RE, dois passos
adicionais so executados: o projeto avante do sistema e a segmentao dos programas, descritos
a seguir.
No primeiro passo adicional elaborado o projeto avante do sistema, visando
reengenharia com mudana do paradigma de implementao, mas sem mudar a funcionalidade
do sistema. Nele so elaborados: o Grafo de Interao de Objetos, o Grafo de Visibilidade, a
Descrio de Classes e os Grafos de Herana.
74
Figura 4.1 - Abordagem proposta para reengenharia com mudana de orientao
O Grafo de Interao de Objetos construdo com base no Modelo de Operaes. Ele
mostra a passagem de mensagens entre os objetos, por intermdio dos mtodos, alm de
diferenciar entre a classe controladora da operao e as classes colaboradoras. Um pseudo-cdigo
escrito para o mtodo da classe controladora da operao, mostrando sua lgica e a seqncia
de chamada dos mtodos das classes colaboradoras. Note-se que o mtodo da classe controladora
(que implementa uma operao) interage com mais de um objeto, porm o faz por intermdio dos
mtodos das classes colaboradoras, com o que so evitadas as anomalias.
O Grafo de Visibilidade estabelece a comunicao entre as classes, delimitando quais
delas podem trocar mensagens e os tipos de mensagens a serem trocadas. Nos grafos de interao
de objetos assume-se que todos os objetos so mutuamente visveis, podendo trocar mensagens
entre si, o que restringido no Grafo de Visibilidade.
A Descrio de Classes contm documentao complementar ao modelo de objetos do
sistema. Assim, para cada classe so reunidas informaes que estavam espalhadas pelos vrios
elementos de documentao at agora produzidos. Do Grafo de Interao de Objetos so
retirados os mtodos; do Modelo de Objetos so extrados alguns atributos de dados e do Grafo
75
de Visibilidade os atributos objeto-valorados. So salientadas, para cada classe, todas as
interaes com as demais.
Os Grafos de Herana so um mecanismo pelo qual uma classe pode ser definida como
uma especializao de outra. Podem ser introduzidas novas classes nesta etapa.
Os procedimentos com anomalias podem agora ser examinados. O resultado desse exame
vai nortear a realizao do passo seguinte.
No segundo passo adicional feita a segmentao do sistema. Programas originalmente
monolticos e contendo anomalias so aqui desmembrados em mtodos, conforme definido nos
grafos de interao de objetos. Os programas so percorridos seqencialmente, identificando-se
os trechos relacionados a uma das classes identificadas no passo 3 do Fusion/RE. Quanto
maiores esses trechos, mais fcil ser a segmentao. Esses trechos sero a base para construo
de cada mtodo, devendo ser substitudos, no programa que corresponde operao, por uma
chamada de procedimento ou funo. Os mtodos obtidos devem ficar disponveis para serem
chamados pela operao. O ideal que sejam mtodos da classe correspondente, mas se a
linguagem de programao no suportar esse conceito, devero estar disponveis por outros
meios.
importante ressaltar que a segmentao do programa feita considerando o projeto do
sistema, desenvolvido no passo de projeto do Fusion, que foi conduzido como se o sistema fosse
ser reprogramado usando uma linguagem orientada a objetos. Isso facilita a segmentao, como
j foi observado, e elimina a dificuldade de identificao dos mtodos. Outra constatao de
que a segmentao no muda a linguagem de programao, no sendo ento verdadeiramente
orientada a objetos. Trata-se de um cdigo programado com estilo de tipos abstratos de dados e
no qual os mecanismos de especializao, generalizao e agregao podem ser simulados.
Entretanto, aps a segmentao, ele pode ser facilmente convertido para uma linguagem
orientada a objetos. Essa experincia foi feita por Sneed, transformando o cdigo legado de
COBOL para COBOL-OO [Sne 96].
Aps a segmentao pode-se proceder o teste do sistema segmentado, com o que se
assegura a conservao de sua funcionalidade. O cdigo segmentado pode servir como entrada
para uma transformao automtica de cdigo, conforme visto na seo 4.3. Entretanto, mesmo
que a mudana de linguagem no ocorra, muitos benefcios da orientao a objetos podero ser
colhidos durante a manuteno do sistema.
76
4.2.2 Estudo de Caso
Aps ter sido obtido o Modelo de Anlise do Sistema, pela aplicao do Fusion/RE, os
dois passos adicionais descritos na seo 4.2.1 so aplicados. Para realizao da experincia
descrita nesta seo foi utilizado o sistema legado cuja engenharia reversa descrita na seo 3.4.
Assim, a documentao de anlise orientada a objetos j existe e pode ser aqui utilizada.
Figura 4.2 - Exemplo de um Grafo de Interao de Objetos
77
No primeiro passo adicional, o Projeto Avante do Sistema executado, obtendo-se os
Grafos de Interao de Objetos, como o exemplificado na figura 4.2, os Grafos de Visibilidade,
as Descries de Classes e os Grafos de Herana. O Grafo de Interao de Objetos mostrado na
figura 4.2 referente operao Abre_Ordem_de_Servio. Ele mostra os mtodos que devem
ser invocados de cada classe para que a operao seja executada, destacando a ordem de chamada
desses mtodos. Os Grafos de Visibilidade, as Descries de Classes e os Grafos de Herana no
tm utilidade imediata para o que se pretende em seguida, que fazer a segmentao dos
programas, mantendo a linguagem de programao original. Como a linguagem Clipper no
possui recursos para implementar a visibilidade e a herana, esses modelos no foram totalmente
desenvolvidos.
Deve-se observar que o Grafo de Interao de Objetos mostrado na figura 4.2 possui
influncia direta da linguagem de programao em que o sistema legado foi desenvolvido. Por
exemplo, mtodos como Abrir_Arquivo e Fechar_Arquivo no seriam necessrios em certas
linguagens, mas foram considerados nesse grafo por se tratar da linguagem Clipper.
No segundo passo adicional, a Segmentao dos programas do sistema legado foi
executada. Os procedimentos correspondentes s operaes foram tratados um a um. A presena
de anomalias foi detectada durante a segunda fase do Fusion/RE e os mtodos foram
identificados na terceira fase e posteriormente detalhados no Grafo de Interao de Objetos. Isso
foi de grande valia, pois pde-se, de antemo, saber quais mtodos seriam esperados. Os
programas foram percorridos seqencialmente, reconhecendo os grupos de comandos
correlacionados, que lidavam com cada uma das classes identificadas no MAS. Os mtodos
foram fisicamente separados do corpo da operao, sendo substitudos por uma chamada a
procedimento ou funo. Na maioria das vezes houve a necessidade de criar parmetros de
entrada ou sada, para permitir que os resultados da execuo do mtodo pudessem ser usados
posteriormente por outros mtodos.
As limitaes da linguagem Clipper obrigaram a adoo de determinadas condutas. Por
exemplo, em Clipper no existe a possibilidade de criao de classes que encapsulem dados e
mtodos. Para contornar esse problema, para cada classe do modelo de objetos foram criados
dois arquivos: um contendo os dados (arquivo do tipo dbf) e outro contendo todos os mtodos
da classe (arquivo do tipo prg). Isso faz parte da simulao da orientao a objetos, que na
verdade a programao com tipos abstratos de dados. Seria tambm possvel simular a herana,
78
mesmo que parcialmente, mas isso no foi feito porque os benefcios no compensariam a
ilegibilidade causada ao cdigo.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
* Nome do programa: OP_OS1.PRG
* Operacao de inclusao da abertura da Ordem de Servico
DO LOGOTIPO
DO ABRCLIEN // Abre_Arquivo_Cli (1)
DO ABRCLIVE // Abre_Arquivo_Veic (3)
DO ABRORDSE // Abre_Arquivo_OS (2)
DO ABRTIPVE // Abre_Arquivo_Tipv (4)
nord =0
codcli =0
gravou=.F.
nomecli=
DO OBTPROXO WITH nord // Obtm_Prximo_Num_OS
(5)
DO TELAOS1 WITH nord, codcli // Obtm_Data_OS (6)
IF LASTKEY() #27 .AND. codcli <>0
enc =.T.
DO PROCLI WITH codcli, enc // Escolhe_Cli (7)
IF .NOT. enc
DO NOVOCLI with codcli // Cria_Cli (8)
ELSE
DO AVISO WITH "Verifique os Dados do Cliente,
Modificando se Necessario"
ENDIF
ok ="N"
nomecli =SPACE(30)
DO WHILE ok ="N"
DO TELACLI WITH enc,nomecli // Obtem_Dados_Cli (9)
ok =CONFDADO( correto )
ENDDO
DO GRCLIEN // Grava_Cli (10)
DO TELALIM
passou =.T.
codvei =0
DO VERCLIVE WITH passou, nomecli // Busca_Veic (11)
Fim =.F.
IF .NOT. passou
Nrovei =0
. . .
@ 7, 25 SAY "Verificacao do(s) Veiculo(s) do Cliente"
@ 8, 25 SAY '""""""""""" """"" """""""""" "" """""""'
. . .
DO WHILE .NOT. fim
DO TELACLVE // Exibe_Tela_veic (12)
pert =" "
men ="Veiculo acima ainda Pertence ao Cliente? (S/N)
===> <>"
DO CONFDADO WITH pert, men
IF pert ="N"
DO APCLIVEI // Elimina_Veic (13)
ELSE
IF passou =.F.
serv =" "
men ="Serao Executados Servicos Nesse Veiculo?
(S/N) ===> <>"
DO CONFDADO WITH serv, men
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
IF serv ="S"
* achou o veiculo no qual sera feito o conserto
passou =.T.
ENDIF
ENDIF
ENDIF
. . .
ENDDO
ENDIF
ENDIF
aband =.F.
IF passou =.F.
* primeira vez que este veiculo do cliente e consertado
. . .
gr =.T.
DO LETIPVEI WITH gr // Obtm_Dados_Tipv (14)
IF gr
DO GRTIPVEI WITH codvei // Cria_Tipv (15)
ELSE
aband =.T.
ENDIF
ENDIF
IF .NOT. aband
. . .
ok ="N"
DO WHILE ok = "N"
DO LECLVEI // Obtm_Dados_Veic (16)
DO CONFDADO WITH ok, correto
ENDDO
DO LEORDSER // Obtm_Dados_Entr_OS (17)
grava =" "
DO CONFGRAV WITH grava
IF grava ="G"
DO GRCLIVEI WITH codcli, codvei, nrovei
// Cria_Veic (18)
DO NOVAORD // Cria_Entr_OS (19)
DO GRORDSER WITH nord, codcli, nrovei
// Grava_OS (20)
gravou =.T.
men ="Imprime 1a. Parte da Ordem de Servico? (S/N)
===> <>"
imp ="N"
DO CONFDADO WITH imp, men
IF imp ="S"
DO IMPOS1 with nord
ENDIF
ENDIF
ENDIF
ENDIF
nro_os=nord
// Varivel a ser passada como parmetro para op_os2
DO FECLIEN // Fecha_Arquivo_Cli (21)
DO FECLIVE // Fecha_Arquivo_Veic (23)
DO FECORDSE // Fecha_Arquivo_OS (22)
DO FECTIPVE // Fecha_Arquivo_Tipv (24)
RETURN
Figura 4.3 - Programa segmentado correspondente operao Abre_Ordem_de_Servio
A figura 4.3 mostra o programa segmentado correspondente operao
Abre_Ordem_de_Servio. Alguns trechos foram omitidos, estando representados por reti-
cncias. A figura 4.4 mostra o cdigo de alguns dos mtodos invocados no trecho de programa
79
segmentado da figura 4.3. O mtodo Obtproxo da figura 4.4 (a) invocado na linha 10 do pro-
grama segmentado (figura 4.3) e corresponde s linhas 10, 11, 12 e 17 do programa legado
(figura 3.6). O mtodo Novocli da figura 4.4 (b) invocado na linha 16 do programa segmen-
tado e corresponde s linhas 34, 35, 38 a 43 do programa legado. O mtodo Leordser da figura
4.4 (c) invocado na linha 71 do programa segmentado e corresponde s linhas 62, 63, 70, 71,
72, 74, 76, 77 e 78 do programa legado. O mtodo Grordser da figura 4.4 (d) invocado na
linha 76 do programa segmentado e corresponde s linhas 85 a 96 do programa legado.
*******************************
FUNCTION OBTPROXO()
***********************************************************
* metodo de ORDSERV para gerar proximo nro vago
de Ordem de Servico.
PARAMETERS nord
SELECT ORDSERV
SET ORDER TO 2
GOTO BOTTOM
vOsnro =OSNRO +1
nord =vOsnro
SET ORDER TO 1
RETURN NIL
(a)
***************************
FUNCTION NOVOCLI()
***********************************************************
* metodo de CLIENTE para criar novo registro de
Cliente e gerar um numero sequencial nico
PARAMETERS codcli
SELECT CLIENTES
SET ORDER TO 1
GOTO BOTTOM
vCodcliente =CODCLIENTE +1
vDatamov =DATE()
APPEND BLANK
REPLACE CODCLIENTE WITH vCodcliente
REPLACE DATAMOV WITH vDatamov
DO AVISO WITH "Digite os Dados do Novo Cliente"
codcli =vCodcliente
RETURN vCodcliente
(b)
*****************************
FUNCTION LEORDSER()
***************************************************************
* metodo de ORDSERV para ler dados da Ordem de Servico
@ 14, 30 SAY "Servicos a Executar"
@ 17, 7 GET vServaex1 PICT REPLICATE ("!",60)
@ 20, 7 SAY "Orcamento (S/N) :"
@ 20, 26 GET vOrcamento PICT "!" VALID vOrcamento $ "SN"
@ 21, 7 SAY "Prometido para as horas"
@ 21, 23 GET vDataprom PICT "@E" VALID vDataprom >=
vDataentra
@ 21, 37 GET vHoraprom PICT "!!!!!"
RETURN NIL
(c)
*******************************
FUNCTION GRORDSER()
**************************************************************************
* metodo de ORDSERV para gravar a nova Ordem de Servico
PARAMETERS nord, codcli, nrovei
v16Osnro =nord
v16Codcliente =codcli
v16Nroveiculo =nrovei
SELECT ORDSERV
REPLACE OSNRO WITH v16Osnro
REPLACE DATAENTRA WITH vDataentra
REPLACE CODCLIENTE WITH v16Codcliente
REPLACE NROVEICULO WITH v16Nroveiculo
REPLACE SERVAEX1 WITH vServaex1
REPLACE ORCAMENTO WITH vOrcamento
REPLACE DATAPROM WITH vDataprom
REPLACE HORAPROM WITH vHoraprom
RETURN NIL
(d)
Figura 4.4 - Alguns mtodos do Programa segmentado
Analisando alguns desses mtodos e comparando-os com o trecho do programa legado do
qual foram extrados, percebe-se que foi necessrio adotar algumas diretrizes para que a
80
segmentao fosse realizada. Por exemplo, adotou-se a conveno de que os nomes dos atributos
das classes seriam armazenados em variveis globais com a letra v precedendo o nome do
atributo. Foi necessrio tornar globais essas variveis para que outros mtodos, invocados pelo
mesmo objeto da classe, tivessem acesso a elas. Porm, aps segmentar uma parte do cdigo,
comearam a surgir variveis com mesmo nome, tanto referentes s chaves estrangeiras quanto a
nomes que coincidiam. Assim, alm do prefixo v, foi necessrio acrescentar um nmero que
identificasse unicamente cada atributo de classe. Para cada classe que precisasse de um nmero
para diferenciar seus atributos foi atribudo um nmero nico. Por exemplo, classe Ordserv
foi atribudo o nmero 16, enquanto que classe Cliente foi atribudo o nmero 26. Na figura
4.4 (d), que corresponde s linhas 85 a 96 do programa legado (figura 3.6), trs dos atributos
receberam o prefixo v16 (v16Osnro, v16Codcliente e v16NroVeiculo), enquanto que os
demais atributos receberam apenas o prefixo v, pois seus nomes no coincidem com nenhum
atributo de outras classes.
O resultado dessa experincia comprovou que os mtodos so muito numerosos e em
geral contm poucas linhas de cdigo. Porm, existe maior possibilidade de reutiliz-los devido
sua funcionalidade bem definida. A facilidade de manuteno tambm maior, pois sua
localizao fsica mais prxima em relao ao sistema legado, no qual trechos de programas
ficavam espalhados por toda parte e faziam acesso a diversas estruturas de dados.
4.3 Reengenharia com mudana de linguagem
Conforme mencionado na seo 4.1, a reengenharia com mudana de linguagem de
programao, alm de atualizar o cdigo para plataformas mais modernas, pode ser realizada
para dar continuidade ao processo de engenharia reversa. Isso faz com que o cdigo fique
sincronizado com a anlise e o projeto, melhorando, portanto, a manutenibilidade futura.
Aps ter sido realizada a engenharia reversa, a reengenharia com mudana de linguagem
pode ser feita manualmente ou auxiliada por uma ferramenta de transformao. A transformao
automtica de uma linguagem para outra, se feita de forma direta, na maioria das vezes gera
cdigo difcil de compreender e manter. A execuo prvia do processo de segmentao permite
que essa transformao seja mais amena, o cdigo gerado seja mais compreensvel e aproveite
melhor as caractersticas da orientao a objetos. Tal experimento foi feito usando a mquina
81
Draco-Puc [Pra 92] e objeto de um artigo publicado em co-autoria com Penteado e outros [Pen
98b]. Um resumo desse experimento relatado nas subsees que se seguem.
4.3.1 Sistema de Transformao utilizado
A mquina Draco baseada nas idias de construo de software por transformao
orientada a domnios. Um primeiro prottipo da mquina Draco foi construdo por Neighbors
[Nei 84]. Posteriormente, ela foi reconstruda na PUC-RJ [Pra 92], usando novas linguagens de
plataformas modernas de hardware e de software. Essa verso foi denominada Draco-Puc.
Pela estratgia proposta por Prado [Pra 92], possvel a reconstruo de um software
pelo porte direto do cdigo fonte para linguagens de outros domnios. Um domnio, de acordo
com a mquina Draco-Puc, constitudo de trs partes: um parser, um pretty-printer e um ou
mais transformadores.
Para a reimplementao automtica necessria a construo dos domnios da linguagem
origem e da linguagem destino, por intermdio de cinco atividades bsicas: construir parsers,
construir pretty-printers, construir um transformador da linguagem origem para a base de
conhecimento, construir um transformador da linguagem origem para a linguagem destino e
construir bibliotecas, conforme mostra a figura 4.5.
(3)
Construir transformador da
ling. Origem para KB
(2)
Construir
pretty-printers
Pargen
(1)
Construir
parsers
Parser da Lin-
guagem Origem
Parser da Lin-
guagem Destino
Base de
Conhecimento
Pretty-printer da
Ling. Origem
Pretty-printer da
Ling. Destino
Ppgen
OrigemToKB.tfm
TFMgen
(4)
Construir transfor-
mador da ling.
Origem para ling.
Destino
OrigemToDestino.tfm
TFMgen
(5)
Construir
bibliotecas
Bibliotecas
Sintaxe da
ling. Destino
Sintaxe da
ling. Origem
82
Figura 4.5 - Atividades bsicas para a construo dos domnios de origem e destino no Draco
Na atividade construir parsers obtm-se os parsers das gramticas livres de contexto
dos domnios origem e destino, a partir da definio dos seus analisadores lxicos e sintticos.
Essa atividade auxiliada pelo subsistema gerador de parsers do Draco, denominado Pargen.
As definies dos parsers so usadas como entrada nessa atividade. Ao lado das regras
gramaticais tm-se as aes semnticas (makenode, makeleaf, etc.) usadas para construo da
DAST (Draco Abstract Sintax Tree), que a linguagem interna usada pelo Draco nas
transformaes.
Na atividade construir pretty-printers o Draco gera automaticamente os pretty-printers
das linguagens origem e destino, usando seu sub-sistema Ppgen. Nessa gerao, parte-se das
definies das regras gramaticais das linguagens origem e destino e das primitivas de formatao
(.sim, .sp, etc.) colocadas ao lado das regras. Um pretty-printer trabalha como unparser que
exibe a DAST orientada pela sintaxe da linguagem, usando as primitivas de formatao.
Exemplo dessas primitivas so: a que estabelece a margem esquerda na coluna corrente (.lm), a
que exibe o n-simo smbolo da regra gramatical (.#n), etc.
A mquina Draco dispe de uma base de conhecimento (Knowledge Base (KB))
semelhante linguagem PROLOG para armazenar fatos e regras. Na atividade construir o
transformador da linguagem origem para a base de conhecimento procura-se percorrer a DAST
da linguagem de origem para reconhecer as suas diferentes estruturas, como os tipos de variveis
e funes, para gerar fatos na KB. O esquema KB que orienta a gerao dos fatos definido
previamente. Nessa atividade, o engenheiro de software faz uso do subsistema TFMgen do
Draco.
Na atividade construir o transformador da linguagem origem para a linguagem destino,
constri-se o transformador inter-domnio que faz o mapeamento semntico da linguagem
origem para a linguagem destino, utilizando os fatos armazenados na KB. O engenheiro de
software usa o sub-sistema TFMgen do Draco para gerar esse transformador.
Para completar o processo de transformao so construdas bibliotecas com classes da
linguagem origem e destino. Essas bibliotecas expressam, na linguagem destino, comandos da
linguagem origem.
Aps a construo dos domnios origem e destino, os programas escritos na linguagem
origem so submetidos ao Draco, que depois de uma srie de etapas produz o cdigo fonte na
83
linguagem destino. O cdigo escrito na linguagem origem inicialmente analisado pelo Draco
usando o parser produzido na atividade 1 citada anteriormente. Isso resulta na DAST com a
representao interna do cdigo original. Essa DAST ento submetida ao unparser, que a
formata de acordo com a sintaxe da linguagem origem, fazendo uso do pretty-printer da
linguagem origem, gerado na atividade 2. O cdigo obtido ento submetido ao transformador
construdo na atividade 3, que extrai os fatos para a base de conhecimento. Finalmente o cdigo
submetido ao transformador construdo na atividade 4 que, usando os fatos da base de
conhecimento e as bibliotecas, transforma-o para a linguagem destino.
4.3.2 Estudo de Caso
O sistema de oficina auto-eltrica e mecnica que passou pela engenharia reversa,
conforme mostrado na seo 3.4, e que sofreu segmentao, conforme mostrado na seo 4.2.2,
foi transformado de Clipper para J ava com o auxlio da mquina Draco. A figura 4.6 mostra, de
forma mais detalhada e especfica do que a figura 4.5, a construo dos domnios Clipper e J ava
[Pen 98b]. Cabe ressaltar que no participei diretamente nessa construo, tendo contribudo de
outras formas, seja dando indicaes de como criar as transformaes, seja fornecendo o cdigo
segmentado como entrada para a mquina Draco, ou ainda na validao do resultado produzido.
As cinco atividades referidas na seo 4.3.1 foram desenvolvidas. Na atividade construir
parser, denotada na figura 4.6 como parser constructing, foram construdos os parsers das
gramticas dos domnios Clipper e J ava, a partir da definio de seus analisadores lxicos e
sintticos. A linguagem destino, J ava, foi escolhida por ser orientada a objetos e bastante atual,
alm de ser portvel para qualquer plataforma de hardware ou software.
Na atividade construir pretty-printers, denotada na figura 4.6 como pretty-printers
constructing, o Draco gera automaticamente os pretty-printers Clipper e J ava pelo uso de seu
sub-sistema Ppgen. Isso feito a partir das definies das regras gramaticais do Clipper e do
J ava e de primitivas de formatao especiais, colocadas ao lado dessas regras gramaticais.
Na atividade construir o transformador da linguagem origem para a base de
conhecimento, denotada na figura 4.6 como ClipperToKB.tfm constructing, foi definido o
transformador ClipperToKb, capaz de percorrer a DAST Clipper, reconhecendo suas diferentes
estruturas e gerando fatos na KB. Conforme dito anteriormente, a construo desse tranformador
auxiliada pelo subsistema Tfmgen do Draco.
84
clipperTojava.tfm
Constructing
Libraries
of Clipper and
DataBase
classes
Clipper and Java PrettyPrinters
clipperToKB.tfmtransformer
Clipper and J ava Parsers
Tfmgen
Ppgen
Pargen
Draco-Puc
Machine
Software
Engineer
Libraries
Constructing
PrettyPrinters
Constructing
clipperToKB.tfm
Constructing
Definition of clipperTojava.tfm Transformer
Software
Engineer
Definition of clipperToKB.tfm Transformer
. . .
Transform
M d C Lhs: {{dast clipper.prog_head
Function [[ID function_name]]
() Use[[ID file_name]] Index to[[iden*
i d ]] [[body_structs*
b d ]] Return Nil
}}
Rhs: {{dast
j il i i class [[Identifier file_name]] extends Database
{ [[field_declaration* body]]
} }}
. . .
. . .
Transform
l Lhs: {{dast clipper.
i [[IID var_name]] =0
}}
Post-Match: {{dast
j il i i . . .
SET_LEAF_VALUE("method_name"
method_name);
KBAssertIfNew("variable([[var_name]]
[[method_name]], int, 0
)") }}
. . .
Global-End: dast
j il i i KBWrite(Utilitary.kb);
}}
. . .
%%
program : var_decl_star
parameter? .nl prog_head+
{$$=MakeNode("program1",$1,$2,$3
NULL); }
prog_head: prog_body
{$$=MakeNode
("prog_head1" , $1,
NULL) | '#' .sp diretiva.sp iden
l {$$=MakeNode
("prog_head2", $2, $3, NULL);
}. . .
if_stat :.lm(+2) 'IF' .sp expr .
l body_structs .nl (1)
%%
compilation_unit :
package_statement?
* .(.nl .slm, ..slm) type_declaration*
{
$$ M k N d (" il i i 1" $1 $2, $3, NULL); }
class_declaration : modifier*
' l ' .sp Identifier ( 'extends' .sp class_name
)?( 'implements' .sp interface_name++','
'{' .slm.lm(+2) field_declaration* .slm(-
2) '}'
{
$$ M k N d (" l d l i 1" $1, MakeLeaf($2), MakeLeaf($3), $4,
$5 $7, NULL); }
. . .
Draco Domains
Libraries
KB
Scheme
Draco-Puc
Machine
Draco-Puc
Machine
Draco-Puc
Machine Software
Engineer
Software
Engineer
PRETTYPRINTER CLIPPER
program1=#1 .NL #2 .NL #3 ;
prog_head1=#1 ;
. . .
if_stat1=.LM(+2) #1" " #2
SLM #3#4 #5 #6 ; (1)
body_structs1=.SLM .LM(+2) #1
SLM(-2) ;
body_struct1=" " " " " " #1 ;
PRETTYPRINTER JAVA
compilation_unit1=#1 #2 #3
package_statement1=#1 " " #2 ";"
. . .
method_declaration1 =.NL .NL
#1 " " #2 " " #3"(" #4 ")" #5#6 #7
throw_part1=#1 " " #2 ;
. . .
class Clipper{
privatestatic Screen Console=new
S () static void initDataBase( String
O C String user, String pwd ) {
String url =
"jdb db " ODBC . . .
static voidsay(int row, int col, String str)
{ if ((row>=0) && (col>=0) && (str !=
ll)) Console.say(row,col,str);
}. . .
class DataBase{
. . .
voidindexDBF(String index[],int size) {
for(int
i 0i I d i ) currentIndexLabel=(String)IndexLabel
elementAt(currentIndex-1
) . . .
catch(SQLException ex) {
Clipper.SQLError(ex); }
}
. . .
Tfmgen
Parser
Constructing
Definition of Clipper and Java parsers
clipperTojava.tfm
transformer
Definition of Database and Clipper Libraries
Clipper
Syntax and
Semantics
Clipper
Syntax and
Semantics
Syntax and
Semantics of
Clipper and J ava
KB
85
Figura 4.6 - Construo dos domnios Clipper e Java no Draco [Pen 98b]
public void OP_OS1()
{
int nord[] =new int[1];
int codcli[] =new int[1];
boolean gravou;
String nomecli[] =new String[1];
boolean encontrou[] =new boolean[1];
String ok[] =new String[1];
boolean passou[] =new boolean[1];
int codvei[] =new int[1];
boolean fim[] =new boolean[1];
int nrovei[] =new int[1];
String pert[] =new String[1];
String men[] =new String[1];
String serv[] =new String[1];
boolean aband;
boolean gr[] =new boolean[1];
String grava[] =new String[1];
String imp[] =new String[1];
int nro_os;
Utilitary.LOGOTIPO();
Clientes CLIENTES =new Clientes();
Cliveic CLIVEIC =new Cliveic();
Tipoveic TIPOVEIC =new Tipoveic();
nord[0] =0;
codcli[0] =0;
gravou =false;
nomecli[0] =" ";
OBTPROXO(nord);
TELAOS1(nord, codcli);
if (Clipper.lastKey() !=27 && codcli[0] !=0) {
encontrou[0] =true;
CLIENTES.PROCLI(codcli, encontrou);
if (!encontrou[0]) {
CLIENTES.NOVOCLI(codcli);
}
else{
Utilitary.AVISO("Verifique os Dados do
Cliente,
Modificando se Necessario");
}
ok[0] ="N";
nomecli[0] =Clipper.space(30);
while (ok[0].equals("N")) {
CLIENTES.TELACLI(encontrou, nomecli);
men[0] =Menuprin.correto[0];
Utilitary.CONFDADO(ok, men);
}
Utilitary.TELALIM();
passou[0] =true;
codvei[0] =0;
CLIVEIC.VERCLIVE(passou, nomecli);
fim[0] =false;
if (!passou[0]) {
nrovei[0] =0;
CLIVEIC.PROCCLIV(codcli, codvei, nrovei,
encontrou);
Utilitary.LIMPA();
if (encontrou[0]) {
Clipper.say(7, 25,
String.valueOf("Verificacao
do(s) Veiculo(s) do Cliente"));
TIPOVEIC.PROCTVEI(codvei);
TIPOVEIC.TELATVEI();
CLIVEIC.TELAVECA();
Clipper.say(13, 5, String.valueOf("Grupo:"));
while (!fim[0]) {
TIPOVEIC.PROCTVEI(codvei);
CLIVEIC.TELACLVE();
pert[0] =" ";
men[0] ="Veiculo ainda Pertence ao Cliente? (S/N) ===> <>";
Utilitary.CONFDADO(pert, men);
if (pert[0].equals("N")) {
CLIVEIC.APCLIVEI(); }
else {
if (passou[0] ==false) {
serv[0] =" ";
men[0] ="Serao Executados Servicos Nesse Veiculo? (S/N)
===> <>";
Utilitary.CONFDADO(serv, men);
if (serv[0].equals("S")) {
passou[0] =true;
}
}
}
CLIVEIC.AVANCCLV(codcli, fim);
Utilitary.LIMPA();
}
}
}
aband =false;
if (passou[0] ==false) {
Utilitary.TELALIM();
TIPOVEIC.TELA();
gr[0] =true;
TIPOVEIC.LETIPVEI(gr);
if (gr[0]) {
TIPOVEIC.PRMARTIP(encontrou, codvei);
if (!encontrou[0]) {
TIPOVEIC.GRTIPVEI(codvei);
}
}
else{
aband =true;
}
}
if (!aband) {
CLIVEIC.TELAVECA();
ok[0] ="N";
while (ok[0].equals("N")) {
CLIVEIC.LECLVEI();
Utilitary.CONFDADO(ok, Menuprin.correto);
}
LEORDSER();
grava[0] =" ";
Utilitary.CONFGRAV(grava);
if (grava[0].equals("G")) {
CLIVEIC.GRCLIVEI(codcli, codvei, nrovei);
NOVAORD();
GRORDSER(nord, codcli, nrovei);
gravou =true;
men[0] ="Imprime 1a. Parte da Ordem de Servico? (S/N) ===>
<>";
imp[0] ="N";
Utilitary.CONFDADO(imp, men);
if (imp[0].equals("S")) {
OP_IMPO1(nord);
}
}
}
}
nro_os =nord[0];
CLIENTES.closeDBF();
CLIVEIC.closeDBF();
closeDBF();
TIPOVEIC.closeDBF();
}
86
Figura 4.7 - Cdigo Java resultante da transformao, ref. operao Abre_Ordem_de_Servico
public void OBTPROXO(int nord[])
{
setOrder(2);
goLast();
ORDSERV.vOsnro =OSNRO +
1;
nord[0] =ORDSERV.vOsnro;
setOrder(1);
}
(a)
public void NOVOCLI(int codcli[])
{
setOrder(1);
goLast();
vCodcliente =CODCLIENTE +1;
vDatamov =Data.today();
appendBlank();
replace("CODCLIENTE", new
Integer(vCodcliente));
replace("DATAMOV", vDatamov);
Utilitary.AVISO("Digite os Dados
do
Novo Cliente");
codcli[0] =vCodcliente;
}
(b)
public void GRORDSER(int nord[], int codcli[],
int nrovei[])
{
v16Osnro =nord[0];
v16Codcliente =codcli[0];
v16Nroveiculo =nrovei[0];
replace("OSNRO", new Integer(v16Osnro));
replace("DATAENTRA", vDataentra);
replace("CODCLIENTE", new
Integer(v16Codcliente));
replace("NROVEICULO", new
Integer(v16Nroveiculo));
replace("SERVAEX1", vServaex1);
replace("ORCAMENTO", vOrcamento);
replace("DATAPROM", vDataprom);
replace("HORAPROM", vHoraprom);
}
(d)
public void LEORDSER()
{
Clipper.say(14, 30, String.valueOf("Servicos a Executar"));
Clipper.get(17, 7, String.valueOf(vServaex1), Clipper.replicate("!", 60));
Clipper.say(20, 7, String.valueOf("Orcamento (S/N) :"));
Clipper.get(20, 26, String.valueOf(vOrcamento), "!", GetField.SIGNAL_IN, String.valueOf("SN"));
Clipper.say(21, 7, String.valueOf("Prometido para as horas"));
Clipper.get(21, 23, String.valueOf(vDataprom), "@E", GetField.SIGNAL_GREQ, String.valueOf(vDataentra));
Clipper.get(21, 37, String.valueOf(vHoraprom), "!!!!!");
Menuprin.getReturn =Clipper.read();
vServaex1 =Menuprin.getReturn.isGot(17, 7) ? Menuprin.getReturn.elementAt(17, 7) : vServaex1;
vOrcamento =Menuprin.getReturn.isGot(20, 26) ? Menuprin.getReturn.elementAt(20, 26) : vOrcamento;
vDataprom =Menuprin.getReturn.isGot(21, 23) ? new Data(Menuprin.getReturn.elementAt(21, 23)) : vDataprom;
vHoraprom =Menuprin.getReturn.isGot(21, 37) ? Menuprin.getReturn.elementAt(21, 37) : vHoraprom;
}
(c)
Figura 4.8 - Alguns mtodos do programa transformado
Na atividade construir o transformador da linguagem origem para a linguagem destino,
denotada na figura 4.6 como clipperToJava.tfm Constructing, foi construdo o transformador
ClipperToJ ava, que faz o mapeamento semntico da linguagem Clipper para a linguagem J ava,
utilizando os fatos armazenados na KB. A construo desse tranformador tambm auxiliada
pelo subsistema Tfmgen do Draco.
Na atividade construir bibliotecas, denotada na figura 4.6 como Libraries
constructing, foram construdas bibliotecas de mapeamento do Clipper para o J ava, com o
87
objetivo de permitir que se expressem em J ava os comandos Clipper referentes a entrada e sada
de dados, gerenciamento de tela, impressora e banco de dados.
Isso tudo preparado, foi possvel efetuar a transformao, alimentando a mquina Draco
com o programa segmentado em Clipper e obtendo a transformao em J ava, seguindo o roteiro
apresentado no fim da seo 4.3.1. O resultado um programa com caractersticas de orientao
a objetos, obtidas graas ao processo de segmentao.
A figura 4.7 mostra o cdigo J ava resultante da transformao referente operao
Abre_Ordem_de_Servio, cujo cdigo segmentado em Clipper consta da figura 4.3. A figura 4.8
mostra os mtodos (em J ava) correspondentes aos mtodos em Clipper da figura 4.4.
Caso a segmentao no fosse efetuada, apesar do programa em J ava ser escrito numa
linguagem orientada a objetos, no se teria as vantagens da orientao a objetos, tais como o
reuso e a manutenibilidade propiciadas pelo encapsulamento. Esses programas podem ser
posteriormente inspecionados e modificados pelo engenheiro de software, se for o caso, para tirar
partido das heranas, agregaes, polimorfismo, etc.
A reengenharia de um sistema originalmente procedimental, obtendo-se um sistema
orientado a objetos foi efetuada com xito. Foram explorados dois caminhos em seqncia. O
primeiro partiu do modelo de objetos obtido pela engenharia reversa e segmentou o cdigo
legado, mantendo a linguagem Clipper. O segundo fez a transformao automtica de cdigo
Clipper para J ava, partindo do cdigo segmentado. Em princpio, os cdigos produzidos pelos
dois caminhos tm a mesma facilidade de manuteno. A transformao para J ava mantm toda
a estrutura do programa segmentado, sendo, portanto, equivalente em termos de manuteno.
Entretanto, o cdigo J ava pode ser executado em qualquer plataforma de hardware ou software, o
que o torna muito mais portvel do que o cdigo Clipper.
Por outro lado, caso a empresa tenha pessoal especializado em Clipper e no necessite de
mudana de plataforma, mais conveniente utilizar o cdigo segmentado em Clipper. Desta
forma no ser necessrio contratar novo pessoal ou dar treinamento em novas linguagens. A
documentao de anlise e de projeto agora compatvel com o cdigo, o que facilita a
manuteno e eventual futura reengenharia com mudana de funcionalidade. Alm disso,
88
resultados obtidos pela engenharia reversa, engenharia avante e segmentao aumentam a
possibilidade de reuso, tanto de cdigo quanto de anlise e projeto.
89
Captulo 5 - Reconhecimento de Padres de Software
Conforme mencionado na seo 1.1 existem padres de software em diversos nveis de
abstrao, desde a anlise, passando pelo projeto e at padres de cdigo. Neste trabalho, o
interesse maior por padres que possam ser empregados em sistemas de informao. A seo
5.2 descreve brevemente alguns desses padres, propostos por autores como Coad [Coa 92],
Boyd [Boy 98] e J ohnson [J oh 98]. Na seo 5.3 proposta uma estratgia para reconhecimento
de padres em modelos de objetos de sistemas legados. Na seo 5.4 feito um estudo de caso
usando como material o que foi preparado na seo 3.4. Na seo 5.5 so feitas as consideraes
finais deste captulo.
5.2 Padres recorrentes para Sistemas de Informao
Existem inmeros padres recorrentes no domnio de sistemas de informao, isto ,
padres que ocorrem repetidamente no seu desenvolvimento. Analisando alguns desses padres e
suas principais aplicaes, puderam ser escolhidos diversos deles que mais ocorrem em sistemas
como os por mim desenvolvidos na prtica profissional. Nesta seo so destacados apenas
aqueles que se aplicam ao caso em estudo discutido na seo 5.4, que so: o TypeObject [J oh
98], o Association-Object [Boy 98], o State across a collection e o Behaviour across a collection
[Coa 92]. Outros padres recorrentes foram mostrados na seo 2.5.2, como o Roles-played [Coa
92] e o Abstract Factory [Gam 93],
5.2.1 Padro Type-Object
Um dos padres encontrados em quase todos os sistemas de informao o Type-Object,
descrito por J ohnson [J oh 98] e mostrado na figura 5.1. Esse padro equivalente ao padro
Item-Description apresentado por Coad [Coa 92]. A verso escolhida foi a de J ohnson por ser
especificada em maior nvel de detalhe.
90
O problema resolvido por esse padro o de uma classe com diversos tipos, que podem
variar em tempo de execuo. A soluo agrupar os atributos comuns classe em Class e
criar uma outra classe TypeClass para conter os tipos. Os objetos da classe Class possuem
uma referncia a algum dos objetos da classe TypeClass. Pode tambm haver a referncia
inversa, embora J ohnson a considere facultativa.
Figura 5.1 - Padro Type-Object [Joh 98]
A figura 5.2 mostra o exemplo utilizado por J ohnson para ilustrar o padro Type-Object.
Em uma videolocadora, um filme possui atributos como ttulo e preo de locao e pode possuir
cpias em diversas fitas de vdeo, cada qual alugada para um cliente diferente. O padro
estabelece que Filme e Fita de vdeo so classes relacionadas, existindo uma referncia nos
objetos da classe Fita de vdeo ligando-os a um objeto da classe Filme.
Figura 5.2 - Exemplo do Type-Object [Joh 98]
Para mostrar a semelhana do Type-Object com o padro Item-description, esse ltimo
apresentado na figura 5.3. Um exemplo ilustrativo dado pelo autor [Coa 92] mostrado na figura
5.4, no qual fcil verificar tal semelhana.
Figura 5.3 - Padro Item-Description [Coa 92]
Figura 5.4 - Exemplo do Item-Description [Coa 92]
Filme
ttulo
preo de locao
Fita de vdeo
est alugada?
Locador()
1
*
Aeronave
Numero
DescrioAeronave
fabricante
modelo
velocidade_mdia_padro
* 1
TypeClass
typeAttribute
Class
attribute
* 1
Item
ItemDescription
1 *
91
5.2.2 Padro Association-Object
Outro padro bastante comum em sistemas de informao o Association-Object,
proposto por Boyd [Boy 98] e mostrado na figura 5.5. semelhante ao padro Time-Association,
descrito por Coad [Coa 92], embora Boyd o tenha apresentado de forma mais detalhada e
especfica para sistemas de informao.
Figura 5.5 - Padro Association-Object [Boy 98]
Esse padro usado sempre que exista uma associao dinmica entre dois objetos
estticos a qual deve ser cuidada pelo sistema. Em geral essa associao dura um certo tempo,
denotado pelos atributos Begin_date e End_date da classe Association e tem algum custo, tratado
pelo atributo Cost dessa mesma classe. Alm dos atributos em comum, a classe Association tem
um comportamento comum, presente nos mtodos Allocate_costs e Create_current_from_plan.
As classes STATIC-1 e STATIC-2 tambm possuem atributos e comportamento comuns.
A figura 5.6 mostra um exemplo de aplicao do padro Association-Object a um sistema
de alocao de salas a departamentos. As classes Sala e Departamento desempenham o papel
de Static-1 e Static-2, respectivamente. A classe Atribuio Sala-Depto figura como
Association. Ao departamento pode ser atribuda uma ou mais salas por perodos
predeterminados. Essa atribuio deve definir um percentual de alocao, calculando o custo da
alocao. Tanto uma sala quanto um departamento podem querer saber seus custos com
alocao. Assim, existem mtodos em ambas as classes para calcular os respectivos custos.
1
1
*
*
STATIC 1
Name
Description
Set
Get
STATIC 2
Name
Description
Set
Get
ASSOCIATION
Begin_Date
End_Date
Cost
Allocate_costs
Create_current_from_plan
Comportamento
Atributos
92
Figura 5.6 - Association-Object [Boy 98]
5.2.3 Padro State across a collection
O padro State across a collection foi proposto por Coad [Coa 92] para resolver um
problema comum em sistemas orientados a objetos: o de agregaes, nas quais a superclasse
possui atributos que so compartilhados pelas subclasses. A figura 5.7 mostra esse padro e a
figura 5.8 mostra um exemplo de aplicao, no qual a classe Venda desempenha o papel
Collection e a classe Item da Venda desempenha o papel de Member.
Figura 5.7 - Padro State across a collection [Coa 92]
5.2.4 Padro Behaviour across a collection
O padro Behaviour across a collection tambm foi proposto por Coad [Coa 92] para
resolver o problema de agregaes, mas no caso em que a superclasse possua mtodos
compartilhados pelas subclasses. A figura 5.9 mostra esse padro e a figura 5.10 mostra um
1 1
*
*
SALA
Nome
Descrio
Calc. custos da sala
Set
Get
DEPARTAMENTO
Nome
Descrio
Calc. custos do depto
Set
Get
Atribuio Sala-Depto
Data_inicial
Data_final
Percentual de alocao
Alocar custos
Criar atribuio
Collection
CollectionAttribute
Member
MemberAttribute
93
exemplo de aplicao para um sistema de chamadas telefnicas, no qual a classe Venda
desempenha o papel Collection e a classe Item da Venda desempenha o papel de Member.
Figura 5.8 - Exemplo do Padro State across a collection [Coa 92]
Figura 5.9 - Padro Behaviour across a collection [Coa 92]
Figura 5.10 - Exemplo do Padro Behaviour across a collection [Coa 92]
Venda
Nmero
Data/Hora
Item da Venda
Quantidade
Collection
CollectionService
Member
MemberService
Coleo de chamadas
telefnicas
SelecionarProxChamada
Chamada telefnica
Hora da chegada
Prioridade
Numero da origem
Rotear
Atribuir importncia
94
5.3 Uma estratgia para reconhecimento de padres
Modelos de objetos de diversos sistemas de informao foram inspecionados a fim de
neles reconhecer padres como os discutidos na seo 5.2. Entre esses foram utilizados um
sistema de biblioteca, um sistema de consultrio mdico e o sistema de oficina auto-eltrica e
mecnica apresentado na seo 3.4. Essa inspeo permitiu que algumas diretrizes bsicas
pudessem ser formuladas para o reconhecimento desses padres em modelos de objetos de
sistemas de informao. Essas diretrizes foram generalizadas e deram origem estratgia
apresentada nesta seo.
5.3.1 Padro Type-Object
O padro TypeObject, discutido na seo 5.2.1, freqentemente encontrado em sistemas
de informao. O seguinte algoritmo genrico deve ser seguido para tentar reconhecer esse
padro em um modelo de objetos existente:
1) todas as classes do modelo de objetos devem ser analisadas, em busca de relacionamentos
com cardinalidade um para muitos. Os pares de classes com tais caractersticas so
selecionados como candidatos a um Type-Object, no qual a classe que fica do lado um
candidata ao papel TypeClass e a classe do lado muitos candidata ao papel Class. As
demais classes so descartadas.
2) em ambas as classes do par candidato deve haver um atributo que identifique unicamente
cada objeto da classe e um outro atributo que o descreva. Os pares que no obedecerem a
essa regra podem ser descartados.
3) finalmente, o valor semntico do relacionamento dever ser analisado. Lendo-se o
relacionamento partindo de Class para TypeClass deve ser natural pensar em mtodos
como: a) dado um objeto da classe Class informe qual seu objeto correspondente na
classe TypeClass e b) atribua a um objeto da classe Class um objeto da classe
TypeClass. Lendo-se o relacionamento no sentido inverso, deve ser possvel pensar em um
mtodo que, dado um objeto da classe TypeClass, retorne todos os objetos da classe
Class. A existncia desses mtodos deve ser natural, no sentido de que eles so cabveis
dentro do domnio de aplicao, sendo fcil imaginar sua utilidade para algum.
95
Conforme j mencionado, esse algoritmo foi construdo com base na experincia prtica
de reconhecimento de padres em diversos sistemas de informao. Porm, possvel que outras
diretrizes sejam descobertas se forem analisadas outras aplicaes. possvel tambm que
algumas dessas diretrizes no se apliquem a todos os casos, apesar dos cuidados que foram
tomados ao fazer a generalizao.
5.3.2 Padro Association-Object
O padro Association-Object, discutido na seo 5.2.2, tambm comum em sistemas de
informao. Para identific-lo, pode-se usar o seguinte algoritmo:
1) todas as classes do modelo de objetos devem ser analisadas, em busca das que contenham um
ou mais atributos do tipo data. Essas classes so candidatas ao papel Association do
padro. As demais classes podem ser descartadas.
2) deve-se ento examinar, para todas as classes candidatas, os relacionamentos do tipo muitos
para um que elas tenham com outras classes. As classes do lado um devem ser estticas,
isto , devem representar itens tangveis do domnio, que contenham caractersticas inerentes
ao longo de seu tempo de vida. Essas classes so candidatas ao papel static-1 ou static-2.
3) se no existe relacionamento desse tipo, pode-se descartar a classe candidata.
4) se existe apenas um relacionamento desse tipo, mas existe uma classe agregada classe
candidata a Association e a partir dessa classe agregada existe um relacionamento como o
descrito no item 2, a classe candidata continua sendo examinada. Nesse caso, a classe do lado
um do primeiro relacionamento identificado assume o papel Static-1 e a classe
relacionada classe agregada assume o papel Static-2. Caso contrtio a classe candidata a
Association pode ser descartada.
5) se existem dois relacionamentos desse tipo, associam-se os papis Static-1 e Static-2 s
duas classes do lado um desses relacionamentos.
6) se existem mais de dois relacionamentos desse tipo, devem ser escolhidas duas classes para
os papis Static-1 e Static-2. Executam-se ento os demais passos e, caso o padro no
seja identificado, devem ser escolhidas outras duas classes at que todas as combinaes
possveis tenham sido exploradas.
7) por fim, o significado semntico deve ser analisado. Focalizando na classe candidata ao papel
Association, deve fazer sentido pensar que ela faz a ligao temporal entre as classes
96
candidatas a Static-1 e Static-2. Essa ligao deve, preferencialmente, envolver algum
custo e deve haver um mtodo na classe Association para criar e/ou desfazer a associao
entre as duas classes estticas.
As mesmas observaes feitas no padro Type-Object so vlidas aqui. Outros sistemas
talvez tenham comportamento diferente, que necessite de diretrizes adicionais ou no se
encaixem nas diretrizes aqui propostas.
5.3.3 Padro State across a Collection
O padro State across a Collection, discutido na seo 5.2.3, reconhecido usando-se o
seguinte algoritmo:
1) todas as classes do modelo de objetos devem ser examinadas em busca de classes que
possuam subclasses agregadas. Essas classes so candidatas ao papel Collection do padro,
enquanto que a subclasse agregada correspondente candidata ao papel Member. As
demais classses podem ser descartadas.
2) para todas as classes candidatas ao papel Collection deve-se examinar seus atributos em
busca daqueles que sejam comuns classe candidata ao papel Member. Se tal atributo
existe, o padro ocorre.
Esse padro aparece com freqncia em sistemas orientados a objeto em geral. Seu
reconhecimento torna-se fcil devido ao uso de agregao, que j meio caminho andado em
busca do padro. Se o engenheiro de software utilizou agregao para representar certa classe,
provavelmente foi devido ocorrncia de atributos ou mtodos compartilhados pela classe e
subclasse. Assim, a ocorrncia desse padro ou do padro Behaviour across a collection,
mostrado a seguir, garantida.
5.3.4 Padro Behaviour across a collection
O padro Behaviour across a Collection, discutido na seo 5.2.4, reconhecido
utilizando-se o seguinte algoritmo:
97
3) todas as classes do modelo de objetos devem ser examinadas em busca de classes que
possuam subclasses agregadas. Essas classes so candidatas ao papel Collection do padro,
enquanto que a subclasse agregada correspondente candidata ao papel Member. As
demais classses podem ser descartadas.
4) para todas as classes candidatas ao papel Collection deve-se examinar seus mtodos em
busca de pelo menos um que se aplique a todos os objetos da coleo como um todo. Se tal
mtodo existe, o padro ocorre.
Aqui valem as mesmas observaes feitas no padro State across a collection. Na
maioria das vezes a ocorrncia desse padro simultnea com a ocorrncia do State across a
collection, devido ao prprio conceito de agregao.
5.4 Estudo de Caso
5.4.1 Reconhecimento dos padres no modelo de objetos do sistema legado
Conforme mencionado na seo 5.3, a estratgia l proposta foi possvel graas
experincia de reconhecimento de padres em diversos sistemas de informao. Um desses
sistemas usado para exemplificar o reconhecimento de padres nesta seo. Trata-se do mesmo
sistema utilizado nos captulos 3 e 4, que referente a uma oficina auto-eltrica e mecnica de
veculos.
O MOS-6a, apresentado na figura 3.17, tomado como base para o reconhecimento de
padres. Os padres reconhecidos foram documentados no modelo de objetos, usando a notao
recomendada pela UML [Eri 98], mostrada na figura 5.11. O nome do padro colocado em uma
elipse com linha tracejada. As classes do sistema que correspondem instncia do padro so
colocadas em caixas retangulares. Setas tracejadas so desenhadas partindo da elipse para as
caixas retangulares, rotuladas com o nome do papel desempenhado pela classe instanciada.
A figura 5.12 mostra o modelo de objetos do sistema aps o reconhecimento de padres.
Sempre que um padro reconhecido, os relacionamentos que fazem parte desse padro so
removidos do modelo de objetos examinado.
98
Figura 5.11 - Notao usada para expressar padres em UML
Como pode ser observado na figura 5.12, foram reconhecidas duas instncias do Type-
Object, quatro instncias do Association-Object, cinco instncias do State across a collection e
cinco instncias do Behaviour across a collection. Esse reconhecimento descrito a seguir.
Inicialmente procurou-se pela ocorrncia do padro Type-Object. Todas as classes foram
examinadas em busca de relacionamentos do tipo muitos para um e foram selecionados os
seguintes candidatos ao papel Class: Atendimento por balco, Conta a Receber, Conta a Pagar,
Pea vendida, Veculo de cliente, Ordem de Servio, Pea da Ordem de Serv., Mo-de-obra da
Ordem de Serv., Pea, Compra, Pea comprada, Pedido e Pea pedida. Foi ento verificada a
existncia de um atributo identificador e outro descritor nos candidatos a Class e nos
respectivos candidatos a TypeClass. Dessa forma, foram descartados muitos dos candidatos,
tendo restado apenas os dois pares de candidatos a Class/ TypeClass: Veculo de cliente/Tipo
de Veculo e Pea/Fabricante. A maioria dos candidatos foi eliminada por no possuir um
identificador nico ou um atributo que os descrevessem. Foi ento analisado o valor semntico
do relacionamento e concluiu-se que os dois finalistas realmente formam uma ocorrncia do
Type-Object. natural pensar em mtodos como: dado um veculo de cliente informe qual seu
tipo; dado o veculo de placa XXX-1234 atribua a ele a marca/tipo Volkswagen-Parati; e
quais veculos da marca/tipo Fiat-Uno Mille foram consertados nos ltimos seis meses.
Partiu-se ento para a busca do padro Association-Object. Na primeira etapa foram
classificados, por conterem atributo do tipo data, as classes Atendimento por balco, Conta,
Ordem de Servio, Compra e Pedido. Foram ento examinados seus relacionamentos do tipo
muitos para um em busca de classes candidatas a Static-1 e Static-2. Para a classe
Atendimento por balco foram encontradas as classes Cliente e Empregado. Para a classe Conta,
por intermdio de suas classes herdeiras, foram encontradas as classes Atendimento por balco,
Ordem de Servio e Compra. Para a classe Ordem de Servio foi encontrada a classe Veculo de
cliente. Para as classes Compra e Pedido foi encontrada a classe Fornecedor.
Type Object
Type Class
Class
Veculo de Cliente
Tipo de Veculo
99
*
*
trabalha com
*
1
obedece a
Association
Static 1
Static 2
Collection
Association
Static 1
Static 2 Static 2
Static 1
Association
Static 1
uma
Static 2
Collection
Member
Collection
Type class
Class
*
0..1
*
*
1 1
uma
uma
*
1
gera
1
0..1
refere-se a
*
*
*
*
adapta-se a
*
adapta-se a
* *
faz parte do
* *
*
*
temvalor
de trabalho
de acordo
com
temtempo
de reparo de
acordo com
feita por
0..1
equivalente a
*
*
1
*
gera
1
*
* 1
1
* is a
1
*
atendido por
Ordemde Servio
Cliente
Veculo de cliente
Pea da Ordemde Serv. Mo-de-Obra da
Ordemde Serv.
Pea
Empregado
Tipo de veculo
Pea adquirida fora
Pea do estoque
Conta
Atendimento por balco
Pea vendida
gera
Conta a Receber
Conta a Pagar
Fabricante
possui
Tipo de mo-de-
obra
Componente
Pedido
Pea pedida
Compra
Pea comprada
Fornecedor
Ramo
Collection
Behavior aac/
State aac
Member
Type Object
Type class
Class
Type Object
Behavior aac/
State aac
Member
Behavior aac/
State aac
Member
Collection
Behavior aac/
State aac
Member
Behavior aac/
State aac
Association
Object
Association
Association
Object
Association
Object
Association
Object
quantvt tempo
Figura 5.12 - Reconhecimento de padres
100
A classe Atendimento por balco foi, portanto, classificada sem maiores problemas.
correto pensar que o Atendimento por balco faz uma associao temporal entre Cliente e
Empregado, isto , existe um atendimento registrando um cliente que foi atendido por um
empregado em uma determinada data. A classe Conta possui trs relacionamentos candidatos,
tendo que ser analisados aos pares. As trs demais possuem apenas um relacionamento candidato
e devem ser investigadas por possuirem classes agregadas. Ao analisar a classe Conta com os
possveis candidatos a Static-1 e Static-2, o valor semntico foi importante para a deciso de
descartar a possibilidade de ocorrncia do Association-Object. No faz sentido dizer que Conta
uma associao temporal entre Atendimento por balco e Ordem de Servio, ou entre Ordem de
Servio e Compra ou entre Atendimento por balco e Compra. A classe Ordem de Servio possui
uma classe agregada, Pea da Ordem de Servio, que por sua vez possui um relacionamento com
a classe esttica Pea. Assim pode-se eleger a classe Veculo de cliente como candidata a Static-
1 e Pea como candidata a Static-2. Pensando no valor semntico desse relacionamento,
correto que a Ordem de Servio faz uma associao temporal entre um veculo consertado e a
pea utilizada, sendo portanto classificado. O mesmo raciocnio foi utilizado para classificar
Compra/Fornecedor/Pea e Pedido/Fornecedor/Pea como ocorrncias do Association-
Object.
O modelo de objetos foi ento analisado em busca dos padres State across a collection e
Behaviour across a collection. As agregaes existentes foram classificadas: Atendimento por
balco/Pea vendida, Ordem de Servio/Pea da Ordem de Servio, Ordem de Servio/Mo-de-
obra da Ordem de Serv., Compra/Pea comprada e Pedido/Pea pedida. Em todas elas existe pelo
menos um atributo na classe candidata a Collection que comum classe correspondente
candidata a Member. Por exemplo, em Atendimento por balco, o atributo Data do
Atendimento tambm a Data em que a pea foi vendida. Tambm em todas as classes
candidatas existem mtodos, embora no estejam explicitamente presentes, que se aplicam
coleo como um todo. Por exemplo, na classe Compra, para calcular o Valor total necessrio
invocar os mtodos individuais de cada pea comprada. Dessa forma, as quatro agregaes
encontradas so ocorrncias simultaneamente dos padres State across a collection e Behaviour
across a collection.
101
5.4.2 Exemplo de implementao de padro
Aps ter sido feito o reconhecimento de padres, partiu-se para a reengenharia do sistema
legado, adotando-se os padres identificados. A funcionalidade do sistema legado foi mantida
durante a reengenharia, embora a interface tenha sido modernizada e adaptada ao estilo
Windows.
ilustrada nesta seo a implementao das duas instncias do padro Type-Object e de
uma das instncias do padro Association-Object no sistema estudado. Escolheu-se a linguagem
Delphi [Can 97, Can 98] para fazer a reengenharia do sistema, por ser uma linguagem
comumente utilizada em sistemas de informao comerciais.
Para facilitar a implementao de instncias do padro Type-Object proposto um
esqueleto de implementao para ele, que agiliza o reuso, bastando para tal particularizar o
esqueleto para cada caso particular. O mesmo poderia ser feito com os demais padres
recorrentes vistos na seo 5.2, o que sugerido como trabalho futuro.
O exemplo de implementao completo do padro Type-Object objeto de um
relatrio tcnico [Bra 98b], no qual constam as listagens de suas duas instanciaes, bem como
diretrizes para utilizar as facilidades do ambiente Delphi na particularizao do padro para cada
instncia.
5.4.2.1 Esqueleto de implementao do padro Type-Object
A figura 5.13 mostra o modelo de objetos do padro Type-Object para o domnio de
aplicao aqui abordado. Foram dados nomes genricos aos atributos e mtodos das classes
Class e TypeClass. Os mtodos que constam dessa figura foram obtidos aps a programao
de uma das instncias do Type-Object, que permitiu identificar quais mtodos seriam necessrios
para implementar as operaes relativas s classes envolvidas no padro. Os atributos
Identificador e Descritor, presentes em ambas as classes, so caractersticos do domnio de
sistemas de informao, no qual objetos estticos possuem uma chave primria para identific-
los e uma chave secundria para descrev-los de alguma forma. Essa foi uma das exigncias para
que o padro fosse reconhecido, conforme a segunda diretriz da seo 5.3.1. O atributo Tipo da
classe Class foi necessrio para fazer a ligao com a classe TypeClass, j que utilizada
uma base de dados relacional para prover a persistncia dos objetos.
102
Figura 5.13 - Modelo de Objetos detalhado do padro Type-Object
Com base nesses atributos e mtodos com nomes genricos, foi feito um esqueleto de
cdigo para a definio das classes do padro Type-Object. A definio das classes Class e
TypeClass ilustrada na figura 5.14 e o corpo de alguns mtodos consta da figura 5.15.
O padro CRUD [Yod 98], que um dos padres sugeridos para conectar objetos a
bases de dados relacionais descritos na seo 2.5, foi utilizado na implementao no que se refere
ao acesso base de dados do Delphi. Assim, mtodos especficos para acesso s tabelas de dados
foram isolados em uma camada. Esses mtodos s podem ser chamados pelos mtodos da
prpria classe. Os mtodos ilustrados na figura 5.13 so os mtodos de interface da classe, isto ,
os mtodos que podem ser invocados por quaisquer outras classes do sistema.
Para implementar a camada de acesso s tabelas da base de dados foi utilizado o recurso
DataModules (mdulos de dados) do Delphi. Um mdulo de dados contm um componente
para fazer referncia tabela em si e alguns componentes para efetuar as operaes bsicas, em
SQL, referentes insero, atualizao, excluso e recuperao de dados. Na verdade, um nico
objeto pode ser armazenado em mais de uma tabela e, nesse caso, o mdulo de dados representa
o objeto, contendo os componentes necessrios para relacion-lo com as respectivas tabelas.
Dessa forma, cada classe faz uso de um nico mdulo de dados, no qual se concentram as tabelas
necessrias para tornar seus objetos permanentes. No caso do padro Type-Object, como cada
uma das classes armazenada em uma nica tabela, so necessrios dois mdulos de dados, cada
qual fazendo referncia a uma das tabelas.
Class
Identificador
Descritor
Tipo
Salvar
Excluir
BuscaIdent
BuscaDescr
BuscaDescrTodos
ExisteIdent
ExisteDescr
GetIdentificador
GetDescritor
GetTipo
SetIdentificador
SetDescritor
SetTipo
Novo
TypeClass
Identificador
Descritor
Salvar
Excluir
BuscaIdent
BuscaDescr
BuscaDescrTodos
ExisteIdent
ExisteDescr
GetIdentificador
GetDescritor
SetIdentificador
SetDescritor
Novo
*
1
103
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
type // Definio da Classe Class do padrao Type_Object
AClass =class
public // Mtodos da interface
procedure Salvar;
function Excluir:Boolean;
function BuscaIdent(x:Integer):Boolean; // Busca objeto por ident
function BuscaDescr(x:String):Boolean; // Busca objeto por descr
procedure BuscaDescrTodos(x:String; ListaFinal: TListBox); // Busca todos objetos
c/descr
function ExisteIdent(x:Integer): Boolean; // verifica a existencia por ident
function ExisteDescr(x:String): Boolean; // verifica a existencia por descr
function GetIdentificador: Integer;
function GetDescritor: String;
function GetTipo: ATypeClass;
procedure SetIdentificador(x: Integer);
procedure SetDescritor(x: String);
procedure SetTipo(tip: ATypeClass);
function Novo: Integer;
private // Atributos Privados
Identificador: Integer;
Descritor: String;
UmTipo: ATypeClass;
// Mtodos que fazem acesso as tabelas do banco de dados
procedure AtribuirObjetoAParametro(x:TQuery);
procedure AtribuirModeloAObjeto(x:TQuery);
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueIdent(x: Integer; atribuir:Boolean): Boolean;
function CarregueDescr(x:String; atribuir:Boolean): Boolean;
function CarregueDescrTodos(x: String; Lista: TListBox): Boolean;
function Ultimo: Integer;
end;
(a)
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
type // Definio da Classe TypeClass do padrao Type_Object
ATypeClass =class
procedure Salvar;
function BuscaIdent(x:Integer):Boolean; // Busca por ident
function BuscaDescr(x:String):Boolean; // Busca por descr
procedure BuscaDescrTodos(x:String; ListaFinal: TListBox); // Busca por todos c/descr
function ExisteIdent(x:Integer): Boolean; // verifica a existencia por ident
function GetIdentificador: Integer;
function GetDescritor: String;
procedure SetIdentificador(x: Integer);
procedure SetDescritor(x: String);
Identificador: Integer;
Descritor: String;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueIdent(x: Integer; atribuir:Boolean): Boolean;
procedure CarregueTodos(Lista: TListBox);
function CarregueDescrTodos(x: String; Lista: TListBox): Boolean;
end;
(b)
Figura 5.14 - Esqueleto da declarao da classe Class do padro Type-Object
104
// Atribuir valor a Identificador
procedure AClass.SetIdentificador(x: Integer);
begin
Identificador:=x;
end;
(a)
// Fornecer o Descritor
function AClass.GetDescritor: String;
begin
GetDescritor:=Descritor;
end;
(b)
// Obter o ltimo identificador registrado na tabela
function AClass.Ultimo: Integer;
var max: Integer;
begin
max :=0;
with DataModuleClass.TabClass do
begin
First;
while not EOF do
begin
if Fields[0].AsInteger >max then
max :=Fields[0].AsInteger;
Next;
end;
end;
Ultimo:=max;
end;
(c)
// Salvar um objeto
procedure ATypeClass.Salvar;
begin
if (not BuscaIdent(Identificador)) and (not BuscaDescr(Descritor)) then
// Objeto da classe Class no cadastrado, inseri-lo na tabela
Crie
else
// Objeto da classe Class j cadastrado, atualizar atributos no-
chave
Atualize;
end;
(d)
Figura 5.15 - Esqueleto de alguns mtodos do padro Type-Object
O mdulo de dados referente classe Class exemplificado na figura 5.16. Ele possui
um componente TTable, que faz referncia tabela fsica; um componente TDataSource
usado para definir a origem dos dados; e cinco componentes Tquery: Insero, para insero
de registro na tabela; Atualizao, para gravar apenas os atributos no-chave da tabela;
Exclusao, para excluir um registro da tabela, dada sua chave primria; SelecionaPrim, para
recuperar registros pela chave primria; e SelecionaSec, para recuperar registros pela chave
secundria. Possui tambm um procedimento para fazer a gravao permanente dos dados ao
fechar a tabela.
105
Os mtodos que fazem o acesso s tabelas da base de dados podem ser vistos nas linhas
23 a 31 e 52 a 61 da figura 5.14, como mtodos privados (clusula private, em Delphi).
Analisando um desses mtodos, como por exemplo o mtodo Ultimo da classe AClass
(figura 5.15 (c)), pode-se notar a referncia efetuada ao mdulo de dados DataModuleClass da
classe Class. Graas utilizao do padro CRUD [Yod 98], esses so os nicos mtodos
que devem saber detalhes das tabelas da base de dados, tais como nome das tabelas, localizao,
nome e posio de campos, etc. Assim, se a base de dados sofrer alguma alterao, poucos
mtodos precisaro ser modificados.
type TdataModuleClass =class(TdataModule)
TabClass: TTable;
DataSource1: TDataSource;
Insercao: TQuery; // insere novo registro na tabela
Atualizacao: TQuery; // atualiza campos nao chave
Exclusao: TQuery; // exclui registro da tabela
SelecionaPrim: TQuery; // seleciona dado um identificador
SelecionaSec: TQuery; // seleciona dado um descritor
procedure TabClassBeforeClose(DataSet: TdataSet);
end;
var
DataModuleClass: TDataModuleClass;
. . .
Figura 5.16 - Esqueleto de um dos mdulos de dados do padro Type-Object
O cdigo SQL a ser executado para cada um dos componentes do mdulo de dados no
fica disponvel no cdigo fonte desse mdulo de dados, sendo armazenado na sua clusula
SQL. As figuras 5.17(a) e (b) ilustram o cdigo SQL para os componentes Insercao e
SelecionaPrim do mdulo de dados Class, respectivamente.
insert into "CLASS.db"
(IDENTIFICADOR_MODELO, DESCRITOR_MODELO, TIPO_MODELO)
values
(:IDENTIFICADOR, :DESCRITOR, :TIPO)
(a)
select * from "CLASS.db"
where IDENTIFICADOR_MODELO=:IDENTIFICADOR
(b)
Figura 5.17 - Cdigo SQL de alguns componentes do mdulo de dados Class
106
Esses esqueletos de cdigo podem ser utilizados em qualquer sistema no qual o padro
Type-Object seja identificado. Para tal, deve-se fazer a substituio dos nomes genricos para
nomes especficos da instncia encontrada, tanto na definio da classe quanto no mdulo de
dados correspondente. Um procedimento passo a passo de como essa substituio deve ser feita
utilizando os recursos do Delphi 3.0 dado em [Bra 98b].
5.2.4.2 Instanciao do padro Type-Object para Pea/Fabricante
A figura 5.18 mostra o modelo de objetos para a instncia do padro Type-Object,
reconhecida na seo anterior para o par de classes Pea/Fabricante. Nota-se que alguns
atributos foram acrescentados classe Pea em relao classe Class do padro, bem como os
mtodos para lidar com esses novos atributos.
Figura 5.18 - Modelo de Objetos de uma instncia do padro Type-Object
A definio das classes e dos mdulos de dados foi feita com base no esqueleto de cdigo
mostrado nas figuras 5.14 a 5.16. As figuras 5.19 e 5.20 mostram as declaraes das classes Pea
e Fabricante, respectivamente. A figura 5.21 mostra os mesmos mtodos da figura 5.15 agora
instanciados para as classes Pea e Fabricante. Alm de fazer a substituio de nomes genricos
para nomes especficos da instanciao, alguns mtodos de acesso s tabelas devem ser revisados
Pea
Cdigo
Descricao
Fabricante
Custo
Preo
Salvar
Excluir
BuscaCod
BuscaDescr
BuscaDescrTodos
ExisteCod
ExisteDescr
GetCodigo
GetDescricao
GetFabricante
GetCusto
GetPreco
SetCodigo
SetDescricao
SetFabricante
SetCusto
SetPreco
Novo
Fabricante
Codigo
Nome
Salvar
Excluir
BuscaCod
BuscaNome
BuscaNomeTodos
ExisteCod
ExisteNome
GetCodigo
GetNome
SetCodigo
SetNome
Novo
*
1
107
para adaptarem-se ao caso instanciado. Quando outros atributos so adicionados classe, deve
ser feita a incluso de algumas linhas nos mtodos responsveis por atribuir os valores dos
objetos aos parmetros da SQL e vice-versa. Devem tambm ser includos os mtodos para
atribuir e recuperar o valor de um atributo (Set e Get, respectivamente).
type // Definio da Classe Peca
Peca =class
procedure Salvar;
function BuscaCod(x:Integer):Boolean; // Busca objeto por cod
function BuscaDescr(x:String):Boolean; // Busca objeto por descr
procedure BuscaDescrTodos(x:String; ListaFinal: TListBox); // Busca todos objetos
c/descr
function ExisteCod(x:Integer): Boolean; // verifica a existencia por cod
function GetCodigo: Integer;
function GetDescricao: String;
function GetTipo: Fabricante;
function GetCusto: Currency;
function GetPreco: Currency;
procedure SetCodigo(x:Integer);
procedure SetDescricao(x:String);
procedure SetCusto(c1:Currency);
procedure SetPreco(p1:Currency);
procedure SetTipo(tip:Fabricante);
Codigo: Integer;
Descricao: String;
UmTipo: Fabricante;
Custo: Currency;
Preco: Currency;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueCod(x:Integer; atribuir:Boolean): Boolean;
function CarregueDescrTodos(x:String; Lista:TListBox): Boolean;
end;
Figura 5.19 - Cdigo em Delphi referente declarao da classe Pea
A figura 5.22 mostra o cdigo referente ao mdulo de dados criado para fazer acesso
tabela Peca. Ele foi criado com base no mdulo de dados genrico mostrado na figura 5.16,
fazendo a devida adaptao de nomes e incluso de novos atributos para o caso especfico. Deve-
se ressaltar que essa mudana de nomes requer alguns cuidados especiais no ambiente Delphi,
como por exemplo: desativar a propriedade Active do componente TTable antes de informar
o nome da base de dados, ativando-a novamente logo em seguida; modificar a propriedade
Name do componente TDataModule antes de efetuar a mudana automtica dos demais
108
nomes; e colocar o nome da base de dados em todos os componentes TQuery de forma manual,
embora possa ser usado o recurso da tecla Shift para agilizar essa colocao. Ainda que esse
procedimento possa parecer um tanto complicado, a adaptao de um mdulo de dados no leva
mais do que cinco minutos. Conforme j foi dito anteriormente, o procedimento passo a passo
para efetuar essa mudana de forma racional est detalhado em [Bra 98b]. Um exemplo de como
o mdulo de dados DataModulePeca utilizado pelo mtodo Ultimo da classe Peca pode
ser visto na figura 5.21 (c).
type // Definio da Classe Fabricante
Fabricante =class
procedure Salvar;
function BuscaCod(x:Integer):Boolean; // Busca por cod
function BuscaNome(x:String):Boolean; // Busca por nome
procedure BuscaNomeTodos(x:String; ListaFinal: TListBox); // Busca por todos c/nome
function ExisteNome(x:String): Boolean; // verifica a existencia por nome
function GetNome: String;
procedure SetCodigo(x: Integer);
procedure SetNome(x: String);
Codigo: Integer;
Nome: String;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueCod(x:Integer; atribuir:Boolean): Boolean;
function CarregueNome(x:String; atribuir:Boolean): Boolean;
function CarregueNomeTodos(x: String; Lista: TListBox): Boolean;
end;
Figura 5.20 - Cdigo em Delphi referente declarao da classe Fabricante
As figuras 5.23 (a) e (b) mostram o cdigo SQL executado pelos componentes Insercao
e SelecionaPrim, respectivamente, quando eles so invocados por algum mtodo. Nota-se que,
em relao ao esqueleto de cdigo mostrado na figura 5.17, foram acrescentados os outros dois
atributos da classe, bem como os parmetros correspondentes, alm de mudar os nomes dos
atributos comuns de acordo com as colunas da tabela fsica. Na implementao das tabelas
adotou-se a conveno de colocar o sufixo _MODELO nos nomes das colunas das tabelas,
para diferenci-los dos nomes dos atributos na classe correspondente.
109
// Atribuir valor a Codigo
procedure Peca.SetCodigo(x: Integer);
begin
Codigo:=x;
end;
(a)
// Fornecer o Descricao
function Peca.GetDescricao: String;
begin
GetDescricao:=Descricao;
end;
(b)
function Peca.Ultimo: Integer;
var max: Integer;
begin
max :=0;
with DataModulePeca.TabPeca do
begin
First;
while not EOF do
begin
Next;
end;
end;
Ultimo:=max;
end;
(c)
// Salvar um objeto
procedure Fabricante.Salvar;
begin
if (not BuscaCod(Codigo)) and (not BuscaNome(Nome)) then
// Objeto da classe no cadastrado, inseri-lo na tabela
Crie
else
// Objeto da classe j cadastrado, atualizar atributos no-chave
// Atualize; opcao desativada, pois nao existem mais atributos alem dos atributos chave
end;
(d)
Figura 5.21 - Cdigo em Delphi referente a alguns mtodos do padro reconhecido
type TDataModulePeca =class(TDataModule)
TabPeca: TTable;
DataSource1: TDataSource;
Insercao: TQuery;
Atualizacao: TQuery;
Exclusao: TQuery;
SelecionaPrim: TQuery;
SelecionaSec: TQuery;
procedure TabPecaBeforeClose(DataSet: TdataSet);
end;
var
DataModulePeca: TDataModulePeca;
. . .
Figura 5.22 - Mdulo de dados da classe Pea
110
insert into "PECA.db"
(CODIGO_MODELO, DESCRICAO_MODELO, FABRICANTE_MODELO, CUSTO_MODELO,
PRECO_MODELO)
values
(:CODIGO, :DESCRICAO, :TIPO, :CUSTO, :PRECO)
(a)
select * from "PECA.db"
where CODIGO_MODELO=:CODIGO
(b)
Figura 5.23 - Cdigo SQL de alguns componentes do mdulo de dados Peca
A figura 5.24 ilustra a interface para cadastro de peas no sistema exemplo. Essa interface
foi elaborada de forma padronizada, de maneira que possa ser facilmente reutilizada. Alm disso,
o usurio se habitua com seus diversos botes, facilitando o uso e o treinamento.
A figura 5.25 mostra alguns trechos do cdigo relativo interface da figura 5.24. Nele
pode-se observar os seguintes fatos: a utilizao das classes do padro pelo formulrio (linha 5);
a declarao dos objetos da classe (linhas 18 e 19); a instanciao dos objetos das classes Pea
e Fabricante sempre que o formulrio de cadastro de pea ativado (linhas 24 e 25); as
chamadas de mtodos (linhas 27, 28 e 35); e a liberao de memria ocupada pelos objetos
sempre que o formulrio desativado (linhas 42 e 43).
111
Figura 5.24 - Interface da operao de cadastro de peas
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// Formulrio para Cadastro de Peas
unit f_peca;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, ClassePeca, ClasseFabricante, Mask;
type
TFormPeca =class(TForm)
CodigoVisao: TEdit;
DescricaoVisao: TEdit;
ListaFabricantesVisao: TListBox;
FabricanteVisao: TMaskEdit;
. . .
Salvar: TButton;
Sair: TButton;
. . .
procedure SalvarClick(Sender: TObject);
. . .
end;
var
FormPeca: TFormPeca;
p: Peca;
tp:Fabricante;
implementation
{$R *.DFM}
procedure TFormPeca.FormActivate(Sender: TObject);
begin
p:=Peca.Create;
tp:=Fabricante.Create;
LimparControles(True);
tp.BuscaNomeTodos('',ListaFabricantesVisao);
p.SetTipo(tp);
end;
procedure TFormPeca.SalvarClick(Sender: TObject);
begin
if (CompareStr(Trim(DescricaoVisao.Text),'')<>0) then
begin
AtribuirVisaoAObjeto;
p.Salvar;
end
else
ShowMessage('No possvel salvar placa em branco!');
end;
. . .
procedure TFormPeca.FormDeactivate(Sender: TObject);
begin
p.free;
tp.free;
end;
end.
Figura 5.25 - Trecho de cdigo referente ao formulrio de cadastro de peas
112
5.4.2.3 Instanciao do padro Type-Object para Veculo de Cliente/Tipo de Veculo
A figura 5.26 mostra o modelo de objetos para a outra instncia do padro Type-Object,
tambm reconhecida na seo anterior, para o par de classes Veculo de Cliente/Tipo de
Veculo. O cdigo com a declarao dessas classes est na figura 5.27 e os mesmos mtodos da
figura 5.15 instanciados a esse caso esto na figura 5.28.
Figura 5.26 - Modelo de Objetos da outra instncia do padro Type-Object
Ao analisar o modelo da figura 5.13 percebe-se que, alm da semelhana no nvel mais
alto de abstrao que levou generalizao, h tambm uma semelhana entre as classes Class
e TypeClass. Isso pode levar construo de uma superclasse de nvel de abstrao maior,
englobando os atributos e mtodos comuns a essas duas classes. Ento, a instanciao para os
dois casos pode ser feita usando herana. Na verdade houve uma tentativa de fazer essa
superclasse em Delphi, mas surgiram problemas na instanciao de listas (listbox) e das tabelas
da base de dados. Como esses problemas no puderam ser resolvidos a tempo de serem includos
nesta dissertao, fica como sugesto para trabalhos futuros incluir mais essa generalizao.
Comparando a figura 5.19 com a figura 5.27 (a), a figura 5.20 com a 5.27 (b) e a figura
5.21 com a 5.28, pode-se perceber que o reuso quase total, devendo apenas ser mudado o nome
da classe e de seus atributos. Seus mtodos podem ter o nome mudado, embora no seja
necessrio.
Veculo de Cliente
Nro Sequencial
Placa
Tipo
Cliente
Salvar
Excluir
BuscaCod
BuscaPlaca
BuscaPlacaTodos
BuscaClienteTodos
ExisteCod
ExistePlaca
GetNroSequencial
GetPlaca
GetTipo
GetCliente
SetNroSequencial
SetPlaca
SetTipo
SetCliente
Novo
Tipo de Veculo
Codigo
Descricao
Salvar
Excluir
BuscaCod
BuscaDescr
BuscaDescrTodos
ExisteCod
ExisteDescr
GetCodigo
GetDescr
SetCodigo
SetDescr
Novo
*
1
113
type // Definio da Classe Veiculo
Veiculo =class
procedure Salvar;
function BuscaCod(x:Integer):Boolean; // Busca objeto por cod
function BuscaPlaca(x:String):Boolean; // Busca objeto por placa
procedure BuscaPlacaTodos(x:String; ListaFinal: TListBox); // Busca todos objetos c/placa
procedure BuscaClienteTodos(x:Integer; ListaFinal: TListBox); // Busca todos objetos por cliente
function ExistePlaca(x:String): Boolean; // verifica a existencia por placa
function GetNroSequencial: Integer;
function GetPlaca: String;
function GetCliente: Cliente;
function GetTipo: TipoDeVeiculo;
procedure SetNroSequencial(x: Integer);
procedure SetPlaca(x: String);
procedure SetTipo(tip: TipoDeVeiculo);
procedure SetCliente(cli: Cliente);
NroSequencial: Integer;
Placa: String;
UmTipo: TipoDeVeiculo;
UmCliente: Cliente;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueCod(x: Integer; atribuir:Boolean): Boolean;
function CarreguePlaca(x:String; atribuir:Boolean): Boolean;
function CarreguePlacaTodos(x: String; Lista: TListBox): Boolean;
function CarregueClienteTodos(x:Integer; Lista: TListBox):Boolean;
end;
(a)
type // Definio da Classe TipoDeVeiculo
TipoDeVeiculo =class
procedure Salvar;
function BuscaCod(x:Integer):Boolean; // Busca por cod
function BuscaMarcaTipo(x:String):Boolean; // Busca por marca
procedure BuscaMarcaTipoTodos(x:String; ListaFinal: TListBox); // Busca por todos c/marca
function GetMarcaTipo: String;
procedure SetCodigo(atr1: Integer);
procedure SetMarcaTipo(atr2: String);
Codigo: Integer;
MarcaTipo: String;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueCod(x: Integer): Boolean;
function CarregueMarcaTipo(x: String): Boolean;
function CarregueMarcaTipoTodos(x: String; Lista: TListBox): Boolean;
end;
(b)
Figura 5.27 - Cdigo em Delphi da declarao das classes Veculo e Tipo de Veculo
// Atribuir valor a NroSequencial
114
procedure Veiculo.SetNroSequencial(x: Integer);
begin
NroSequencial:=x;
end;
(a)
// Fornecer o Placa
function Veiculo.GetPlaca: String;
begin
GetPlaca:=Placa;
end;
(b)
function Veiculo.Ultimo: Integer;
var max: Integer;
begin
max :=0;
with DataModuleVeiculo.TabVeiculo do
begin
First;
while not EOF do
begin
Next;
end;
end;
Ultimo:=max;
end;
(c)
// Salvar um objeto
procedure TipoDeVeiculo.Salvar;
begin
if (not BuscaCod(Codigo)) and (not BuscaMarcaTipo(MarcaTipo)) then
// Objeto da classe Class no cadastrado, inseri-lo na tabela
Crie
else
// Objeto da classe Class j cadastrado, atualizar atributos no-chave
// Atualize; nao existem mais atributos alem dos atributos chave
end;
(d)
Figura 5.28 - Cdigo em Delphi referente a alguns mtodos da segunda instncia do padro
Neste trabalho optou-se por adaptar os nomes dos mtodos de busca, atribuio e
recuperao, de acordo com os atributos identificador e descritor de cada classe. No entanto,
se toda a equipe de desenvolvimento estiver habituada ao uso do padro, pode ser desejvel
manter o nome genrico para facilitar a manuteno do sistema. Por exemplo, ao fazer uma
busca pela chave primria, o desenvolvedor pode achar mais fcil utilizar sempre o mtodo
BuscaIdent do que ter que lembrar o nome do atributo para decidir-se por BuscaCod,
BuscaNro, etc. Alis, quando utilizada a herana os nomes dos mtodos so nicos nas
classes e subclasses, podendo sobrepor-se apenas o seu contedo.
5.4.2.4 Instanciao do Padro Association-Object para Ordem de Servio
115
A figura 5.29 mostra o modelo de objetos contendo as classes e relacionamentos
necessrios para implementar a operao Abre_Ordem_de_Servio. Essa operao foi utilizada
como exemplo nas sees 4.2 e 4.3, nas quais houve reengenharia com mudana de orientao e
com mudana automtica de linguagem para J ava, respectivamente. Nesta seo essa mesma
operao sofre reengenharia com mudana de linguagem, adotando os padres reconhecidos.
Figura 5.29 - Modelo de Objetos para a operao Abre_Ordem_de_Servio
Na Abertura da Ordem de Servio, efetuada quando o cliente leva o veculo para ser
consertado, esto envolvidas as classes Cliente, Veculo de Cliente, Tipo de Veculo e
Ordem de Servio, como pode ser visto na figura 5.29 e tambm nas figuras 3.9, 3.19 e 4.2.
Dessas classes, Veculo de Cliente desempenha o papel Static-2 no padro Association-
Object, mas j foi implementada na seo 5.4.2.3, juntamente com a classe Tipo de Veculo,
por fazerem parte do padro Type-Object. A classe Ordem de Servio desempenha o papel
Association, conforme visto na seo 5.4.1. A classe Cliente precisa ser implementada
*
1
*
1
Veculo de Cliente
Nro Sequencial
Placa
Tipo
Cliente
Salvar
Excluir
BuscaCod
. . .
Tipo de Veculo
Codigo
Descricao
Salvar
Excluir
BuscaCod
. . .
Cliente
Cdigo
Nome
Endereco
CEP
Cidade
Estado
Telefone
Salvar
Excluir
BuscaCod
BuscaNome
BuscaNomeTodos
ExisteCod
ExisteNome
GetCodigo
GetNome
GetEndereco
GetCEP
GetCidade
GetEstado
GetTelefone
SetCodigo
SetNome
SetEndereco
SetCEP
SetCidade
SetEstado
SetTelefone
Novo
Ordemde Servio
NroOrdemServ
DataEntrada
Defeitos
PreoTotal
DataSada
Veculo
Salvar
Excluir
BuscaNroOS
ExisteNroOS
GetNroOrdemServ
GetDataEntrada
GetDefeitos
GetPreoTotal
GetDataSada
GetVeiculo
SetNroOrdemServ
SetDataEntrada
SetDefeitos
SetPreoTotal
SetDataSada
SetVeiculo
Novo
*
1
116
devido funcionalidade da operao Abre_Ordem_de_Servio. O papel Static-1
desempenhado pela classe Pea, por intermdio da classe Pea da Ordem de Serv., conforme
j explicado na seo 5.4.1. A classe Pea s usada no Fechamento da Ordem de Servio,
quando o veculo acabou de ser consertado e as peas e mo-de-obra so cadastradas. Como o
interesse aqui, para fins de comparao, pela operao Abre_Ordem_de_Servio, o padro
Association-Object implementado ento de forma parcial, deixando de tratar da parte que lida
com a classe Static-1.
A classe Cliente foi implementada com base no esqueleto da classe Class, mostrada
na figura 5.14 (a), j que possui caractersticas semelhantes s classes do padro Type-Object: um
atributo identificador e um atributo descritor (Codigo e Nome, respectivamente). Os
mtodos tambm puderam ser aproveitados, fazendo apenas a adaptao de nomes e incluso dos
demais atributos da classe Cliente.
Para implementao da classe OrdemDeServico, apesar de no haver tanta semelhana
quanto nos outros casos, foi tambm utilizado o esqueleto da classe Class. Diversos mtodos
tiveram que ser eliminados, j que OrdemDeServio no possui um atributo descritor. Porm,
o processo de reuso foi vlido, tendo havido um rendimento bem maior do que se a classe tivesse
sido construda a partir do zero. A figura 5.30 mostra a definio dessa classe e as figuras 5.31
(a) e (b) mostram o corpo de alguns de seus mtodos. Os mtodos mostrados na figura 5.31 (a)
correspondem ao mtodo OBTPROXO, cujo cdigo segmentado consta na figura 4.4 (a) e cujo
cdigo transformado para J ava consta na figura 4.8 (a). Os mtodos mostrados na figura 5.31 (b)
correspondem ao mtodo GRORDSER, cujo cdigo segmentado consta na figura 4.4 (d) e cujo
cdigo transformado para J ava consta na figura 4.8 (d). O mtodo GRORDSER foi
desmembrado em quatro mtodos para isolar o acesso s tabelas da base de dados pelo uso do
padro CRUD, conforme explicado na seo 5.4.2.1.
Alguns mtodos que foram necessrios devido s caractersticas da linguagem Clipper
no possuem o correspondente na implementao em Delphi, como, por exemplo, os mtodos
para abertura e fechamento de arquivos e os mtodos para leitura de dados de interface. Em
Delphi, no existe um mtodo que implemente a lgica da operao Abre_Ordem_de_Servio.
Em vez disso, o formulrio de entrada da Ordem de Servio que faz a chamada dos mtodos e
sua sincronizao, de acordo com a lgica desejada. Esse formulrio de entrada tambm faz a
leitura de dados por intermdio de componentes visuais. A abertura e o fechamento dos arquivos
117
da base de dados so de responsabilidade do mdulo de dados de cada classe, sendo programados
pelo desenvolvedor em tempo de projeto.
type // Definio da Classe Ordem de Servico
OrdemDeServico =class
procedure Salvar;
function BuscaNroOS(x:Integer):Boolean; // Busca objeto por NroOS
function ExisteNroOS(x:Integer): Boolean; // verifica a existencia por NroOS
function GetNroOrdemServ: Integer;
function GetDataEntrada: TDateTime;
function GetDefeitos: String;
function GetPrecoTotal: Currency;
function GetDataSaida: TDateTime;
function GetVeiculo: Veiculo;
procedure SetNroOrdemServ(x: Integer);
procedure SetDataEntrada(x: TDateTime);
procedure SetDefeitos(x: String);
procedure SetPrecoTotal(x: Currency);
procedure SetDataSaida(x: TDateTime);
procedure SetVeiculo(x: Veiculo);
NroOrdemServ: Integer;
DataEntrada: TDateTime;
Defeitos: String[80];
PrecoTotal: Currency;
DataSaida: TDateTime;
UmVeiculo: Veiculo;
procedure Crie;
procedure Atualize;
procedure Elimine;
function CarregueNroOS(x: Integer; atribuir:Boolean): Boolean;
end;
Figura 5.30 - Definio da classe OrdemDeServio
A figura 5.32 mostra a tela de abertura do sistema, no momento em que a opo de
Abertura da Ordem de Servio requisitada pelo usurio, por intermdio de um menu. A figura
5.33 mostra a interface para Abertura da Ordem de Servio. Deve-se observar que a disposio
dos botes na parte inferior da janela semelhante das demais operaes do sistema, como a
mostrada na figura 5.24. Trs botes foram adicionados: Cliente..., para permitir que o usurio
faa a busca de clientes j cadastrados com maior rapidez, inclua novos clientes ou modifique
dados de um determinado cliente; Novo Veculo..., para incluso de um novo veculo, se for o
caso; e Eliminar Veculo, para eliminar os veculos da lista que no pertenam mais ao cliente.
118
// Obter um novo nro de objeto
function OrdemDeServico.Novo: Integer;
begin
Novo:=Ultimo+1;
end;
// Obter o ltimo nro de ordem de servio registrado
function OrdemDeServico.Ultimo: Integer;
var max: Integer;
begin
max :=0;
with DataModuleOrdemDeServico.TabOrdemDeServico do
begin
First;
while not EOF do
begin
Next;
end;
end;
Ultimo:=max;
end;
(a)
// Salvar um objeto
procedure OrdemDeServico.Salvar;
begin
if (not ExisteNroOS(NroOrdemServ)) then
// Objeto no cadastrado, inseri-lo na tabela
Crie
else
// Objeto j cadastrado, atualizar atributos no-chave
Atualize;
end;
// Criar novo registro
procedure OrdemDeServico.Crie;
begin
AtribuirObjetoAParametro(DataModuleOrdemDeServico.Insercao);
DataModuleOrdemDeServico.Insercao.ExecSQL;
end;
// Atualizar registro
procedure OrdemDeServico.Atualize;
begin
AtribuirObjetoAParametro(DataModuleOrdemDeServico.Atualizacao);
DataModuleOrdemDeServico.Atualizacao.ExecSQL;
end;
// Atribuir objeto aos parametros de busca
procedure OrdemDeServico.AtribuirObjetoAParametro(x:TQuery);
begin
with x do
begin
ParamByName('NroOrdemServ').AsInteger:=NroOrdemServ;
ParamByName('DataEntrada').AsDateTime:=DataEntrada;
ParamByName('Defeitos').AsString:=Defeitos;
ParamByName('DataSaida').AsDateTime:=DataSaida;
ParamByName('PrecoTotal').AsCurrency:=PrecoTotal;
ParamByName('CodigoVeiculo').AsInteger:=UmVeiculo.GetNroSequencial;
end;
end;
(b)
Figura 5.31 - Alguns mtodos da classe OrdemDeServio
119
Figura 5.32 - Interface do sistema mostrando um dos menus
Figura 5.33 - Interface da operao de Abertura da Ordem De Servio
120
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
unit f_ordemdeservico; // Formulrio para Cadastro de Veiculos de
Cliente
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
ClasseVeiculo, ClasseTipoDeVeiculo, ClasseCliente, ClasseOrdemDeServico,
StdCtrls, Mask;
type
TformAberturaOrdemDeServico =class(TForm)
NroOrdemServVisao: TEdit;
PlacaVisao: TEdit;
Buscar: TButton;
NovaOS: TButton;
Salvar: TButton;
Sair: TButton;
Excluir: TButton;
ClienteVisao: TEdit;
BotaoCliente: TButton;
BotaoVeiculo: TButton;
DataEntradaVisao: TMaskEdit;
MarcaVisao: TEdit;
DefeitosVisao: TMemo;
ListaVeiculosVisao: TListBox;
Eliminarveiculo: TButton;
. . .
procedure SalvarClick(Sender: TObject);
procedure LimparControles;
procedure AtribuirVisaoAObjeto;
procedure AtribuirObjetoAVisao;
procedure FormActivate(Sender: TObject);
procedure BuscarClick(Sender: TObject);
procedure NovaOSClick(Sender: TObject);
procedure SairClick(Sender: TObject);
procedure FormDeactivate(Sender: TObject);
procedure ExcluirClick(Sender: TObject);
procedure BotaoClienteClick(Sender: TObject);
procedure BotaoVeiculoClick(Sender: TObject);
procedure ClienteVisaoExit(Sender: TObject);
procedure ListaVeiculosVisaoClick(Sender: TObject);
procedure EliminarveiculoClick(Sender: TObject);
end;
. . .
procedure TformAberturaOrdemDeServico.NovaOSClick(Sender: TObject);
begin
LimparControles;
NroOrdemServVisao.Text:=IntToStr(os.Novo);
os.SetNroOrdemServ(StrToInt(NroOrdemServVisao.Text));
DataEntradaVisao.text:=DateTimeToStr(date);
DataEntradaVisao.SetFocus;
end;
procedure TformAberturaOrdemDeServico.BotaoClienteClick(Sender: TObject);
begin
FormCliente.NomeVisao.Text:=ClienteVisao.Text;
FormCliente.FormActivate(self);
FormCliente.Buscar.Click;
FormCliente.ShowModal;
ClienteVisao.Text:=FormCliente.NomeVisao.Text;
end;
procedure TFormAberturaOrdemDeServico.ClienteVisaoExit(Sender: TObject);
begin
if ((ClienteVisao.Text <>'') and (c.BuscaNome(ClienteVisao.Text+'%'))) then
begin
ClienteVisao.Text:=c.GetNome;
v.BuscaClienteTodos(c.GetCodigo,ListaVeiculosVisao);
end;
end;
. . .
Figura 5.34 - Trechos do cdigo referente ao formulrio de Abertura da Ordem De Servio
A figura 5.34 mostra trechos do cdigo referentes ao formulrio de abertura da Ordem de
Servio. Conforme citado anteriormente, esse formulrio corresponde operao
121
Abre_Ordem_de_Servio. A lgica envolvida na operao ditada pelos eventos possveis em
cada um dos componentes do formulrio. Por exemplo, nas linhas 40 a 47 da figura 5.34 est o
mtodo executado quando o usurio ativa o boto Nova OS e nas linhas 48 a 55 est o mtodo
referente ativao do boto Cliente. No primeiro caso, o mtodo Novo da classe
OrdemDeServico invocado (linha 43) e os componentes do formulrio so atualizados para
refletir a nova ordem de servio. No segundo caso, outro formulrio de entrada de dados
ativado (linhas 50 a 53) e, ao retornar desse, faz-se a atualizao do componente que mostra o
nome do cliente (linha 54).
Conforme pode ser observado nas linhas 24 a 38, existem mtodos associados ativao
de todos os botes do formulrio e tambm mtodos associados navegao por alguns dos
componentes de entrada de dados. Por exemplo, quando o usurio digita o nome do cliente e
avana para outro componente, gerado o evento Exit, que dispara o mtodo
ClienteVisaoExit (linha 36). Esse mtodo d o tratamento adequado a esse evento, mostrado
nas linhas 56 a 63, que basicamente trata de verificar a existncia de tal cliente e buscar seus
veculos cadastrados, colocando-os na lista de veculos do cliente.
A ocorrncia de diversas instncias do mesmo padro no sistema aumenta
significativamente o reuso, acelerando o processo de reengenharia. A estratgia proposta
centrada na importncia de saber identificar a ocorrncia de padres, para poder tirar proveito
deles. O cdigo resultante do uso de padres claro e de fcil entendimento.
As diversas experincias de implementao efetuadas mostraram que o tempo gasto para
instanciar o padro Type-Object significativamente menor do que se ele fosse programado a
partir do zero. Em cerca de quarenta minutos pode-se ter uma instncia do padro programada e
em condies de ser executada.
Algumas classes participam de mais de um padro, como a Veiculo de cliente, que
desempenha o papel Class no padro Type-Object e o papel Static-2 no padro Association-
Object. Nesse caso, aps implementar um dos padres j se tem a classe programada, o que
facilita a implementao do outro padro no qual ela ocorre.
122
CAPTULO 6 Concluses Finais e Sugestes para novas pesquisas
Foi proposta nesta dissertao uma abordagem para reengenharia de sistemas, com uso de
padres de software para maximizar o reuso e melhorar a manutenibilidade. Algumas atividades
intermedirias foram desenvolvidas. A engenharia reversa do sistema legado foi efetuada, tendo
sido proposto um detalhamento do passo de abstrao do Modelo de Anlise do Sistema. A
reengenharia com mudana de orientao foi realizada, transformando o sistema originalmente
procedimental em um sistema com caractersticas da orientao a objetos. A reengenharia com
mudana de linguagem de programao foi feita, transformando o cdigo fonte de Clipper para
J ava. Foi, ento, estabelecida uma estratgia para reconhecimento de alguns padres recorrentes
de sistemas de informao, a partir do modelo de objetos produzido na engenharia reversa.
Finalmente, foi executada a reengenharia com uso de padres de software, utilizando a
linguagem Delphi.
Na seo 6.2 so feitas as concluses gerais de todo o trabalho desenvolvido. Na seo
6.3 so apresentadas as contribuies deste trabalho e na seo 6.4 esto as sugestes para novas
pesquisas.
6.2 Concluses Gerais
A engenharia reversa forneceu a documentao de anlise orientada a objetos necessria
para a reengenharia pretendida e para o reconhecimento de padres.
A realizao da reengenharia com mudana de orientao do paradigma de
desenvolvimento do sistema obteve xito. Um sistema originalmente desenvolvido com
orientao procedimental foi transformado segundo o paradigma da orientao a objetos, sem
mudana de funcionalidade ou linguagem de programao. Com isso, obteve-se maior
compatibilidade entre o modelo de anlise obtido pelo Fusion/RE e o cdigo fonte. Se somente a
engenharia reversa tivesse sido efetuada, haveria maior dificuldade em associar o cdigo aos
componentes do modelo de anlise.
123
A realizao da reengenharia com mudana automtica de linguagem tornou possvel a
integrao do processo geral Fusion/RE com a mquina Draco-Puc, pelo acrscimo de dois
passos novos ao Fusion/RE e pela construo dos elementos necessrios na mquina Draco-Puc
para que ela pudesse trabalhar com outros domnios. A reconstruo de software para que ele
possa ser executado em novas plataformas de hardware e software permite sua melhora sem
perder a funcionalidade. A abordagem utilizada acrescenta a isso melhor documentao do
sistema em nveis mais altos de abstrao, essencial para uma boa manutenibilidade. O cdigo
Clipper poderia ter sido transformado para J ava sem a segmentao prvia, mas dessa forma o
cdigo resultante no tiraria proveito dos recursos de orientao a objetos, resolvendo apenas o
problema de portabilidade. A fase de segmentao que garante as caractersticas do sistema
resultante.
A identificao de padres no modelo de anlise obtido pela engenharia reversa tornou
possvel a implementao em Delphi com maior racionalidade. A estratgia para reconhecimento
de padres proposta mostrou-se eficiente nos casos em que foi aplicada.
A comparao do sistema legado em Clipper com os sistemas obtidos aps a
reengenharia (Sistema Segmentado Clipper, Sistema transformado para J ava e Sistema em
Delphi com uso de padres), mostrada na tabela 6.1.
Todos os sistemas obtidos pela reengenharia so mais fceis de manter em relao ao
cdigo legado, mas existe uma vantagem marcante do cdigo que usa padres de software.
Quanto legibilidade, o cdigo transformado automaticamente para J ava deixa um pouco a
desejar. Da forma como foi definida a transformao de comandos de Clipper para J ava, a
maioria
das funes Clipper foi implementada como um mtodo em J ava. O cdigo resultante parece ser
uma mistura do Clipper e do J ava, no sendo compreendido facilmente nem por um programador
Clipper, nem por um programador J ava. As vantagens da reengenharia para J ava foram quanto
portabilidade, j que essa linguagem independente de plataforma, ao passo que as outras no, e
quanto ao tempo gasto na transformao, que insignificante aps a segmentao e construo
dos domnios apropriados. Deve-se observar que parte dos problemas notados podem ser
resolvidos com a definio de outras estratgias de transformao, com base na experincia e
aprendizado obtidos com este primeiro experimento.
O reuso superior no sistema que usa padres, j que so reusados desde os conceitos de
anlise e projeto at os detalhes de implementao. Todas as formas de reengenharia implicam
124
em custos. Porm, a segmentao parece ser mais vivel economicamente, pois pode ser feita aos
poucos, utilizando o prprio pessoal habituado linguagem Clipper.
Tabela 6.1 Comparao dos resultados
Caracterstica Sistema Legado
em Clipper
Sistema Segmentado
em Clipper
Sistema transfor-
mado para Java
usando Draco-Puc
Sistema em Delphi,
com uso de padres
Legibilidade Boa, pois o programa
est estruturado
Boa, embora os
parmetros includos
na segmentao
aumentem o grau de
acoplamento
Boa, pois a
transformao
mantm a estrutura
do cdigo segmenta-
do, apesar do cdigo
no ser tpico de um
programa em J ava.
Excelente, devido aos
nomes mnemnicos e
estruturao
permitida pelo uso de
classes.
Manuteno Dificultada devido s
anomalias
Facilitada, pois os
mtodos ficam
agrupados no arquivo
de cada classe
Facilitada, apesar da
legibilidade do
cdigo no ser boa
Facilitada, pois a
estrutura do sistema
uniformizada
Reuso Limitado a sistemas
com funcionalidade
semelhante
Bom, devido ao
grande nmero de
mdulos com
funcionalidade bem
definida
Bom, devido ao
grande nmero de
mdulos com funcio-
nalidade bem defini-
da, apesar do proble-
ma de legibilidade
Muito bom, pois
abrange desde a
anlise, projeto at a
implementao das
classes, mdulos de
dados e formulrios
Esforo para
reengenharia
- Pode ser feita de for-
ma gradual, focali-
zando primeiramente
os mdulos de manu-
teno mais crtica.
No h necessidade
de mudana de
pessoal.
O maior custo est na
fase de segmentao
e na construo dos
domnios origem e
destino. Uma ferra-
menta de auxlio
poderia diminuir esse
custo. H necessida-
de de pessoal espe-
cializado para uso
dessa tcnica.
Deve haver um custo
no treinamento do
pessoal no uso de
padres e, se for o
caso, no uso de uma
linguagem orientada
a objetos.
Portabilidade Especfico para
plataforma DOS
Especfico para
plataforma DOS
Independente de
plataforma de
hardware ou software
Especfico para
plataforma Windows
Interface com o
usurio
Pobre Pobre Pobre Rica
Usabilidade Regular Regular Regular Boa
Desempenho timo timo Bom Bom
Quanto interface com o usurio, o sistema legado apresenta uma interface pobre,
baseada em janelas do ambiente DOS, sem muitos recursos para facilitar sua operao. O
sistema segmentado mantm essa interface, assim como o sistema transformado para J ava. Desta
forma, a reengenharia para Delphi a nica que fez a modernizao da interface, oferecendo ao
usurio todos os recursos dos ambientes atuais. Deve-se ressaltar que a mudana de interface
125
pode tambm ser feita no sistema em J ava, para aproveitar melhor seus recursos, mas essa
mudana deve ser feita manualmente, aps o processo de transformao. A interface influi
tambm na usabilidade, que pode ser melhorada empregando os recursos das linguagens
modernas, tais como botes, listas, ajuda sensvel ao contexto, etc.
O desempenho dos sistemas, em termos de tempo de execuo, foi testado em mquinas
Pentium 233 Mhz com Windows 95. Obteve-se melhor resultado nos sistemas Clipper do que
nos sistemas J ava e Delphi. Isso principalmente devido ao fato de que aplicaes DOS so bem
mais enxutas em relao a aplicaes WINDOWS.
A experincia de reuso efetuada durante este trabalho extremamente compensadora.
Quando comparado ao reuso que tenho feito dentro de minha prtica profissional, conforme
mencionado na seo 1.2, sua eficincia fica ainda mais evidente. Unidos s vantagens oferecidas
pela orientao a objetos, os padres aceleram o processo de desenvolvimento, por embutirem
solues para problemas na maioria das vezes comuns, mas cuja freqncia de ocorrncia
acarreta tempo substancial de desenvolvimento.
6.3 Contribuies deste trabalho
Alm de alcanar o objetivo de reconhecimento de padres de software teis no reuso,
ampliao de funcionalidade e manuteno de sistemas, vrios subprodutos originaram-se deste
trabalho: o detalhamento da abstrao do modelo de anlise do sistema, a abordagem para
mudana de orientao do sistema como preparao para a mudana automtica de linguagem e
os esqueletos de classes para a implementao do padro Type-Object.
A contribuio mais significativa o fornecimento de uma estratgia para
reconhecimento de padres especficos de sistemas de informao, tanto na engenharia reversa
de sistemas legados quanto na engenharia avante de sistemas. O uso de padres implica em
aumento de produtividade, maior uniformidade na estrutura do software e reduo da
complexidade, pois blocos construtivos podem ser usados na elaborao de sistemas maiores. A
estratgia geral proposta pode ser seguida por outros engenheiros de software durante a
engenharia reversa ou avante de sistemas. Por meio dessa estratgia o reuso poder ser expandido
a nveis mais altos de abstrao, ao invs de se manter puramente no nvel do cdigo. Na
engenharia reversa esses padres podem ser reconhecidos aps a recuperao do Modelo de
Objetos do Sistema. Na engenharia avante esses padres podem ser reconhecidos aps o projeto
126
do sistema e utilizados na implementao. A realizao da reengenharia com mudana de
linguagem adotando os padres reconhecidos permitiu a visualizao dos padres depois de
programados em uma linguagem comercial, o Delphi no caso. Com isso, pde-se avaliar a
melhoria da manutenibilidade do sistema que possui padres refletidos no cdigo fonte.
O detalhamento da abstrao do modelo de anlise do sistema reforou o mtodo
Fusion/RE, facilitando sua aplicao a sistemas de informao. A transio do Modelo de
Objetos do Sistema Atual, construdo com influncia da implementao atual, para o Modelo de
Objetos do Sistema, que deve refletir o domnio de aplicao num nvel de abstrao mais alto,
complexa. O detalhamento sugerido ameniza essa transio, diminuindo o salto que era antes
dado entre um modelo e outro.
O estabelecimento de uma abordagem para mudana de orientao do paradigma de um
sistema, de procedimental para orientado a objetos, por intermdio da segmentao, torna
possvel a reengenharia de mudana de orientao sem mudana de linguagem de programao.
Sistemas importantes para as empresas, mas com alto custo de manuteno, podem passar por
esse processo e ter facilitada sua manuteno. A segmentao elimina as anomalias no cdigo
fonte, tornando-o um cdigo programado pelo conceito de tipos abstratos de dados. Isso feito
em continuidade ao trabalho de Penteado [Pen 96], no qual as anomalias so detectadas durante a
engenharia reversa pelo Fusion/RE e os mtodos necessrios para resolver essas anomalias so
indicados de forma textual, no chegando a ser implementados no cdigo. O cdigo segmentado
Clipper tambm utilizado como entrada para a transformao automtica pela mquina Draco-
Puc, que nesse experimento o transforma para a linguagem J ava. Se a transformao fosse feita
sem a segmentao prvia, o cdigo resultante no traria as vantagens da orientao a objetos.
O fornecimento de esqueletos das classes para servirem como base para implementao,
em Delphi, do padro Type-Object, facilita o uso desse padro. Desenvolvedores podem ter um
ponto de partida que os estimule ao uso de padres de software e ao desenvolvimento de uma
biblioteca com os padres usados com mais freqncia. A linguagem Delphi, comumente
utilizada em sistemas de informao comerciais, provou ser adequada para a implementao de
padres, embora a literatura consultada no mencione esse fato.
6.4 Sugestes para futuras pesquisas
127
O processo de segmentao foi executado de forma manual, auxiliado somente por um
editor de textos. Inicialmente esse processo consumiu bastante tempo mas, depois de adquirir
alguma experincia, houve um aumento na eficincia. Isso explicado pelo carter repetitivo das
tarefas envolvidas na segmentao. Assim, uma possvel pesquisa poderia ser a construo de
uma ferramenta de auxlio computadorizado segmentao. Tarefas tais como a identificao de
anomalias, isolamento de trechos em mtodos (slices), etc. poderiam ser facilitadas por tal
ferramenta, eliminando muito do trabalho tedioso e repetitivo. Acredita-se que a interveno do
engenheiro de software seja fundamental durante o processo de segmentao, no sendo possvel,
portanto, a segmentao totalmente automtica.
O reconhecimento de padres a partir dos modelos de anlise do sistema tambm foi feito
de forma manual, embora existam diversas indicaes de que alguns padres pudessem ser
descobertos com o auxlio de uma ferramenta especificamente projetada para tal. O
conhecimento do domnio de aplicao essencial no reconhecimento de padres de anlise, mas
a construo sinttica tambm pode ajudar, descartando classes sem chance de se encaixar no
padro. A ferramenta poderia auxiliar na anlise da construo sinttica.
Aps o reconhecimento dos padres, sua utilizao em futuros desenvolvimentos poderia
ser mais encorajada se eles ficassem disponveis em um repositrio. Esse repositrio de padres
poderia englobar classes prontas, pr-programadas em diversas linguagens, que poderiam ser
usadas facilmente instanciando-se o padro para a aplicao especfica, de forma similar aos
esqueletos apresentados na seo 5.4.2.1.
A implementao dos esqueletos de classes para o padro Type-Object poderia evoluir
para um framework que englobasse diversos padres recorrentes, facilitando ainda mais seu
reuso em novas aplicaes.
128
Bibliografia
[Arm 98] Armstrong, M. N.; Trudeau, C. Evaluating Architectural Extractors. In: IEEE
Working Conference on Reverse Engineering, 5., Honolulu, Hawai, EUA, outubro
de 1998. Anais. LosAlamitos-CA, EUA, IEEE Computer Society, p. 30-39.
[Ben 92] Benedusi, P.; Cimitile, A; Carlini, U. Reverse Engineering Processes, Design
Document Production and Structure Charts. J . Systems Software, V.19, p. 225-245,
1992.
[Ben 96] Benedusi, P. Improving reverse engineering models with test-case related
knowledge. Information and Software Technology, V.38, p.711-718, 1996.
[Big 89] Biggerstaff, Ted. J . Design Recovery for Maintenance and Reuse. Computer-IEEE,
p. 36-49, julho 1989.
[Big 94] Biggerstaff, Ted J .; Mitbander, Bharat G.; Webster, Dallas E. Program
Understanding and the Concept Assignment Problem. Communications of the
ACM, V.37, n5, maio 1994.
[Bos 97] Bosch, J an. Design Patterns as Language Constructs. Disponvel a partir da Wide
World Web <URL:http://st-www.cs.uiuc.edu/users/patterns/papers>, 1997.
[Boy 98] Boyd, L. Business Patterns of Association Objects. In: Martin, R.C.; Riehle, D.;
Buschmann, F. Pattern Languages of Program Design 3. Reading, MA, Addison-
Wesley, 1998, p. 395-408.
[Bra 86a] Braga, Rosana T.V. Construo pelo mtodo de Jackson de um prottipo em Dbase
II do sistema de processamento de Concurso de Jornal especificado por Jackson.
So Carlos, USP, 1986. (Relatrio apresentado FAPESP, dentro do plano de bolsa
de iniciao cientfica referente ao processo 85/0405-9)
[Bra 86b] Braga, Rosana T.V. Aplicao de um instrumento de apoio por computador ao
mtodo Gane. So Carlos, USP, 1986. (Relatrio apresentado FAPESP, dentro do
plano de bolsa de iniciao cientfica referente ao processo 85/0405-9)
[Bra 90] Braga, Rosana T.V. Manual de Uso do Sistema de Oficina Auto-eltrica e
Mecnica. So Carlos, 1990. (Documento de Trabalho)
[Bra 98a] Braga, Rosana T.V.; Masiero, Paulo C. Detalhamento do passo de abstrao do
modelo de anlise do mtodo Fusion/RE. So Carlos, USP, maro de 1998.
(Relatrio Tcnico do ICMSC-USP, 70)
[Bra 98b] Braga, Rosana T.V.; Germano, Ferno S.R.; Masiero, Paulo C. Experimentos para
implementao do padro Type-Object em linguagem Delphi. So Carlos, USP,
1998. (Relatrio Tcnico do ICMSC-USP, em elaborao)
129
[Bud 96] Budinsky, F.J , et al. Automatic code generation from design patterns. IBM Systems
J ournal, V. 35, n 2, p. 151-171, 1996.
[Bus 97] Buschmann, Frank, et al. Pattern-Oriented Software Architecture. European
Conference on Object-Oriented Programming, 11., Finland, J unho 1997. Anais.
Finland.
[Cam 97] Campo, Marcelo; Price, R.T. Automated Recognition of Design Patterns for
Framework Understanding. (Comunicao particular), 1997.
[Can 97] Cantu, Marco. Dominando o Delphi 2. So Paulo, Makron Books, 1997.
[Can 98] Cantu, Marco; Gooch, Tim; Lam, J ohn F. Delphi Developers Handbook. Alameda-
CA, Sibex, 1998.
[Chi 90] Chikofsky, Elliot J .; Cross, J ames H. Reverse Engineering and Design Recovery: a
Taxonomy. IEEE Software, p. 13-17, janeiro 1990.
[Coa 92] Coad, Peter. Object-Oriented Patterns. Communications of the ACM, V. 35, n9, p.
152-159, setembro 1992.
[Col 94] Coleman D. et al. Object Oriented Development - The Fusion Method. Prentice
Hall, 1994.
[Cop 92] Coplien, J .O. Advanced C++ Programming Styles and Idioms. Reading-MA,
Addison-Wesley, 1992.
[Eri 98] Eriksson, H.; Penker, M. UML Toolkit. New York, Wiley Computer Publishing,
1998.
[Fer 95] Ferreira, Aurlio B.H. Dicionrio Aurlio Bsico da Lngua Portuguesa. So Paulo,
Editora Nova Fronteira, 1995.
[Fin 97] Finnigan, P. J . et al. The Software bookshelf. IBM Systems J ournal, V. 36, n 4, p.
564-593, 1997.
[Fow 97] Fowler, M. Analysis Patterns. Menlo-Park-CA, Addison-Wesley, 1997.
[Fow 98] Fowler, M.; Scott, K. UML Distilled Applying the standard object modeling
language. Reading, Massachusetts, Addison-Wesley, 1998.
[Gal 95] Gall, Harald C., Klsh, Ren R.; Mittermeir, Roland T. Architectural
Transformation of Legacy Systems. International Conference on Software
Engineering, 11., Abril 1995. (Technical Report n CS95-418)
[Gal 96] Gall, Harald C., Klsh, Ren R.; Mittermeir, Roland T. Application Patterns in Re-
Engineering: Identifying and Using Reusable Concepts. International Conference
on Information Processing and Management of Uncertainty in Knowledge-Based
Systems, 6., J ulho 1996. Anais. p. 1099-1106.
130
[Gam 93] Gamma, E.; Helm, R.; J ohnson,R.; Vlissides, J . Design Patterns - Abstraction and
Reuse of Object-Oriented Design. LNCS, n 707, p. 406-431, julho de 1993.
[Gam 95] Gamma, E.; Helm, R.; J ohnson, R.; Vlissides, J . Design Patterns - Elements of
Reusable Object-Oriented Software. Reading-MA, Addison-Wesley, 1995.
[Gan 83] Gane, Chris, Sarson, Trish. Anlise Estruturada de Sistemas, Rio de J aneiro, Livros
Tcnicos e Cientficos Editora S. A., 1983.
[Hai 96] Hainaut, J -L et al. Structure Elicitation in Database Reverse Engineering. In:
Working Conference on Reverse Engineering (WCRE), 3., Monterey-California,
1996. Anais. IEEE, 1996, p. 131-140.
[Hai 96a] Hainaut, J -L. Ajuda on-line do DB-MAIN - Demo Version 2.01. 1996. (Manual
tcnico)
[J ac 83] J ackson, M. System Development. Englewood Cliffs-NJ , Prentice-Hall International
Inc., 1983.
[J ac 91] J acobson, Ivar e Lindstrom, Fredrik. Re-engineering of old systems to an object-
oriented architecture. In: Conference on Object Oriented Programming Systems,
Languages and Applications (OOPSLA). Anais. 1991, p. 340-350.
[J oh 98] J ohnson, R.; Woolf, B. Type Object. In: Martin, R.C.; Riehle, D.; Buschmann, F.
Pattern Languages of Program Design 3. Reading-MA, Addison-Wesley, 1998, p.
47-65.
[Klo 96] Klsh, Ren R. Reverse Engineering: Why and How to Reverse Engineer Software.
In: California Software Symposium (CSS), California, EUA, abril de 1996. Anais.
University of Southern California, 1996, p. 92-99.
[Kra 96] Krmer, Christian; Prechelt, Lutz. Design Recovery by Automated Search for
Structural Design Patterns in Object-Oriented Software. In: Working Conference
on Reverse Engineering (WCRE), 3., Monterey-CA, EUA, 1996. Anais. IEEE,
1996, p. 208-215.
[Mar 94] Markosian, Lawrence, et al. Using na Enabling Technology to Reengineer Legacy
Systems. Communications of the ACM, V.37, n5, p. 58-70, maio 1994.
[Mar 98] Martin, R.C.; Riehle, D.; Buschmann, F. (eds.) Pattern Languages of Program
Design 3, Reading-MA, Addison-Wesley, 1998.
[May 95] Mayrhauser, Anneliese von; Vans, A. M. Program Comprehension During
Software Maintenance and Evolution. Computer-IEEE, p.44-55, agosto 1995.
[May 96] Mayrhauser, Anneliese von; Vans, A. M. Identification of Dynamic Comprehension
Processes During Large Scale Maintenance. IEEE Transactions on Software
Engineering, V.22, n 6, junho 1996.
131
[Mas 88] Masiero, Paulo C.; Germano, Fernao S.R. JSD as an Object Oriented Design
Method. Software Engineering Notes, V.13, n 3, julho 1988.
[Nei 84] Neighbors, J .M. The Draco Approach to Constructing Software from Reusable
Components. IEEE Transactions on Software Engineering, V.SE-10, n 5, p. 564-
77, 1984.
[Nin 94] Ning, J im Q.; Engberts, A.; Kozaczynsku, W. Automated Support for Legacy Code
Understanding. Communications of the ACM, V.37, n 5, p. 50-57, maio 1994.
[Oli 91] Oliveira, J acqueline A.; Braga, Rosana T.V. Documentao Tcnica do Sistema de
Oficina Auto-eltrica e Mecnica. So Carlos, 1991 (Documento de Trabalho)
[Pen 95] Penteado, R.D., Germano, F.; Masiero, P.C. Engenharia Reversa Orientada a
Objetos do Ambiente StatSim: Mtodo Utilizado e Resultados Obtidos, In:
Simpsio Brasileiro de Engenharia de Software, 9., Recife-PE, 1995. Anais. Recife,
UFPE, 1995. p. 345-351.
[Pen 96] Penteado, R.D. Um mtodo para Engenharia Reversa Orientada a Objetos. So
Carlos, 1996. 251p. Tese (Doutorado) - Instituto de Fsica de So Carlos,
Universidade de So Paulo.
[Pen 96a] Penteado, R.D., Germano, F.; Masiero, P.C. An Overall Process Based on Fusion to
Reverse Engineer Legacy Code. In: Working Conference on Reverse Engineering,
3., Monterey-CA, 1996. Anais. IEEE, 1996, p. 179-188.
[Pen 96b] Penteado, R.D., Germano, F.; Masiero, P.C. Melhoria na Manutenibilidade de
Software Legado com Base em Engenharia Reversa. In: Conferncia Internacional
de Tecnologia de Software - Qualidade de Sofware, 7., Curitiba-PR, 1996. Anais.
Curitiba, PUC-PR, p. 155-169.
[Pen 98a] Penteado, Rosangela D.; Braga, Rosana T.V.; Masiero, Paulo C. Improving the
Quality of Legacy Code by Reverse Engineering. In: International Conference of
Information Systems Analysis and Synthesis, 4., Orlando-FL, EUA, julho de 1998.
Anais. Orlando-FL, EUA, International Institute of Informatics, p. 364-370.
[Pen 98b] Penteado, Rosangela D.; Masiero, Paulo C.; Prado, Antonio F.; Braga, Rosana T.V.
Reengineering of Legacy Systems Base on Transformation Using the Object
Oriented Paradigm. In: IEEE Working Conference on Reverse Engineering, 5.,
Honolulu-HI, EUA, outubro de 1998. Anais. LosAlamitos-CA, EUA, IEEE
Computer Society, p. 144-153.
[Pra 92] Prado, A.F. Estratgia de Reengenharia de Software Orientada a Domnios. Rio
de J aneiro, 1992. 333p. Tese (Doutorado) Pontifcia Universidade Catlica do Rio
de J aneiro.
[Pre 95] Pressman, Roger S. Engenharia de Software. So Paulo, Makron Books, 1995.
[Rek 85] Rekoff, M. G. On Reverse Engineering. IEEE Transactions on Systems, Man and
Cybernetics, V.SMC-15, n 2, p. 244-252, Maro-Abril 1985.
132
[Ric 90] Rich, Charles; Wills, Linda M. Recognizing a Programs Design: A Graph-Parsing
Approach. IEEE Software, p. 82-89, J aneiro 1990.
[Rob 91] Robson, D.J .; Bennet, K.H.; Cornelius, B.J .; Munro, M. Approaches to Program
Comprehension. J .Systems Software, V.14, p. 79-84, fevereiro 1991.
[Sag 95] Sage, Andrew P. Systems Engineering and Systems Management for Reengineering,
J ournal Systems Software, V.30, p. 3-25, 1995.
[Sem 95] Semmel, R. D. e Winkler, R. P. Integrating Reengineered Databases to Support
Data Fusion. J ournal Systems Software, V.30, p. 127-135, 1995.
[Shn79] Shneiderman, Ben; Mayer, Richard Syntatic/Semantic Interactions in Programmer
Behavior: A Model and Experimental Results. International J ournal of Computer
and Information Sciences, V.8, n 3, p. 219-238, 1979.
[Sne 95] Sneed, Harry M.; Nvry, Erika. Extracting Object-Oriented Specification from
Procedurally Oriented Programs, In: Working Conference on Reverse Engineering
(WCRE), 2., Toronto, Canada, 1995. Anais. IEEE, 1995, p. 217-226.
[Sne 95a] Sneed, Harry M. Planning the Reengineering of Legacy Systems. IEEE Software, p.
24-34, janeiro 1990.
[Sne 96] Sneed, Harry M. Object-Oriented COBOL Recycling. In: Working Conference on
Reverse Engineering (WCRE), 3., Monterey-CA, EUA, 1996. Anais. IEEE, 1996,
p. 169-178.
[Sol 84] Soloway, Elliot; Ehrlich, Kate. Empirical Studies of Programming Knowledge.
IEEE Transactions on Software Engineering, V.SE-10, n 5, p. 595-609, setembro
1984.
[Vli 95] Vlissides, J ohn. Reverse Architecture, Position Paper for Software Architectures
Seminar, Schloss Daghstuhl, Germany, disponvel a partir da Wide World Web
<URL:http://st-www.cs.uiuc.edu/users/patterns/papers/>, agosto 1995.
[Wel 95] Welch, Lonnie R. et al. Reengineering Computer-Based Systems for Enhanced
Concurrency and Layering. J ournal Systems Software, V.30, p. 45-70, 1995.
[Wil 95] Wilkening, D. E.; Loyall, J . P.; Pitarys, M.J . e Littlejohn, K. A Reuse Approach to
Software Reengineering. J ournal Systems Software, V.30, p. 117-125, 1995.
[Won 95] Wong, Kenny; et al. Structural Redocumentation: A case Study. IEEE Software, p.
46-54, janeiro 1995.
[Yod 98] Yoder, J .W.; J ohnson, R.E.; Wilson, Q.D. Connecting Business Objects to
Relational Databases. Conference on the Pattern Languages of Programs, 5.,
Monticello-IL, EUA, 1998. Anais. St.Louis, Missouri, EUA, agosto de 1998.
(Relatrio Tcnico n WUCS-98-25 da Universidade de Washington).

9 C 960521 B 534 Ac 20 e 1

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

9 C 960521 B 534 Ac 20 e 1

Diunggah oleh

Hak Cipta:

Format Tersedia

Padres de Software a partir da Engenharia

Reversa de Sistemas Legados

Anda mungkin juga menyukai