Uma Abordagem Gradativa de Modernização de Software Monolítico e em Camadas para Serviços

Alessandro Borges Rodrigues
Uma Abordagem Gradativa de Modernizao de

Software Monoltico e em Camadas para SOA
Recife, PE - Brasil
2017
Alessandro Borges Rodrigues
Uma Abordagem Gradativa de Modernizao de

Software Monoltico e em Camadas para SOA
Este trabalho foi apresentado Ps-

Graduao em Cincia da Computao do
Centro de Informtica da Universidade Fe-
deral de Pernambuco como requisito parcial
para obteno do grau de Mestre.
Universidade Federal de Pernambuco - UFPE

Centro de Informtica - CIn
Programa de Ps-Graduao em Cincia da Computao
Orientador: Vinicius Cardoso Garcia
Recife, PE - Brasil
2017
Dedico este trabalho minha esposa, Rejane, pelo apoio e auxlio durante toda nossa vida
juntos, e por me proporcionar o privilgio de me tornar pai.
Agradecimentos
Agradeo aos meus pais, Dulce e Adail, por terem me ensinado que a educao
um patrimnio para toda a vida e por ter me dado o suporte necessrio para seguir neste
caminho.
Aos companheiros de mestrado, em especial aos amigos do alojamento do IFPE.
Aos meus colegas de trabalho do IFTO e a esta instituio que, junto com a UFPE
e demais instituies, possibilitaram a oportunidade desse mestrado vrios servidores de
todo o pas.
Aos professores do Centro de Informtica da UFPE pelos seus ensinamentos, aos
funcionrios do CIn que contriburam para que este curso fosse realizado e especialmente
ao meu orientador Vinicius Garcia, pela acompanhamento deste trabalho.
"Se voc encontrar um caminho sem obstculos, ele provavelmente no leva a lugar
nenhum."
Frank Clark
Resumo
A constante evoluo tecnolgica, tanto de hardware quanto de software, faz com que
muitos sistemas tornem-se obsoletos, apesar de ainda atenderem seus requisitos e serem
estveis. Outrora foi a poca dos sistemas procedurais, hoje vemos que a prpria evoluo
deles, os orientados a objetos, em muitos casos, se tornaram obsoletos, grandes e complexos,
com tecnologias ultrapassadas e contendo centenas ou milhares de classes, sendo esses
problemas agravados naqueles que foram construdos de forma monoltica, possuindo assim
apenas um nico arquivo como resultado. A arquitetura orientada a servios permite
a criao de sistemas com menor complexidade, j que seus servios possuem baixo
acoplamento, permitindo atualizaes individuais sem afetar os demais servios. Porm,
a reconstruo dos sistemas j existentes nessa nova arquitetura invivel, devido ao
custo necessrio (tempo, mo de obra etc.), sendo a reengenharia deles uma possvel
soluo, que permite a reformulao desses sistemas de uma maneira menos onerosa.
Apesar da arquitetura em camadas ser bastante utilizada nos sistemas orientados a
objetos, faltam solues de reengenharia que leve esse fato em considerao, no sendo to
efetivas quando executadas em sistemas com essa arquitetura. Este trabalho busca definir
uma abordagem para modernizao de sistemas monolticos, orientados a objetos e que
tenham sido desenvolvidos com a arquitetura em camadas, para a arquitetura orientada a
servios, de uma forma semi-automatizada, sem a necessidade de o engenheiro de software
possuir um profundo conhecimento do sistema a ser modernizado. No sistema reconstrudo,
as classes das camadas de negcio e persistncia sero agrupadas de acordo com seus
relacionamentos, e os mtodos das classes de negcio sero disponibilizados como servios.
As etapas da abordagem proposta so constitudas de tcnicas, cujas frmulas e algoritmos
podem ser adicionados/transformados em ferramentas que automatizaro o processo. Esta
metodologia de modernizao permite que os web services criados possuam uma quantidade
menor de classes, alm de menor complexidade em cada servio, mantendo a funcionalidade
original. Isso conseguido tanto atravs de refatoraes no cdigo original que diminui a
quantidade de dependncia entre as classes, quanto atravs da separao de agrupamentos
de classes em pedaos menores. Foram obtidos resultados satisfatrios no estudo de caso,
como reduo de 24% da dependncia mdia entre as classes, diminuio de 80% e 6,33%
do tamanho e da complexidade esttica do componente (CSC), respectivamente e 100%
de sucesso nos testes de regresso.
Palavras-chave: Reengenharia de Software, Migrao, SOA, Refatorao, Modernizao,

Arquitetura de Software
Abstract
The constant technological evolution, both hardware and software, makes many systems
become obsolete, although they still attend their requirements and are stable. Once
was the time of procedural systems, today we see that the very evolution of them, the
object-oriented, in many cases, have become obsolete, large and complex, with outdated
technologies and containing hundreds or thousands of classes, these problems being
aggravated in those that were built in a monolithic way, thus possessing only a single
file as a result. The service-oriented architecture allows the creation of systems with
less complexity, as their services have low coupling, allowing individual updates without
affecting other services. However, reconstruction of existing systems in this new architecture
is not feasible due to the cost needed (time, labor etc), reengineering them being a possible
solution, which allows the reformulation of these systems in a less costly way. Although
the layered architecture is the most used in object oriented systems, it lacks reengineering
solutions that take this fact into account, not being so effective when executed in systems
with this architecture. This work aims to define an approach to the modernization of
monolithic and layered systems for service-oriented architecture, in a semi-automated
manner, without the need for the sotware engineer has a deep knowledge of the system
to be modernized. In the rebuilt system, the business and persistences layer classes will
be grouped according to their relationships, and methods of business classes will be
made available as services. The steps of the proposed approach are techniques, whose
formulas and algorithms can be added/transformed into tools that will semi-automate the
process. This modernization methodology allows the created web services to have a smaller
number of classes, in addition to less complexity in each service, maintaining the original
functionality. This is accomplished both by refactoring in the original code that decreases
the amount of dependency between classes, and by separating class clusters into smaller
pieces. Satisfactory results were obtained in the case study, such as a reduction of 24%
in average dependence between classes, a decrease of 80% and 6.33% in component size
and static complexity (CSC), respectively, and a 100% success rate in the tests regression
analysis.
Keywords: Software Reengineering, Migration, SOA, Refactoring, Modernizing, Software

Architecture
Lista de ilustraes
Figura 2.1 Ciclo de Vida do Software (Traduo minha)(CHIKOFSKY; CROSS,

1990) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 3.1 Exemplo de um documento SOAP (SAUDATE, 2013) . . . . . . . . . . 25
Figura 3.2 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3.3 Exemplo de arquiteturas em camadas . . . . . . . . . . . . . . . . . . . 28
Figura 3.4 Exemplo de SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 4.1 Exemplo de cdigo para clculo da fora de conectividade . . . . . . . 32
Figura 4.2 Exemplo de grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 4.3 Clusterizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 4.4 Macro Fluxo da abordagem de modernizao de sistemas OO para SOA 35
Figura 4.5 Refatorao das classes de persistncia . . . . . . . . . . . . . . . . . . 36
Figura 4.6 Refatorao das classes de negcio . . . . . . . . . . . . . . . . . . . . 37
Figura 4.7 Exemplo de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 4.8 Refatorao: Incluso de Mtodos . . . . . . . . . . . . . . . . . . . . . 39
Figura 4.9 Refatorao: Alterao das chamadas aos mtodos . . . . . . . . . . . 39
Figura 4.10Fluxo do processo de diminuio das dependncias das classes . . . . . 40
Figura 4.11Exemplo de grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 4.12Clusterizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 4.13Fluxo do processo de clusterizao . . . . . . . . . . . . . . . . . . . . 44
Figura 4.14Refatorao chamada entre servios . . . . . . . . . . . . . . . . . . . . 45
Figura 4.15Padres de descrio de web services (FREUND; STOREY, 2002) . . . 46
Figura 4.16Utilizao dos protocolos de transao (LANGWORTHY et al., 2004) . 48
Figura 4.17Fluxo para criao dos servios . . . . . . . . . . . . . . . . . . . . . . 48
Figura 5.1 Exemplo de script do JTransformer (KNIESEL; HANNEMANN; RHO,
2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 5.2 Script para encontrar chamadas entre classes de persistncia . . . . . . 58
Figura 5.3 Funcionamento da ferramenta JTransformer . . . . . . . . . . . . . . . 58
Figura 5.4 Refatorao para retirada de dependncia entre persistncias . . . . . . 59
Figura 5.5 Resultado das refatoraes da modernizao onde uma persistncia est
associada apenas um negcio . . . . . . . . . . . . . . . . . . . . . . 60
Figura 5.6 Parte do script de refatorao das classes de negcio . . . . . . . . . . 61
Figura 5.7 Grafo representando o sistema SIGA-EPCT . . . . . . . . . . . . . . . 63
Figura 5.8 Zoom do grafo representando o sistema SIGA-EPCT . . . . . . . . . . 63
Figura 5.9 Clusterizao das classes . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 5.10Criao de web service . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 5.11Script para encontrar nomes de mtodos duplicados . . . . . . . . . . . 65
Figura 5.12Mudana dos nomes dos mtodos dos web services . . . . . . . . . . . 66
Figura 5.13Refatorao para chamada a web services . . . . . . . . . . . . . . . . 66
Figura 5.14Web service com controle de transao . . . . . . . . . . . . . . . . . . 67
Figura 5.15Refatorao da classe CopiarTurmaEJB . . . . . . . . . . . . . . . . . 68
Figura 5.16Exemplo de ciclo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Lista de tabelas
Tabela 2.1 Viso geral das famlias de modernizao para SOA (RAZAVIAN;
LAGO, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 5.1 Lista de mtricas e relao com as questes do paradigma GQM. . . . 51
Tabela 5.2 Pesos com base no tipo de relacionamento para o clculo do CSC (CHO;
KIM; KIM, 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tabela 5.3 Comparao entre ferramentas de anlise de cdigo (ALVES; HAGE;
RADEMAKER, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Tabela 5.4 Segmento do resultado da identificao das classes persistncias com
suas respectivas classes de negcios . . . . . . . . . . . . . . . . . . . . 59
Tabela 5.5 Valores de tipo de fluxo existentes (ORACLE, 2016). . . . . . . . . . . 67
Tabela 5.6 Clculo da quantidade mdia de dependncias das classes por camada . 68
Tabela 5.7 Variao dos valores das mtricas de acordo com ponto de corte da
clusterizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Tabela 5.8 Resultado dos casos de teste . . . . . . . . . . . . . . . . . . . . . . . . 70
Lista de abreviaturas e siglas
IDE: Integrated Development Enviroment
JSON: JavaScript Object Notation
OO: Orientao a Objetos
REST: Representational State Transfer
SOA: Service-Oriented Architecture
SOAP: Simple Object Access Protocol
WSDL: Web Services Description Language
XML: eXtensible Markup Language

Sumrio
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . 15
2 REENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . 17
2.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Abordagens de Reengenharia de Sofware para SOA . . . . . . . . . . 19
2.3 Consideraes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 ARQUITETURAS DE SOFTWARE . . . . . . . . . . . . . . . . . . 23
3.1 Conceitos Bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Arquitetura monoltica . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 MODERNIZAO DE SISTEMAS MONOLTICOS PARA ARQUI-

TETURA ORIENTADA A SERVIOS . . . . . . . . . . . . . . . . . 30
4.1 Mecanismos da Abordagem proposta . . . . . . . . . . . . . . . . . . 30
4.1.1 Fora de Conectividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 Algoritmo Fast Community . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Proposta de Metodologia de Modernizao . . . . . . . . . . . . . . 35
4.2.1 Diminuio das dependncias . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Clusterizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 Criao dos servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3.1 Transaes entre servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 ESTUDO DE CASO E AVALIAO DA ABORDAGEM . . . . . . . 50

5.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 Ferramentas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1.1 JCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1.2 JTransformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Execuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Diminuio das dependncias . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.2 Clusterizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.3 Criao dos servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4 Anlise e Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.1 Questo 1: Que tipo de melhoria a refatorao das classes traz? . . . . . . 67
5.4.2 Questo 2: Quais foram as melhorias obtidas nos componentes gerados? . . 68
5.4.3 Questo 3: A funcionalidade original mantida aps a criao dos servios? 70
5.5 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 CONSIDERAES FINAIS E TRABALHOS FUTUROS . . . . . . 73

6.1 Trabalhos correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Limitaes e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . 75
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
13
1 Introduo
1.1 Contextualizao
Atualmente existe um grande nmero de empresas que trabalham com sistemas
implementados com linguagens de programao antigas, alm de arquiteturas muito
restritivas. A defasagem das linguagens e arquiteturas um problema recorrente e pode
acontecer com qualquer sistema em seu ciclo de vida, pois sempre surgem novas tecnologias
e paradigmas que melhoram a qualidade dos sistemas desenvolvidos, alm de diminuir o
tempo de desenvolvimento necessrio, tornando as tecnologias existentes obsoletas.
Apesar das grandes vantagens na utilizao das novas tecnologias, reconstruir os
sistemas legados geralmente um trabalho complexo, demanda tempo, possui um custo
alto e muitas vezes chega a ser invivel. Porm, devido a quantidade de informaes
armazenadas e a confiabilidade que suas funcionalidades possuem aps vrios anos de
utilizao e aprimoramento, esses sistemas continuam sendo essenciais para as empresas
(CONNALL; BURNS, 1993; ULRICH, 1994), de forma que uma opo mais vivel a
atualizao do sistema legado existente para que usufrua das novas tecnologias.
A Reengenharia de Software uma forma de conseguir evoluir esses sistemas
legados, mantendo o conhecimento existente neles (Dos Santos Brito et al., 2008). No
incio dos anos 90, com a popularizao das linguagens orientadas a objetos (OO), foram
iniciadas vrias pesquisas relacionadas modernizao dos sistemas procedurais para
OO atravs da Reengenharia, devido ao ganho na reutilizao e manutenibilidade que a
orientao a objetos possibilita.
Em pouco tempo, linguagens orientadas a objetos se tornaram as mais utilizadas
no desenvolvimento de sistemas (TIOBE.COM, 2017), o que significa que uma grande
quantidade de sistemas foram e vm sendo desenvolvidos nessas linguagens OO. Porm,
com o tempo, o aprimoramento gradual desses sistemas OO aumentou sua complexidade
na manuteno e testes. Essa complexidade agravada naqueles que so monolticos
(STOJANOVI, 2005), ou seja, geram apenas um executvel ou componente como resultado,
dificultando tambm na escalabilidade e introduo de novas tecnologias em funcionalidades
especficas, (DRAGONI et al., 2016), sendo essas novas tecnologias, em alguns casos,
incompatveis com as utilizadas.
A arquitetura orientada a servio (SOA) resolve os problemas dos sistemas monol-
ticos, melhorando a escalabilidade, que pode ser feita para cada servio, alm de diminuir
a complexidade da manuteno e testes, j que estes podem ser feitos em componentes
menores (VILLAMIZAR et al., 2015).
Captulo 1. Introduo 14
Existem na literatura vrias tcnicas de Reengenharia para auxiliar na modernizao

de sistemas OO para SOA, como Erdemir e Buzluca (2014), Yousef, Adwan e Abushariah
(2014), Liang Bao et al. (2010), mas muitas delas ignoram o fato de que a maioria dos
sistemas OO possuem uma arquitetura em camadas, de modo que a utilizao dessas
tcnicas pode agrupar as classes de forma incorreta, podendo, por exemplo, separar uma
classe de negcio de uma classe de persistncia ou entidade que ela utiliza, impossibilitando,
ou aumentando as refatoraes necessrias para sua utilizao, conforme observado por
Wang et al. (2008).
Motivado pelos problemas existentes nos sistemas legados, em especial aqueles
monolticos, orientados a objetos e que possuem uma arquitetura em camadas, esta
pesquisa pretende apresentar uma proposta de modernizao, quebrando essa arquitetura
monoltica e modernizando-a para SOA. As limitaes impostas pelos requisitos se deve ao
fato, como citado anteriormente, dos sistemas orientados a objetos englobar grande parte
das aplicaes existentes e as pesquisas relacionadas a modernizao de sistemas OO no
serem to efetivas quando executadas sobre aqueles com arquiteturas em camadas.
1.2 Objetivos
Esta dissertao tem o objetivo de definir um catlogo de tcnicas para auxiliar
na modernizao de sistemas orientados a objetos, monolticos e com arquitetura em
camadas para SOA, independente da linguagem de programao utilizada. Por causa da
aplicabilidade dessa abordagem em vrias linguagens de programao, no so definidas
ferramentas especficas a serem utilizadas, e sim tcnicas, frmulas e algortimos que podem
ser adicionados/transformados em ferramentas de apoio. Esta abordagem composta
de trs etapas, diminuio de dependncias, clusterizao 1 e criao dos servios, sendo
que cada uma delas possui tcnicas semi-automatizadas que agilizar o processo. O foco
principal dessa abordagem na identificao dos possveis servios, atravs do agrupamento
de classes que se relacionam entre si.
Um dos objetivos da primeira etapa, diminuio de dependncias, a reduo do
acoplamento entre as classes, diminuindo a quantidade de relacionamentos entre elas e
permitindo a criao de servios menores, ou seja com menos classes. Essa etapa tambm
padroniza a comunicao que deve acontecer somente entre as classes da camada de
negcio.
Na segunda etapa, "clusterizao", definida uma tcnica que permite a diviso de
um servio em servios menores, de acordo com a modularidade que essa diviso ir gerar.
O objetivo dessa etapa , tambm, permitir a criao de servios menores, que facilitar
1
Clusterizao a palavra equivalente em portugus para o termo clustering, em ingls, que significa
agrupamento, referenciando a agrupamento de classes no contexto desta pesquisa.
futuras manutenes e testes (VILLAMIZAR et al., 2015).

O objetivo da terceira etapa definir regras que devem ser observadas no momento
da criao dos servios atravs de web services, de maneira a permitir que a funcionalidade
continue operando da mesma forma que a original. Nessa etapa no so definidas tcnicas
para criao de web services, pois podem variar de acordo com a linguagem de programao
e IDE utilizada, e a idia da proposta de modernizao que ela possa ser executada em
sistemas escritos em qualquer linguagem de programao, desde que sejam observados
os requisitos iniciais, que ser orientado a objetos, monoltico, e com arquitetura em
camadas.
Este trabalho no abordar a alterao da camada de apresentao para a utilizao
dos servios criados, pois implica em anlise tando da parte de back-end da camada de
apresentao quanto do prprio front-end da aplicao, que pode variar de acordo com
o framework utilizado. Tambm no ser abordado a separao do banco de dados para
cada servio ou conjunto de servios, que implica, possivelmente na criao/alterao
de campos/tabelas, remoo de restries, sincronizao de dados entre servios etc,
afetando vrios scripts SQL (Structured Query Language) que possam existir. Alm disso,
as alteraes no banco de dados ir refletir em mudanas nas classes de entidades e scripts
HQL (Hibernate Query Language) ou similares, j que estas so a representao OO do
banco de dados. Essas excluses foram feitas devido a complexidade e tempo necessrio
para faz-los, ficando essas tarefas para um trabalho futuro.
1.3 Organizao da Dissertao

Esta dissertao est organizada em seis captulos mais uma seo relacionada s
referncias bibliogrficas, sendo o primeiro captulo relacionado introduo.
No Captulo 2 so apresentados os principais conceitos sobre Reengenharia de
Software e so exibidos vrios tipos uma categorizao dos trabalhos relacionados a
modernizao de sistemas, atravs da reengenharia, para a arquitetura orientada a servios
(SOA).
No Captulo 3 apresentada uma viso geral das arquiteturas envolvidas no processo
de modernizao, desde as arquiteturas de origem (monoltica e em camadas) at a de
destino (SOA).
O Captulo 4 detalha a abordagem proposta para a realizao da modernizao
dos sistemas, descrevendo as etapas, tcnicas e ferramentas utilizadas.
O Captulo 5 apresenta um estudo de caso feito sobre um sistema real, com o
objetivo de validar a eficcia da abordagem.
Por ltimo, o Captulo 6 apresenta as consideraes finais, abordando os trabalhos
correlatos, as principais contribuies e os trabalhos futuros.

17
2 Reengenharia de Software
Nos dias atuais fcil perceber a dependncia das organizaes em relao aos
softwares por ela utilizados, no sendo mais possvel a existncia de uma organizao
sem eles (CONNALL; BURNS, 1993; ULRICH, 1994). Tal importncia faz com que
essas organizaes procurem utilizar as mais modernas tecnologias, seja para melhorar o
desempenho interno, seja para ganhar alguma vantagem em relao a seus concorrentes.
Porm, grande parte dos sistemas crticos utilizados foram desenvolvidos h muitos anos e
apenas sua manuteno no o bastante para mant-los atualizados.
Lehman e Belady (1985) demonstram que pior que a desatualizao, quando
no se faz alguma melhoria, a degradao da qualidade atravs da manuteno e,
consequentemente, a manutenibilidade do software. Visaggio (2001) chama essa degradao
de "sintomas de envelhecimento"(aging symptoms) e apresenta evidncias de que o processo
de Reengenharia pode diminui-los.
Neste captulo so apresentados conceitos de Reengenharia de Software que sero
relevantes na abordagem proposta.
2.1 Conceitos
Segundo Seacord, Plakosh e Lewis (2003), reengenharia uma forma de moderni-
zao que melhora as capacidades ou manutenibilidade de um sistema legado atravs da
introduo de tecnologias e prticas modernas. Os objetivos principais da Reengenharia
so (SNEED, 1995):
Melhorar manutenibilidade: pode-se, por exemplo, reduzir a manuteno com

a Reengenharia de mdulos menores com interfaces mais explcitas. difcil de
medir seu ganho porque tambm pode ocorrer por outros fatores como equipe mais
treinada, ou utilizao de mtodos mais eficientes;
Migrao/Modernizao: a Reengenharia pode ser utilizada para realizar a mi-

grao de um sistema entre ambientes operacionais diferentes. Tambm pode mudar
sistemas desenvolvidos em linguagens ou arquiteturas obsoletas para outras mais
modernas e flexveis;
Obter maior confiabilidade: os testes extensivos necessrios para garantir a

equivalncia das funcionalidades podem evidenciar erros antigos e a reestruturao
revela potenciais defeitos. Esse objetivo pode ser medido atravs da anlise de erros;
Captulo 2. Reengenharia de Software 18
Preparao para melhorias funcionais: decompor um sistema em mdulos

menores melhora sua estrutura alm de isol-los uns dos outros. Isso facilita a adio
ou alterao de funes sem afetar outros mdulos.
2.1.1 Terminologia
Chikofsky e Cross (1990) apresenta a terminologia empregada na engenharia de
software relacionadas as tecnologias de anlise e entendimento de sistemas legados, sendo
os principais termos:
Engenharia avante: o processo tradicional de desenvolvimento, indo de abstra-

es e lgicas de alto nvel com projetos independentes de implementao para a
implementao fsica de um sistema;
Engenharia reversa: o processo de anlise de um sistema para identificar seus

componentes e inter-relacionamentos, e criar representaes do sistema em outra
forma ou em um nvel maior de abstrao. H vrias subreas na engenharia re-
versa, sendo que as que so mais amplamente referenciadas so redocumentao e
recuperao de projeto;
Redocumentao: a criao ou reviso de representao semanticamente

equivalente a outra, mantendo o mesmo nvel de abstrao. As representaes
resultantes so geralmente consideradas vises alternativas (por exemplo, fluxo
de dados, estrutura de dados e fluxo de controle) com o objetivo de serem
analisadas por pessoas;
Recuperao de projeto: um subconjunto da Engenharia Reversa em que
o conhecimento do domnio, informaes externas e deduo ou raciocnio difuso
so adicionados s observaes do sistema alvo para identificar abstraes de alto
nvel significativas alm daquelas obtidas diretamente atravs da examinao
direta do sistema;
Reestruturao: a transformao de uma representao para outra no mesmo

nvel de abstrao, preservando o comportamento externo do sistema (funcionalidades
e semntica). Um exemplo a alterao de um cdigo para melhorar sua estrutura,
no sentido tradicional de projeto estruturado; e
Reengenharia: a anlise e alterao de um sistema para reconstitu-lo e implement-

lo em uma nova forma.
A Figura 2.1 mostra o relacionamento entre esses termos, sendo que foi considerado
apenas trs estgios do ciclo de vida (Requisitos, Projeto e Implementao), com claras
diferenas no nvel de abstrao. Os Requisitos especificam o problema a ser resolvido,

incluindo objetivos, restries e regras de negcio. O Projeto trata de especificao da
soluo e a Implementao refere-se a codificao, teste e entrega de um sistema em
funcionamento. Nessa figura nota-se que a Engenharia Avante vai do nvel de abstrao mais
alto (Requisitos) para o mais baixo (Implementao), enquanto a Engenharia Reversa faz o
caminho inverso. A Reengenharia pode ser feita tanto somente na parte de implementao
ou em conjunto com a parte de Projeto.
Figura 2.1 Ciclo de Vida do Software (Traduo minha)(CHIKOFSKY; CROSS, 1990)
2.2 Abordagens de Reengenharia de Sofware para SOA

Na literatura existem vrias abordagens de reengenharia que tratam sobre a moder-
nizao de sistemas legados para SOA, indo desde a descrio de passos a serem seguidos
a tcnicas semi-automatizadas. Razavian e Lago (2015) analisou 75 abordagens existentes,
verificando suas semelhanas e diferenas, agrupando-as em 8 diferentes "famlias", de
acordo com as atividades executadas.
Para fazer esse agrupamento foi utilizado o framework SOA-MF criado por Razavian
e Lago (2010), que um esqueleto de atividades genricas representando as necessidades a
serem executadas em um projeto de modernizao. Esse framework composto de trs
processos: Engenharia Reversa, Transformao (Reestruturao) e Engenharia Avante. As

famlias definidas so:
Famlia da transformao de cdigo (code transformation family): se li-

mita a transformaes no nvel de sistema, convertendo o cdigo legado para baseado
em servios. Nesta famlia a modernizao implica em mover o sistema legado como
um todo para SOA, sem decompor o sistema existente. Se uma transformao desse
tipo for executado em um sistema monoltico, ele continuar monoltico, mesmo que
disponibilize servios;
Famlia da identificao de servio (service identification family): no

abrange o processo de transformao, significando que no ocorre a remodelao
do sistema de elementos legados para elementos baseados em servio. Nesta famlia
a modernizao limitada a identificao de possveis servios dentro do sistema
legado, atravs de tnicas de Reengenharia;
Famlia da transformao do modelo de negcio (business model trans-

formation family): os processos de Engenharia Reversa e a Engenharia Avante no
so contemplados, sendo a modernizao realizada atravs do processo de transforma-
o, realizado no nvel conceitual. Existem duas principais categorias de abordagens
de migrao nessa famlia sendo a primeira quelas que definem meta-processos, cujo
objetivo apoiar na tomada de deciso sobre como fazer a modernizao. A segunda
categoria executa a Reengenharia sobre os processos de negcio do sistema, para
que sirvam de base para o desenvolvimento top-down de servios;
Famlia de transformao de elementos de projeto (design element trans-

formation family): o processo de transformao ocorre somente nos elementos
bsicos de projeto (por exemplo, mdulos ou classes). Caso os processos de Enge-
nharia Reversa e Avante forem abordados se limitaro tambm somente esse nvel.
Nesta famlia a modernizao limitada a remodular os elementos do sistema legado
para elementos baseados em servio, por exemplo, uma especificao de componente
alterada para especificao de servio, um mdulo transformado em um servio,
ou um segmento de cdigo da camada de persistncia convertido em um servio de
dados;
Famlia da Engenharia Avante (forward engineering family): abrange com-

pletamente o processo de Engenharia Avante, sendo que os processos de transformao
e Engenharia Reversa ocorrem somente no nvel de elementos bsicos de projeto.
O foco desta famlia o desenvolvimento de sistemas baseados em servios, tendo
como ponto de partida os processos de negcios. A Engenharia Reversa utilizada
apenas para localizar as funcionalidades dos servios identificados no processo de
Engenharia Avante;
Famlia da transformao de projetos e elementos compostos (design and

composite element transformation family): os trs processos de modernizao
ocorrem nos nveis de elementos bsicos de projeto e elementos de composio de
projeto. Engloba a recuperao e refatorao da arquitetura do sistema legado para
SOA, alm de remodelar os elementos legados para elementos baseados em servio;
Famlia da transformao de composio baseada em padres (pattern-

based composition transformation family): inclui apenas o processo de trans-
formao no nvel de elementos de composio de projeto, implicando que a arqui-
tetura do sistema existente alterada ou configurada dentro de SOA, geralmente
atravs da utilizao de patterns;
Famlia da Engenharia Avante com anlise de lacunas (forward enginee-

ring with gap analysis family): o processo de transformao ocorre nos nveis
conceituais, de elmentos de composio de projeto e elementos bsicos de projeto.
Aqui o processo de Engenharia Avante engloba as atividades de anlise e projeto
de servios, enquanto a Engenharia Reversa no utilizada. O foco principal dessa
famlia no desenvolvimento top-down de servios, comeando com a extrao dos
modelos de negcio do sistema legado para depois projetar os servios. O que diferen-
cia esta famlia da outra que tambm utiliza desenvolvimento top-down (Famlia da
Engenharia Avante) que nesta so feitas comparaes entre os artefatos originais e
os gerados, sendo essas comparaes feitas em cada nvel de abstrao (incluindo s
nveis conceituais, de composio e de projeto).
A Tabela 2.1 mostra a diviso das 75 abordagens avaliadas dentro das fmlias
definidas, sendo que a coluna Quantidade mostra o nmero de abordagens dentro de
cada famlia e a coluna Percentual mostra seu percentual equivalente em relao ao total
de abordagens analisadas.
Tabela 2.1 Viso geral das famlias de modernizao para SOA (RAZAVIAN; LAGO,
2010)
Famlia Quantidade Percentual
Famlia da transformao de cdigo 12 16%
Famlia da identificao de servio 12 16%
Famlia da transformao do modelo de negcio 5 7%
Famlia de transformao de elementos de projeto 21 28%
Famlia da Engenharia Avante 8 10%
Famlia da transformao de projetos e elementos compostos 10 14%
Famlia da transformao de composio baseada em padres 3 4%
Famlia da Engenharia Avante com anlise de lacunas 4 5%
2.3 Consideraes finais

A categorizao das metodologias de modernizao de sistemas para SOA, apresen-
tada na seo anterior, permite uma viso geral dos vrios tipos de abordagens existentes,
mostrando diversos tipos de modernizaes possveis para atingir o mesmo objetivo, embora,
em alguns casos, possuam nveis de abstrao diferentes.
Com base nesta categorizao, possvel incluir a proposta deste trabalho dentro
da famlia de identificao de servio (service identification service), pois este o seu
principal objetivo. Porm, embora o foco da abordagem de modernizao proposta foque
na identificao dos servios, existe uma etapa especfica para o tratamento dos web
services, que define as regras que eles devem seguir no momento de suas criaes, sem
definir, entretanto, tcnicas ou ferramentas especficas. O Captulo 4 mostrar os detalhes
da abordagem proposta.
2.4 Resumo do Captulo

Este captulo apresentou a terminologia e conceitos da Engenharia de Software
que sero utilizados neste trabalho. Tambm mostrou uma categorizao das abordagens
existentes, de acordo com as atividades realizadas, o que possibilitou a incluso da
abordagem deste trabalho em uma delas.
O prximo captulo apresenta as arquiteturas que esta proposta abrange, desde as
existentes no sistema de origem, at SOA, que a arquitetura de destino da abordagem
de modernizao proposta.
23
3 Arquiteturas de Software
Este captulo aborda os conceitos sobre arquitetura de software e detalha as

arquiteturas referenciadas na abordagem de modernizao, sendo elas a arquitetura
monoltica na Seo 3.2, baseadas em servios na Seo 3.3 e a em camadas na Seo 3.4.
3.1 Conceitos Bsicos

Bass, Clements e Kazman (2012) define arquitetura de software como sendo um
conjunto de estruturas necessrios de um sistema, compreendendo elementos de software,
relacionamentos entre eles e as propriedades de ambos.
Dentre as estruturas de software que compem uma arquitetura importante
ressaltar trs delas:
Estruturas estticas: unidades de implementao (mdulos) que se concentram

na forma como a funcionalidade do sistema dividida e atribuda a equipes de
implementao;
Estruturas dinmicas: se concentram na forma como os elementos interagem

uns com os outros em tempo de execuo para executar as funes do sistema (ex:
conjunto de componentes e/ou servios);
Estruturas de alocao: descreve o mapeamento das estruturas de software com

os ambientes de organizao, desenvolvimento, instalao e execuo do sistema (ex:
atribuio de mdulo/componente a um time de desenvolvimento).
Rotem-Gal-Oz (2012) apresenta uma outra definio descrevendo a arquitetura

de software como uma coleo de decises fundamentais sobre um produto ou soluo,
projetado para atender os atributos de qualidade do projeto (requisitos da arquitetura).
A arquitetura inclui os principais componente e atributos, alm de suas interaes e
comportamentos para atender os atributos de qualidade.
Com base nas definies apresentadas, pode-se inferir que uma arquitetura deve
estabelecer os componentes de um software, suas interaes e limites, servindo de guia no
desenvolvimento na distribuio das estruturas criadas durante o ciclo de vida do sistema.
Nas sees a seguir sero apresentadas alguns exemplos de arquiteturas, mostrando os
principais componentes e a forma em que interagem entre si.
Captulo 3. Arquiteturas de Software 24
3.2 Arquitetura monoltica

Villamizar et al. (2015) define que uma aplicao monoltica um sistema que
possui um nico arquivo como resultado, que oferece dezenas ou centenas de servios
usando diferentes interfaces como pginas HTML e web services.
Conforme observado pela definio, a arquitetura monoltica est ligada forma em
que as estruturas de software sero publicadas, existindo nesse caso apenas uma. Dentro
desta estrutura pode haver outros nveis de arquitetura, relacionadas organizao de
seus elementos, como a diviso por camadas, ou at mesmo a disponibilizao de servios.
O uso desta arquitetura possui vrias vantagens, podendo-se destacar:
Simplicidade no desenvolvimento, j que muitas das atuais ferramentas e IDEs foram

projetadas para o desenvolvimento de aplicaes monolticas;
Simplicidade de publicao, pois existe apenas um arquivo, ou estrutura de diretrios,

e
Simplicidade de escalonamento, uma vez que basta criar mltiplas cpias da aplicao
acessadas por um balanceador de carga.
Porm, apesar da simplicidade que a utilizao desta arquitetura traz, tambm

existe as limitaes impostas por ela. Dragoni et al. (2016) cita um conjunto dessas
limitaes, sendo algumas delas apresentadas a seguir:
Quanto maior o tamanho da aplicao monoltica mais difcil mant-la e evolu-la,

devido ao aumento de sua complexidade;
Limitao na escalabilidade do sistema, uma vez que para escalar deve-se criar novas
instncias de toda a aplicao, mesmo que o trfego seja intenso em apenas um
grupo pequeno de mdulos, ou mesmo apenas um;
Dificuldade de evoluir as tecnologias utilizadas, devido a necessidade de utilizao

de uma mesma linguagem e frameworks da aplicao original.
Com base nas vantagens e desvantagens dessa arquitetura, o engenheiro de software

deve tomar a deciso se vale a pena utiliz-la para criar um novo sistema, assim como
decidir o momento em que ela passa a ser prejudicial em um sistema j existente, sendo
necessrio sua modernizao para uma nova arquitetura.
3.3 SOA
Erl (2005) define a arquitetura orientada a servios (SOA) como um estilo arquite-
tural que define o uso de servios de software com baixo acoplamento e interoperacionais
para atender os requisitos dos processos de negcio e usurios. Segundo Daigneau (2012),
o servio se refere a qualquer funo de software que executa uma operao de negcio.
Apesar de ser possvel utilizar tecnologias como CORBA e DCOM para dispo-
nibilizar servios atravs de componentes, o foco deste trabalho ser na utilizao de
web services, pois provm os meios para integrar sistemas diferentes e expem funes
reutilizveis atravs de HTTP (DAIGNEAU, 2012), utilizando-se de padres abertos e
interoperveis em diferentes plataformas de computao e independentes das tecnologias
de execuo subjacentes.
De acordo com Daigneau (2012), os web services podem utilizar o HTTP (Hypertext
Transfer Protocol) de duas maneiras, sendo a primeira para a troca de dados, empregando
para isso padres como XML e JSON (servios SOAP/WSDL). A segunda usando o HTTP
como protocolo de aplicao que define semnticas para o comportamento dos servios
(servios REST).
REST (REpresentational State Transfer), inicialmente definido por Fielding (2000),
um estilo de arquitetura de software para sistemas de hipermdia distribudos, ou
sistemas em que texto, imagens, udios, e outras mdias so armazenadas atravs da rede
e interconectadas atravs de hyperlinks (KALIM, 2013). REST web services so baseados
em URLs e nos quatro mtodos do protocolo HTTP, utilizando POST para inserir um
novo registro, PUT para alterar um registro existente, DELETE para excluir um registro
e GET para pegar as informaes de um registro.
SOAP (Simple Object Access Protocol) um protocolo para troca de mensagens,
utilizado para traduzir as informaes de um web service (por exemplo request e response),
sendo as mensagens documentos XML (KHAN; ABBASI, 2015). SOAP tambm conhecido
como Envelope SOAP, j que seu elemento raiz o Envelope. Seu formato segue o padro
mostrado na Figura 3.1.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
, xmlns:ser="http://servicos.estoque.knight.com/"/>


<soapenv:Body>
</soapenv:Body>
</soapenv:Envelope>
Figura 3.1 Exemplo de um documento SOAP (SAUDATE, 2013)
Segundo Saudate (2013) o elemento Envelope um container para os elmentos

Header, que contm metadados relativos requisio (ex: informaes de autenticao e
endereo de retorno), e Body, que possui o corpo da requisio (ex: nome da operao
e seus parmetros). O Header tambm permite a adio de especificaes de recursos
adicionais relativos a web services, como o WS-Transaction, que permite um controle extra
de transaes entre servios, e o WS-Security que adiciona camadas de segurana ao web
service.
A existncia dessas extenses, em especial a WS-Transaction (detalhado na Seo
4.2.3) foi o principal motivo para a escolha do protocolo SOAP ao invs de REST para os
web services a serem criados pela proposta de modernizao de arquitetura. Apesar de
existirem formas para controle de transaes entre REST web services, isso geralmente no
conseguido de forma to transparente, sendo necessria a adio de uma nova camada ou
framework, como por exemplo o Atomikos1 , e a criao de funes especficas para desfazer
as operaes j concludas quando ocorrer um erro. Essa adio de operaes acrescenta
um ponto crtico modernizao, pois o cdigo acrescentado, se feito de forma incorreta,
pode prejudicar a confiabilidade dos dados, alm de ser necessrio um maior conhecimento
do sistema a ser modernizada. Apesar de dificuldades adicionais existentes com utilizao
de REST, esta ainda uma opo vivel, desde que observados os pontos levantados.
Porm, para simplificar o processo de modernizao e aumentar a confiabilidade do sistema
modernizado, todos os web services citados neste trabalho esto relacionados a SOAP.
Alm de SOA existem outras arquiteturas baseadas em servio, sendo que a de
microservios merece mais destaque. A diferenciao entre a arquitetura de microservios
e SOA um ponto de discusso delicado entre os pesquisadores, pois ambas utilizam
servios como principal componente de implementao e execuo de funcionalidades
(RICHARDS, 2015). Alm disso, existem autores que inclusive colocam microservio como
uma abordagem SOA (NEWMAN, 2015).
Embora possa se discutir se microservios ou no SOA, existem algumas
caractersticas que uma arquitetura deve possuir para receber tal classificao. Newman
(2015) define microservios como servios pequenos e autnomos que trabalham em
conjunto. Com base nessa definio, possvel inferir que a proposta da utilizao de
servios neste trabalho no atende estes requisitos, isso porque nem o tamanho ou sua
independncia esto entre as restries impostas pela abordagem de modernizao proposta,
podendo gerar servios de vrios tamanhos, tanto independentes quanto relacionados entre
si. A criao destes servios apresentada com mais detalhes na Seo 4.2.3.
3.4 Arquitetura em Camadas

A diviso do sistema em camadas uma das arquiteturas mais comuns usadas
por desenvolvedores para separar as complexidades de um sistema, de acordo com Fowler
1
Disponvel em <https://www.atomikos.com/>
(2002). Nessa arquitetura os elementos do sistema so organizados em camadas horizontais,

sendo que cada camada executa papis especficos da aplicao. A troca de informaes
feita somente entre as camadas diretamente conectadas, sendo que a responsvel por fazer
as requisies ser sempre a camada superior. Essa arquitetura pode ser visualizado na
Figura 3.2.
Figura 3.2 Arquitetura em Camadas
Embora a arquitetura no defina a quantidade de camadas que deve existir, as

principais utilizadas so trs, sendo elas: apresentao, negcio e persistncia, podendo
cada uma delas ser definidas como (FOWLER, 2002):
Apresentao: gerencia todas as interfaces com o usurio e lgica de comunicao;
Negcio: executa regras de negcio especficas para cada requisio;
Persistncia: faz a comunicao com o banco de dados e gerencia transaes.
Apesar de ser a camada de apresentao que mostra os dados para o usurio, ela
no tem acesso direto a eles, mas sim a persistncia. Como apenas a camada superior
pode fazer requisies a camada abaixo dela, uma requisio da apresentao deve passar
pela camada de negcio, que processar e retransmitir para a camada subjacente que a
persistncia. A resposta para essa requisio far o caminho inverso.
Em sistemas orientados a objetos, geralmente usada uma outra estrutura para
representar os dados do banco de dados (Entidade da Figura 3.2), sendo que ela trafega
entre as camadas. Pelo fato dessa arquitetura estar relacionada a separao das estruturas
estticas, ela pode estar presente tanto em um sistema monoltico quanto dentro de um
servio SOA.
3.5 Consideraes Finais

O motivo da escolha da arquitetura em camadas como requisito para a modernizao
se deve ao fato de que embora esta seja a arquitetura mais utilizada para a maioria das
aplicaes Java Enterprise Edition (BASS; CLEMENTS; KAZMAN, 2012), muitas das
pesquisas relacionadas modernizao de sistemas legados para componentes ou servios
no levam em considerao a existncia dessas camadas.
Essa declarao pode ser observada na pesquisa de Wang et al. (2008), que evidencia
a desconsiderao da existncia de camadas. Apesar disso no estar explcito em outras
pesquisas (ADJOYAN; SERIAI; SHATNAWI, 2014; CONSTANTINOU et al., 2015;
BUDHKAR; GOPAL, 2012; YOUSEF; ADWAN; ABUSHARIAH, 2014; Liang Bao et al.,
2010; Eunjoo Lee et al., 2003; WANG et al., 2008), o mesmo fato pode ser constatado.
Pois estas outras pesquisas observam apenas os relacionamentos entre as classes, podendo
por exemplo gerar componentes/servios onde pode existir uma classe de negcio e uma de
persistncia, mas sem as entidades que trafegaro as informaes, ou uma classe entidade
e uma de negcio, sem uma persistncia para salvar as informaes.
As arquiteturas baseadas em servios resolvem os problemas listados na Seo 3.2.
Porm, mesmo utilizando essas novas arquiteturas para os novos desenvolvimentos, ainda
restam os sistemas legados, escritos monoliticamente, que precisam ter sua arquitetura
migrada de forma a aproveitar de seus benefcios, sendo o auxlio a essa modernizao o
foco deste trabalho.
class ClasseN1{ class ClasseN2{
public void metodo1(){ public void metodo2(){
ClasseN2 classeN2 = new ClasseN2(); ClasseP2 classeP2 = new ClasseP2();
classeN2.metodo2(); classeP2.alterar();
}
ClasseP1 classeP1 = new ClasseP1();
classeP1.alterar(); public void metodo4(){
} ClasseN1 classeN1 = new ClasseN1();
classeN1.metodo3();
public void metodo3(){
ClasseP1 classeP1 = new ClasseP1(); ClasseP2 classeP2 = new ClasseP2();
classeP1.alterar(); classeP2.alterar();
} }
} }
Figura 3.3 Exemplo de arquiteturas em camadas
Apesar da proposta de modernizao ser transformar um sistema monoltico em

SOA, a estrutura em camadas ser mantida dentro dos servios criados, diminuindo assim
a quantidade de refatoraes necessrias. As Figuras 3.3 e 3.4 exemplificam, atravs de
trechos de pseudo-cdigo, a arquitetura em camadas e SOA, respectivamente, sendo que
os servios do exemplo SOA tambm possuem uma arquitetura em camadas dentro delas.
A diferenciao do cdigo entre as arquiteturas e suas figuras se faz atravs do destaque
nas linhas de cdigo que sofrem alterao. Nessas figuras as classes ClasseN1 e ClasseN2
pertencem camada de negcio, e as classes ClasseP1 e ClasseP2 camada de persistncia,
sendo que as figuras detalham somente a camada de negcio.
@WebService @WebService
class ClasseN1{ class ClasseN2{
//ServicoClasseN2 referencia ao web service da ClasseP2 classeP2 = new ClasseP2();
, classe ClasseN2 classeP2.alterar();
ServicoClasseN2 servicoClasseN2 = new }
, ServicoClasseN2();
servicoClasseN2.metodo2(); public void metodo4(){
//ServicoClasseN1 referencia ao web service da
ClasseP1 classeP1 = new ClasseP1(); , classe ClasseN1
classeP1.alterar(); ServicoClasseN1 servicoClasseN1 = new
} , ServicoClasseN1();
servicoClasseN1.metodo3();
public void metodo3(){
ClasseP1 classeP1 = new ClasseP1(); ClasseP2 classeP2 = new ClasseP2();
classeP1.alterar(); classeP2.alterar();
} }
} }
Figura 3.4 Exemplo de SOA

Este captulo descreveu as arquiteturas referenciadas pela proposta de modernizao,
apresentando suas caractersticas e detalhando os motivos que levaram a escolh-las como
arquiteturas de origem e destino desta proposta.
No prximo captulo apresentado os detalhes propostos de modernizao, de-
talhando os passos que permitiro que um sistema monoltico, orientado a objetos e
desenvolvido com uma arquitetura de trs camadas, seja transformado em um sistema
com arquitetura SOA.
30
4 Modernizao de sistemas monolticos para

arquitetura orientada a servios
Nos captulos anteriores foram apresentados os principais conceitos envolvidos nesta

pesquisa, que proporcionaram o fundamento terico para a criao de uma abordagem
que auxilie a modernizao, para SOA, de sistemas monolticos, orientados a objetos e
desenvolvidos com uma arquitetura de trs camadas.
A abordagem composta de trs etapas sendo a primeira a diminuio de de-
pendncia, que reduzir a quantidade de relacionamentos entre as classes, a segunda a
"clusterizao", responsvel pelo agrupamento dessas classes e a terceira e ltima a criao
dos servios, que definir critrios a serem observados na criao dos web services. Dentro
delas sero definidas tcnicas e frmulas que podero ser utilizaras por ferramentas para
automatizar suas realizaes. Antes de iniciar com a descrio de cada um das etapas ser
apresentado os fundamentos que sero utilizados.
4.1 Mecanismos da Abordagem proposta

A abordagem proposta utiliza tcnicas j existentes na literatura, adequando-as
conforme a necessidade para melhor atender os requisitos desejados.
4.1.1 Fora de Conectividade

Para auxiliar no agrupamento das classes h a necessidade de identificar o grau
de ligao existente entre elas, de forma a unir aquelas com maior ligao. Para atingir
esse objetivo encontram-se na literatura vrias pesquisas, podendo citar Adjoyan, Seriai e
Shatnawi (2014), Constantinou et al. (2015), Budhkar e Gopal (2012), Yousef, Adwan e
Abushariah (2014), Liang Bao et al. (2010), Eunjoo Lee et al. (2003), Wang et al. (2008).
Escolheu-se a frmula definida por Eunjoo Lee et al. (2003) e aprimorada por Wang
et al. (2008), a qual foi atribuda o nome fora de conectividade (connectivity strength),
pois ela leva em considerao apenas as ligaes existentes no cdigo fonte, que, em grande
parte dos sistemas legados, o nico documento existente, ou pelo menos o nico confivel
(ERDEMIR; TEKIN; BUZLUCA, 2011; ERDEMIR; BUZLUCA, 2014).
Essa tcnica baseia-se na quantidade e tipos de parmetros dos mtodos de uma
classe que so utilizados por outra, sendo que quanto maior a quantidade e/ou a complexi-
dade dos parmetros, maior ser a ligao entre as classes. Sua frmula descrita atravs
Captulo 4. Modernizao de sistemas monolticos para arquitetura orientada a servios 31
da equao:
X X
F C(N1 , P1 ) = F C(Mn , Mp ) (4.1)
Mn M SET (N1 ) Mp M SET (P1 )
PAbscount(Mp )
P ricount(M ) w + COX(Pi ) , se Mn chama Mp
p pri i=0
F C(Mn , Mp ) =
0 , caso contrrio
(4.2)
P
w
aT Y P E(Pi ) pri

, se a primitivo
COX(Pi ) = wabs , se a membro de Pi (4.3)

COX(a) wabs , caso contrrio

Em que:
N1 , P1 = Classe de negcio e persistncia respectivamente;
MSET(N1 ) = Conjunto de mtodos da classe N1 ;
Mn , Mp = mtodo especfico da classe;
Pricount(Mp ) = quantidade de parmetros do tipo primitivo no mtodo Mp;
Abscount(Mp ) = conjunto de parmetros que so classes criadas pelo desenvolvedor;
wpri , wabs = pesos para parmetros primitivo e criados pelo desenvolvedor (wpri +
wabs . = 1, geralmente wabs > wpri , pois tipos criados costumam ser mais complexos
que tipos primitivos). Esses pesos devem ser definidos pelo Engenheiro de Sofware
responsvel pela modernizao do sistema legado (Eunjoo Lee et al., 2003);
Pi = classe passada como parmetro para o mtodo Mp e que foi criada pelo desen-
volvedor e
COX(Pi ) = valor da complexidade da classe criada pelo desenvolvedor.
Para exemplificar, ser feito o clculo da fora de conectividade entre as classes

N1 e P1 do trecho do cdigo mostrado na Figura 4.1. O primeiro passo o clculo da
complexidade (COX) dos parmetros dos mtodos de P1 e que so executados por N1,
sendo esses parmetros uma entidade criada no projeto (E1), uma classe externa ao projeto,
pertencente a uma biblioteca (Ex), e dois parmetros de tipos primitivos, um inteiro (i1) e
float (flt1).
Como E1 possui dois atributos primitivos, o valor de sua complexidade COX(E1)
= 2 * wpri 2 * 0,3 0,6. No calculada a complexidade para o tipo EX, pois sua
implementao, assim como sua complexidade, no de responsabilidade do sistema, sendo
considerado para esse caso, apenas o peso wabs para representar essa complexidade. Para
os parmetros primitivos, i1 e flt1, tero como complexidade o peso wpri .
public class N1{ public class P1{ public class E1{

public void metodoN1(){ public void metodoP1(E1 e1, float flt1){ private int attrInt;
P1 p1 = new P1(); ... private String attrStr;
p1.metodoP1(e1, 0.85); }
p1.metodoP3(ex, 7); ...
public void metodoP3(Ex ex, int i1){
... ...
} }
} } }
Figura 4.1 Exemplo de cdigo para clculo da fora de conectividade
Com essas informaes possvel calcular a fora de conectividade entre N1 e P1,

somando as complexidades dos parmetros de cada mtodo de P1 executado por N1, sendo
o clculo apresentado a seguir:
F C(N 1, P 1) = (COX(E1)+wpri )+(wabs +wpri ) (0, 6+0, 3)+(0, 7+0, 3) 0, 9+1 1, 9
Na abordagem proposta, a fora de conectividade ser utilizada como insumo para

a refatorao da camada de negcio, em relao execuo de classes da camada de
persistncia, explicada da Seo 4.2.1.
4.1.2 Algoritmo Fast Community

Apesar de o agrupamento de classes atravs de seus relacionamentos no ser uma
tarefa muito complexa, s vezes, necessrio fazer a diviso do componente gerado, de
forma a diminuir seu tamanho. Para realizar essa diviso, utilizou-se o algoritmo de
"clusterizao"chamado fast community, definido por Newman (2003). O objetivo principal
desse algoritmo, executado sobre grafos, encontrar as communities, sendo que community
sructure uma organizao especial, em que vrtices formam grupos com alta densidade nas
arestas internas e baixa densidade nas arestas externas (ERDEMIR; TEKIN; BUZLUCA,
2011).
Segundo Erdemir e Buzluca (2014), este algoritmo apresentou-se superior a outros
da literatura, quando observados sob os critrios de authoritativeness, stability e extremity
of cluster distribution, significando (ERDEMIR; TEKIN; BUZLUCA, 2011; ERDEMIR;
BUZLUCA, 2014):
Authoritativenes: similaridade entre a decomposio feita por profissionais e a

automatizada por um algoritmo de "clusterizao";
Stability: o resultado da extrao automtica no deve produzir efeitos drastica-

mente diferentes quando executados sobre verses similares de um software com
pequenas alteraes e
Extremity of cluster distribution: diz respeito equivalncia do tamanho dos

componentes, pois, no se deve produzir componentes muito grandes ou muito
pequenos por no serem comuns na arquitetura dos mesmos, alm de poder ocasionar
a diminuio da coeso e o aumento do acoplamento.
Apesar desse algoritmo no ter sido inicialmente idealizado para a "clusterizao"de

classes em sistemas orientados a objetos, Erdemir, Tekin e Buzluca (2011), Erdemir e
Buzluca (2014) demonstram essa possibilidade, criando um grafo a partir do cdigo fonte
do sistema, sendo que cada vrtice representa uma classe, as arestas seus relacionamentos
e a seta pertencente as arestas indica que a classe de origem executa mtodos da classe de
destino. Um exemplo desse grafo pode ser visualizado atravs da Figura 4.2, sendo que o
cdigo que o originou composto por quatro classes, N1, N2, N3 e N4, a classe N2 executa
mtodos das classes N1, N3 e N4, e a classe N3 executa mtodos de N4.
Figura 4.2 Exemplo de grafo
O algoritmo fast community descrito no Algoritmo 1 (NEWMAN, 2003; ERDE-

MIR; TEKIN; BUZLUCA, 2011; SHIOKAWA; FUJIWARA; ONIZUKA, 2013; ERDEMIR;
BUZLUCA, 2014).
1 Considere cada vrtice como um cluster diferente;

2 while existir mais de um cluster do
3 Junte os dois clusters que tiveram o maior crescimento, ou menor reduo da
modularidade;
end
4 Selecione o ponto de corte do dendrograma resultante, analisando o maior valor de
da modularidade;
Algoritmo 1: Algoritmo Fast Community.
Conforme pode ser observado no algoritmo, a "clusterizao" feita em iteraes e,

em cada uma delas, dois clusters so agrupados at que reste apenas um nico cluster.
Essa sequencia de agrupamentos gera um dendrograma, que mostra a ordem em que os
agrupamentos foram feitos.
A Figura 4.3 mostra o dendrograma relacionado ao grafo da Figura 4.2, sendo
que a rgua na parte superior indica o nmero de iteraes que o algoritmo teve. Nela
possvel verificar que o primeiro agrupamento foi o das classes N2 e N1, pois, com
ele, conseguiu-se o maior ganho de modularidade (W=0,6250) em relao as outras
possibilidades de agrupamento (N2-N3, N2-N4 e N3-N4). Na segunda iterao o maior ganho
da modularidade foi com a juno de N2 com N3 (W=0,500), e para a ltima iterao
restou a juno dos dois nicos componentes existentes, N1-N2 e N2-N3, transformando
tudo em um nico cluster e encerrando o algoritmo.
Figura 4.3 Clusterizao
A escolha do ponto de corte ser baseada na modularizao que cada iterao gera,
de acordo com a modularidade que o sistema possui em cada iterao. Neste exemplo,
optando-se pelo ponto de corte nas junes N1-N2 ou N3-N4 o mesmo resultado ser
gerado, ou seja, produzir dois componentes, um contendo as classes N1 e N2 e outro
contendo as classes N3 e N4. importante ressaltar que pode haver casos em que o
melhor no selecionar nenhum ponto de corte, mantendo todas as classes em um nico
componente. O clculo da modularidade feito atravs da seguinte frmula (ERDEMIR;
TEKIN; BUZLUCA, 2011; SHIOKAWA; FUJIWARA; ONIZUKA, 2013; ERDEMIR;
BUZLUCA, 2014):
P
Qw = i (C(i))
C(i) = eii ai2
Em que:
Qw = modularidade;
eii = quantidade de arestas internas dividida pelo total de arestas do grafo (frao
de arestas internas ao cluster) e
ai 2 = quantidade de arestas externas dividida pelo total de arestas do grafo (frao

de arestas externas que se ligam ao cluster).
A escolha do ponto de corte baseada no valor da modularidade do sistema em

cada iterao (varivel "Q"da Figura 4.2), sendo os critrios utilizados para tal seleo
sero detalhados na Seo 4.2.2.
4.2 Proposta de Metodologia de Modernizao

A abordagem demonstrada nesta pesquisa foi definida a partir da utilizao de
mecanismos de identificao de componentes/servios. Pois a pesquisa objetiva auxiliar na
modernizao, para SOA, de sistemas orientados a objetos, monolticos, e que tambm
possuam uma arquitetura de trs camadas. A proposta composta por trs etapas,
conforme pode ser observada pela Figura 4.4, que foi criada seguindo a notao BPMN
(Object Management Group (OMG), 2011).
Figura 4.4 Macro Fluxo da abordagem de modernizao de sistemas OO para SOA
Como boa parte dos sistemas legados no possuem documentao ou estas esto
desatualizadas ou incompletas (LEWIS; MORRIS; SMITH, 2005; KHADKA et al., 2013;
ERDEMIR; BUZLUCA, 2014), todas as tcnicas apresentadas usam como entrada apenas
o prprio cdigo fonte do sistema, analisando-o e/ou refatorando-o para atingir o objetivo
final.
Na primeira etapa feita uma anlise do cdigo, verificando as ligaes entre as
classes e calculando a fora de conectividade (FC) entre as classes de negcio e as classes
de persistncia utilizadas. A FC utilizada como base nas refatoraes para diminuir a
quantidade de relacionamentos existentes. Na segunda etapa, a partir do cdigo refatorado,
executado o agrupamento das classes de acordo com seus relacionamentos. Para os casos
necessrios, o engenheiro de software executa o algoritmo de "clusterizao"fast community
(Seo 4.1.2), responsvel pela diviso em grupos menores. A etapa final culmina na criao
de web services a partir das classes de negcio. Nesta ltima etapa no so definidas
tcnicas especficas, mas critrios para auxiliar na tomada de deciso do engenheiro na
criao dos servios. Devido a variedade de formas possveis que os desenvolvedores podem
utilizar para determinar se uma classe de negcio ou persistncia, como incluso em
pacotes especficos ou estender determinada classe, a identificao da camada das classes
ficar a cargo do Engenheiro de Software encarregado pela modernizao do sistema.
Nas sees a seguir sero detalhadas as etapas da abordagem, suas tcnicas e
ferramentas utilizadas, alm de demonstr-las atravs de sua execuo sobre o sistema SIGA-
EPCT (Sistema Integrado de Gesto Acadmica da Educao Profissional e Tecnolgica).
Esse sistema atende os requisitos iniciais e utilizado por alguns Institutos Federais de
Educao, Cincia e Tecnologia do pas.
4.2.1 Diminuio das dependncias

Com o intuito de melhorar a coeso e o acoplamento dos web services resultantes,
o primeiro passo melhorar esses atributos nas classes existentes. Para guiar esta etapa,
definiu-se que ser mantida, para cada componente gerado (conjunto de classes), a arquite-
tura em camadas existente no sistema original. A camada de negcio, que a camada de
mais alto nvel dentro de cada componente, ir disponibilizar seus mtodos como servios.
Partindo-se desta premissa, foram feitas anlises de cada camada, iniciando pela
persistncia e, assim, identificou-se a existncia de relacionamentos entre suas classes. Isto
um indcio de que elas esto tratando de regras de negcio, sendo necessrias refatoraes,
transportando parte do cdigo para a camada superior. Esta alterao possibilita a criao
futura de componentes menores, conforme demonstrado atravs da Figura 4.5, que contm
a representao do cdigo original na Figura 4.5a e do cdigo refatorado na Figura 4.5b.
(a) Componente Original

(b) Componente Refatorado
Figura 4.5 Refatorao das classes de persistncia
Aps essas refatoraes, passou-se para a anlise da camada de negcio e seus

relacionamentos com a persistncia. Percebeu-se que no negcio existiam diferentes classes
relacionadas a uma mesma classe de persistncia. Embora essa utilizao no quebre o
conceito de camadas (FOWLER, 2002), essa prtica dificulta a criao das classes em
componentes menores, conforme ilustrado pela Figura 4.6a.
Para tentar diminuir o tamanho do componente a ser gerado, definiu-se mais uma
refatorao, na qual cada classe de persistncia ir se relacionar com apenas uma classe de
negcio, conforme ilustrado na Figura 4.6b.
(b) Componente Refatorado

(a) Componente Original
Figura 4.6 Refatorao das classes de negcio
Porm, para realizar a operao proposta primeiro deve-se identificar qual classe de
negcio ser responsvel por qual classe de persistncia. Isto feito calculando a FC entre
cada classe das camadas de negcio e persistncia, sendo que a frmula para o clculo da
FC foi explicada na Seo 4.1.1. Com base na FC, cada classe de persistncia dever se
relacionar com a classe de negcio que possuir a maior conectividade.
Para exemplificar essa refatorao, supem-se um sistema com duas classes de
negcio (N1 e N2), duas de persistncia (P1 e P2) e trs de entidade (E1, E2 e E3),
conforme mostrado na Figura 4.7.
Inicialmente necessrio calcular a complexidade (COX) das classes usadas como
parmetros entre N1 e P1, ou seja, as entidades E1 e E2. Como E1 tem dois atributos
primitivos ento sua complexidade COX(E1) = 2 * wpri 2 * 0,3 0,6. Para o clculo
referente a classe E2, temos COX(E2) = 1 * wpri + COX(E3) * wabs 1 * 0,3 + (1 *
0,3) * 0,7 0,51. Para esse exemplo usou-se os valores 0,3 e 0,7 para os pesos wpri e wabs
respectivamente, conforme definidos por Eunjoo Lee et al. (2003).
Com o valor das complexidades obtidas anteriormente possvel calcular a fora
de conectividade entre N1P1, N1P2, N2P1, N2P2, tendo:
F C(N 1, P 1) = 0 wpri + ((COX(E1) + COX(E2)) + (COX(E2) + 1 wpri ))

0 0, 7 + (0, 6 + 0, 51) + (0, 51 + 1 0, 3) 1, 11 + 0, 81 1, 92
F C(N 1, P 2) = 1 wpri 1 0, 3 0, 3
public class N1{ public class N2{

public void metodoN1(E1 e1, E2 e2){ public void metodoN2(E1 e1, E2 e2){
P1 p1 = new P1(); P1 p1 = new P1();
p1.metodoP1(e1, e2); p1.metodoP3(e2, 5);
p1.metodoP3(e2, 7); ...
... P2 p2 = new P2();
P2 p2 = new P2(); p2.metodoP4(e1, e2);
p2.metodoP2(100000); ...
... }
}
} }
public class P1{ public class P2{

public void metodoP1(E1 e1, E2 e2){ public void metodoP2(long l1){
... ...
} }
public void metodoP3(E2 e2, int i1){ public void metodoP4(E1 e1, E2 e2){
... ...
} }
} }
public class E1{ public class E2{ public class E3{

private int attrInt; private long attrLng; private boolean attrBool;
private String attrStr; private E3 attrE3;
} } }
Figura 4.7 Exemplo de cdigo
F C(N 2, P 1) = 1 wpri + COX(E2) 1 0, 3 + 0, 51 0, 81
F C(N 2, P 2) = 0 wpri + (COX(E1) + COX(E2)) 0 0, 7 + (0, 6 + 0, 51) 1, 11
Comparando as foras de conectividade, tem-se que N1 possui uma conectividade

maior com P1 (FC= 1,92) e N2 com P2 (FC= 1,11). Com essa informao, segue-se
para a refatorao das classes N1 e N2, para que elas utilizem apenas suas respectivas
persistncias, e caso necessrio, passem a relacionar entre si.
Nessa refatorao, inclui-se os mtodos que fazem chamadas a persistncia, caso
eles no existam. Ento deve-se substituir as chamadas originais para que utilizem os
mtodos recm inseridos. O resultado pode ser observado na Figura 4.8.
Aps essa alterao, verificou-se que alguns mtodos tinham em seu corpo apenas
uma chamada classe de persistncia pertencente a outra classe de negcio, no fazendo
sentido sua permanncia e optando-se por exclu-los. Como consequncia, algumas classes
de negcio ficaram sem nenhum mtodo em seu corpo, sendo possveis suas retiradas
do projeto, aps devida verificao de sua inutilizao pela camada de apresentao. A
exemplificao desses procedimentos pode ser visualizada na Figura 4.9.
O processo completo desta etapa pode ser visto na Figura 4.10. Na etapa seguinte,
o novo cdigo analisado e, a partir de seus relacionamentos, feita a "clusterizao"das
classes, formando grupo de classes coesos e com baixo acoplamento.
Cdigo Original Cdigo Refatorado

P1 p1 = new P1(); P1 p1 = new P1();
p1.metodoP1(e1, e2); p1.metodoP1(e1, e2);
p1.metodoP3(e2, 7); p1.metodoP3(e2, 7);
... ...
P2 p2 = new P2(); N2 n2 = new N2();
p2.metodoP2(100000); n2.metodoP2(100000);
... ...
} }
... public void metodoP3(E2 e2, int i1){

P1 p1 = new P1();
} p1.metodoP3(e2, i1);
}
...
}

P1 p1 = new P1(); N1 n1 = new N1();
p1.metodoP3(e2, 5); n1.metodoP3(e2, 5);
... ...
P2 p2 = new P2(); P2 p2 = new P2();
p2.metodoP4(e1, e2); p2.metodoP4(e1, e2);
... ...
} }
... public void metodoP2(long l1){

P2 p2 = new P2();
} p2.metodoP2(l1);
}
...
}
Figura 4.8 Refatorao: Incluso de Mtodos
Cdigo Original Migrao da Persistncia Excluso de Mtodo
public class N3{ public class N3{ public class N3{

public void metodoP4(E2 e2, public void metodoP4(E2 e2, int
, int i1){ , i1){ ...
P4 p4 = new P4(); N4 n4 = new N4();
p4.metodoP6(l1); n4.metodoP6(l1); }
} }
public class N4{
... ...
...
} }
public void metodoP6(long l1){
public class N4{ public class N4{ P4 p4 = new P4();
p4.metodoP6(l1);
... ... }
}
} public void metodoP6(long l1){
P4 p4 = new P4();
p4.metodoP6(l1);
}
}
Figura 4.9 Refatorao: Alterao das chamadas aos mtodos

Figura 4.10 Fluxo do processo de diminuio das dependncias das classes
4.2.2 Clusterizao
Aps as refatoraes para diminuio das dependncias, deve-se reanalisar o cdigo
fonte, de forma a agrupar as classes para que, posteriormente, venham a formar componentes
que iro disponibilizar servios. Como cada classe de negcio j engloba um conjunto
especfico de persistncias, torna-se possvel simplificar essa anlise, focando apenas na
camada de negcio.
O objetivo dessa etapa unir as classes que possuem relacionamento, criando
grupos independentes. Porm, pode ser necessrio que alguns desses componentes precisem
ser divididos, diminuindo, assim, seus tamanhos. Como uma tentativa dessa reduo,
executado o algoritmo apresentado na Seo 4.1.2.
Para exemplificar a execuo desse algoritmo, primeiramente deve-se criar um grafo
a partir do cdigo do sistema. A Figura 4.11 mostra o grafo contendo as classes de negcio
do cdigo da Figura 4.7, sendo includo outras arestas nesse grafo para melhor ilustrar a
execuo do algoritmo de "clusterizao".
Para esse grafo, inicialmente efetuado o clculo de sua modularidade, considerando
cada aresta como um cluster diferente, obtendo os valores:
2
0 2
C(N 1) = 4
4
0, 25
2
0 3
C(N 2) = 4
4
0, 5625
2
0 2
C(N 3) = 4
4
0, 25
2
0 1
C(N 4) = 4
4
0, 0625
Qw = C(N 1) + C(N 2) + C(N 3) + C(N 4) = 0, 25 + 0, 5625 + 0, 25 + 0, 0625

1, 125
Figura 4.11 Exemplo de grafo
A modularidade Qw acima reflete o valor quando considera que cada aresta, que
representa uma classe, um cluster diferente, sendo Qw obtido atravs da soma do clculo
de C(N1), C(N2), C(N3) e C(N4), que levam em considerao as arestas internas e externas
de cada cluster.
O prximo passo do algoritmo agrupar os dois clusters que geraram um maior
ganho de modularidade. Essa variao da modularidade deve ser calculada agrupando as
classes que possuem arestas entre si (N1N2, N1N3, N2N3 e N2N4), sendo o valor
da modularidade Qw para cada agrupamento demonstrado a seguir.
A unio de N1 a N2 resulta em:
2
1 3
C(N 1, N 2) = 4
4
= 0, 3125
Qw1 = C(N 1, N 2) + C(N 3) + C(N 4) = 0, 3125 + 0, 25 + 0, 0625 0, 625
Q1 = Qw1 Qw = 0, 625 (1, 125) 0, 50
2
1 2
C(N 1, N 3) = 4
4
=0
Qw2 = C(N 1, N 3) + C(N 2) + C(N 4) = 0 + 0, 5625 + 0, 0625 0, 625
Q2 = Qw2 Qw = 0, 625 (1, 125) 0, 50
2
1 3
C(N 2, N 3) = 4
4
= 0, 3125
Qw3 = C(N 2, N 3) + C(N 1) + C(N 4) = 0, 3125 + 0, 25 + 0, 0625 0, 625
Q3 = Qw3 Qw = 0, 625 (1, 125) 0, 50
2
1 2
C(N 2, N 4) = 4
4
=0
Qw4 = C(N 2, N 4) + C(N 1) + C(N 3) = 0 + 0, 25 + 0, 25 0, 50
Q4 = Qw4 Qw = 0, 50 (1, 125) 0, 625
Com base nas simulaes apresentadas acima, a juno que trouxe o maior ganho
de modularidade foi a juno de N2 com N4 que obteve um ganho de 0,625 (Q4 = 0, 625).
Essa juno encerra a primeira iterao do algoritmo, lembrando que as iteraes acabam
somente quando todas as arestas estiverem dentro do mesmo cluster.
Para a segunda iterao deve-se fazer novamente todas as junes possveis, mas
agora considerando N2 e N4 como um nico cluster. Dessa forma as junes possveis so
N1N3, N1N2,N4 e N2,N4N3. Nessa iterao a modularidade a ser utilizada como
base deve ser a que gerou a juno, ou seja Qw4 .
2
1 2
C(N 1, N 3) = 4
4
=0
Qw5 = C(N 1, N 3) + C(N 2, N 4) = 0 + 0 0
Q5 = Qw5 Qw4 = 0 (0, 50) 0, 50
2
2 2
C(N 1, N 2 N 4) = 4
4
= 0, 25
Qw6 = C(N 1, N 2 N 4) + C(N 3) = 0, 25 + 0, 25 0
Q6 = Qw6 Qw4 = 0 (0, 50) 0, 50
2
2 2
C(N 2 N 4, N 3) = 4
4
= 0, 25
Qw7 = C(N 2 N 4, N 3) + C(N 1) = 0, 25 + 0, 25 0
Q7 = Qw7 Qw4 = 0 (0, 50) 0, 50

Como todas as junes da segunda iterao gerou um mesmo ganho na modularidade

(Q5 = Q6 = Q7 = 0, 50), pode-se escolher qualquer uma delas, sendo que nesse
exemplo ser escolhido a primeira juno, de N1 com N3. Feito essa escolha resta apenas
juntar os clusters N2-N4 com o N1-N3 e teremos todas as arestas em um nico cluster,
encerrando, assim, o algoritmo que gerar o dendrograma da Figura 4.12.
Figura 4.12 Clusterizao
Segundo Girvan e Newman (2003) o valor de Qw [-0,5, +1] geralmente varia entre
0,3 e 0,7, sendo que o valor para estruturas com forte ligao varia entre 0,6 e 0,7. Com
base nesses dados, verifica-se que, para o exemplo da Figura 4.12, o melhor deixar todas
as classes em um nico componente, pois no foi encontrado um ponto de corte em que o
valor da modularidade esteja dentro da variao citada.
Utilizando das informaes obtidas nessa etapa, possvel separar os grupos de
classes de negcio e suas respectivas dependncias em projetos separados. Cada projeto
ter classes de negcio e de persistncia exclusivas. Porm, como a camada de entidade a
representao da base de dados, as entidades utilizadas sero copiadas para cada projeto,
de acordo com a utilizao, podendo haver duplicao de classes. Contudo, no o foco
desse trabalho tratar da separao das entidades. Caso haja interfaces e superclasses na
camada de negcio e/ou de persistncia, elas tambm sero copiadas, conforme sugerido
por Wang et al. (2008).
O processo de "clusterizao"dessa seo pode ser visto na Figura 4.13. O prximo
passo consiste na a criao e disponibilizao dos servios para cada um dos projetos
criados, de forma que possam ser acessados atravs da internet.
Figura 4.13 Fluxo do processo de clusterizao
4.2.3 Criao dos servios

Seguindo as etapas descritas anteriormente tm-se vrios grupos de classes que
podero disponibilizar servios. Alm disso, conforme dito anteriormente, os mtodos a
serem disponibilizados sero os existentes na camada de negcio de cada componente.
Cada linguagem especifica anotaes, bibliotecas e cdigos a serem inseridos para
que sejam disponibilizados os web services. Alm disso, existem vrias IDEs que agilizam
esse processo, de forma que no ser detalhado uma tcnica especfica para isso, sendo
essa seo responsvel pela discusso de pontos importantes a serem observados.
Independente da forma em que os web services forem criados, ser necessrio alterar
as chamadas feitas classes que agora pertencem a outro servio. Uma ilustrao dessa
refatorao pode ser visualizada na Figura 4.14.
Para que a refatorao citada acima possa ser realizada, primeiramente os web
services precisam criados. Porm, existem algumas restries a serem observadas no
momento da criao desses servios, conforme levantado por Guo et al. (2005), sendo elas:
1. O tipo do mtodo deve ser pblico;
2. Mtodos abstratos no podem ser publicados porque esse tipo de mtodo no contm
um corpo com sua implementao, ficando esta implementao a cargo de suas
subclasses que podero publicar seus mtodos;
Chamada entre classes Chamada entre servios
class Classe1{ class Classe1{

//Classe2 e Classe2 pertencem ao mesmo projeto ...
... //Classe2 migrou para outro servico
Classe2 classe2 = new Classe2(); ServicoClasse2 classe2 = new ServicoClasse2();
classe2.metodo2(); classe2.metodo2();
... ...
Classe3 classe3 = new Classe3(); //Classe3 continua no mesmo projeto
classe3.metodo3(); Classe3 classe3 = new Classe3();
... classe3.metodo3();
} ...
} }
}
Figura 4.14 Refatorao chamada entre servios
3. Mtodos com mesmo nome devem possuir nomes de servio diferentes, pois o padro
WSDL, responsvel pela descrio e localizao dos servios, no leva em considerao
as assinaturas dos mtodos, somente seus nomes;
4. Se um mtodo possui transao, mas no a raiz dessa transao, no deve ser

disponibilizado como servio, pois ele possui apenas parte da operao a ser realizada.
A ltima restrio s relevante se um mtodo que no raiz de uma transao

no contiver uma operao completa, o que nem sempre acontece. Pode haver mtodos que
realizam uma operao completa, mas que tambm compem uma funcionalidade maior
ao mesmo tempo. Porm, independente dele ser executado sozinho ou em conjunto com
outros mtodos, em ambos os casos pode existir a necessidade de controlar a transao.
No exemplo da Figura 4.14, se o metodo1 fizer uso de transao, esse controle deve ser
mantido mesmo depois da refatorao, j que no houve mudana da funcionalidade.
Como um dos objetivos dessa abordagem que a funcionalidade original seja
mantida no sistema modernizado, importante que as funcionalidades em que todo
um conjunto de operaes so concludas, ou nenhum de seus resultados so efetivados,
mantenham essas mesmas propriedades. Isso conseguido atravs do uso de transaes que
so mecanismos para garantir que todos os participantes de uma aplicao alcancem um
resultado de comum acordo. Ela tem sido historicamente definida atravs das propriedades
ACID (Atomicidade, Consistncia, Isolamento e Durabilidade), sendo essas propriedades
definidas como (REUTER; GRAY, 1993):
Atomicidade: todas operaes so concludas ou nenhuma operao concluda.
Consistncia: a aplicao deve sair de um estado consistente para outro estado

tambm consistente.
Isolamento: os efeitos de uma operao no so compartilhados para fora da

transao at que seja concluda com sucesso.
Durabilidade: uma vez que a transao for concluda com sucesso, as alteraes
devem permanecer mesmo em caso de futuras falhas.
A Seo 4.2.3.1 traz mais detalhes sobre o controle de transaes entre servios
diferentes.
4.2.3.1 Transaes entre servios
Segundo Snell (2002), transaes so conceitos fundamentais na construo de

aplicaes distribudas confiveis, porm, nenhuma das principais especificaes de web
services (SOAP, WSDL, UDDI, etc), foram projetadas para prover mecanismos que
permitam a eles se conectarem para criar solues dependentes e confiveis.
Para resolver esse problema a IBM, juntamente com a Microsoft, definiram duas
especificaes complementares, a WS-Coordination (NEWCOMER; ROBINSON, 2009b),
e a WS-Transaction (NEWCOMER; ROBINSON, 2009a). A WS-Coordination prov
mecanismos para criar e registrar servios, usando os protocolos definidos pela WS-
Transaction (FREUND; STOREY, 2002; LANGWORTHY et al., 2004), sendo seus nveis
de operao visualizados na Figura 4.15.
Figura 4.15 Padres de descrio de web services (FREUND; STOREY, 2002)
WS-Coordination
Segundo Freund e Storey (2002), Langworthy et al. (2004), o framework definido

pela WS-Coordination composto por trs elementos:
Servio de ativao: cria uma atividade e especifica seu protocolo de ativao

disponvel;
Servio de registro: coordena a seleo de protocolos e registra os participantes e
Servio de coordenao: controla o processo de concluso das atividades, utili-

zando para isso o protocolo de coordenao selecionado para a transao (definidos
pela especificao WS-Transaction).
Para cada nova atividade criada, o servio de ativao retorna um Coordination-

Context (elemento XML utilizado em uma mensagem como convite para participar de
uma atividade), que contem os seguintes campos (LANGWORTHY et al., 2004):
Identificador da atividade;
Tipo da transao (atmica ou de negcio);
Endereo do servio de registro;
Tempo de expirao da atividade (opcional) e
Elementos extendidos, que permitem que outras informaes sejam comunicadas.
Temos, ento, que o framework de coordenao prov um sistema para gerenciar

comunicaes entre web services, alm de poder trabalhar com sistemas que utilizam
transaes ACID, assim como outras formas de transao. De modo que fica a cargo da
coordenao de protocolos (definida pela especificao WS-Transaction) implementar as
transaes ACID (FREUND; STOREY, 2002).
WS-Transaction
Segundo Freund e Storey (2002), Langworthy et al. (2004), a especificao WS-

Transaction define os protocolos de coordenao atmicos e de negcio.
O protocolo para transaes atmicas utilizado para tratar atividades com tempo
de vida curto. No escopo desse protocolo observado todo o conjunto de operaes a
serem executadas, sendo que ou todas so concludas com sucesso, ou em caso de falha
de alguma delas, nenhuma operao efetivada. Esse objetivo atingido utilizando o
protocolo Two-Phase Commit (2PC).
O protocolo 2PC coordena o registro dos servios para poder tomar a deciso de
efetivar ou cancelar as operaes e informa todos os servios do resultado final, sendo esta
deciso a mesma para todos os servios envolvidos. Essa tomada de deciso feita nas
duas fases descritas a seguir (LANGWORTHY et al., 2004):
Fase de preparao: todos os participantes so avisados para aguardarem sinal de

concluso ou cancelamento de suas operaes e, ento, votar no resultado final. Esse
voto propagado para o coordenador geral da transao para tomar a deciso final.
Fase de efetivao: se todos os participantes votarem pela concluso, ento as

operaes so efetivadas, caso contrrio so abortadas.
O protocolo para transaes de negcio trata de atividades de longa durao,

mas, para diminuir a espera pela utilizao dos recursos, os resultados das operaes
intermedirias devem ser liberados mesmo antes do trmino de todo o processo. Mecanismos
de gerenciamento de falha e compensao so geralmente utilizados para reverter os efeitos
de atividades anteriormente completadas.
possvel usar ambos protocolos em combinao, conforme pode ser observado na
Figura 4.16, sendo que a atividade 2 utiliza transaes atmicas e a atividade 3 utiliza
ambas as transaes, atmicas e de negcio. A imagem mostra tambm a relao existente
entre os protocolos WS-Transaction e WS-Coordination.
Figura 4.16 Utilizao dos protocolos de transao (LANGWORTHY et al., 2004)
O fluxo dessa etapa pode ser visualizada na Figura 4.17.
Figura 4.17 Fluxo para criao dos servios

Conforme detalhado neste captulo, a abordagem proposta para modernizao
de sistemas monolticos, orientados a objetos e que tambm possuem arquitetura de
trs camadas, composta por trs etapas (Seo 4.1). A primeira a diminuio de
dependncias (Seo 4.2.1), que ir reduzir a quantidade de relacionamentos entre as
classes, tanto na camada de persistncia quanto na de negcio. A segunda etapa a
"clusterizao", (5.3.2) que agrupar as classes relacionadas, e a ltima define critrios a
serem seguidos durante a criao dos web services.
Para auxiliar na etapa de diminuio de dependncias, utilizada a frmula da
fora de conectividade (Seo 4.1.1), que calcula a fora de ligao entre as classes. Na
etapa de "clusterizao" executado o algoritmo fast community (Seo 4.1.2) que agrupa
as classes relacionadas permitindo a diviso dos grupos com tamanhos indesejados.
No prximo captulo apresentado o estudo de caso, feito sobre um sistema acad-
mico, que executa as trs etapas apresentadas, demonstrando a efetividade das mesmas.
Foram utilizadas ferramentas que automatizam a execuo das duas primeiras etapas,
diminuio de dependncias e clusterizao, mostrando a eficcia da semi-automatizao
dessas etapas. Para a etapa de criao de servios, apresentada a implementao dos
critrios definidos, para a criao dos web services, dentro do sistema acadmico.
50
5 Estudo de caso e avaliao da abordagem
O principal objetivo deste estudo de caso analisar a eficcia do modelo de

modernizao proposto dentro do contexto de sistemas monolticos, orientados a objetos e
que possuem tambm uma arquitetura de trs camadas, sendo que foi executado seguindo
a metodologia Goal/Question/Metric (BASILI; CALDIERA; ROMBACH, 1994).
5.1 Contexto
Segundo Kitchenham e Pickard (1998), o estudo de caso define o conjunto de
objetivos e limitaes em que ele deve ser executado. Para definir esses objetivos, a
metodologia GQM (Goal/Question/Metric) foi utilizada, derivando em um conjunto de
questes que devem ser respondidas para determinar se o objetivo foi alcanado.
Objetivo (Goal): Avaliar a abordagem proposta, em relao a sua eficcia, do
ponto de vista do engenheiro de software e no contexto de sistemas monolticos, orientados
a objetos e que tenham sido desenvolvidos com arquitetura de trs camadas.
Definido o objetivo, ele refinado em questes para caracterizar a forma em que
a avaliao do objetivo ser realizada (BASILI; CALDIERA; ROMBACH, 1994). As
questes (questions) definidas foram:
Questo 1: Que tipo de melhoria a refatorao das classes traz?
Nesta questo, tenta-se identificar a melhoria obtida com a etapa de Diminuio
de dependncias (Seo 4.2.1).
Questo 2: Quais foram as melhorias obtidas nos componentes gerados?
Nesta questo, tenta-se identificar os benefcios obtidos com a etapa de "Clusteriza-
o"(Seo 5.3.2).
Questo 3: A funcionalidade original mantida aps a criao dos servios?
Nesta questo, tenta-se verificar se as funcionalidades originais foram mantidas
aps a modernizao de arquitetura.
Para responder s perguntas, um conjunto de mtricas (metrics) so definidas e
associadas s questes (WOHLIN et al., 2000), sendo elas apresentadas na Tabela 5.1,
na qual a coluna Medida mostra a medida utilizada para o clculo, a coluna Questes
mostra qual questo a mtrica est relacionada e a coluna Resultados Esperados
indica se esperado que os percentuais aumentem () ou diminuam (), para as mtricas
M1 a M4. Para a mtrica M5, a coluna de resultados indica o percentual de testes de
Captulo 5. Estudo de caso e avaliao da abordagem 51
regresso executados com sucesso.
Tabela 5.1 Lista de mtricas e relao com as questes do paradigma GQM.

Resultado
Mtrica Medida Questo
Esperado
M1 % de variao no acoplamento mdio das classes ACCL Q1
M2 % de variao no tamanho dos componentes TACO Q2
M3 % de variao na complexidade dos componentes COXP Q2
M4 % de variao no acoplamento entre componentes ACCO Q2
M5 % de testes de regresso realizados com sucesso TEST Q3 100%
A medida ACCL (acoplamento entre classes) calculada somando-se a quantidade

de classes de negcio ou persistncia referenciadas por uma classe de negcio, desconside-
rando o nmero de vezes em que a referncia acontece. TACO (tamanho do componente)
a quantidade de classes de negcio ou persistncia que fazem parte um componente.
ACCO (acoplamento entre componentes) a quantidade de outros componentes que ele
referencia, independente do nmero de vezes que isso acontece. TEST a execuo de um
caso de teste no qual a comparao da funcionalidade original com a do web service geram
o mesmo resultado. Vale ressaltar que as medidas ACCL e TACO consideram somente as
classes de negcio e persistncia devido ao fato de ser essas as classes a serem distribudas
entre os componentes, sendo que as demais sero copiadas de acordo com a necessidade.
COXP (complexidade de um componente) foi definida por Cho, Kim e Kim (2001)
e representa a complexidade esttica de um componente (CSC). Ela leva em considerao
os relacionamentos entre as classes contidas no componente. Sua frmula definida como:
m
X
CSC = (Count(Ri ) W (Ri ))
i=1
Em que:
Count(Ri ) = Quantidade de cada tipo de relacionamento entre as classes (Depen-

dncia, Agregao, Generalizao, Composio) e
W(Ri ) = Peso atribudo para cada tipo de relacionamento (Tabela 5.2).
Tabela 5.2 Pesos com base no tipo de relacionamento para o clculo do CSC (CHO;
KIM; KIM, 2001).
Tipo do Relacionamento Peso

Dependncia 2
Associao 4
Generalizao 6
Agregao 8
Composio 10
5.2 Planejamento
Para o teste da proposta foi escolhido o sistema acadmico SIGA-EPCT12 (Sistema
Integrado de Gesto Acadmica da Educao Profissional e Tecnolgica), na qual as
tcnicas apresentadas foram testadas. Este sistema foi idealizado inicialmente atravs de
um projeto de pesquisa da SETEC/MEC que financiou o seu desenvolvimento atravs de
parcerias com vrios Institutos Federais em todo o Brasil. Hoje, o sistema acadmico
utilizado por alguns desses institutos.
A escolha desse sistema se deve ao fato dele atender aos requisitos da pesquisa
sendo um sistema Java, desenvolvido sob a arquitetura trs camadas e monoltico, pois
possui apenas um arquivo EAR (Enterprise Application aRchive) a ser publicado em
um servidor de aplicao. Ele possui 200 classes de negcio, 244 persistncias e 474
entidades, totalizando 1148 classes e 77.092 linhas de cdigo, desconsiderando a camada
de apresentao.
5.2.1 Ferramentas utilizadas

Para automatizar os clculos necessrios foram utilizadas duas ferramentas, sendo
que a primeira foi desenvolvida no decorrer desta pesquisa, nomeada de JCluster, e
responsvel pelos clculos citados anteriormente (sees 4.1.1 e 4.1.2). A segunda a
ferramenta JTransformer3 , encarregada de analisar padres de cdigo e realizar refatoraes.
Ambas as ferramentas, JCluster e JTransformer, so plugins da IDE Eclipse. Elas
executam suas operaes utilizando como entrada o projeto Java aberto na IDE. A
limitao dessas ferramentas que elas funcionam apenas para sistemas desenvolvidos em
Java. Para a utilizao dessas ferramentas em outros sistemas Java ser necessrio que
o Engenheiro de Software faa algumas configuraes sobre a identificao das camadas
de negcio e persistncia. Nas sees subsequentes suas funcionalidades sero brevemente
descritas, ficando a explicao de suas utilizaes para a seo do estudo de caso (Captulo
5).
5.2.1.1 JCluster
O plugin idealizado e desenvolvido durante esta pesquisa4 possui as funcionalidades

listadas abaixo, sendo que todas elas usam como base o cdigo do projeto aberto na
IDE Eclipse. Alm disso, esse plugin identifica uma classe como pertencente camada de
negcio ou persistncia se faz atravs do pacote em que a classe pertence.
1
Site do sistema: <http://colaboracao.sigaepct.net/>
2
Foi utilizada nessa pesquisa foi a verso em desenvolvimento 11.1 (commits do dia 05/10/2016)
3
Site da ferramenta <https://sewiki.iai.uni-bonn.de/research/jtransformer/start>
4
Disponibilizado no github atravs do link <https://github.com/aborgesrodrigues/
hierarchical-clustering>
Clculo da fora de conectividade: calcula a FC entre as classes, seguindo as

frmulas da Seo 4.1.1. Com base nesses clculos, tambm so identificadas as
maiores ligaes entre as classes de negcio e persistncia, detalhado na Seo 4.2.1.
Gerao de grafo: a partir do cdigo-fonte do sistema gerado um grafo, no qual

cada classe de negcio representada por um vrtice e seus relacionamentos por
arestas. Cada conjunto de classes relacionadas tem a mesma cor para facilitar a
identificao. O exemplo de um grafo gerado pode ser visualizado na Figura 5.7 da
Seo 5.3.2, no qual ser descrito a utilizao desse plugin em um estudo de caso.
Gerao de dendrograma:5 ao clicar em qualquer uma das classes do grafo,

gerado um dendrograma, seguindo o algoritmo fast community (Seo 4.1.2),
baseando-se em todas as arestas que contm a mesma cor da selecionada. Ao clicar
com o boto direito em um dos pontos de juno possvel pre-visualizar a quantidade
de grupos a serem gerados diferenciando-os atravs das cores. Ao clicar duas vezes
em uma juno, as cores dos grupos do dendrograma so repassadas para o grafo.
A visualizao dessa funcionalidade est ilustrada na Figura 5.9 da Seo 5.3.2, na
qual descrita a utilizao desse plugin em um estudo de caso.
Separao dos componentes: para cada conjunto de cores do grafo criada uma
pasta com todas as classes de mesma cor, alm de suas dependncias. Com isso
possvel criar projetos independentes para cada componente, observando apenas as
bibliotecas necessrias.
Dentre as funcionalidades citadas acima, vale detalhar o algoritmo usado para a

colorao dos vrtices no grafo, sendo ele descrito no Algoritmo 2.
1 while existir vrtice sem cor do

2 Selecione um dos vrtices sem cor;
3 Defina uma cor para o vrtice selecionado;
4 while existir vrtices referenciados pelo vrtice selecionado do
5 Selecione um dos vrtices referenciados;
6 if vrtice no possuir cor then
7 Insira mesma cor do vrtice selecionado;
else
8 Insira uma nova cor para o vrtice selecionado;
end
end
end
Algoritmo 2: Algoritmo de colorao dos vrtices do grafo.
5
Foi utilizado como base o sistema j existente disponvel atravs do link <https://github.com/
lbehnke/hierarchical-clustering-java>:
O if/else da linha 6 do algoritmo 2 faz com que um vrtice que possua mais de
uma origem no tenha a mesma cor de nenhuma delas. Esse passo foi definido para que o
engenheiro de software no seja induzido a englobar esses vrtices a nenhuma das origens
primrias.
5.2.1.2 JTransformer
Essa ferramenta um plugin do Eclipse que permite a anlise e as transformaes

de cdigos Java (KNIESEL; HANNEMANN; RHO, 2007; ALVES; HAGE; RADEMAKER,
2011; BINUN; KNIESEL, 2012). O JTransformer analisa o cdigo fonte, suas dependncias
com projetos e bibliotecas, alm de criar uma representao do cdigo em Prolog6 . Suas
anlises podem ser expressas em um nvel de abstrao bastante elevado. Kniesel, Hanne-
mann e Rho (2007) compararam-na com um conjunto de outras ferramentas de anlise e
transformao de cdigo, sendo que o JTransformer foi melhor nos seguintes aspectos:
Expressividade: no limita as anlises e transformaes que podem ser realizadas;
Turnaround: suporta um nvel de abstrao que promove o rpido desenvolvimento

sem limitar a expressividade;
Integrao: realiza anlise e integrao sem necessidade de ferramentas externas;
Performance: rapidez nas anlises individuais (de milisegundos a segundos);
Escalabilidade: a performance nas anlises individuais acontecem mesmo em siste-

mas com dezenas de milhares de classes;
Suporte a Multi-projetos: permite a anlise e as transformaes de mltiplos

projetos que relacionam entre si e
Disponibilidade: possibilita baixar verses do software e documentao apropriada.
Alves, Hage e Rademaker (2011) tambm compararam algumas ferramentas, anali-

sando os items abaixo, sendo que o resultado pode ser visualizado na Tabela 5.3, sendo que
o "x" e -" representam se a ferramenta atende ou no determinado critrio, respectivamente,
seguindo os seguintes critrios:
Paradigma em que a linguagem de busca baseada;
Tipos de dados suportados pela linguagem;
6
Detalhes da linguagem Prolog pode ser encontrado no link <http://lpn.swi-prolog.org/lpnpage.php?
pageid=online>
Parametrizao que indica se o comportamento das consultas podem depender de

parmetros;
Polimorfismo que especifica se as consultas podem ser abstradas dos tipos em que
as relaes so construdas;
Modularidade que determina a extenso em que possvel reutilizar uma consulta

especfica para construir outras consultas e
Bibliotecas que determina a possibilidade de usar e/ou criar bibliotecas de consultas

genricas.
Tabela 5.3 Comparao entre ferramentas de anlise de cdigo (ALVES; HAGE; RADE-
MAKER, 2011).
Criterio vs. Grok Rscript JRelCal SemmleCode CrocoPat JGraLab JTransformer
Ferramentas
Paradigma Relational Relational and API OO and FO-logic SQL-like and FO-logic
Comprehensions Relational SQL-like Imperative Path Expr
String x x x x x x x
Tipos Int x x x x x x x
Real x - x x x x x
Bool - x x x x x x
Other - Composite Java Object - Edges Logic terms
and Location and Node
Parametrizao - x x - x x x
Polimorfismo - x x x - x x
Modularidade x x x x x - x
Bibliotecas - - x x - - x
A Figura 5.1 mostra alguns dos predicados bsicos do JTransformer (aqueles

terminados com T maisculo, com marcao onde aparecem). As palavras iniciadas
em maisculo so variveis, o underscore uma pseudo-varivel que indica atributos
irrelevantes para a anlise/transformao.
Para facilitar o entendimento de quem no familiarizado com os termos da
programao lgica, Kniesel, Hannemann e Rho (2007) fazem uma comparao desse tipo
de programao com suas contrapartes do banco relacional (entre parnteses).
Cada n AST um fact base (tupla do banco de dados). O predicado (nome da
relao), representa o tipo do n, o primeiro parmetro (atributo) um identificador nico
(chave) do respectivo n e os outros parmetros so valores primitivos ou identificadores
de outros ns, representando referncia, sendo que o segundo parmetro referencia o n
superior. Diferentemente dos bancos relacionais, os programas lgicos no armazenam
facts para cada relao, mas define predicados atravs de derivao de regras e podem ser
definidos recursivamente.
Para exemplificar esses conceitos, a seguir ser dada uma breve explicao dos
termos destacados da Figura 5.1, lembrando que o caractere underscore () pode ser utilizado
em qualquer um dos parmetros esperados, para o caso de se fazer buscas genricas:
fieldDefT (linha 6): identifica a declarao de um atributo dentro de classes

(InClass), pertencente a determinado tipo (T);
methodT (linha 10): identifica mtodos, pertencentes a classes (InClass), que

possuam parmetros (Args) e tipo de retorno (T) especficos;
getFieldT (linha 18): identifica o acesso a um atributo dentro de um mtodo

(MName) por uma varivel ou sendo enviado como parmetro a outro mtodo
(OnRecv);
execT (linha 21): identifica uma execuo dentro de um mtodo (CallingM);
NewClassT (linha 24): identifica a instanciao de uma classe, dentro de um

mtodo (CalledM), que tenha recebido alguns parmetros (Args);
paramT (linha 27): identifica os parmetros parametrized, por exemplo, em

String[], Class<T>, os colchetes ([]) e a sequncia <T>, sero os itens iden-
tificados;
forLoopT (linha 30): identifica a instruo for executada em determinado mtodo

(InMethod);
1 type(Type,Name) :-
2 classDefT(Type, _,Name, _).
3
4 field(Field, InClass, FType, FName) :-
5 type(_ ,FType, _),
6 fieldT(Field,InClass,T,FName, _).
7
8 method(Meth,InClass,MName,Args,RetType) :-
9 type( _,RetType, _),
10 methodT(Meth,InClass,MName,Args,T, _, _).
11
12 instanceMethod(Method,InClass,Name,Args,Type) :-
13 method(Method,InClass,Name,Args,Type),
14 not(Name = <init>),
15 not(Name = <cinit>).
16
17 accesses(AccessingM,InBlock,OnRecv,AccessedField) :-
18 getFieldT( _,InBlock,AccessingM,OnRecv,AccessedField).
19
20 calls(CallingM,InBlock,CalledM,Args) :- // %Inst. method
21 execT(Exec,InBlock,CallingM, Call),
22 applyT(Call,Exec,CallingM, _, _,Args,CalledM).
23 calls(CallingM,InBlock,CalledM,Args) :- // %Constructor
24 newClassT( _,InBlock,CallingM,CalledM,Args, _, _, _).
25
26 param(Param,InMethod,Type) :-
27 paramT(Param,InMethod,type( _,Type, _), _).
28
29 forLoopBody(For,InMethod, LoopBody) :-
30 forLoopT(For, _,InMethod, _, _, _,LoopBody).
Figura 5.1 Exemplo de script do JTransformer (KNIESEL; HANNEMANN; RHO, 2007)
Nas prximas sees sero mostradas a abordagem proposta para modernizao

de sistemas orientados a objetos para SOA e a utilizao dos mecanismos apresentados
dentro dessa abordagem.
5.3 Execuo
Nessa seo, ser descrita a execuo da abordagem de modernizao sobre o
sistema SIGA-EPCT, detalhando cada uma das etapas, facilitando o entendimento das
questes, das mtricas e de seus clculos.
5.3.1 Diminuio das dependncias

Conforme explicado na Seo 4.1, os primeiros passos da abordagem proposta
a diminuio das dependncias entre as classes, de forma que possa obter componentes
menores nas etapas posteriores.
Inicialmente procura-se por classes de persistncia que executem mtodos de outras
classes tambm de persistncias. Para isso utilizou-se o plugin JTransformer (Seo 5.2.1.2)
para realizar essa pesquisa dentro do cdigo fonte do sistema SIGA-EPCT.
A Figura 5.2 mostra o cdigo desse script, cuja explicao segue abaixo:
Linha 1: nome do mtodo;
Linha 5: identifica toda chamada a mtodo feita, atribuindo o mtodo de origem e o

receptor da chamada s variveis MethodCall e Receiver respectivamente;
Linhas 7 e 8: identificam todas as classes de persistncia (classes que extendem de

GenericDAO);
Linhas 10 a 16: filtram somente os receptores que so classes de persistncia;
Linhas 18 a 20: filtram apenas os mtodos de classe de persistncia;
Linha 22: ignora chamadas a mtodos dentro da prpria classe e
Linha 24: ignora chamadas a mtodos da superclasse.
O resultado da execuo do script mostrado na Figura 5.3, sendo que, no ponto

1, tem-se o cdigo da classe com a identificao do ponto onde o script encontrou a
chamada entre persistncias. O ponto 2 mostra os scripts existentes e a quantidade de
ocorrncias encontradas na execuo de cada um deles. J o ponto 3 contm as prprias
ocorrncias, indicando a classe e o nmero da linha em que ela ocorre. Ao clicar em uma
dessas ocorrncias aberto o arquivo com o cursor j na linha identificada, como mostrado
no ponto 1.
No caso da classe RegraAcademicaDAO da Figura 5.3, a refatorao para re-
mover a dependncia entre as classes de persistncia, consiste em retirar o mtodo inserir
dessa classe e migr-lo para a classe de negcio correspondente, que a ManterRegraA-

cademicaEJB. O resultado dessas operaes pode ser observado atravs dos trechos de
cdigo mostrado na Figura 5.4. Cada uma das ocorrncias encontradas deve ser analisada
individualmente, pelo engenheiro de software, para encontrar uma melhor forma de retirar
esses relacionamentos indesejados da camada de persistncia, sendo essa uma limitao
que pode ser abordada em um trabalho futuro.
1 :- module(persistence__persistence_analysis, [ persistence_persistence_call/1 ]).
2
3 persistence_persistence_call(CallId) :-
4 %Identifica cada chamada de metodo
5 callT(CallId, _, MethodCall, Receiver, _, _, _, _),
6 %Identifica classes de persistncia
7 fully_qualified_name(GenericDAO, 'org.sigaept.nucleo.dao.GenericDAO'),
8 subtype(DAO, GenericDAO),
9 %filtra somente chamadas feitas a classes de persistncia
10 (
11 (identT(Receiver, CallId, MethodCall, Local), localT(Local, _, _, DAO, _, _))
12 ;
13 newT(Receiver, _, _, _, _, _, _, DAO, _)
14 ;
15 callT(Receiver, _, _, _, _, _, _, DAO)
16 ),
17 % busca somente em mtodos de classes de persistncia
18 methodT(MethodCall, DAOClass, _, _, _, _, _, _),
19 subtype(DAOClass, GenericDAO),
20 classT(DAOClass,_,_,_,_),
21 %ignorar chamadas dentro da prpria classe
22 DAOClass \== DAO,
23 %ignorar chamadas a superclasse
24 DAO \== GenericDAO.
Figura 5.2 Script para encontrar chamadas entre classes de persistncia
Figura 5.3 Funcionamento da ferramenta JTransformer
A prxima etapa para diminuio das dependncias fazer com que uma classe de
persistncia fique relacionada a somente uma classe de negcio, conforme explicado na
Seo 4.2.1. Para isso, primeiramente necessrio identificar as persistncias e a classe de
negcio correspondente a cada uma delas. Assim, foi desenvolvido o plugin JCluster (Seo
5.2.1.1) que analisa o cdigo e calcula a fora de conectividade (Seo 4.1.1) entre todas
as classes de negcio e persistncia. Ao final do processo gerado um arquivo contendo
essa relao, conforme pode ser observado na Tabela 5.4.
Mtodo na classe de persistncia Mtodo migrado para classe de negcio
public class RegraAcademicaDAO extends public class ManterRegraAcademicaEJB extends

, GenericDAO<RegraAcademica> { , GenericCrudEJB<RegraAcademica,
... , RegraAcademicaDAO> implements
, IManterRegraAcademicaEJB{
@Override ...
public void inserir(RegraAcademica entidade)
, throws NegocioException { @Override
if (entidade.getAtoAutorizativo() != null && public void inserir(RegraAcademica entidade)
, entidade.getAtoAutorizativo().getId() , throws NegocioException {
, == null) if (entidade.getAtoAutorizativo() != null &&
new AtoAutorizativoDAO(this.em).inserir( c , entidade.getAtoAutorizativo().getId()
, entidade.getAtoAutorizativo()); , == null)
new AtoAutorizativoDAO(this.em).inserir( c
super.inserir(entidade); , entidade.getAtoAutorizativo());
}
super.inserir(entidade);
... }
}
...
}
Figura 5.4 Refatorao para retirada de dependncia entre persistncias
Tabela 5.4 Segmento do resultado da identificao das classes persistncias com suas
respectivas classes de negcios
Classe de Persistncia Classe de Negcio FC

RegraAcademicaDAO ManterRegraAcademicaEJB 81.82
MatrizCurricularPeriodoDAO ManterMatrizCurricularEJB 28.05
ModalidadeAprendizagemDAO ManterCursoEJB 0.15
LotacaoServidorDAO ManterServidorEJB 129.35
ParticipacaoEventoExternoDAO ManterEventoExternoEJB 0.90
ContaCorrentePagamentoDAO ManterServidorEJB 1.94
CDUDAO ManterCDUEJB 0.30
AlunoDAO ManterRelatorioAlunoEJB 523.80
ProjetoExtensaoDAO ManterProjetoExtensaoEJB 64.56
ReaberturaTurmaDAO ReaberturaTurmaClasseEJB 33.62
Com essas informaes pode-se fazer a refatorao no cdigo, alterando as classes de

negcio que aparecem no arquivo gerado, de forma que elas executem somente as suas classes
de persistncia, modificando as demais chamadas para as classes de negcio adequada.
Essa refatorao feita, em sua maior parte, tambm pela ferramenta JTransformer (Seo
5.2.1.2), atravs da utilizao de scripts e pode ser representado pelo Algoritmo 3.
A excluso citada nas linhas 5 e 6 se faz possvel porque existe somente um mtodo
com apenas uma chamada para outra classe de negcio sem agregar nem processar nenhuma
informao. Dessa forma, esse mtodo torna-se irrelevante, j que possvel obter a mesma
informao apenas chamando a classe de destino diretamente. Conforme dito antes, ao
realizar essas excluses, pode acontecer de algumas classes ficarem sem nenhum mtodo
em seu corpo, podendo, ento, ser excludas do projeto, sendo que no sistema SIGA-EPCT,
sete classes de negcio foram removidas.
1 for cada classe de negcio do

2 Criao de mtodos na classe de negcio para disponibilizar suas persistncias,
caso no existam;
3 for cada mtodo da classe que possui chamadas persistncias de outra classe de
negcio do
4 Migrar chamadas a persistncias no pertencentes a ela para os mtodos do
negcio de destino;
5 if mtodo contiver somente essa chamada then
6 Excluir mtodo;
end
end
end
Algoritmo 3: Algoritmo para alterao das chamadas da camada de negcio
(a) Incluso de mtodos
(b) Alterao de chamada e excluso de mtodos
Figura 5.5 Resultado das refatoraes da modernizao onde uma persistncia est
associada apenas um negcio
A Figura 5.5 mostra parte do resultado das etapas da refatorao citada anterior-
mente, sendo que a 5.5a exibe alguns mtodos inseridos na classe ManterCalendarioA-
cademicoEJB, referentes a chamadas de sua persistncia que estavam includas em outras
classes. A Figura 5.5b demonstra a excluso de mtodos que no agregavam informao
ou processamento ao resultado da chamada (item 2.2 das etapas de refatorao). Alm
disso, tambm revela o resultado da alterao do mtodo removerFaltasDaAula, que
teve a chamada ao mtodo remover da classe FaltaDAO, alterado para uma chamada
ao mtodo de mesmo nome mas pertencente classe ManterDiarioClasseEJB, que a
responsvel pela persistncia.
Apesar de agilizar bastante o processo, ainda necessrio fazer pequenas adequaes
manuais no cdigo aps as refatoraes, como adequao dos imports e adaptao dos
mtodos duplicados que podem ter sido inseridos, alm da excluso, quando possvel, de
classes que ficaram sem nenhum mtodo, entre outros.
1 :- module(persistence_migration_transformation, []).
2
3 :- multifile(user:ct/3).
4
5 %CallId - Chamada a uma persistncia que no pertence classe de negcio
6 %Business - Classe de negcio onde ocorre a chamada
7 %BusinessTarget - Classe de negcio para onde foi a persistncia chamada
8 user:ct( replaceCalls(CallId, Business, BusinessTarget),
9 (
10 %cria a varivel do negcio a ser chamado
11 classT(BusinessTarget, _, NameBusinessTarget, _, _),
12 implementsT(_, BusinessTarget, BusinessTargetInterface),
13 fieldT(FieldEJB, Business, BusinessTargetInterface, NameBusinessTarget, null),
14 new_id(NewGetFieldEJB)
15 ),
16 (
17 %insere a varivel no cdigo
18 add(fieldAccessT(NewGetFieldEJB,_,_,_,FieldEJB,_)),
19 %substitui a chamada da persistncia para o negcio
20 replace(callT(CallId, Parent, Encl, _, Args, Method, TypeParams, Type),
21 callT(CallId, Parent, Encl, NewGetFieldEJB, Args, Method, TypeParams, Type))
22 )
23 ).
Figura 5.6 Parte do script de refatorao das classes de negcio
Parte desse script, responsvel pela substituio da chamada de um mtodo de

uma classe da persistncia pelo mtodo equivalente de sua respectiva classe de negcio,
pode ser observado na Figura 5.6, sendo a explicao desse script detalhada a seguir:
Linha 8: Varivel CallId identifica uma chamada a uma persistncia que no pertence
a classe de negcio, e BusinessTarget representa a classe de negcio para a qual a
persistncia foi migrada;
Linhas 9 a 15: Cria uma referncia para o atributo da classe BusinessTarget;
Linha 18: Cria a declarao de uma varivel do tipo BusinessTarget no cdigo;
Linhas 20 e 21: altera a chamada a um mtodo de uma persistncia para a classe de

negcio BusinessTarget.
Ao terminar as refatoraes pode-se iniciar o processo de "clusterizao"das classes.

O novo cdigo refatorado ser utilizado como base para a execuo do prximo passo.
5.3.2 Clusterizao
Seguindo o procedimento detalhado na Seo 4.2.2, foi criado o grafo do sistema
SIGA-EPCT, atravs da ferramenta JCluster (Seo 5.2.1.1), que representa as classes de
negcio e seus relacionamentos, sendo possvel visualizar parte dele na Figura 5.7. Nessa
figura cada conjunto de cores representa um possvel componente a ser gerado, sendo que
a colorao seguiu o Algoritmo 2 da Seo 5.2.1.1.
Na Figura 5.7 possvel ver a existncia de alguns grupos de vrtices isolados, porm
verifica-se que em grande parte eles esto inter-relacionados (dentro da marcao). Para esse
caso, e mesmo para os grupos menores, pode-se executar o algoritmo de "clusterizao"fast
community, descrito na Seo 4.1.2, gerando um dendrograma para tentar identificar uma
melhor diviso das classes. O algoritmo no executado sobre todo o sistema de uma vez,
sendo necessrio que o engenheiro de software escolha cada conjunto de classes que deseja
tratar. A Figura 5.8 mostra um zoom maior nas classes presentes dentro da marcao,
para melhor visualizao.
O dendrograma da Figura 5.9 representa a "clusterizao"dos vrtices contidos
dentro da marcao da Figura 5.7 e gerado ao se clicar em qualquer um desses vrtices.
Nessa imagem possvel verificar a modularidade em cada iterao e sua variao, conforme
explicado na Seo 4.1.2. Com base nas informaes disponibilizadas, o engenheiro de
software pode selecionar um dos pontos de juno e visualizar a quantidade de componentes
que esse ponto de corte ir gerar, atravs das cores apresentadas (Figura 5.9).
Ao escolher um ponto de corte, as cores do dendrograma so repassadas para o
grafo. Apesar do Engenheiro de Software ter liberdade na escolha do ponto de corte, Girvan
e Newman (2003) sugere que a modularidade do ponto escolhido seja igual ou superior a
0,6, conforme explicado na Seo 4.2.2. O engenheiro dever fazer esse procedimento em
todos os grupos de classes nos quais deseja diminuir seu tamanho.
Figura 5.7 Grafo representando o sistema SIGA-EPCT
Figura 5.8 Zoom do grafo representando o sistema SIGA-EPCT
Aps o trmino das clusterizaes, JCluster (Seo 5.2.1.1) cria diretrios separados
para cada grupo de cores existentes no grafo e move para elas cada conjunto que possuem a
mesma cor, levando alm das classes de negcio, suas persistncias, e copiando as entidades,
interfaces e superclasses utilizadas. Cada pasta conter todas as classes necessrias para
criao de um projeto que ir criar e disponibilizar os servios, sendo necessria a verificao

das bibliotecas extras que devem ser inseridas ou excludas.
Figura 5.9 Clusterizao das classes
5.3.3 Criao dos servios

Conforme explicado na Seo 4.2.3, no ser apresentada tcnica de automatizao
para criao e disponibilizao dos servios, mas ser exemplificado, dentro do estudo de
caso, as questes abordadas na referida seo.
O primeiro passo a disponibilizao dos mtodos como servios. Como foi defi-
nido que so as classes de negcio que iro disponibilizar seus mtodos, deve-se incluir
a anotao @javax.jws.WebService nessas classes. Essa anotao responsvel por
definir uma classe como web service e todos os mtodos pblicos existentes podero ser
acessados. Apesar de no ser obrigatrio, recomendado a utilizao da anotao @ja-
vax.jws.WebMethod nos mtodos a serem disponibilizados (KALIM, 2013). Um exemplo
de uma classe do sistema SIGA-EPCT contendo essas anotaes pode ser visualizada na
Figura 5.10.
Com os web services criados, necessrio verificar a existncia de mtodos com
mesmo nome, mesmo tendo assinaturas diferentes, conforme restries apresentadas na
Seo 4.2.3. possvel agilizar a identificao desses mtodos com a utilizao do plugin
JTransformer, sendo necessrio a criao de um script para isso, conforme pode ser visto
na Figura 5.11.
@WebService
public class ManterStatusAlunoEJB implements IManterStatusAlunoEJB {
@PersistenceContext(unitName = "siga")
private EntityManager em;
@WebMethod
public List<TipoStatusAluno> consultarTodosTipoStatusAluno() throws NegocioException {
return new TipoStatusAlunoDAO(this.em).consultarTodos();
}
Figura 5.10 Criao de web service
:- module(duplicated_method_names_analysis, [ duplicated_method_names_finder/2 ]).
duplicated_method_names_finder(MethodId, MethodIdAux) :-
%filtrar somente as classes de negcio
packageT(Package, 'org.sigaept.edu.negocio.ejb'),
compilationUnitT(CompilationUnit, Package, _, _, [ClassId]),
classT(ClassId, CompilationUnit, _, _, _),
%compara os mtodos dentro de uma mesma classe
methodT(MethodId, ClassId, MethodName, _, _, _, _, _),
methodT(MethodIdAux, ClassId, MethodNameAux, _, _, _, _, _),
%ignora a comparao de um mtodo com ele mesmo
MethodId \== MethodIdAux,
%compara mtodo com mesmo nome
MethodName == MethodNameAux.
Figura 5.11 Script para encontrar nomes de mtodos duplicados
Uma vez identificados os mtodos de mesmo nome, fica a cargo do engenheiro

de software alterar o nome do mtodo, ou o nome a ser disponibilizado como servio,
incluindo o atributo operationName anotao @javax.jws.WebMethod. A Figura
5.12 mostra ambas refatoraes, que produziro o mesmo resultado, feitas na classe
ManterAbonoFaltaEJB, que possui dois mtodos com o nome pesquisaSimples, mas
assinaturas diferentes.
Tratados os nomes dos mtodos, necessrio refatorar as chamadas s classes
que agora pertencem a outro componente e, consequentemente, a outro web service. Essa
refatorao pode ser visualizada no trecho cdigo da Figura 5.13. Uma explicao mais
detalhada sobre utilizao de web services pode ser obtida em Oracle (2016).
Feito os passos citados, resta ainda verificar a necessidade de controle de transao
dos mtodos, sendo necessria a anlise individual de cada mtodo pelo engenheiro de
software. Apesar de existir as transaes atmicas e de negcio, dentro do sistema SIGA-
EPCT, tem-se a necessidade de utilizar apenas a primeira, pois no existe nenhuma
operao de longa durao. A diferena entre esses tipos de transao explicado na Seo
4.2.3.
Alterao do nome do mtodo Alterao do nome do servio
@WebService @WebService
public class ManterAbonoFaltaEJB{ public class ManterAbonoFaltaEJB{
... ...
@WebMethod @WebMethod
public List<AbonoFalta> pesquisaSimples(...) { public List<AbonoFalta> pesquisaSimples(...) {
... ...
} }
@WebMethod @WebMethod(operationName="pesquisaSimples2")
public List<AbonoFalta> pesquisaSimples2(...){ public List<AbonoFalta> pesquisaSimples(...) {
... ...
} }
... ...
} }
Figura 5.12 Mudana dos nomes dos mtodos dos web services
public class ManterEducacensoEJB{ public class ManterEducacensoEJB {

@EJB ManterTurmaEJBService manterTurmaEJBService;
private IManterTurmaEJB ManterTurmaEJB;
...
... private List<RegistrosComposto>
private List<RegistrosComposto> , getDadosProfissionalDocencia(Docente
, getDadosProfissionalDocencia(Docente , docente) {
, docente) { ...
... List<Turma> listaTurma =
List<Turma> listaTurma = ManterTurmaEJB manterTurmaEJBService
.consultarTodosTurmasPorDocente(docente); .getManterTurmaEJBPort()
... .consultarTodosTurmasPorDocente(docente)
} ...
... }
} ...
}
Figura 5.13 Refatorao para chamada a web services
O primeiro passo para habilitar a transao adicionar a anotao @com.sun.xml.

ws.api.tx.at.Transactional na classe ou mtodo. Ao inserir a anotao na classe, todos
os mtodos dela seguiro as mesmas configuraes. Adicionando diretamente nos mtodos,
possvel definir configuraes diferentes para uma mesma classe. Oracle (2016) descreve
as opes de configurao existentes para essa anotao:
Verso: verso do contexto da coordenao de transao atmica utilizado pelo

web service e seus clientes. A verso especificada deve ser a mesmo atravs da
transao inteira, sendo os seguintes valores possveis: WSAT10, WSAT11, WSAT12
e DEFAULT
Tipo do fluxo: indica se o contexto da coordenao de transao atmica ser

passado adiante durante o fluxo da transao. Seus possveis valores podem ser
encontrados na Tabela 5.5.
Tabela 5.5 Valores de tipo de fluxo existentes (ORACLE, 2016).
Valor Cliente web service Web service

No exporta o contexto No importa o contexto
NEVER da transao mesmo que da transao mesmo que
possua uma transao j exista um fluxo de transao
Exporta o contexto de Importa o contexto da
SUPPORTS
transao somente se j transao somente se j
(Valor padro)
existir uma transao existir um fluxo de transao
Se no houver uma Se no houver um contexto
MANDATORY transao a ser exportada, de transao a ser importado,
um erro reportado um erro reportado
O cdigo final de um web service da classe ManterTurmaEJB, contendo as

anotaes descritas acima pode ser vista na Figura 5.14.
@WebService
@Transactional(value=Transactional.TransactionFlowType.SUPPORTS, version=Transactional.Version.DEFAULT)
public class ManterTurmaEJB extends GenericCrudEJB<Turma, TurmaDAO> implements IManterTurmaEJB {
...
@WebMethod
public List<Turma> consultarTodosTurmasPorDocente(Docente docente) {
return new TurmaDAO(em).consultarTodosTurmasPorDocente(docente);
}
...
}
Figura 5.14 Web service com controle de transao
Seguindo as orientaes apresentadas, possvel disponibilizar os web services

referentes a camada de negcio de cada componente identificado na seo anterior.
importante lembrar que embora no abordada por esta pesquisa, ainda ser necessrio a
refatorao da camada de apresentao do sistema, de forma a usar os servios criados,
ficando esta tarefa para um trabalho futuro.
5.4 Anlise e Resultados

Nesta seo sero analisadas os valores das mtricas calculadas aps a execuo
da abordagem, utilizando-as como base para avaliar se o objetivo de eficcia definido
anteriormente foi atingido.
5.4.1 Questo 1: Que tipo de melhoria a refatorao das classes traz?

Com a execuo da etapa de diminuio das dependncias, foi possvel observar
a reduo geral do acoplamento das classes atravs da Medida ACCL da Tabela 5.1. A
Tabela 5.6 mostra a quantidade mdia de dependncias das classes, antes e depois das
refatoraes, dividindo os resultados por camadas. Quando observada somente a camada
de negcio, o aumento do acoplamento encontrado ocorre porque originalmente no havia

muitas dependncias entre classes de negcio, mas sim a reutilizao do mesmo mtodo
da mesma classe de persistncia. Apesar disso, ainda possvel observar uma diminuio
mdia de 24% no acoplamento (mtrica M1 da Tabela 5.1) existentes nas classes.
Tabela 5.6 Clculo da quantidade mdia de dependncias das classes por camada

Negcio - Negcio 0,08 1,05
Negcio - Persistncia 4,34 2,30
Geral 4,42 3,36
Um exemplo que demonstra essa realidade apresentado pela Figura 5.15, mos-
trando que originalmente a classe CopiarTurmaEJB fazia uso de trs classes de persistn-
cia, PeriodoLetivoDAO, CursoDAO, TurmaDAO, e depois da refatorao passou a
referenciar apenas uma nica classe de negcio ManterTurmaEJB. Essa figura tambm
mostra a remoo de mtodos que deixaram de ser relevantes, pois passaram a existir na
classe de negcio ManterTurmaEJB.
Figura 5.15 Refatorao da classe CopiarTurmaEJB
5.4.2 Questo 2: Quais foram as melhorias obtidas nos componentes gerados?

Com a tcnica de "clusterizao", responsvel pela diviso dos componentes,
conseguiu-se uma diminuio da complexidade (medida COXP) e do tamanho dos com-
ponentes gerados (medida TACO), podendo ser facilmente verificado pela reduo da
quantidade de classes em cada componente. Porm ao se dividir um componente, pro-
vavelmente iro ser criados outros com dependncias entre si (medida ACCO), j que
originalmente eram um s componente. Entretanto, como o ponto de corte, responsvel
pela diviso do componente, de livre escolha do engenheiro de software, essa reduo
pode variar significativamente.
Para exemplificar, se o algoritmo de "clusterizao"for executado no maior compo-

nente do sistema SIGA-EPCT (cor azul da Figura 5.7), criado automaticamente a partir
dos relacionamentos das classes, teremos valores diferentes para as mtricas citadas acima.
A Tabela 5.7 mostra essa variao em relao as medidas definidas na Tabela 5.1,
sendo que os dados dessa tabela refletem ao componente e dendrograma das Figuras 5.8 e
5.9, respectivamente, com exceo da medida COXP que relacionado a complexidade
mdia de todo o sistema. As colunas da tabela 5.7 representa o componente original e
quatro conjuntos de componentes gerados aps a escolha de quatro dos possveis pontos
de corte do dendrograma, todos com modularidade superior a 0,6, conforme sugerido
por Girvan e Newman (2003). Para cada um desses pontos de corte, as linhas da tabela
representam:
Modularidade: valor da modularidade no ponto de corte;
Qtde de clusters: quantidade de componentes que o cluster original ir derivar;
TACO: quantidade mdia de classes pertencentes a cada componente derivado;
ACCO: acoplamento mdio entre os componentes derivados;
Tabela 5.7 Variao dos valores das mtricas de acordo com ponto de corte da clusteri-
zao
Aps Clusterizao
Ponto de Ponto de Ponto de Ponto de
Original
Corte 1 Corte 2 Corte 3 Corte 4
Modularidade 1 0,9612 0,8999 0,8117 0,7253
Qtde de componentes 1 2 3 4 5
COXP 14,20 13,96 13,73 13,51 13,30
TACO 22 11 7,33 5,5 4,4
ACCO 0 0,50 1,33 1,50 1,80
Com base nas medidas da Tabela 5.7 possvel calcular as mtricas M2, M3 e M4,
tambm calculadas a partir dos pontos de corte definidos nessa tabela (1 ao 4). Temos
ento:
M2: reduo variou entre 50% e 80%
M3: reduo variou entre 1,70% e 6,33%
M4: aumento variou entre 166% e 260%
Para a mtrica M4 foi utilizado como base o valor de ACCO calculado para o ponto
de corte 1, j que originalmente no existe dependncia com outro componente (ACCO =
0). Essas dependncias passam a existir aps a diviso do componente original, que gera
componentes menores que se relacionam.
5.4.3 Questo 3: A funcionalidade original mantida aps a criao dos

servios?
Conforme dito anteriormente, as alteraes propostas no alteram os algoritmos
do sistema, de forma que as mudanas so feitas apenas nas chamadas e/ou nomes e no
nos corpos dos mtodos, conforme explicitado nas Figuras 5.5 e 5.13.
Para o clculo da mtrica M3 foram criados 5 casos de teste7 nos quais foram
executados mtodos do sistema antes e depois da modernizao. A Tabela 5.8 mostra o
resultado da execuo dos testes, sendo que a coluna Classe representa a classe original do
sistema, Servio representa o web service criado a partir da classe, Mtodo o mtodo
tanto da classe quanto do web service que foi executado, Ind. informa se o web service
independente, ou seja, contm todo o cdigo dentro de si ou se depende de outro servio e
a coluna Resultado mostra o resultado dos testes.
Tabela 5.8 Resultado dos casos de teste
Classe Servio Mtodo Ind. Resultado
ManterCursoEJB ManterCursoService consultarTodosEtapaEnsino no sucesso
ManterTCCMatriculaEJB ManterTCCMatriculaService remover no sucesso
ManterTCCMatriculaEJB ManterTCCMatriculaService consultarTodosTCCs sim sucesso
ManterMatrizCurricularEJB ManterMatrizCurricularService consultarTodos no sucesso*
ReaberturaTurmaClasseEJB ReaberturaTurmaClasseService reabrirTurma sim sucesso*
Em todos os casos de teste foram obtidos sucesso nas comparaes, indicando que
a funcionalidade continuou trazendo os mesmos resultados. Os asteriscos (*) nos dois
ltimos resultados da Tabela 5.8 so para informar que foi necessrio uma refatorao
antes de sua execuo. O motivo foi pelo fato de as entidades utilizadas como parmetros
formarem um ciclo a partir de seus atributos, que geram erro no momento da montagem
dos XMLs para troca de mensagens, sendo necessrio retirar os ciclos encontrados. Um
exemplo de ciclo encontrado pode ser verificado pelas linhas destacadas dos trechos de
cdigos mostrados na Figura 5.16, onde para esse caso foi retirado o atributo private
List<ProjetoPedagogicoCurso> projetosPedagogicosCurso da classe Curso.
public class Curso extends GenericEntidadeId { public class ProjetoPedagogicoCurso extends
@CampoUnico(descricao="Cdigo") , GenericEntidadeId{
@Column(name="codigo")
private String codigo; ...
... @Column(name="nome_arquivo")
private String nomeArquivo;
@OneToMany(mappedBy="curso")
private List<ProjetoPedagogicoCurso> @ManyToOne
, projetosPedagogicosCurso; @JoinColumn(name = "curso_id")
private Curso curso;
...
} ...
}
Figura 5.16 Exemplo de ciclo

7
O ambiente de teste criado pode ser acessado atravs do link <https://github.com/aborgesrodrigues/
ambiente_teste_siga>.
Apesar de a alterao para retirada dos ciclos das entidades no ter uma complexi-
dade alta, pode afetar vrias partes do sistema, onde necessrio substituir as chamadas
aos atributos retirados por novos mtodos de consulta para trazer os mesmos dados.
5.5 Discusso
Com base nas mtricas calculadas para as questes definidas anteriormente pode-se
observar a eficcia da proposta de modernizao, sendo esse o objetivo principal deste
estudo de caso. Uma das principais caractersticas est na reduo do tamanho dos web
services gerados. Isso feito tanto na primeira etapa, diminuio de dependncias, que
reduz o acoplamento entre as classes, quanto na etapa de "clusterizao", que permite a
quebra dos grupos de classes. Outro ponto a incluso do controle de transaes entre
servios, que ajuda a garantir que as funcionalidades originais continuaro funcionando da
mesma forma.
Apesar dos benefcios obtidos, existem alguns pontos crticos a serem observados
nesta pesquisa. O primeiro relacionados ao uso da frmula da fora de conectividade
(Seo 4.1.1) para a diminuio do acoplamento das classes, e o segundo na utilizao
do algoritmo fast community na "clusterizao"das classes(Seo 4.1.2). Apesar de serem
tcnicas sobre as quais j foram comprovadas suas eficcias, no possvel assegurar que
so as melhores opes existentes para subsidiar essas operaes, pois embora existam
vrias abordagens que podem ser utilizadas para atingir o mesmo objetivo, faltam trabalhos
que os comparem de forma a auxiliar na escolha. Devido a complexidade existente em
realizar essas comparaes, essa atividade no foi includa no escopo desse trabalho.
Outro ponto crtico est relacionado aos testes. No foi utilizado nenhum framework
para a execuo dos testes da Seo 5.4.3, mas criou-se um ambiente integrado com o
sistema original e com os web services gerados, onde foi possvel executar ambos e comparar
os resultados. A no utilizao de um framework de testes como Junit8 ou Arquillian9 foi
por causa de problemas tcnicos encontrados, como a chamada de classes EJB (Enterprise
JavaBeans) de dentro dos casos de teste. Tambm no foi testado a performance dos web
services criados, ficando a cargo do engenheiro de software definir uma forma de fazer tais
validaes, alm de realizar um conjunto de testes que abranjam mais reas do sistema.
Apesar da abordagem proposta no exigir que o Engenheiro de Software possua um
profundo conhecimento sobre sistema a ser modernizado, o cdigo sistema SIGA-EPCT,
do estudo de caso foi conseguido pelo fato do autor pertencer a equipe de desenvolvimento,
o que prejudica essa avaliao. Apesar disso, a utilizao do sistema SIGA-EPCT como
estudo se caso foi devido a dificuldade de se conseguir acesso ao cdigo fonte de sistemas
8
Site do Junit: <http://junit.org/junit4/>
9
Site do Arquillian: <http://arquillian.org/>
razoavelmente complexos.
A metodologia proposta no tem a pretenso de gerar uma arquitetura ideal de
servios ao final do processo, mas garantir que esse novo cdigo seja funcional, mantenha as
mesmas funcionalidades do sistema original e facilite a manuteno dos servios disponibili-
zados. Um importante resultado a ser obtido permitir ao engenheiro de software, a partir
do cdigo refatorado, analisar pontualmente a performance de cada servio, identificando
possveis gargalos. A partir de uma anlise mais restrita, e no da totalidade do sistema,
possvel fazer novas refatoraes que se julgarem necessrias, podendo alterar a arquitetura
ou at mesmo a linguagem utilizada em cada servio sem afetar os demais web services,
desde que no sejam alteradas as assinaturas dos mtodos disponibilizados.

Neste captulo a abordagem de modernizao proposta foi executada no sistema
SIGA-EPCT como forma de um estudo de caso. Para guiar essa execuo foi utilizado o
paradigma GQM, com o objetivo de mostrar a eficcia da abordagem, que de acordo com
as mtricas estabelecidas, foi alcanado.
No prximo captulo sero apresentados as consideraes finais da abordagem de
modernizao proposta, apresentando suas principais contribuies, as oportunidades de
trabalhos futuros que permite, e os trabalhos correlatos existentes.
73
6 Consideraes finais e trabalhos futuros
Esta dissertao apresentou uma abordagem para modernizao de sistemas mo-

nolticos, orientados a objetos, e desenvolvidos com uma arquitetura de trs camadas,
para SOA. Diferentes tcnicas foram estudadas e aplicadas, como clculo da Fora de
Conectividade, "Clusterizao"e Refatoraes, que do suporte Reengenharia desses
sistemas.
6.1 Trabalhos correlatos

Conforme observado na Seo 2.2 existem vrias famlias de abordagens existentes
na literatura para modernizar sistemas legados para SOA. Contudo, nesta seo sero
apresentadas as abordagens referentes mesma famlia da apresentada nesta dissertao
(Famlia da identificao de servio), focando naquelas que utilizam sistemas orientados a
objetos como origem e que definem tcnicas de semi-automatizao do processo.
O primeiro trabalho o Eunjoo Lee et al. (2003), que define a frmula para o
clculo da fora de conectividade, utilizada na primeira etapa da abordagem proposta nesta
dissertao. Wang et al. (2008) utiliza o trabalho anterior como base e aprimora o clculo
da fora de conectividade, com a utilizao de pesos diferentes para atributos primitivos e
complexos. Com base na fora de conectividade feita a "clusterizao"hierrquica das
classes, que gerar um dendrograma com os agrupamentos realizados em cada iterao,
sendo que os novos valores da FC encontrados em cada iterao sero utilizados para
definir o ponto de corte. Na abordagem desta dissertao optou-se pela utilizao do
algoritmo fast community para a "clusterizao". Embora os trabalhos de Eunjoo Lee et al.
(2003) e Wang et al. (2008) tenham como objetivo a identificao de componentes e no
servios, sua comparao vlida, pois o foco deles tambm na identificao de grupos
de classes.
Budhkar e Gopal (2012) utiliza a similaridade existente entre as classes para realizar
um algoritmo de "clusterizao"hierrquico, utilizando-se de um threshold, definido pelo
engenheiro de software, como ponto de encerramento nas iteraes de agrupamento. Apesar
de no apresentar a frmula para o clculo da similaridade, deixa claro que baseado nos
tipos de relacionamentos existentes entre as classes, como herana, composio, execuo
de mtodos, etc.
Adjoyan, Seriai e Shatnawi (2014) define outra funo para calcular a ligao
entre as classes, a fitness function (FF), que leva em conta os clculos de functionality,
composability e self- containment. Neste trabalho tambm utilizado um algoritmo de
Captulo 6. Consideraes finais e trabalhos futuros 74
"clusterizao"hierrquico com base nos valores das FF obtidos. Para definir o ponto de
corte utilizado o algoritmo depth first search (DFS), sendo que inicialmente, no n raiz,
comparado a similaridade do n corrente com a similaridade dos ns filhos, sendo que
quando a similaridade do n corrente for maior que a mdia da similaridade dos ns filhos,
este n ser o ponto de corte.
Tanto o agrupamento das classes quanto a clusterizao delas se assemelham nas
propostas apresentadas acima, inclusive em relao a proposta desta pesquisa. Todas
essas abordagens, apesar de definirem critrios distintos, agrupam as classes atravs destes
critrios e utilizam algoritmos de "clusterizao"hierrquica para o agrupamento dessas
classes. Essas clusterizaes so todas feitas de forma hierrquica, sendo que algumas geram
grafos, criam dendrogramas e escolhem um ponto de corte (Eunjoo Lee et al., 2003; WANG
et al., 2008; ADJOYAN; SERIAI; SHATNAWI, 2014), ou agrupam hierarquicamente as
classes, analisando o valor que esse agrupamento gera at que se atinja um ponto de
parada, ou treshold, que assemelha-se ao uso do ponto de corte (BUDHKAR; GOPAL,
2012).
Uma das vantagens da abordagem de modernizao proposta em relao as apre-
sentadas anteriormente, so as refatoraes definidas com o intuito de diminuir o tamanho
dos servios a serem criados, enquanto as demais no possuem esta etapa. Outra vantagem
que a abordagem desta pesquisa leva em considerao a existncia de uma arquitetura
de camadas no sistema legado a ser modernizado, enquanto as demais abordagens descon-
sideram esse fato, podendo causar agrupamentos de classes inviveis de se manter, como
entidades e persistncia sem negcio, ou negcio e persistncia sem entidades, tornando-as
difceis de se aplicar nos sistemas com esse tipo de arquitetura.
6.2 Contribuies
A principal contribuio a definio de uma abordagem para a modernizao
para SOA de sistemas monolticos, orientados a objetos e que tambm possuam uma
arquitetura em camadas, atravs das etapas e tcnicas semi-automatizadas que foram
definidas nela.
A primeira etapa dessa abordagem, diminuio das dependncias, contribui com
tcnicas que permitem a semi-automatizao de refatoraes que reduzir a quantidade
de dependncias que cada classe possui, em relao a outras classes, tanto na camada
de persistncia quanto na de negcio, de modo a permitir um menor acoplamento nos
servios a serem gerados.
A segunda etapa, "clusterizao", tambm apresenta tcnicas que possibilitam
a semi-automatizao da identificao dos grupos de classes de negcio, que podero
disponibilizar seus mtodos como servios. Alm disso, tambm apresentada tcnicas
que permitem a diviso desses grupos, caso seja necessrio, devido quantidade de classes
que possuram em um primeiro momento.
Apesar da abordagem no ser direcionada a uma linguagem de programao
especfica, foi criado o plugin JCluster que implementa as tcnicas das duas primeiras
etapas da abordagem, semi-automatizando o processo para os sistemas desenvolvidos
na linguagem Java. A descrio da utilizao do plugin JTransformer para a anlise e
refatorao de cdigo contribui para elucidar seu funcionamento, que pode ser utilizado
das mais diversas formas.
A terceira etapa, criao de servios, apesar de no descrever nenhuma tcnica
para a criao dos web services, contribui com a descrio de como eles devem ser criados,
e as caractersticas que eles devem possuir.
6.3 Limitaes e trabalhos futuros

A abordagem de modernizao proposta abre espao para novas contribuies que
podero complement-las.
Como explicitado anteriormente, a abordagem de modernizao definida no
abrange a adequao da camada de apresentao, que necessitar ser refatorada para
que possa usufruir dos web services gerados. Essas refatoraes so bastante complexas
e trabalhosas e precisam de tcnicas e/ou ferramentas que permitam a automatizao
ou semi-automatizao do trabalho. Uma soluo seria a construo de uma ferramenta
para auxiliar essas refatoraes, alm de identificar os pontos a serem refatorados. Para
deix-la independente de linguagem ser necessrio que essa ferramenta permita a insero
de padres das chamadas aos web services para as diversas linguagens, de acordo com a
necessidade do Engenheiro de Software. Essa ferramente tambm pode ser utilizada para
refatorar as chamadas entre os web services, aps suas criaes, na etapa de criao de
servios.
Outro ponto no abordado a separao do banco de dados por servio. Essa
separao permitiria que cada servio possusse uma base de dados prpria. Como as
entidades so a representao do banco de dados, estas tambm provavelmente sero
afetadas, de forma que cada web service ter seu prprio conjunto exclusivo de entidades.
Para realizar essa tarefa ser necessrio descobrir quais tabelas so acessadas por quais
web services, montando um mapeamento. Alm disso, ser necessrio a excluso das chaves
estrangeiras entre tabelas de web services diferentes, sendo necessrio a incluso dessa
constraint dentro dos web services. Devero ser refatoradas as entidades, retirando os
atributos que referenciam entidades de outros web services, alm de refatorar os scripts
SQL (ou HQL), que utilizem essas referncias que foram removidas.
Na anlise dos relacionamentos entre classes de persistncia, da etapa de diminuio

de dependncias, no foi definido uma tcnica para automatizar as refatoraes necessrias.
Apesar de ser possvel agilizar a identificao dessas classes atravs de ferramentas como
a JTransformer, a migrao desse tipo de chamada para a camada de negcio, conforme
exemplificado pela Figura 5.4, exige conhecimento do sistema por parte do Engenheiro
de Software responsvel pela modernizao. Seria necessrio a criao/utilizao de uma
ferramenta que agilizasse tal refatorao, permitindo ao Engenheiro de Software interagir
com essa ferramenta para fazer as devidas configuraes, como a escolha da classe de
negcio que receber o cdigo removido da persistncia.
Conforme apresentado na Seo 5.5, no s este trabalho mas, a literatura em
geral sobre modernizaes para SOA, carece de estudos de comparao das tcnicas
utilizadas tanto para calcular a fora de ligao entre as classes, quanto para realizar a
"clusterizao"das mesmas. Para analisar as tcnicas que possibilitam o agrupamento de
classes pode-se utilizar a tcnica MoJo (TZERPOS; HOLT, 1999), que uma mtrica que
pode ser usada para avaliar a similaridade entre decomposies de um sistema. Uma forma
de avaliar os modelos de "clusterizao" a utilizada por Erdemir e Buzluca (2014), que
avalia as abordagens sobre os critrios de authoritativeness, stability e extremity of cluster
distribution.
Pelo fato desta pesquisa focar nos critrios a serem observados na criao de web
services, mas no estabelecer tcnicas para cri-los de fato, os testes destes web services
foram retirados do escopo da pesquisa, mas pode ser incorporado em um trabalho futuro.
Um importante tipo de teste seria o teste de regresso dos web services, comparando os
resultados do sistema monoltico original com o SOA refatorado, atravs de um conjunto
amplo de casos de teste e uso de ferramentas para auxiliar. Outros testes tambm podem
ser feitos como teste de performance, que analisa o comportamento dos web services atravs
de mtricas e valores de referncia pr-definidos, e o teste de stress, que verifica volume de
dados que web services consegue atender. O uso de ferramentas fundamental na execuo
de testes, como por exemplo as ferramentas SOAPUI 1 , TestingWhiz 2 e SOAtest 3 .
O plugin JCluster est disponvel para atualizaes, podendo melhorar a distribuio
dos vrtices (classes) no grafo gerado por ele, de forma a facilitar a visualizao. Se for
definida tcnicas especficas, possvel adicionar a funcionalidade de criao dos web
services e a refatorao das chamadas.
1
Disponvel em <https://www.soapui.org>
2
Disponvel em <http://www.testing-whiz.com/>
3
Disponvel em <https://www.parasoft.com/product/soatest/>
77
Referncias
ADJOYAN, S.; SERIAI, A.-D.; SHATNAWI, A. Service Identification Based on Quality

Metrics. Proceedings of the 26 International Conference on Software Engineering &
Knowledge Engineering (SEKE2014), p. 16, 2014. Citado 4 vezes nas pginas 28, 30, 73
e 74.
ALVES, T. L.; HAGE, J.; RADEMAKER, P. A comparative study of code query

technologies. In: Proceedings - 11th IEEE International Working Conference on Source
Code Analysis and Manipulation, SCAM 2011. [S.l.: s.n.], 2011. p. 145154. ISBN
9780769543475. Citado 3 vezes nas pginas 9, 54 e 55.
BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The goal question metric approach.
Encyclopedia of Software Engineering, v. 2, p. 528532, 1994. Citado na pgina 50.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice (3rd Edition)
(SEI Series in Software Engineering). [S.l.: s.n.], 2012. 640 p. ISBN 0321815734. Citado 2
vezes nas pginas 23 e 28.
BINUN, A.; KNIESEL, G. Joining forces for higher precision and recall of design pattern
detection. . . . , Technical report IAI-TR-2012-01, 2012. Citado na pgina 54.
BUDHKAR, S.; GOPAL, A. Component-based architecture recovery from object

oriented systems using existing dependencies among classes. International Journal of
Computational Intelligence Techniques, v. 3, n. 1, p. 5659, 2012. Citado 4 vezes nas
pginas 28, 30, 73 e 74.
CHIKOFSKY, E. J.; CROSS, J. H. Reverse Engineering and Design Recovery: A

Taxonomy. IEEE Software, v. 7, n. 1, p. 1317, 1990. ISSN 07407459. Citado 3 vezes nas
pginas 7, 18 e 19.
CHO, E. S.; KIM, M. S.; KIM, S. D. Component metrics to measure component quality.
Proceedings Eighth Asia-Pacific Software Engineering Conference, p. 419426, 2001. ISSN
1530-1362. Citado 2 vezes nas pginas 9 e 51.
CONNALL, D.; BURNS, D. Reverse Engineering: Getting a Grip on Legacy Systems.

Data Management Review, v. 24, n. 7, 1993. Citado 2 vezes nas pginas 13 e 17.
CONSTANTINOU, E. et al. Extracting reusable components: A semi-automated approach

for complex structures. Information Processing Letters, Elsevier B.V., v. 115, n. 3, p.
414417, 2015. ISSN 00200190. Citado 2 vezes nas pginas 28 e 30.
DAIGNEAU, R. Service Design Pattern. [S.l.: s.n.], 2012. XXXIII. 8187 p. ISSN
0717-6163. ISBN 9780874216561. Citado na pgina 25.
Dos Santos Brito, K. et al. LIFT - A Legacy information retrieval tool. Journal of
Universal Computer Science, v. 14, n. 8, p. 12561284, 2008. ISSN 0958695X. Disponvel
em: <http://www.scopus.com/inward/record.url?eid=2-s2.0-45949097336{&}partnerID=
40{&}md5=717a584161cfa00c2741519582>. Citado na pgina 13.
Referncias 78
DRAGONI, N. et al. Microservices: yesterday, today, and tomorrow. 2016. Citado 2 vezes
nas pginas 13 e 24.
ERDEMIR, U.; BUZLUCA, F. A learning-based module extraction method for

object-oriented systems. Journal of Systems and Software, Elsevier Inc., v. 97, p. 156177,
2014. ISSN 01641212. Citado 7 vezes nas pginas 14, 30, 32, 33, 34, 35 e 76.
ERDEMIR, U.; TEKIN, U.; BUZLUCA, F. Object Oriented Software Clustering Based on
Community Structure. Proceedings - 18th Asia-Pacific Software Engineering Conference,
APSEC 2011, p. 315321, 2011. ISSN 1530-1362. Citado 4 vezes nas pginas 30, 32, 33
e 34.
ERL, T. Service-Oriented Architecture: Concepts, Technology, and Design. City, p. 760,

2005. ISSN 0131858580. Citado na pgina 25.
Eunjoo Lee et al. A reengineering process for migrating from an object-oriented legacy
system to a component-based system. In: Proceedings 27th Annual International Computer
Software and Applications Conference. COMPAC 2003. [S.l.]: IEEE Comput. Soc, 2003. p.
336341. ISBN 0-7695-2020-0. ISSN 0730-3157. Citado 6 vezes nas pginas 28, 30, 31, 37,
73 e 74.
FIELDING, R. T. Architectural Styles and the Design of Network-based Software

Architectures. Building, v. 54, p. 162, 2000. ISSN 1098-6596. Disponvel em:
<http://www.ics.uci.edu/{~}fielding/pubs/dissertation/top.h>. Citado na pgina 25.
FOWLER, M. J. Patterns of Enterprise Application Architecture. Boston, MA, USA:

Addison-Wesley Longman Publishing Co., Inc., 2002. ISBN 0321127420. Citado 2 vezes
nas pginas 27 e 37.
FREUND, T.; STOREY, T. Transactions in the world of Web services. Research Paper,
IBM, 2002. Citado 3 vezes nas pginas 7, 46 e 47.
GIRVAN, M.; NEWMAN, M. E. J. Finding and evaluating community structure in

networks. Cond-Mat/0308217, p. 116, 2003. ISSN 1063651X. Citado 3 vezes nas pginas
43, 62 e 69.
GUO, H. et al. Wrapping client-server application to Web services for Internet computing.
Parallel and Distributed Computing, Applications and Technologies, PDCAT Proceedings,
v. 2005, p. 366370, 2005. Citado na pgina 44.
KALIM, M. Java Web Services: Up and Running, 2nd Edition. [S.l.: s.n.], 2013. 359 p.
ISBN 9781449365110. Citado 2 vezes nas pginas 25 e 64.
KHADKA, R. et al. A structured legacy to SOA migration process and its evaluation in
practice. c2013 IEEE 7th International Symposium on the Maintenance and Evolution
of Service-Oriented and Cloud-Based Systems, MESOCA 2013, p. 211, 2013. ISSN
2326-6910. Citado na pgina 35.
KHAN, M. W.; ABBASI, E. Differentiating Parameters for Selecting Simple Object Access
Protocol ( SOAP ) vs . Representational State Transfer ( REST ) Based Architecture.
Journal of Advances in Computer Networks, v. 3, n. 1, 2015. ISSN 17938244. Citado na
pgina 25.
Referncias 79
KITCHENHAM, B. A.; PICKARD, L. M. Evaluating Software Engineering Methods

and Tools Part 9: Quantitative Case Study Methodology. ACM SIGSOFT Software
Engineering Notes, v. 23, n. 1, p. 2426, 1998. ISSN 01635948. Citado na pgina 50.
KNIESEL, G.; HANNEMANN, J.; RHO, T. A comparison of logic-based infrastructures

for concern detection and extraction. Proceedings of the 3rd workshop on Linking aspect
technology and evolution, p. 6, 2007. Citado 4 vezes nas pginas 7, 54, 55 e 56.
LANGWORTHY, D. et al. Coordinating Web Services Activities with WS-

Coordination, WS-AtomicTransaction, and WS-BusinessActivity. 2004. Disponvel em:
<http://msdn.microsoft.com/en-us/library/ms996526.aspx>. Acesso em: 29/01/2017.
Citado 4 vezes nas pginas 7, 46, 47 e 48.
LEHMAN, M. M.; BELADY, L. A. Program evolution: processes of software change. [S.l.]:

Academic Press Professional, Inc., 1985. 538 p. ISBN 0-12-442440-6. Citado na pgina 17.
LEWIS, G.; MORRIS, E.; SMITH, D. Service-Oriented Migration and Reuse Technique
(SMART). Software Technology and Engineering Practice, 2005. 13th IEEE International
Workshop on, n. September, p. 222229, 2005. Citado na pgina 35.
Liang Bao et al. Extracting reusable services from legacy object-oriented systems. 2010
IEEE International Conference on Software Maintenance, p. 15, 2010. ISSN 1063-6773.
Citado 3 vezes nas pginas 14, 28 e 30.
NEWCOMER, E.; ROBINSON, I. Web Services Atomic Transaction ( WS-

AtomicTransaction ). Oasis, n. February, p. 128, 2009. Citado na pgina
46.
NEWCOMER, E.; ROBINSON, I. Web services coordination (WS-Coordination) Version

1.2. Oasis, n. February, p. 126, 2009. Citado na pgina 46.
NEWMAN, M. E. J. Fast algorithm for detecting community structure in networks.

Physics, n. 2, p. 15, 2003. Citado 2 vezes nas pginas 32 e 33.
NEWMAN, S. Building Microservices. 1st. ed. [S.l.]: OReilly Media, Inc., 2015. 280 p.
ISBN 1491950358, 9781491950357. Citado na pgina 26.
Object Management Group (OMG). Business Process Model and Notation (BPMN)
Version 2.0. Business, v. 50, n. January, p. 170, 2011. ISSN 13507540. Citado na pgina
35.
ORACLE. Metro User Guide. 2016. Disponvel em: <https://metro.java.net/guide/>.

Acesso em: 29/01/2017. Citado 4 vezes nas pginas 9, 65, 66 e 67.
RAZAVIAN, M.; LAGO, P. Towards a conceptual framework for legacy to SOA migration.
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics), v. 6275 LNCS, p. 445455, 2010. ISSN
03029743. Citado 3 vezes nas pginas 9, 19 e 21.
RAZAVIAN, M.; LAGO, P. A systematic literature review on SOA migration. Journal of

Software: Evolution and Process, v. 27, n. 5, p. 337372, 2015. ISSN 20477481. Citado na
pgina 19.
Referncias 80
REUTER, A.; GRAY, J. Transaction Processing: Concepts and Techniques. [S.l.: s.n.],
1993. Citado na pgina 45.
RICHARDS, M. Microservices vs. Service-Oriented Architecture. [s.n.], 2015. 155 p.

ISBN 9781491952429. Disponvel em: <https://www.nginx.com/microservices-soa/>.
Citado na pgina 26.
ROTEM-GAL-OZ, A. SOA Patterns. [S.l.: s.n.], 2012. 296 p. ISBN 9781933988269.

Citado na pgina 23.
SAUDATE, A. SOA Aplicado Integrando com web services e alm. [S.l.: s.n.], 2013. 293 p.
ISBN 9788566250152. Citado 2 vezes nas pginas 7 e 25.
SEACORD, R. C.; PLAKOSH, D.; LEWIS, G. A. Modernizing Legacy Systems: Software

Technologies, Engineering Processes, and Business Practices. [S.l.: s.n.], 2003. 332 p. ISSN
08953805. ISBN 0321118847. Citado na pgina 17.
SHIOKAWA, H.; FUJIWARA, Y.; ONIZUKA, M. Fast Algorithm for Modularity-Based

Graph Clustering. Proceeding of the Twenty-Seventh Conference on Artificial Intelligence,
p. 11701176, 2013. Citado 2 vezes nas pginas 33 e 34.
SNEED, H. M. Planning the Reengineering of Legacy Systems. IEEE Software, v. 12, n. 1,

p. 2434, 1995. ISSN 07407459. Citado na pgina 17.
SNELL, J. Automating business processes and transactions in Web services. Research

paper, IBM Emerging Technologies, p. 46, 2002. Citado na pgina 46.
STOJANOVI, Z. A Method for Component-Based and Service-Oriented Software Systems

Engineering. [S.l.: s.n.], 2005. ISBN 9090191003. Citado na pgina 13.
TIOBE.COM. TIOBE Index for January 2017. 2017. Disponvel em: <http:
//www.tiobe.com/tiobe-index/>. Acesso em: 28/01/2017. Citado na pgina 13.
TZERPOS, V.; HOLT, R. MoJo: a distance metric for software clusterings. Sixth Working
Conference on Reverse Engineering, p. 187193, 1999. Citado na pgina 76.
ULRICH, W. From Legacy Systems to Strategic Architectures. Software Engineering

Strategies, v. 2, n. 1, p. 1830, 1994. Citado 2 vezes nas pginas 13 e 17.
VILLAMIZAR, M. et al. Evaluating the Monolithic and the Microservice Architecture

Pattern to Deploy Web Applications in the Cloud Evaluando el Patrn de Arquitectura
Monoltica y de Micro Servicios Para Desplegar Aplicaciones en la Nube. 10th Computing
Colombian Conference, p. 583590, 2015. Citado 3 vezes nas pginas 13, 15 e 24.
VISAGGIO, G. Ageing of a Data Intensive Legacy System: Symptoms and Remedies.

Journal of Soft. Maintenance and Evolution, v. 13, p. 281308, 2001. Citado na pgina
17.
WANG, X. et al. A new approach of component identification based on weighted

connectivity strength metrics. Information Technology Journal, v. 7, n. 1, p. 5662, 2008.
ISSN 18125638. Citado 6 vezes nas pginas 14, 28, 30, 43, 73 e 74.
WOHLIN, C. et al. Experimentation in Software Engineering: An Introduction. [S.l.: s.n.],

2000. xx, 204 p. p. ISBN 0792386825. Citado na pgina 50.
Referncias 81
YOUSEF, R.; ADWAN, O.; ABUSHARIAH, M. A. M. Extracting SOA Candidate

Software Services from an Organizations Object Oriented Models. JSEA - Journal of
Software Engineering and Applications, v. 7, n. August, p. 770778, 2014. ISSN 1945-3116,
1945-3124. Citado 3 vezes nas pginas 14, 28 e 30.

Uma Abordagem Gradativa de Modernização de Software Monolítico e em Camadas para Serviços

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Abordagem Gradativa de Modernização de Software Monolítico e em Camadas para Serviços

Enviado por

Direitos autorais:

Formatos disponíveis

Alessandro Borges Rodrigues

Uma Abordagem Gradativa de Modernizao de

Uma Abordagem Gradativa de Modernizao de

Este trabalho foi apresentado Ps-

Universidade Federal de Pernambuco - UFPE

Orientador: Vinicius Cardoso Garcia

Palavras-chave: Reengenharia de Software, Migrao, SOA, Refatorao, Modernizao,

Keywords: Software Reengineering, Migration, SOA, Refactoring, Modernizing, Software

Figura 2.1 Ciclo de Vida do Software (Traduo minha)(CHIKOFSKY; CROSS,

IDE: Integrated Development Enviroment

JSON: JavaScript Object Notation

OO: Orientao a Objetos

REST: Representational State Transfer

SOA: Service-Oriented Architecture

SOAP: Simple Object Access Protocol

WSDL: Web Services Description Language

XML: eXtensible Markup Language

4 MODERNIZAO DE SISTEMAS MONOLTICOS PARA ARQUI-

5 ESTUDO DE CASO E AVALIAO DA ABORDAGEM . . . . . . . 50

6 CONSIDERAES FINAIS E TRABALHOS FUTUROS . . . . . . 73

Existem na literatura vrias tcnicas de Reengenharia para auxiliar na modernizao

futuras manutenes e testes (VILLAMIZAR et al., 2015).

1.3 Organizao da Dissertao

correlatos, as principais contribuies e os trabalhos futuros.

Melhorar manutenibilidade: pode-se, por exemplo, reduzir a manuteno com

Migrao/Modernizao: a Reengenharia pode ser utilizada para realizar a mi-

Obter maior confiabilidade: os testes extensivos necessrios para garantir a

Preparao para melhorias funcionais: decompor um sistema em mdulos

Engenharia avante: o processo tradicional de desenvolvimento, indo de abstra-

Engenharia reversa: o processo de anlise de um sistema para identificar seus

Redocumentao: a criao ou reviso de representao semanticamente

Reestruturao: a transformao de uma representao para outra no mesmo

Reengenharia: a anlise e alterao de um sistema para reconstitu-lo e implement-

diferenas no nvel de abstrao. Os Requisitos especificam o problema a ser resolvido,

Figura 2.1 Ciclo de Vida do Software (Traduo minha)(CHIKOFSKY; CROSS, 1990)

2.2 Abordagens de Reengenharia de Sofware para SOA

processos: Engenharia Reversa, Transformao (Reestruturao) e Engenharia Avante. As

Famlia da transformao de cdigo (code transformation family): se li-

Famlia da identificao de servio (service identification family): no

Famlia da transformao do modelo de negcio (business model trans-

Famlia de transformao de elementos de projeto (design element trans-

Famlia da Engenharia Avante (forward engineering family): abrange com-

Famlia da transformao de projetos e elementos compostos (design and

Famlia da transformao de composio baseada em padres (pattern-

Famlia da Engenharia Avante com anlise de lacunas (forward enginee-

2.3 Consideraes finais

2.4 Resumo do Captulo

Este captulo aborda os conceitos sobre arquitetura de software e detalha as

3.1 Conceitos Bsicos

Estruturas estticas: unidades de implementao (mdulos) que se concentram

Estruturas dinmicas: se concentram na forma como os elementos interagem

Estruturas de alocao: descreve o mapeamento das estruturas de software com

Rotem-Gal-Oz (2012) apresenta uma outra definio descrevendo a arquitetura

3.2 Arquitetura monoltica

Simplicidade no desenvolvimento, j que muitas das atuais ferramentas e IDEs foram

Simplicidade de publicao, pois existe apenas um arquivo, ou estrutura de diretrios,

Porm, apesar da simplicidade que a utilizao desta arquitetura traz, tambm

Quanto maior o tamanho da aplicao monoltica mais difcil mant-la e evolu-la,

Dificuldade de evoluir as tecnologias utilizadas, devido a necessidade de utilizao

Com base nas vantagens e desvantagens dessa arquitetura, o engenheiro de software

Figura 3.1 Exemplo de um documento SOAP (SAUDATE, 2013)

Segundo Saudate (2013) o elemento Envelope um container para os elmentos

3.4 Arquitetura em Camadas