YanDeLimaJustino DISSERT

Universidade Federal do Rio Grande do Norte
Instituto Metrópole Digital

Programa de Pós-graduação em Engenharia de Software
Mestrado Profissional em Engenharia de Software
Do monolito aos microsserviços:

um relato de migração de sistemas legados
da Secretaria de Estado da Tributação do
Rio Grande do Norte
Yan de Lima Justino
Natal-RN
Agosto/2018
Yan de Lima Justino

um relato de migração de sistemas legados da Secretaria
de Estado da Tributação do Rio Grande do Norte
Dissertação de Mestrado apresentada ao Pro-

grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Engenharia
de Software.
Universidade Federal do Rio Grande do Norte – UFRN

Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Prof. Dr. Carlos Eduardo da Silva
Brasil
2018
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Justino, Yan de Lima.

Do monolito aos microsserviços: um relato de migração de
sistemas legados da Secretaria de Estado da Tributação do Rio
Grande do Norte / Yan de Lima Justino. - 2018.
87 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande

do Norte, Instituto Metrópole Digital - IMD, Programa de Pós-
Graduação em Engenharia de Software. Natal, RN, 2018.
Orientador: Prof. Dr. Carlos Eduardo da Silva.
1. Reengenharia de software - Dissertação. 2. Arquitetura

Orientada a Serviço - SOA - Dissertação. 3. Software
Reengineering - Dissertação. 4. DevOps - Dissertação. I. Silva,
Carlos Eduardo da. II. Título.
RN/UF/BCZM CDU 004.415.2.043
Elaborado por Kalline Bezerra da Silva - CRB-15/327

Yan de Lima Justino

um relato de migração de sistemas legados da Secretaria
de Estado da Tributação do Rio Grande do Norte
Dissertação de Mestrado apresentada ao Pro-

grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Engenharia
de Software.
Trabalho aprovado. Brasil, 06 de agosto de 2018:
Prof. Dr. Carlos Eduardo da Silva

Orientador
Prof. Dr. Eiji Adachi M. Barbosa

Examinador interno
Prof. Dr. Nabor Mendonça

Examinador externo
Brasil
2018
Este trabalho é dedicado a minha amada esposa Andréia M. Sakakima e a meu amado
filho Pedro Sakakima Justino,
pelo apoio incondicional e compreensão diante do irreparável vazio causado pela ausência.
AGRADECIMENTOS
Agradeço primeiramente o apoio da a diretoria da IVIA Soluções e Tecnologia nas

pessoas de Márcio Braga, Alexandre Menezes e Edgy Paiva; e a gerência local nas pessoas
de Diego Soares dos Santos, Gilberto Coelho de Azevedo Neto e Carolina Cavalcante. A
concretização desse projeto não seria possível sem a sua ajuda.
À Secretaria de Estado da Tributação do Rio Grande do Norte (SET) nas pessoas do
Secretário André Horta Melo; do Secretário Adjunto Fernando José Oliveira de Amorim; e
da Coordenadora de Informática Adriana Assunção Silva, pela confiança cedida e liberdade
de atuação.
Ao meu orientador, Prof. Dr. Carlos Eduardo da Silva, pela paciência, coragem e
horas dedicadas com muito afinco para “lapidar” essa pesquisa. Foi uma jornada enrique-
cedora.
Por fim, agradecimentos especiais são direcionados a todos os analistas da área
de desenvolvimento da IVIA lotados na SET, que com profissionalismo e compromisso
responderam com extraordinária dedicação aos desafios desse projeto.
Muito obrigado a todos!

“Quanto mais sabemos que não somos ninguém, mais nos tornamos alguém”
(Pierre Lévy)
RESUMO
A Orientação a Serviço fornece um paradigma de projeto baseado em um conjunto de
metas estratégicas para o alinhamento entre tecnologia da informação (TI) e negócios,
promovendo eficiência, agilidade e produtividade. Nesse contexto, a reengenharia de
sistemas legados para uma arquitetura orientada a serviços (SOA) pode ser justificada para
resolver problemas como a demanda por interoperabilidade e a necessidade de fornecer uma
interface robusta de serviço de alta disponibilidade. No entanto, a implantação de SOA em
um ambiente corporativo é uma tarefa desafiadora, pois pode envolver o uso de diferentes
técnicas, como a modernização de sistemas com alto endividamento técnico e altos custos
de manutenção. Para isso, é necessário um processo que forneça um conjunto apropriado de
técnicas que minimizem os riscos e, ao mesmo tempo, garantam a qualidade dos sistemas
durante o processo de migração. Neste sentido, este trabalho apresenta a aplicação de
um processo de reengenharia de sistemas legados para suportar a implementação de um
projeto SOA. O SPReaD (Service-oriented process for Reengineering and Devops) é uma
instanciação da Mainstream SOA Methodology, com foco na reengenharia de sistemas
legados, integrando os aspectos de DevOps para o direcionamento de SOA. Esse processo
foi criado durante um projeto real de reengenharia de software para evolução de sistemas
legados de uma Secretaria de Estado de Tributação. O uso do SPReaD tem apresentado
resultados significativos em relação à conquista de importantes metas de qualidade como a
padronização de contratos de serviços para efeitos de interoperabilidade; a gestão da dívida
técnica, tendo em vista uma melhor manutenibilidade e portabilidade de componentes;
uma maior escalabilidade e melhora no desempenho como um todo para suportar uma
grande carga de requisições.
Palavras-chave: SOA. Reengenharia de Software. DevOps. Reuso de Software. Evolução

e Manutenção de Software. Arquitetura de Software
ABSTRACT
Service-orientation provides a design paradigm based on a set of strategic goals towards
the alignment between information technology and business, promoting efficiency, agility
and productivity. In this context, the reengineering of legacy systems to a service-oriented
architecture (SOA) can be justified to solve problems such as the demand for interoperability
and the need to provide a robust high-availability service interface. However, the deployment
of SOA into an enterprise environment is challenging task, as it may involve the use of
different techniques, such as the modernization of systems with high technical debt and
high maintenance costs. To this end, a process is required that provides an appropriate set
of techniques that minimize risks and at the same time ensure the quality of the systems
during the migration process. In this sense, this work presents the application of a process
for the reengineering legacy systems to support the implementation of an SOA project.
This process has been identified during a real software reengineering project for evolution
of legacy systems of a Secretariat of State for Taxation. The SPReaD (SOA Process for
Reengineering and DevOps) is an instantiation of the mainstream SOA methodology
focusing on the reengineering of legacy systems integrating DevOps aspects for targeting
SOA. The use of SPReaD have presented significant results regarding the achievement of
important quality goals. The use of SPReaD has presented significant results in relation
to achieving important quality goals such as the standardization of service contracts
for interoperability purposes; technical debt management, for better maintainability and
portability of components; scalability and performance improvement to support a large
load of requests.
Keywords: SOA. Software Reengineering. DevOps. Software Reuse. Software Evolution

and Maintenance. Software Architecture
LISTA DE ILUSTRAÇÕES
Figura 1 –Diagrama da metodologia de pesquisa aplicada (fonte-própria) . . . . . 18

Figura 2 –Diagrama dos níveis de implementação de SOA (ERL et al., 2014). . . 21
Figura 3 –Fases da metodologia MSOAM (ERL; MERSON; STOFFERS, 2017). . 22
Figura 4 –Modelo geral para Reengenharia de Software (WAGNER, 2014). . . . . 25
Figura 5 –A relação entre integração, entrega e implantação contínuas (SHAHIN;
BABAR; ZHU, 2017). . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 6 – Arquitetura monolítica (fonte-própria) . . . . . . . . . . . . . . . . . . 29
Figura 7 – Estrutura monolítica do sistema UVT (fonte-própria) . . . . . . . . . . 30
Figura 8 – Relação das camadas de tecnologias do processo SPReaD (fonte-própria). 35
Figura 9 – Estratégia e Táticas do SPReaD (fonte-própria). . . . . . . . . . . . . . 36
Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman
e Maxin (fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 11 – Estrutura completa do processo SPReaD (fonte-própria). . . . . . . . . 38
Figura 12 – Fase de Comunicação do SPReaD (fonte-própria). . . . . . . . . . . . . 40
Figura 13 – Fase de Planejamento do SPReaD (fonte-própria). . . . . . . . . . . . . 42
Figura 14 – Fase de Análise do SPReaD (fonte-própria). . . . . . . . . . . . . . . . 44
Figura 15 – Fase de Design do SPReaD (fonte-própria). . . . . . . . . . . . . . . . 45
Figura 16 – Aplicação da Análise de Inventário de Serviço (fonte-própria). . . . . . 46
Figura 17 – Aplicação da Análise Orientada a Serviço (fonte-própria). . . . . . . . . 47
Figura 18 – Práticas da Análise Orientada a Serviço (fonte-própria). . . . . . . . . 48
Figura 19 – Fase de Construção do SPReaD (fonte-própria). . . . . . . . . . . . . . 50
Figura 20 – Fluxo de Migração de Software (fonte-própria). . . . . . . . . . . . . . 52
Figura 21 – Fase Etapa de Entrega do SPReaD (fonte-própria). . . . . . . . . . . . 53
Figura 22 – Fase de Suporte e Feedback do SPReaD (fonte-própria). . . . . . . . . 54
Figura 23 – Instâncias de microsserviços na estrutura de alocação da SET (fonte-
própria). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 24 – Definição do Inventário de Serviços de Arrecadação (fonte-própria). . . 58
Figura 25 – Comunicação entre Inventários de Serviços da SET e contextos externos
(fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 26 – Engenharia reversa dos serviço legado de Débitos no escopo de Análise
Orientada a Serviço (fonte-própria). . . . . . . . . . . . . . . . . . . . . 60
Figura 27 – Design dos microsserviços de Recolhimento e Repasse do Inventário de
Arrecadação (fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 28 – Inventário de serviços da SET (fonte-própria). . . . . . . . . . . . . . . 62
Figura 29 – Template de Solução Visual Studio do Inventário de Arrecadação -
Aplicação Padrão de Utilitários Transversais aos Domínios (fonte-própria). 64
Aplicação do Padrão de Normalização de Serviços (fonte-própria). . . . 64
Aplicação do Padrão de Segregação de Micro Tarefas (fonte-própria). . 65
Aplicação do Padrão de Camadas de Serviço (fonte-própria). . . . . . . 66
Aplicação do Padrão de Encapsulamento de Legado (fonte-própria). . . 66
Figura 34 – Estrutura de alocação de serviços SET - publicação de microsserviços
de Arrecadação e Prefeituras (fonte-própria). . . . . . . . . . . . . . . . 68
Figura 35 – Detalhamento do processo de build no TFS (fonte-própria). . . . . . . 69
Figura 36 – Dashboard de monitoramento ativo de serviços da SET (fonte-própria). 70
LISTA DE TABELAS
Tabela 1 – Métricas da dívida técnica do sistema UVT agrupadas pela categorias. 32

Tabela 2 – Métricas da dívida técnica da categoria “Architecture”. . . . . . . . . . 32
Tabela 3 – Dívida técnica do sistema UVT antes e depois da migração. . . . . . . 72
Tabela 4 – Métricas de LoC no código legado Vs código dos Inventários. . . . . . . 73
Tabela 5 – Resultados da eficiência de desempenho dos serviços). . . . . . . . . . . 74
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Problemática e Motivação . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . 19
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Orientação a serviço, SOA e MSOAM . . . . . . . . . . . . . . . . . 20
2.2 Reengenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Microsserviços e DevOps . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 MIGRAÇÃO DO SISTEMA UVT . . . . . . . . . . . . . . . . . . . 28

3.1 Arquitetura do Sistema UVT . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Processo adhoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 PROCESSO SPREAD . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Extração do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 APLICAÇÃO DO SPREAD NO SISTEMA UVT . . . . . . . . . . . 57

5.1 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Consideração Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1 Resultados da Reengenharia de Software aplicada ao Sistema UVT 71
6.2 Resultados da adoção de SOA . . . . . . . . . . . . . . . . . . . . . . 74
7 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 77
7.1 Migração de Sistemas Legados . . . . . . . . . . . . . . . . . . . . . . 77
7.2 Aplicação de SOA em contextos de Governo eletrônico (e-gov) . . . 78
7.3 Uso de MSOAM como metodologia para projetos SOA . . . . . . . 80
7.4 O uso de microsserviços . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.1 Contribuições e Resultados Alcançados . . . . . . . . . . . . . . . . . 82
8.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
14
1 INTRODUÇÃO
A evolução de software é a capacidade de alterar, de forma rápida e confiável, um

sistema de software para adaptá-lo às mudanças do ambiente, aos novos usuários e às
necessidades do mercado, bem como manter seu desempenho operacional em um nível
satisfatório (BENNETT; RAJLICH, 2000). Quando um software não é mais viável, é
considerado envelhecido, em decaimento ou legado (BENNETT; RAJLICH, 2000; PARNAS,
1994). Nesse estágio, as equipes de desenvolvimento tendem a evitar modificações no núcleo
do sistema, realizando apenas adaptações através de técnicas como wrappers de entradas
e saídas. Consequentemente, os sistemas tornam-se cada vez mais desatualizados e não
atendem mais às necessidades dos usuários.
Muitas vezes, esses sistemas legados são vitais para os objetivos estratégicos das
organizações e não podem ser simplesmente encerrados e descartados (BENNETT, 1995),
o que leva essas organizações a decidir como lidar com esses sistemas. Diante disso, elas
podem investir na tentativa de reverter o processo de decaimento do software, ansiando por
restaurar sua capacidade de desenvolvimento, ou podem optar por reestruturar os recursos
do sistema legado em um novo sistema de software, geralmente em tecnologias mais
atualizadas, através de um processo de reengenharia. Neste trabalho, nos concentramos
nesse último processo.
Um dos principais desafios da Reengenharia de Software é garantir a equivalência
funcional na nova versão (GRUBB; TAKANG, 2003), ou seja, a nova versão do sistema deve
fornecer as mesmas funcionalidades existentes do sistema legado, além de poder atender de
maneira rápida e confiável novas solicitações. Além disso, o processo de reengenharia deve
estar alinhado com os objetivos estratégicos da organização, ajudando a criar processos de
negócios revisados e que melhor atendam a esses objetivos.
Em muitos casos, a migração de sistemas legados para SOA (Service-oriented
Architecture) tem sido uma estratégia de reengenharia adotada para se alcançar um
conjunto de metas e benefícios que prometem reduzir o custo do portfólio de aplicativos e
maximizar o retorno sobre o investimento (ROI) (ERL; MERSON; STOFFERS, 2017). O
seja, embora a aplicação de SOA esteja associada a um esforço inicial, visando benefícios
futuros, uma vez que o esforço tenha sido alcançado, os benefícios são maiores que o
custo (LEON, 2017).
Nesse sentido, a Secretaria de Estado da Tributação do Rio Grande do Norte (SET)
diante da necessidade de migração do sistemas UVT (Unidade Virtual de Tributação)
- a principal interface de comunicação entre o contribuinte e a SET - optou por uma
arquitetura de serviços moderna e robusta que suprisse as necessidades de escala, capacidade
Capítulo 1. Introdução 15
de aceleração e garantias de qualidade. Porém as estratégias tradicionais para se obter

SOA são tidas como opções pesadas e complexas para criação de soluções orientadas a
serviço (LEON, 2017; JAMSHIDI et al., 2018). Isso levou a SET a cogitar a adoção de
uma arquitetura alinhada com design, padrões e práticas emergentes que abraçasse novas
tecnologias e favorecessem uma entrega ágil de software.
Vistos como a mais recente alternativa para o design, desenvolvimento e entrega de
serviços de software, os microsserviços são uma abordagem de software e de arquitetura
de sistemas que se baseia em conceitos bem estabelecidos de modularização e limites
técnicos (JAMSHIDI et al., 2018). Além disso, compartilham dos mesmos princípios de
design de SOA (RICHARDS, 2015) e sua adoção pode trazer benefício como desenvolvi-
mento e tempo de comercialização mais rápidos, reação rápida à mudanças, dinamismo,
redução de custos econômicos e aplicações mais robustas (LEON, 2017). Nesse contexto,
metodologias como desenvolvimento ágil e práticas contínuas como DevOps (integração,
entrega, implantação e monitoramento contínuos), pavimentam o caminho para uma
evolução convergente de SOA chamada de microsserviços (LEON, 2017; NEWMAN, 2015;
BASS; WEBER; ZHU, 2015).
Convergente, porque a indústria não possui uma definição uniforme sobre que se
afaste completamente daquelas estabelecidas por SOA. Ou seja, uma arquitetura de micros-
serviços ainda exige uma definição e padronização mais aprofundada e compatível com sua
natureza dinâmica (LEON, 2017). Na verdade, contando com serviços independentes com
limites claros, os microsserviços são semelhantes aos da SOA mais tradicional (JAMSHIDI
et al., 2018) e, segundo Zimmermann (ZIMMERMANN, 2017), “não constituem um novo
estilo arquitetural diferente de SOA, mas qualificam-se como SOA implementado e serviços
realizados de uma maneira particular com as práticas de engenharia de software de última
geração”.
Dado esse contexto, Este autor, na condição de Arquiteto de Software da IVIA
Soluções e Tecnologia, empresa contratada para suprir as demandas de desenvolvimento
de software da SET, foi escolhido como arquiteto responsável pelo projeto de migração
do sistema UVT. Contudo essa migração apresentou um grande desafio de projeto: a
ausência de um processo de Reengenharia de Software que conduzisse a migração de
um sistema monolítico com alto endividamento técnico para Arquitetura Orientada a
Serviço, baseando-se em abordagem modernas como microsserviços. Diante desse desavio,
foi proposto a condução de uma pesquisa no âmbito da indústria para definir um processo
de migração de sistemas legados para o paradigma orientado a serviços. Essa pesquisa foi
conduzida entre os anos de 2016 e 2018 no âmbito da SET concomitante ao projeto de
migração do sistema UVT.
1.1 Problemática e Motivação

Com o passar dos anos e a ausência de boas práticas de Engenharia de Software,
o sistema UVT começou a apresentar decaimento na qualidade de suas operações, bem
como adquiriu um alto grau de endividamento técnico e, consequentemente, um alto custo
de manutenção e evolução. Além disso, o desejo da SET por modernização da interface
gráfica e pela disponibilização de serviços tributários em aplicativos móveis, demandaram
uma maior interoperabilidade, o que levaria a uma reengenharia de sua arquitetura para
prover serviços de software.
Essa a ausência de um processo de migração de um sistema legado com alto
endividamento técnico, baseando-se em uma abordagem de microsserviços tem se mostrado
um grande desafio de projeto. Diante do alto nível de abstração e complexidades envolvidas
em um processo de Reengenharia de software, a adoção de metodologias já consolidadas
pode ser uma resposta no que diz respeito a organizar os esforços relacionados à condução
desse projeto.
A despeito disso, a MSOAM (Mainstream SOA Methodology) é um modelo de
referência estabelecido por Thomas Erl como parte de uma metodologia abrangente
caracterizada pela aplicação de fases sequenciais para a implantação de projetos SOA (ERL,
2005). No entanto, é reconhecido que a implantação de SOA é única em cada organização
e pode considerar o uso de diferentes abordagens (ERL; MERSON; STOFFERS, 2017),
dependendo da natureza e escopo do projeto. Sendo assim, o uso de metodologias como o
MSOAM por si só não é suficiente para lidar com o nível de abstração e complexidades
envolvidas na reengenharia de um sistema legado.
Ou seja, é preciso instâncias mais concretas que possibilitem a metodologia MSOAM
lidar com abordagens modernas como microsserviços e práticas contínuas como as de
DevOps. Essas necessidades motivaram a condução de uma pesquisa no âmbito da indústria
que colaborasse com a adoção de SOA a partir da Reengenharia de Software utilizando
microsserviços como tática para construção de soluções orientadas a serviço e DevOps
para se obter sistemas com melhor garantia de qualidade e monitoramento no processo de
integração, entrega e implantação contínua(SHAHIN; BABAR; ZHU, 2017). Neste sentido,
o desafio considerado por este trabalho é a necessidade de um processo de desenvolvimento
que suporte a reengenharia de sistemas legados e práticas contínuas relacionadas ao DevOps
tendo como alvo o paradigma SOA.
1.2 Objetivos
O objetivo geral deste trabalho é definir um processo de Reengenharia de Software
aplicado a sistemas legados para apoiar a implantação de projetos SOA. Esse processo foi
aplicado no contexto de migração do sistema UVT da SET/RN. Para alcançar o objetivo

geral desta pesquisa emergem os seguintes objetivos específicos:
1. Extrair, formalizar e conduzir um processo de Reengenharia de Software que lide

com sistemas legados afim de construir soluções orientadas a serviços e implantá-las
através de práticas contínuas de DevOps.
2. Aplicar a implantação de um projeto SOA no contexto de migração do sistema UVT.
3. Avaliar os impactos da reengenharia do sistema UVT e implantação de SOA na

SET/RN.
Com base nisso, a principal contribuição deste trabalho é a definição de um

processo de Reengenharia de Software orientado a serviços: O Service-oriented Process for
Reengineering and DevOps (SPReaD). O SPReaD é uma instanciação de um processo de
Reengenharia de Software com foco no desenvolvimento de soluções orientadas a serviços,
que foi identificado nos últimos dois anos durante a migração do sistema UVT (Unidade
Virtual de Tributação) da SET/RN. A aplicação desse processo apresentou resultados
significativos em relação à conquista de importantes metas do projeto, bem como metas
de qualidade de software como manutenibilidade, escalabilidade e desempenho.
1.3 Metodologia
Dada a complexidade e abrangência que envolve um processo de Reengenharia de
Software, bem como a necessidade de realizar a pesquisa no ambiente de sua aplicação, a
metodologia adotada para a condução desta pesquisa foi a Pesquisa-ação. Essa escolha
se deu pela necessidade de definição de um processo de reengenharia de sistemas legados,
com alto endividamento técnico, para uma arquitetura orientada a serviços baseada em
microsserviços, dentro de um processo interativo de investigação.
Como ilustrado na Figura 1, a pesquisa foi iniciada com a Escolha do referencial
teórico. Nessa fase foram aplicadas a coleta e a leitura de textos da base teórica dos
estudos relacionados a SOA, Reengenharia de Software e DevOps, detalhados no capítulo
2 . Já a Aplicação do caso foi marcada inicialmente pela execução de um processo ad
hoc, cuja finalidade foi a identificação de um processo mais organizado. O resultado disso
foi a extração de um processo denominado SPReaD, que foi refinado e documentado
durante as iterações.
Os artefatos gerados durante as iterações do processo SPReaD, foram coletados
e organizados em duas categorias: artefatos de concepção e criação, e artefatos de mo-
nitoramento. Essa divisão serviu para direcionar a fase de Avaliação na identificação
de resultados qualitativos, bem como quantitativos. Por fim, a fase de Divulgação foi
Figura 1 – Diagrama da metodologia de pesquisa aplicada (fonte-própria)
dedicada ao compartilhamento dos resultados (prévios) da pesquisa em workshops internos

da organização, eventos da indústria e eventos acadêmicos.
No tocante aos eventos da indústria, o tema foi submetido e aceito como palestra
nos dois principais eventos de desenvolvimento de software que ocorrem no país: a QCon
São Paulo, conferência internacional de desenvolvimento de software realizada pela InfoQ
1
, realizada em maio de 2016; e na TDC 2017 2 (The developer’s conference), conferência
nacional de desenvolvimento de software, realizada em Julho de 2017, também em São
Paulo.
Já em Julho de 2018 o tema foi submetido e aprovado na TDC 2018, na trilha
arquitetura dotnet, sob o título Reengenharia de sistemas legados para arquitetura de
serviços: Metodologia, Processos e técnicas aplicadas ao .Net Framework. O tema foi bem
aceito pelo publico-alvo da trilha e proporcionou uma série de discussões, motivadas pela
grande parcela de participantes que atualmente estão passando por algum processo de
migração de legado.
No âmbito acadêmico, o tema foi submetido ao EPOCA 2017 (Escola Potiguar de
Computação e suas Aplicações), evento regional realizado pela UFRN, no qual este trabalho
foi premiado na categoria Artigos longos; este estudo também foi submetido na trilha
SEIP (Software Engineering in Practice) da 40a edição do ICSE (International Conference
On Software Engineering) 3 , realizado em 2018 Gotemburgo/Suécia. O trabalho foi aceito
como poster, e publicado como resumo expandido nos anais do ICSE4 . A Divulgação se
1
https://www.infoq.com/
2
http://www.thedevelopersconference.com.br/
3
https://www.icse2018.org/
4
https://dl.acm.org/citation.cfm?id=3195067
mostrou uma atividade fundamental na iteração da metodologia, uma vez que os feedbacks
obtidos eram retro-alimentados na Aplicação do caso, colaborando inicialmente no
refinamento do processo e posteriormente na sua formalização.
1.4 Organização do Documento

Este trabalho está organizado da seguinte maneira. O capítulo 2 apresenta um
conjunto de discussões difundidas no âmbito acadêmico e na industria sobre SOA, Re-
engenharia de Software e DevOps, que serviram como referencial teórico para nortear o
desenvolvimento da pesquisa. Em seguida, no Capítulo 3 contextualiza o sistema legado
que foi modernizado por meio da aplicação do SPReaD. Nosso processo orientado a serviços
para reengenharia e DevOps é apresentado no Capítulo 4 e detalhado, no contexto de
migração do sistema UVT no Capítulo 5. Uma avaliação deste caso é apresentada no
Capítulo 6, enquanto o Capítulo 7 apresenta uma discussão sobre o trabalho relacionado a
fim de motivar nossa abordagem. O Capítulo 8 conclui o trabalho.
20
2 REFERENCIAL TEÓRICO
Este capítulo apresenta um conjunto de discussões difundidas no âmbito acadêmico

e na industria sobre Orientação a serviço, SOA, MSOAM, Reengenharia de Software,
microsserviços e DevOps, que serviram como referencial teórico para nortear o desenvolvi-
mento da pesquisa.
2.1 Orientação a serviço, SOA e MSOAM

Um Serviço é um software publicado via API, que faz parte de um contrato e que
pode fornecer uma coleção de recursos (ERL; MERSON; STOFFERS, 2017). Esses recursos
são agrupados em unidades lógica que representam um contexto funcional. A Orientação
a Serviço atua como paradigma de design que compreende essas unidades lógicas como
representações de recursos corporativos que podem ser modelados como serviços que
apoiam a realização dos objetivos estratégicos da Computação Orientada a Serviço
que são: o aumento da interoperabilidade intrínseca, o aumento da governança, maior
diversificação de fornecedores, maior alinhamento entre negócios e tecnologia, aumento
do Retorno do investimento (ROI), maior agilidade organizacional e redução do custo TI.
Segundo Erl (ERL, 2008), a Orientação a serviço pode ser compreendida pela aplicação
de oito princípios de design:
Padronização de Contrato: “serviços dentro do mesmo escopo de negócio estão em

conformidade com os padrões de design de contrato” (ERL, 2008, p. 130);
Baixo acoplamento: “Os contratos de prestação de serviços impõem baixos requisitos

de acoplamento ao consumidor e são eles próprios dissociados do seu ambiente circun-
dante” (ERL, 2008, p. 168);
Abstração: “os contratos de serviço contenham apenas informações essenciais publicadas

nos contratos de serviços” (ERL, 2008, p. 214);
Reusabilidade: “os serviços que contêm e expressam uma lógica agnóstica, possam ser
posicionados como recursos empresariais reutilizáveis” (ERL, 2008, p. 258);
Autonomia: “os serviços exercem um alto nível de controle sobre seu ambiente e do tempo
Capítulo 2. Referencial Teórico 21
de execução subjacente” (ERL, 2008, p. 296);
Baixa Manutenção de Estado: “os serviços minimizam o consumo de recursos ao

adiar o gerenciamento das informações do estado quando necessário” (ERL, 2008, p. 332);
Descoberta:, “os serviços são complementados com metadados comunicativos pelos quais
eles podem ser efetivamente descobertos e interpretados” (ERL, 2008, p. 368);
Composição: “os serviços são participantes de composição eficazes, independentemente

do tamanho e complexidade da composição” (ERL, 2008, p. 392);
Para entregar serviços baseados nos princípios da Orientação a Serviço, é preciso uma
arquitetura tecnológica com características distintas, capaz de acomodar comportamentos
e requisitos que possibilitem alcançar as metas da Computação Orientada a Serviço (ERL
et al., 2014). Para Erl (ERL et al., 2014, p. 13), esta arquitetura “é a Service-oriented
architecture”(SOA), que segundo o autor, “pode existir em quatro escopos ou níveis
diferentes de implementação, sendo que alguns níveis abrangem os outros” (ERL et al.,
2014, p. 15), como ilustra a Figura 2.
Figura 2 – Diagrama dos níveis de implementação de SOA (ERL et al., 2014).

Segundo Erl (ERL et al., 2014), esses escopos ou níveis de implementação são
classificados como: Arquitetura de Serviço, que representa a arquitetura de um único
serviço; Arquitetura de Composição de Serviço, que é a arquitetura de um conjunto de
serviços relacionados através de em uma composição; Arquitetura de Inventário de Serviço,
que apoia uma coleção de serviços co-relatos e que são padronizados e gerenciados de forma
independente;e Arquitetura de Empresa Orientada a Serviço que representa a arquitetura
da empresa em si, em qualquer extensão que seja orientada a serviços.
Esta arquitetura requer a compreensão de como projetos SOA bem-sucedidos de-
vem ser conduzidos (ERL; MERSON; STOFFERS, 2017, p. 91). Nessa linha, A MSOAM
(Mainstream SOA Methodology) é um modelo de referência idealizado para proporcionar a
realização de projetos SOA. Como ilustra a Figura 3, essa metodologia é composta por
um conjunto comum de etapas que fazem a transição da concepção de serviços para a
implementação e para a evolução, através de um ciclo de vida pré-definido (ERL; MERSON;
STOFFERS, 2017). As etapas do projeto desse ciclo de vida são as seguintes:
Figura 3 – Fases da metodologia MSOAM (ERL; MERSON; STOFFERS, 2017).
Plando de Adoção de SOA: “Durante esse estágio inicial, as decisões de planejamento

fundacional são tomadas. Essas decisões moldarão todo o projeto, e é por isso que esse é
considerado um estágio crítico que pode exigir financiamento e tempo alocados separada-
mente para realizar estudos significativos necessários para avaliar e determinar uma série
de fatores” (ERL; MERSON; STOFFERS, 2017, p. 95).
Análise de Inventário de Serviço: “Este estágio é dedicado a definir conceitualmente o

inventário de serviços para que os serviços candidatos individuais possam ser identificados
e atribuídos a contextos funcionais apropriados em relação uns aos outros. Isso garante
que os serviços (dentro do limite do inventário de serviços) sejam normalizados, pois não
se sobrepõem.” (ERL; MERSON; STOFFERS, 2017, p. 96).
Análise Orientada a Serviço: “É geralmente realizada iterativamente, uma vez para

cada processo de negócios. Normalmente, a entrega de um inventário de serviços determina
um escopo que representa um domínio significativo da empresa ou da empresa como um
todo. Todas as iterações de uma Análise Orientada a Serviços pertencem a esse escopo, com
cada iteração contribuindo para o blueprint de inventário de serviço.” (ERL; MERSON;
STOFFERS, 2017, p. 99).
Design Orientado a Serviço: “Estágio dedicado a produção de contratos de serviços em

apoio a abordagem Contract-first para o desenvolvimento de software” (ERL; MERSON;
STOFFERS, 2017, p. 101).
Design de Lógica de Serviço: “Estágio no qual o contrato de serviço é finalizado antes

da arquitetura de serviço subjacente e da lógica que será responsável por executar a
funcionalidade expressa no contrato de serviço” (ERL; MERSON; STOFFERS, 2017, p.
103).
Desenvolvimento de Serviço: “Depois de todas as especificações de design terem sido

concluídas, a programação real do serviço pode começar. Como a arquitetura de serviço já
terá sido bem definida como resultado dos estágios anteriores e do envolvimento de padrões
de design personalizados, os desenvolvedores de serviço geralmente terão uma direção
clara sobre como construir as várias partes da arquitetura de serviço” (ERL; MERSON;
STOFFERS, 2017, p. 103).
Teste de Serviço: “Os serviços precisam passar pelos mesmos tipos de ciclos de teste
e garantia de qualidade que os aplicativos tradicionais personalizados. No entanto, além
disso, há novos requisitos que introduzem a necessidade de métodos e esforços de teste
adicionais” (ERL; MERSON; STOFFERS, 2017, p. 103).
Implantação e Manutenção de Serviço: “A implantação de serviço representa a im-

plementação real de um serviço no ambiente de produção. Manutenção de serviço refere-se
a atualizações ou alterações que precisam ser feitas no ambiente de implementação, como
parte da implementação inicial ou subsequentemente” (ERL; MERSON; STOFFERS,
2017, p. 105).
Uso e Monitoramento de Serviço: “O monitoramento contínuo do serviço ativo gera

métricas necessárias para medir o uso do serviço para manutenção evolutiva (como es-
calabilidade, confiabilidade, etc.), bem como para fins de avaliação de negócios (como
no cálculo do custo de propriedade e do ROI)” (ERL; MERSON; STOFFERS, 2017, p. 105).
Descoberta de Serviço: “Para garantir a reutilização consistente de serviços agnósticos

e recursos de serviço, as equipes de projeto executam um processo de Descoberta de Serviço
separado e explicitamente definido” (ERL; MERSON; STOFFERS, 2017, p. 106).
Versionamento e Retirada de Serviço: “Depois que um serviço tiver sido implemen-

tado e usado em ambientes de produção, pode surgir a necessidade de fazer alterações
na lógica de serviço existente ou aumentar o escopo funcional do serviço. Em casos como
esse, uma nova versão da lógica de serviço e / ou do contrato de serviço provavelmente
precisará ser introduzida” (ERL; MERSON; STOFFERS, 2017, p. 106).
De acordo com Erl (ERL; MERSON; STOFFERS, 2017), esta metodologia ofe-
rece um conjunto de processos genéricos e práticas que quase sempre requerem maior
customização quando incorporadas a ambientes corporativos.
2.2 Reengenharia de Software

Dependendo do escopo do projeto de SOA, diferentes abordagens podem ser consi-
deradas (ERL; MERSON; STOFFERS, 2017). Por exemplo, técnicas de Reengenharia
de Software para modernização de sistemas legados. Segundo Pressman e Maxim (PRES-
SMAN; MAXIM, 2016, p. 795), “A Reengenharia de Software abrange as atividades de
análise de inventários, reestruturação de documentos engenharia reversa, reestruturação
de programas e dados e engenharia direta”. Para Wagner (WAGNER, 2014), ela oferece
uma estratégia de modernização de sistemas pelo atendimento de importantes propósitos
como portar sistemas para uma nova plataforma, introduzir novas tecnologias, extrair
conhecimentos, design e quebrar arquiteturas monolíticas. O consenso entre esses autores,
é que o objetivo a Reengenharia de Software é a criação de versões dos programas com
maior qualidade e melhor manutenibilidade.
Conforme ilustrado na Figura 4, esse processo pode ser compreendido por três
fases distintas (TRIPATHY; NAIK, 2014): Abstração, na qual as técnicas de Engenharia
reversa (Reverse Engineering) como análise de código, análise de documentos, coleta de
requisitos e extração de modelos são aplicados; Refinamento, com o qual as atividades
Engenharia direta (Forward engineering) são aplicadas. Esta fase visa atingir um sistema
alvo com melhor qualidade, em comparação ao sistema original; a fase de Alteração é a
relação entre abstração e refinamento para repensar os modelos conceituais, re-especificar
requisitos, re-desenhar e re-codificar uma nova implementação;
Um dos principais desafios desse processo é garantir a equivalência funcional na
nova versão (GRUBB; TAKANG, 2003). Para a nova versão do sistema deve fornecer as
mesmas funcionalidades existentes do sistema legado, além de poder atender de maneira
rápida e confiável novas solicitações.
Figura 4 – Modelo geral para Reengenharia de Software (WAGNER, 2014).
2.3 Microsserviços e DevOps

A constante necessidade de entregas mais rápidas e confiáveis demandam respostas
ágeis em um ambiente de negócio cada vez mais fluido (PRESSMAN; MAXIM, 2016,
p. 67). Nesse contexto, a abordagem de software e arquitetura de sistemas denominada
“Microsserviços” tem se demonstrado uma tendência no design, desenvolvimento e entrega
de serviços (JAMSHIDI et al., 2018). Emergidos de conceitos como Domain-Driven
Design (EVANS, 2003), Continuous delivery, On-demand virtualization, Infrastructure
automation, Small autonomous teams, System scale (NEWMAN, 2015), microsserviços se
baseiam no conceito bem definido de modularização.
Ou seja, cada microsserviço é implementado e operado como um pequeno sistema
independente, oferecendo acesso à lógica e dados através de uma interface de rede bem
definida (JAMSHIDI et al., 2018). Como consequência, há um aumento na agilidade,
uma vez que cada microsserviço torna-se uma unidade autônoma de desenvolvimento,
implantação, operação, versionamento e dimensionamento (JAMSHIDI et al., 2018). Para
Fowler (FOWLER, 2016), “com a arquitetura de microsserviço, um aplicativo pode ser
facilmente dimensionado horizontalmente e verticalmente, a produtividade e a velocidade
do desenvolvedor aumentam drasticamente, e tecnologias antigas podem ser facilmente
trocadas para as mais novas”. Para isso, é preciso a adoção de práticas contínuas, ou
seja, integração, entrega, implantação e monitoramento contínuos para permitir que as
organizações liberem novos recursos com freqüência e confiabilidade, garantindo a alta
qualidade do sistema implantado durante todo o seu ciclo de vida (BASS; WEBER; ZHU,
2015).
Essas práticas da Continuous Software Engineering podem ser classificadas em três
modalidades (SHAHIN; BABAR; ZHU, 2017): Continuous Integration (CI): prática
em que os membros de uma equipe integram o trabalho de desenvolvimento frequentemente;
Continuous Delivery (CDE): prática adotada para a garantir que um aplicativo esteja
sempre em estado preparado para a produção depois de passar com êxito por testes
automatizados e controles de qualidade; Continuous Deployment (CD): prática de
implantação contínua dá um passo adiante e implanta de forma automática e contínua o
aplicativo para ambientes de produção. É importante notar que a prática de CD implica
na prática de CDE, mas a inversa não é verdadeira.
Como ilustrado na Figura 5, a relação dessas práticas contínuas inicia-se com o time
de desenvolvimento realizando commits na base de código. Essa ação notifica o servidor de
CI que executa o build e os testes automatizados da aplicação. Em seguida, as etapas de
CDE e CD são executadas para preparar pacotes de software para a entrega e implantá-los
em ambiente de produção. Os resultados de cada etapa são notificados para o time de
desenvolvimento.
Figura 5 – A relação entre integração, entrega e implantação contínuas (SHAHIN; BABAR;

ZHU, 2017).
Na indústria, estas práticas contínuas são rotuladas como DevOps, que de acordo
com Bass (BASS; WEBER; ZHU, 2015, p. 4), “é um conjunto de práticas destinadas a
reduzir o tempo entre executar uma alteração em um sistema e a mudança ser colocada em
produção, garantindo ao mesmo tempo alta qualidade”. Ainda para Bass (BASS; WEBER;
ZHU, 2015, cap. 7) associa-se às práticas contínuas do DevOps o Monitoramento, que
fornece identificação de falhas, identificação da degradação do desempenho, o planejamento
das capacidades de recursos, identificação da dinâmica do negócio e detecção de intrusão.
Essas práticas em conjunto ajudam a moldar as decisões tomadas sobre como construir
microserviços e como implantá-los.
Sendo assim, os benefícios associados a adoção de Microsserviços e DevOps são a
construção de serviços que apresentam heterogeneidade de tecnologias, resiliência, escala,
fácil implantação, alinhamento organizacional, passividade de composição, e substituibili-
dade (NEWMAN, 2015). Apesar desses benefícios já serem endereçados e amplamente

discutidos numa perspectiva da Service-Oriented Architecture (ERL, 2008; ZIMMER-
MANN, 2017), para Newman (NEWMAN, 2015, p. 8), “há uma falta de consenso sobre
como fazer SOA bem”.
Talvez essa percepção resida no fato de que literaturas proeminentes de SOA
como as providas por Erl (ERL, 2005; ERL, 2008; ERL et al., 2012; ERL et al., 2014;
ERL; MERSON; STOFFERS, 2017) concentram seus esforços para explicar os princípios,
padrões, análise e design do paradigma orientado a serviços; enquanto literaturas como as
fornecidas por Newman (NEWMAN, 2015), Mark (RICHARDS, 2015) e Fowler (FOWLER,
2016) apresentam um catálogo de práticas que se aproximam da implementação de serviços.
Sob essa ótica, é possível admitir SOA como uma abordagem estratégica e microsserviços
como uma abordagem tática.
Vale salientar que embora os microsserviços e DevOps reflitam filosofias que remetam
a uma estrutura de pequenas equipes independentes, a maioria das organizações tem um
grande sistema de missão crítica que não é arquitetado dessa maneira. Essas organizações
precisam decidir se desejam migrar suas arquiteturas para arquiteturas de microsserviço e
quais migrar (BASS; WEBER; ZHU, 2015).
2.4 Considerações Finais

Este capítulo apresentou conceitos de SOA, MSOAM, Reengenharia de Software,
microsserviços e DevOps, que serviram de referencial teórico para nortear o o desenvolvi-
mento desta pesquisa. No Capítulo 3 serão apresentadas as motivações que levaram a SET
adotá-los como elementos para alcançar as metas de qualidade esperadas na migração do
sistema legado UVT.
28
3 MIGRAÇÃO DO SISTEMA UVT
Uma das principais responsabilidades da administração pública fazendária é a

prevenção e a detecção de evasão fiscal. No estado do Rio Grande do Norte, a Secretaria de
Estado da Tributação (SET) desenvolve sistemas para apoiar essas atividades, auxiliando
auditores fiscais e contribuintes a realizarem suas obrigações fiscais e tributárias. O UVT
(Unidade Virtual de Tributação) é um desses sistemas. Ele é a principal interface de
comunicação entre contribuintes e a SET 1 . Neste capítulo apresentaremos o sistema UVT,
sua arquitetura e métricas, contextualizando sua migração antes do início da pesquisa
acadêmica.
O sistema UVT foi projetado para fornecer serviços “abertos”, que não necessitam
de um mecanismo de autenticação e autorização, bem como serviços de acesso “restrito”.
Qualquer cidadão pode emitir uma certidão negativa ou consultar algumas informações
públicas de um cadastro de contribuinte, sem que haja a necessidade de identificação, uma
vez que estas informações não configuram dados protegidos pelo sigilo fiscal. Entretanto,
contribuintes, contadores e auditores fiscais podem utilizar uma área restrita do sistema,
na qual é possível acessar informações e serviços específicos, desde que autorizados a
fazê-lo. São exemplos de serviços da área restrita, a emissão de extratos fiscais e a baixa
de Documentos Fiscais eletrônicos (DF-e) como a Nota Fiscal eletrônica (NF-e) e Livros
Fiscais.
Desenvolvido entre os anos de 2008 e 2010 utilizando a linguagem de programação
Visual Basic e o Framework Webforms (ambas da Microsoft), o sistema UVT tinha como
objetivo técnico migrar para uma única solução algumas funcionalidades que originalmente
foram construídas utilizando tecnologias que naquele momento encontravam-se legadas
como Oracle Forms 2 e ASP (Clássico). A SET esperava com essa migração reunir
em uma única página Web todos os serviços disponíveis ao contribuinte, contabilistas,
transportadores e demais atores que interagem com a Secretaria de Tributação do RN.
3.1 Arquitetura do Sistema UVT

Seguindo padrões de desenvolvimento de aplicações web vigentes na época e
utilizando Frameworks web baseados em componentes, o sistema UVT foi construído sobre
uma estrutura na qual: a) todos os serviços estavam contidos em um núcleo indecomponível
1
Contribuinte é qualquer pessoa, seja física ou jurídica, que efetue, normalmente em volume que carac-
terize finalidade comercial, operações de movimentação de bens ou serviços de transporte interestadual
e intermunicipal.
2
http://www.oracle.com/technetwork/developer-tools/forms/overview/index.html
Capítulo 3. Migração do sistema UVT 29
Figura 6 – Arquitetura monolítica (fonte-própria)
que permitia a comunicação irrestrita entre os componentes; b) todo o sistema era executado
em um único nó de processamento (Single thread); c) havia um acúmulo de múltiplas
responsabilidades como a renderização da camada de apresentação, controle de estado dos
objetos complexos, longos processamentos (síncronos) em background, processamento de
lógicas de negócio, acesso a banco de dados e outros componentes de infraestrutura, como
ilustra a Figura 6.
As escolhas realizadas para o desenvolvimento dessa estrutura trouxeram algumas
consequência como: a implantação de um novo serviço ou uma nova versão exigia a re-
distribuição da solução por inteiro; ajustes nos parâmetros de aplicação forçavam a
reinicialização do sistema para atualizações das configuração; uma baixa esca-
labilidade, uma vez que o sistema foi construído para ser executado em uma única thread
de processamento e seu controle de estado de sessão não foi projetado para funcionar de
forma distribuída; efeitos colaterais indesejados em serviços que não foram alterados
devido a manutenções em áreas comuns do sistema; o baixo desempenho ocasionado
pelo uso indiscriminado de alguns recursos do Framework web como o uso gerenciável
de sessão para guarda de objetos muito complexos por muito tempo; por fim, o alto
acoplamento pela ausência de isolamento da lógica do serviço ocasionada pelo mal uso de
ferramentas baseada em conceito RAD (Rapid Application Development), o que permitia
que um desenvolvedor “arrastasse” um componente para uma “página” e lhe atribuísse um

comportamento do serviço em uma classe chamada Code-behind, a qual estava diretamente
associada a página.
Figura 7 – Estrutura monolítica do sistema UVT (fonte-própria)
A Figura 7 ilustra a relação desses componentes estruturais da arquitetura monolí-

tica do sistema UVT. Nela é possível observar o forte acoplamento, através da relação entre
os componentes de interface visual (página aspx) e a classe do code-behind. Devido esse alto
acoplamento na camada de apresentação, o reaproveitamento de serviços tornou-se algo
extremamente complexo, dada a total dependência das classes do serviços aos componentes
de interface gráfica do framework web.
Outro aspecto negativo, é o compartilhamento de uma mesma entidade de negócio
para todos os serviços de um mesmo contexto do domínio. Esse tipo de abordagem pode
provocar ambiguidades sobre a entidade modelada, efeitos colaterais indesejados pelo
alto risco de constantes mudanças e uma sobrecarga de responsabilidades, uma vez que a
entidade precisa conhecer todos os comportamentos e propriedades de todos os cenários
dos quais ela participa.
Com o passar dos anos, essa estrutura e a falta de boas práticas de engenharia de
software, como a ausência de padrões e princípios de design, comprometeram a qualidade
do sistema UVT. Além disso, os constantes efeitos colaterais ocasionados por bugs, o
aumento substancial de linhas de código, o uso indiscriminado dos recursos computacionais

e a baixa escalabilidade do sistema o levaram a uma significativa queda do seu desempenho,
o que tornou sua manutenção e usabilidade cada vez mais complexas.
Esses fatos motivaram a equipe a realizar uma avaliação crítica sobre a qualidade do
sistema UVT. Nessa avaliação a equipe decidiu quantificar a dívida técnica do sistema afim
de levantar os principais pontos de comprometimento da sua qualidade e manutenabilidade.
Para isso foi adotado o uso de ferramentas de análise estática de código afim de identificar
os problemas que afetam a base de código do sistema UVT 3 . Essa avaliação revelou um
acumulo da dívida técnica e indicou um preocupante quadro de decaimento na qualidade
de software. O impacto negativo desse decaimento ficou evidente ao analisar as métricas
obtidas.
A Tabela 1 apresenta a apuração dos registros da dívida técnica agrupados por
categorias de correções. Nelas os dados são dispostos nas colunas Categorias, que re-
presentam as categorias das regras violadas; esforço 4 , que quantifica o esforço para
desenvolver o elemento de código (apresentado em dias/horas/minutos); o custo (em R$),
que representa o valor total de horas/homem 5 gastos com a correção; e as colunas que
quantificam as correções por severidade Críticas, Altas, Médias e Baixas.
Analisando os dados da Tabela 1 é possível perceber que a categoria “Architecture”
é a que apresenta maior endividamento técnico no que diz respeito a esforço e custo,
respectivamente 176 dias e R$ 70.6 mil. Expandindo esta categoria (ver Tabela 2) podemos
observar que o sistema precisa de correções de alto impacto como remover o acesso à
camada de Dados a partir da Interface Gráfica de Usuário, relacionamentos que causam
dependência circular e baixa coesão no empacotamento de componentes.
Totalizando esses dados, são 4.217 correções registradas, o que correspondem a 267
dias de esforço necessários para realizar as correções do sistemas UVT, o que corresponde a
um custo total R$ 107K Hora/Homen. Em termos de severidade, as métricas obtidas pela
ferramenta também indicaram que há uma necessidade de esforço para melhorar a qualidade
do sistema UVT para resolver 72 correções críticas, 1.710 correções de alta-prioridade,
2.372 correções de média-prioridade e 63 correções de baixa prioridade.
Outro fator de impacto negativo levantado pela análise da equipe foi a ausência de
3
A ferramenta NDepend foi aqui utilizada para demonstrar valores totais da dívida técnica, bem como
categorizar os tipos de correção associados a essa dívida. Sua escolha se deu também pelo fato de se
basear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediate
language (IL) do .net framwork, abarcando assim todas as linguagens da família .net framework (C#,
Visual Basic e F#) sob uma mesma ótica de análise (https://www.ndepend.com/)
4
O esforço é obtido pela relação de número homen-dia para desenvolver 1000 linhas de código. Por
padrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de código
escritas por desenvolvedor em um dia
5
Os valores configurados para o calculo do custo foram: R$ 50,00 Hora/Homem, jornada de 8 horas
diárias e 240 dias por ano
Tabela 1 – Métricas da dívida técnica do sistema UVT agrupadas pela categorias.

Dívida Correções
Catégoria Esforço Custo Críticas Altas Médias Baixas Total
.NET Framework
System 6h45min 338 - 29 4 - 33
Collection 2h10min 108 - - 13 - 13
Globalization 3d1h 1.25K - - 179 - 179
Reflection 6h 30min 325 - 38 1 - 39
InteropServices 35min 29.2 - 3 4 - 7
System.Threading 40min 33.3 - 1 0 - 1
System.Xml 3h50min 192 - - 23 - 23
Project Rules
Architecture 176d 70.6K 72 660 0 5 737
Code Smells 51d 20.6K - 108 164 1 273
Design 4d1h 1.65K - - 434 15 449
Immutability 17d7h 7.17K - 854 35 - 889
Naming Conventions 1h25min 70.8 - - 27 39 66
OOP Design 8d5h 3.46K - 2 832 3 837
Source Organization 3h45min 188 - 15 - - 15
Visibility 2d4h 1.02K - - 656 - 656
Total 267d 107K 72 1710 2372 63 4217
Tabela 2 – Métricas da dívida técnica da categoria “Architecture”.
Regras Correções Esforço Custo

UI layer shouldn’t use directly DAL layer 470 issues 155d 62.1K
UI layer shouldn’t use directly DB types 166 issues 17d 3h 6.96K
Avoid namespaces mutually dependent 93 issues 3d 0h 1.24K
Avoid namespaces dependency cycles 3 issues 6h 0min 300
Namespaces with poor cohesion (RelationalCohesion) 5 issues 50min 41.7
Práticas contínuas como integração de código, entrega contínua, implementação contínua

e monitoramento durante o ciclo de vida do sistema UVT, o que tornava a implantação de
versões do sistema um processo complexo e com baixa garantia de qualidade. Por exemplo,
a ausência de mecanismos automatizados de integração de código-fonte para lidar com
os conflitos gerados durante o desenvolvimento, reduziu a qualidade de verificação do
código integrado, favorecendo o surgimento de bugs com maior frequência no ambiente de
produção, algumas vezes provocando efeitos colaterais indesejados.
Nesse sentido, o alto endividamento técnico, a ausência de práticas contínuas,
somados as demandas por renovação visual de seu portal Web e de prestação de serviços
em dispositivos móveis intensificaram o desejo de modernização do sistema UVT. Contudo,
essa modernização requereu muito mais do que a renovação de interfaces visuais (GUI) e a
adoção de técnicas de desenvolvimento para dispositivos móveis.

Na verdade, a ausência de uma camada de interoperabilidade do sistema UVT
exigiu uma revisão da arquitetura do sistema e adequação da infraestrutura, considerando
um re-design com foco no reuso, bem como uma reformulação nas abordagens empregadas
para a construção e entrega de soluções de software orientadas a serviço. Nesse sentido,
para a equipe de desenvolvimento da SET, a reestruturação do sistema UVT necessitava
passar pela criação de um conjunto de serviços flexíveis e de fácil manutenção, robustos
e capazes de responder a cenários de alta disponibilidade, bem como suportar grandes
cargas de solicitações, garantindo coexistência com os sistemas existentes.
3.2 Processo adhoc

Dada a importância do sistema UVT para as atividades de arrecadação e fiscaliza-
ção de tributos do Estado do Rio Grande do Norte, diante da insuficiência desse sistema
responder satisfatoriamente aos requisitos de qualidade esperados como manutenibilidade
e desempenho, além da crescente demanda por modernização visual e por interoperabi-
lidade, a SET se viu diante da necessidade de uma migração iminente do sistema UVT.
Para isso, em 2015 a SET manifestou sua intenção de reestruturar o sistema UVT no
contexto do projeto PROFISCO-RN 6 , financiado pelo BID (Banco Inter-Americano de
Desenvolvimento).
Num plano geral, o objetivo dessa reestruturação era proporcionar uma nova vida
útil ao sistema UVT, tornando-a uma central de serviços mais segura, simples de usar, com
visual moderno e com a possibilidade de inclusão de novos serviços. Além disso, proporcionar
mais mobilidade aos usuários internos e externos através do desenvolvimento de aplicações
próprias para dispositivos móveis como smartphones e tablets. Numa perspectiva visando
benefícios futuros, a migração do sistema legado UVT é uma oportunidade de lidar com
as problemáticas existentes, assim como uma oportunidade de se obter: a) os benefícios
advindos da implantação bem-sucedida de um projeto SOA (ver 2.1); b) uma melhor
manutenibilidade pelo pagamento contínuo da dívida técnica (ver 2.2); bem como, c) os
benefícios pela adoção das práticas contínuas de DevOps(ver 2.3).
No intuito de alcançar essa metas de qualidade, a equipe de desenvolvimento da
SET optou pela adoção de um processo de Reengenharia de Software para lidar com
a crescente dívida técnica do sistema; SOA para lidar a falta reuso de aplicações e a
ausência de interoperabilidade; e microsserviços e DevOps para lidar com a inflexibilidade
da arquitetura monolítica e com processos complexos e não automatizado de implantação
de sistemas. Esse processo inicialmente foi realizado de forma adhoc. No entanto, algumas
6
projeto de númeero BR-L1207: Projeto de Integração da Modernização da Administração Fiscal do Rio
Grande do Norte - PROFISCO-RN)
iterações e a crescente maturidade adquirida sobre temas circundantes à migração de

sistemas legados num contexto de pesquisa, foram direcionando esse processo para uma
formalização que será tratada no Capítulo 4.

Neste capítulo foi contextualizada a migração do sistema UVT e apresentadas
algumas características de projeto que limitam o reuso de software e comprometem a sua
qualidade. Foram explanadas as problemáticas relacionadas à Dívida Técnica, Ausência
de interoperabilidade, Arquitetura monolítica de sistema e processos de implantação
inflexíveis. Além disso, foram apresentadas as motivações para a migração do sistema UVT,
bem como as motivações para adoção de SOA, processos de Reengenharia de Software,
microsserviços e DevOps.
35
4 PROCESSO SPREAD
Para atender as demandas do projeto de migração do sistema UVT e alcançar

uma solução orientada à serviço moderna e bem-sucedida, a equipe de desenvolvimento
da SET conduziu um processo de Reengenharia de Software tendo SOA como paradigma
estratégico, microsserviços como tática de implementação e DevOps como prática contínua
de integração, entrega, implantação e monitoramento. Dessa experiência, suportada pela
pesquisa acadêmica, foi extraído um novo processo chamado SPReaD, que significa Service-
oriented Process for Reengineering and DevOps. Este capítulo é dedicado a explanação
desse processo. Para isso, uma rápida apresentação é descrita na Seção 4.1. Já a seção 4.2
apresenta como se deu a extração do processo e explana de forma geral como foi a definição
de suas fases e atividades, que nas seções 4.3, 4.4, 4.5, 4.6 e 4.7 são detalhadas.
4.1 Visão Geral

O SPReaD consiste em uma instanciação do MSOAM para lidar com sistemas
monolíticos legados. Esta instanciação é focada na Reengenharia de Software, incorporando
aspectos do DevOps como meio para otimizar a entrega, implantação e monitoramento de
serviços. A Figura 8 ilustra a relação dessas “camadas” de tecnologias.
Figura 8 – Relação das camadas de tecnologias do processo SPReaD (fonte-própria).
Ao passo que um sistema legado entra num processo de Reengenharia de Software,

Capítulo 4. Processo SPReaD 36
é importante que se trace estratégias para que ele atinja as metas de qualidade desejadas,
bem como sua dívida técnica seja diminuída e passe a ser gerenciada continuamente. Para
isso, o SPReaD estabelece um conjunto de medidas: Adotar a Orientação a serviço
como paradigma capaz guiar a Reengenharia de Software na identificação e modelagem de
serviços a partir da engenharia reversa do sistema legado. Aplicar Reengenharia de
Software para decompor o sistema monolítico em pequenos componentes de serviço de fácil
manutenção, maior autonomia, reuso e capacidade de compor modernas soluções orientadas
a serviço; Adotar práticas contínuas para melhorar a qualidade de implantação e
monitoramento do sistema. As medidas antes descritas podem ser observadas na Figura 9.
Figura 9 – Estratégia e Táticas do SPReaD (fonte-própria).
Além disso, é preciso que hajam elementos táticos que indiquem como proceder
para migrar sistemas monolíticos legados para uma solução orientada a serviço. Nesse
sentido, o SPReaD adota os padrões do catálogo SOA para estruturar inventários de
serviço afim de construir soluções utilizando tanto abordagens clássicas de SOA como
Enterprise Service Bus (ESB), ou abordagens mais recentes como microsserviços.
Em resposta a um cenário no qual serviços necessitam de mais autonomia no
desenvolvimento e implantação - para satisfazer as exigências das mudanças de negócio
cada vez mais dinâmicas - as abordagems escolhidas foram a de microsserviços, DevOps e
Domain-Driven Design (DDD) (EVANS, 2003). A definição do que venha ser um serviço
“micro” na visão do SPReaD aqui é estabelecido pelos conceitos de Contextos Delimitados
(Bounded Context) (EVANS, 2003) definidos dentro de um Inventário de Serviço, o que
será demonstrado nas práticas relacionadas as atividades do processo.
4.2 Extração do Processo

Para lidar com essas abstrações do MSOAM é preciso um processo adaptável que
possibilite a escolha de um conjunto apropriado de ações e tarefas que absorva as etapas
de um projeto de reengenharia como foco na implantação de SOA. A forma adotada
para alcançar esse processo foi a acomodação do MSOAM no framework de processo
genérico descrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016), que compreende
cinco fases metodológicas: Comunicação, Planejamento , Modelagem, Construção
e Implantação.
Essas fases principais do framework de processo descrito por Pressman e Ma-
xim (PRESSMAN; MAXIM, 2016) englobam um conjunto de etapas: Análise e Design
em suporte a Modelagem; Codificação, Teste em suporte a Construção; e Entrega,
Suporte e Feedback em suporte a Implantação. Uma atenção deve ser reservada a fase
de Comunicação, que recebeu um conjunto de atividades específicas para lidar com a
coleta de requisitos e gestão da dívida técnicas, não abarcadas pelo MSOAM. A Figura 10
representa as etapas de acomodação das atividades do MSOAM no framework de processo
descrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016).
Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman e

Maxin (fonte-própria).
O objetivo dessa acomodação foi estabelecer a base de um processo de Reengenharia

de Software completo, pelo qual camadas de tecnologias como SOA e DevOps possam
se manter coesas e o desenvolvimento de software possa ser conduzido de forma racio-
nal (PRESSMAN; MAXIM, 2016). Como resultado disso a identificação das atividades do
MSOAM dentro de um processo tornou-se mais contundente.
Essa estrutura serviu como ponto de partida para a organização do SPReaD,
na qual foram acrescentadas atividades pertinentes a Reengenharia de Software como

Engenharia Reversa e Engenharia Direta, bem como as relacionadas a DevOps como
Prática Contínuas (CI, CDE, CD) e Monitoramento. A identificação de todas essas
fases possibilitou ao MSOAM alcançar uma abstração mais próxima da instanciação de
um processo de software que contempla a relação entre SOA, Reengenharia e DevOps.
Esta instância denominamos de SPReaD (SOA Process, Reengineering and DevOps).
A Figura 11 ilustra a estrutura completa desse processo.
Figura 11 – Estrutura completa do processo SPReaD (fonte-própria).
De forma geral, as fases do processo SPReaD podem ser compreendidas da seguinte

forma: A fase Comunicação é dedicada à compreensão dos objetivos dos Stakeholders
para o projeto e à coleta de requisitos que auxiliem na compreensão das funcionalidades
de software e atributos de qualidades esperados. Esta fase marca o início do projeto de
migração. Por sua vez, a fase de Planejamento envolve a atividade de Plano de Adoção
de SOA, que descreve o escopo do projeto, os recursos necessários, os riscos envolvidos,
um cronograma de trabalho e os produtos resultantes. Estas atividades são organizadas
em um plano.
Dado o foco em reengenharia, a fase de Modelagem é dedicada a aplicação das
atividades de Análise e Design para identificar modelos que atendam as necessidades de
desenvolvimento de software. A Análise compreende o uso de Engenharia Reversa para se
obter do sistema legado informações que colaborem na identificação de serviços candidatos
que compartilem os mesmos limites conceituais. Para isso, são executadas as atividades de
Análise de Inventário de Serviço; e Análise Orientada a Serviço.
No tocante ao Design, são executadas as atividades de Design Orientado a
Serviço e Design da Lógica de Serviço, que marcam o início da Engenharia Direta,
cujo foco é o re-design e re-arquitetura da solução, bem como a elaboração de contratos de
serviços. A fase Construção é marcada pela implementação das estruturas modeladas no
Design. Para isso, a Codificação e o Teste são conduzidos respectivamente pela atividades
de Desenvolvimento de Serviço e Teste de Serviço, que completam a Engenharia
Direta pela geração de código e testes necessários para migrar as funcionalidades do sistema
legado e as encapsular em novas estruturas.
A fase de Implantação, está dividida em duas partes: na primeira são executadas
as atividades de Implantação e Manutenção de Serviço, responsáveis pela entrega de
software como entidade completa ou como incremento. Essa fase está associada às práticas
contínuas do DevOps. Em seguida, a etapa de Suporte e Feedback é conduzida pelas
atividades de Uso e Monitoramento de Serviço, Descoberta de Serviço e Versio-
namento e Retirada de Serviços, respectivamente para realização do monitoramento
contínuo dos serviços e infraestrutura, descoberta de serviços em seus inventários, bem
como para identificação da necessidade de alteração na versão do serviço ou sua retirada
de um inventário.
As fases do SPReaD, descritas anteriormente são conduzidas num fluxo de um
processo evolucionário, “um modelo iterativo que possibilita desenvolver versões cada vez
mais completas do software” (PRESSMAN; MAXIM, 2016, p. 45). Nesse fluxo o SPReaD
é aplicado iterativamente executando todas as fases do processo para planejar, modelar,
construir e entregar Inventários de serviços. Nesse sentido, a entrega de um Inventário
determina um escopo de uma ou mais iterações, com cada iteração contribuindo com a
ampliação do blueprint de Inventário de serviços.
Essa visão geral captura a essência do processo SPReaD, aplicado nos últimos anos
para modernizar o sistema UVT. As seções a seguir detalharão as atividades, artefatos e
praticas de cada fase do processo. Ressaltamos que as fases de Comunicação e Planeja-
mento foram executadas dentro de um processo adhoc, antes da formalização do processo
SPReaD em si. Sendo assim, elas estão aqui descritas no intuito de serem registradas como
fases importantes que precisam ser executadas. Já as fases de Modelagem, Construção e
Implantação serão apresentadas com um nível maior de profundidade.
4.3 Comunicação
A comunicação é uma das primeiras fases do processo SPReaD. Nela os requisitos
iniciais do projeto são coletados e documentados no intuito de definir as necessidades para
atingir os objetivos pretendidos pelos stakeholders.
4.3.1 Atividades
Como ilustrado na Figura 12, esta fase executa a atividade da Coleta de Requi-
sitos que inicia-se com a Definição de um Grupo de Foco envolvendo os stakeholders
do projeto para se obter informações, experiências e requisitos iniciais que auxiliem na
fragmentação do problema em partes menores e mais gerenciáveis. Uma vez que o foco do
processo é a reengenharia do sistemas legados, é importante que sejam extraídas métricas
Figura 12 – Fase de Comunicação do SPReaD (fonte-própria).
desse sistema no início do processo de migração para que haja um ponto de comparação
que evidencie se a equipe alcançou ou não seus objetivos de migração.
Nesse sentido, a fase de comunicação do SPReaD adota como métrica o Calculo da
Dívida Técnica Atual do Sistema Legado. Ao Comunicar essa Dívida Técnica
aos stakeholders é fornecido um “retrato” da qualidade atual do sistema legado. O intuito
disso é conscientizar a todos sobre os pontos críticos do sistema e quais as práticas que
devem ser revistas durante o ciclo de desenvolvimento de software. Por fim, os princípios da
Orientação a Serviço são utilizados como referência durante a Definição de Requisitos
Gerais (ver 2.1) para antecipar a identificação de elementos que favoreceram a formalização
de contratos, serviços reutilizáveis e composição.
4.3.2 Artefatos
Um dos artefatos produzidos nessa fase é o Documento de Visão Geral, que
fornece um conjunto de requisitos para executar a migração do sistema legado, bem como
um conjunto de metas e atributos de qualidade a serem alcançados. Além disso, também é
gerado um Relatório da Dívida Técnica, cujo principal objetivo é deixar claro qual é
o ponto de partida da migração, quais são os atributos de qualidade mais comprometidos
e o impacto disso no sistema em sua versão atual.
4.3.3 Práticas
No intuito de orientar a execução da atividade de Coleta de Requisitos é sugerido
que as reuniões do Grupo de foco busquem a ampliar o foco em problemas de domínio
e não apenas tecnologias. No tocante a Calculo e Comunicação da Dívida Técnica,
recomenda-se o suporte de ferramentas que forneçam avaliação de qualidade de software
com base em padrões e metodologias consolidados de qualidade (ISO, SQALE), bem
como apresente as métricas numa linguagem adaptada para os públicos técnicos e de
negócio. Por fim, na Coleta de Requisitos Gerais recomenda-se utilizar técnicas que
ampliem a compreensão dos requisitos como Class Responsibility Collaboration Cards
(CRC), Prototipagem rápida, Event Storming, Mapas mentais e de impacto, Business
Model Canvas etc 1 .
4.4 Planejamento
Em um processo de migração de sistemas legados para adoção de SOA, é necessário
que haja um plano de migração de software para definir o escopo de análise, os prazos,
os recursos, os produtos resultantes e os riscos envolvidos no projeto. Esse plano, na
perspectiva da equipe de TI, é um guia para organizar o cronograma de desenvolvimento e
implantação, bem como dimensionar quais partes do sistema legado devem ser priorizadas;
na perspectiva dos patrocinadores, o planejamento ajuda a estimar os recursos necessários
para sustentar o projeto.
4.4.1 Atividades
A Figura 13 ilustra a fase de Planejamento executando a atividade de Planeja-
mento de adoção de SOA. Essa atividade ocorre pela definição de escopo de análise,
que se dá pelo isolamento de um conjunto de funcionalidades de sistema com o mesmo con-
texto de domínio; seguida pela definição do produto esperado após a migração. Com base
nesse escopo são definidos os marcos de entrega, os recursos necessários para migrar esse
conjunto de funcionalidades, bem como é mensurado os riscos envolvidos nessa migração.
4.4.2 Artefatos
Para aplicar um plano de migração em um sistema legado com inúmeras funciona-
lidades, o planejamento precisa lidar com questões de longo prazo como um cronograma
geral de projeto, insumos a serem fornecidos, instalações, equipamentos exigidos, local
de execução etc. Para isso, deve ser estipulado uma plano de trabalho com as equipes
de projeto. Esse plano visa oferecer aos patrocinadores uma visão geral do cronograma e
1
Uma leitura rápida destas práticas estão descritas no livro Patterns, principles and practices of
domain-driven design (MILLETT, 2015)
Figura 13 – Fase de Planejamento do SPReaD (fonte-própria).
marcos do projeto, bem como como os recursos disponíveis seriam empregados no projeto.
Uma série de documentos podem compor esse plano como Termos de referência, Atas de
Reunião, Cronogramas de execução, Relatórios, Contratos etc.
Ao mesmo tempo, o projeto de migração precisa lidar com questões mais imedi-
atas como mudança de escopo, conflitos de interesses, adequação de recursos e entregas
incrementais antecipadas. Nesse sentido, deve ser adotado um processo iterativo no qual
planejamentos de curto prazo precisam ser realizado a cada ciclo. O foco desse planejamento
da iteração é organizar e estimar os escopos de trabalho do ciclo, promover um maior foco
no objetivo da entrega, reduzir custos de mudança durante o processo de reengenharia
de software, alinhar a equipes de negócio e de TI, bem como promover entregas mais
frequentes de software. Para realização de um planejamento iterativo, recomenda-se a
adoção de ferramentas para gestão de projetos ágeis para gerenciar a migração do sistema
legado nos ciclos de desenvolvimento.
4.4.3 Práticas
No intuito de orientar a execução da atividade de Plano de adoção de SOA é
sugerido adotar práticas de gestão de projetos para realização do planejamento geral (longo
prazo) e práticas ágeis para realização do planejamento das iterações na fase de execução
(curto prazo). Além disso, adotar ferramentas que proporcionem tanto a gestão de projetos
de software como o controle do ciclo de vida do desenvolvimento. De modo a manter um
registro do planejamento, recomenda-se utilizar documentos como Termos de referência,
Atas de Reunião, cronogramas de execução, relatórios, cópias de contratos etc.
4.5 Modelagem
Esta fase está relacionada a Análise e Design num contexto da Reengenharia de
Software pela execução das atividades de Análise de Inventário de Serviço e Análise
Orientada a Serviço, para aplicação de Engenharia Reversa; e Design Orientado a
Serviço e Design da Lógica de Serviço, para aplicação de Engenharia Direta.
4.5.1 Atividades
A Figura 14 ilustra o fluxo da execução das atividades da Análise. A Análise de
Inventário de Serviço é responsável pela a definição conceitual de Inventários de Serviço,
a partir da identificação de serviços candidatos fazendo uso de abordagens como Contextos
Delimitados e Mapeamento de Contexto (EVANS, 2003; VERNON, 2013) para auxiliar
na identificação das fronteiras dos componentes de negócio, bem como as estratégias de
composição de serviços.
A Análise Orientada a Serviço consiste na coleta de informações por meio de
técnicas de engenharia reversa, envolvendo análise de código legado e documentação de
software. Como resultado dessa engenharia reversa, uma nova documentação de software
(Diagramas de Classe, Diagramas de Entidade Relacional, Casos de Usos etc) é criada
para suportar o processo de engenharia direta.
A Figura 15 ilustra o fluxo das atividades de Design Orientado a Serviço e Design da
Lógica de Serviço. O Design Orientado a Serviço tem por objetivo o re-design da solução
de software com foco na reutilização, bem como uma redefinição da arquitetura de software
para expressar as novas características de design. Em suporte ao re-design, os serviços são
categorizados como: serviços de entidade, que é um serviço reutilizável com contexto
funcional agnóstico associado a uma ou mais entidades empresariais relacionadas (ERL et
al., 2012); serviço de tarefa, que é um contexto funcional não-agnóstico que geralmente
corresponde à lógica de processos de negócio com propósito único (ERL et al., 2012);
serviço utilitários, que é também um serviço reutilizável com um contexto funcional
agnóstico, mas intencionalmente não derivado de especificações e modelos de análise de
negócios" (ERL et al., 2012).
Por sua vez, a atividade de Design da Lógica de Serviço, é responsável por
completar a lógica de serviço, através da definição de um conjunto de informações como a
Figura 14 – Fase de Análise do SPReaD (fonte-própria).
versão do serviço, suas políticas de acesso, esquemas de contrato, rotas de acesso das APIs
etc.
4.5.2 Artefatos
Como resultado da Análise, são gerados o blueprint dos inventários de serviço
indicando os principais contextos de domínio; e uma documentação de software voltada
para explanação do escopo de cada inventário e os seus serviços candidatos. Uma forma
para representar esse blueprint é a criação de um mapa mental, no qual os nós de primeiro
nível podem representar os inventários identificados e o segundo nível os serviços candidatos
desse inventário.
Já o resultado do Design é a especificação dos componentes da arquitetura de
serviço em termos da sua modelagem através de diagramas estruturais, como diagramas
de classe e diagramas de componentes da UML. Além disso, um conjunto de metadados
criados juntos ao código-fonte do novo serviço, o que permitirá a construção dos contratos
de serviços, o que facilitará a descoberta de suas capacidades.
Figura 15 – Fase de Design do SPReaD (fonte-própria).
4.5.3 Práticas
Como prática da atividade de Análise de Inventário de Serviço é adotada a
abordagem de Contextos Delimitados (EVANS, 2003) a partir da engenharia reversa do
sistema legado. Como ilustra a Figura 16, isso se dá pela definição de Contextos Delimitados
a partir do agrupamento dos serviços candidatos que estão logicamente unificados, porém
sem fronteiras estabelecidas dentro dos sistema legado. Após essa definição, o Contexto
Delimitado deve ser nomeado e extraído para Inventários de Serviço. Cada Contexto
Delimitado equivale a um microsserviço, e cada serviço identificado no sistema legado
passa a ser uma capacidade a ser oferecida pelo microsserviço identificado. Um inventário
pode conter um ou mais Contextos Delimitados dependendo do escopo de negócio do
Inventário.
Identificados os Inventários e seus serviços candidatos, a prática a ser adotada
na Análise Orientada a Serviço, seguindo a linha da engenharia reversa, é o início
da decomposição do serviço legado. Essa decomposição se dá pela extração da lógica de
Figura 16 – Aplicação da Análise de Inventário de Serviço (fonte-própria).
serviço das camadas de apresentação. Como ilustrado na Figura 17 essa extração gera dois
focos de análise: um foco para identificar comportamentos e modelos que satisfazem as
lógicas associadas à interface gráfica; e o outro voltado à lógica de serviço, com o qual são
identificados as capacidades e entidades de negócio do serviço. Nesse processo, é necessário
identificar os modelos de software que contenham múltiplas responsabilidades e separá-los
em classes distintas, afim isolar capacidades de negócio para obter uma melhor autonomia
e manutenção dessas classes.
Em relação às entidades relacionais no banco de dados, a equipe deve levar em
consideração o custo de migração dessas entidades para contextos separados, bem como o
custo de continuar com as entidades compartilhadas. Se por um lado o custo e o riscos
envolvidos na migração de um banco legado podem ser demasiadamente alto, o custo
de preservar a estrutura de banco de dados exige um maior esforço para mapear essas
entidades relacionais nos inventários de serviço. Para isso, é preciso adotar técnicas de
Mapeamento Objeto Relacional (ORM), e estratégias para lidar com problemas como a
concorrência por uma mesma instância (Tupla) de uma entidade, bem como lidar com
o versionamento e migração da base de dados num cenário onde o sistemas distribuídos
estão constantemente acessando recursos de dados.
Em relação a comunicação entre os componentes do sistema legado, antes a arqui-
Figura 17 – Aplicação da Análise Orientada a Serviço (fonte-própria).
tetura monolítica permitia que essa comunicação ocorresse de forma irrestrita, uma vez
que esses componentes compartilhavam um mesmo núcleo. Ao decompor esse núcleo em
Contextos Delimitados e distribuí-los em microsserviços, é preciso que haja estratégias de
comunicação entre eles. Uma vez que as relações entre Contextos Delimitados assumem
várias formas, o Domain-Driven Design (EVANS, 2003; VERNON, 2013; MILLETT, 2015)
provê uma abordagem chamada de Mapeamento de Contextos (Context Mapping), que
especifica o uso de um padrão (DDD relational pattern) para identificação de cinco possíveis
estratégias de relacionamento entre Contextos Delimitados:
• camada de anti-corrupção (Anticorruption Layer (ACL)), que representa uma

camada de tradução/adaptação de modelos externos (downstream) ao domínio para
a modelos do contexto;
• conformista (Conformist), para representar contextos que apenas recebem (donwns-

tream) modelos externos ao domínio sem que tenha o poder de modifica-los ou
adapta-los;
• cliente-fornecedor (Customer-Suplier), que revela a relação entre dois contextos

do domínio no qual o fornecedor realiza o envio de informação (upstream) enquanto
o cliente apenas recebe (downstream) essa informação;
• parceria (Partnership) que representa contextos auto-dependentes mas que são

desenvolvidos de forma separada (sem compartilhamento de código) e que realizam
transferências mútuas (upstream/downstream) de informação;
• núcleo compartilhado (Shared Kernel), que representa dois contextos acoplados

pelo compartilhamento de um subconjunto de modelos.
De forma a organizar os componentes de uma solução orientada a serviço, a fase

de Design do SPReaD propõe um modelo arquitetural no qual os microsserviços possam
ser construídos baseando-se nos princípios que regem SOA. A Figura 18 ilustra esse
modelo abrangente de solução através de uma arquitetura cliente-servidor. Nessa visão,
Consumidor e Provedor de serviços são representados numa relação de baixo acoplamento, o
que significa que as interfaces gráficas dos Clientes não estão “presas” às lógicas de serviços
implantadas no Provedor. Esses serviços residem em instâncias autônomas denominadas
de microsserviços, que expõem capacidades de negócio separadas por camadas (serviços
de Entidade , serviços de Tarefa e serviços Utilitários), além de representar uma abstração
de negócio, um Contexto Delimitado do domínio encapsulado como biblioteca de software.
Figura 18 – Práticas da Análise Orientada a Serviço (fonte-própria).
Para acessar essas capacidades de negócio o Cliente deve utilizar Contratos Padro-
nizados, o que evita que o cliente conheça aspectos de infraestrutura e detalhes técnicos
encapsulados no Provedor de Serviços como acesso a servidores de estado, de arquivos,

banco de dados, filas etc. Nesse sentido, os contratos devem ser passíveis de fácil localização.
Isso se dá por um mecanismo de descoberta com o qual o Provedor expõem as capacidades
de negócio e detalhes das instâncias de serviços ativas. A Figura 18 expõe a definição
de como deve ser uma estrutura de um microsserviço, que é composta por uma camada
de API de serviço que é responsável por lidar com requisições HTTP/REST(ERL et al.,
2012), incluindo autenticação e autorização no acesso a recursos, através de Fachadas de
Serviços (Façade) para orquestrar a lógica de serviço.
Por sua vez, a Camada de Aplicação adota a abordagem do padrão CQRS (Com-
mand Query Responsibility Segregation), para separar a aplicação em dois fluxos: um fluxo
de escrita denominado Command, no qual reside modelos de domínio e serviços para lidar
com as lógicas de negócio; e um fluxo de Query, no qual residem objetos de transporte de
dados (DTOs) que correspondem às operações de consulta dos consumidores de serviço.
Já a camada de cross-cutting fornece um conjunto de componentes cross-domínio para
abstrair recursos de infraestrutura, bem como para lidar com a manutenção de estado de
objetos do serviço.
Com base neste modelo, a implementação de cada microsserviço pode ser padro-
nizada para refletir um produto com maior autonomia. Além disso, o escopo reduzido e
especializado de cada microsserviço, bem como uma melhor componentização das camadas
de aplicações e abstração da camada de cross-cutting favorecem a sua portabilidade e
manutenibilidade. Por fim, ao transferir o estado de objetos para camadas de infraestrutura
e adotar estratégias de separação dos fluxos da aplicação em escrita e leitura pela adoção de
CQRS, o sistema ganha um potencial para alcançar uma ampla escalabilidade horizontal e
melhorar significativamente seu desempenho. Detalhes de implementação dessa arquitetura
serão abordados no Capítulo 5.
4.6 Construção
Esta fase envolve as etapas de Codificação e Teste, que estão relacionadas
respectivamente as atividades de Desenvolvimento de serviço e Teste de serviço do
MSOAM. Elas também completam o ciclo da engenharia direta dentro do processo da
Reengenharia de Software.
4.6.1 Atividades
A atividade de Desenvolvimento de serviço adota duas abordagens: a Imple-
mentação de API de serviço e a Migração de Software A Figura 19 ilustra o fluxo
dessas atividades na fase de construção.
Figura 19 – Fase de Construção do SPReaD (fonte-própria).
A Implementação de API de serviço é executada quando uma capacidade de

um serviço precisa ser fornecida para o consumo de um ou mais clientes. Neste contexto,
a API de serviço é construída através da implementação do contrato do serviço iniciado
na atividade de Design Orientado a Serviço e completada na atividade de Design
da Lógica de Serviço.Em seguida, a implementação da lógica do serviço é finalizada
e as preocupações com segurança são aplicadas, afim de garantir que apenas os clientes
autorizados possam acessar os recursos do serviço .
A atividade de Migração de Software é aplicada sobre o software legado no in-
tuito de transportar o serviço para uma nova estrutura de software. Para isso, duas técnicas
podem ser aplicadas: a Decomposição funcional ou Wrapping (WAGNER, 2014). A Decom-
posição Funcional é utilizada para alcançar uma melhor separação das responsabilidades
no software legado. Além disso tem o intuito de "quebrar"grandes problemas em problemas
menores e melhor administráveis (ERL et al., 2014). A técnica de Wrapping é utilizada
para encapsular softwares legados com alta complexidade e com um alto custo de migração
associado, em componentes que funcionam como uma camada de anti-corrupção (EVANS,
2003; VERNON, 2013). Por fim, o acesso aos componentes migrados são normatizados pela
criação de uma Fachada do serviço (Façade), que oculta toda a complexidade existente no
software.
Além dos testes dentro do processo de desenvolvimento de software, a atividade
de Teste de Serviço é executada para garantir que os serviços estejam respondendo aos
resultados esperados e estabelecidos no contrato do serviço. Para isso, são aplicados testes
em serviços agnósticos para verificar se estão prontos para uso repetitivo, bem como em
serviços não-agnósticos para garantir a operação correta da composição do serviço.
4.6.2 Artefatos
Como resultado direto da atividade do Desenvolvimento de Serviço, os compo-
nentes de software e as APIs são criados e compilados em pacotes publicáveis na rede. Como
resultado dos Testes de Serviço, um conjunto de testes que representam as validações
do sistemas são gravados e versionados para usos futuros tanto no ciclo de implantação,
quanto de manutenção de software.
4.6.3 Práticas
Dois fluxos possíveis de desenvolvimento podem ser adotados como prática da
atividade do Desenvolvimento de Serviço: um fluxo é o de migração de software e
um fluxo de construção da API por primeiro. A Figura 20 ilustra os passos do fluxo de
migração: primeiro, o serviço legado é decomposto para extrair entidades e lógicas de
serviços. Em seguida, são criados componentes de negócio que correspondam a arquitetura
de serviços projetada, enquanto que os recursos compartilhados e classes de acesso a
infraestrutura ou serviços externos são envolvidos por wrappers. Por fim, o componente
de negócio é envolvido por uma API web responsável por expor as capacidades de cada
serviço através de contratos padronizados.
Em alguns casos, o contrato do serviço precisa ser disponibilizado antes da lógica
do serviço em si. Por exemplo, equipes externas contratadas para o desenvolvimento do
front-end podem demandar o acesso ao contrato para prosseguir a construção de GUI’s
(Graphic User Interfaces). Também, alguns cenários de composição de serviço ou Testes
de integridade podem demandar a exposição prévia de contratos. Nesse cenário, a API
web é disponibilizada antes da construção do componente de negócio.
4.7 Implantação
A fase de implantação envolve o uso de técnicas de DevOps, como Integração
Contínua (Continuous Integration - CI ), Entrega Contínua (Continuous Delivery - CDE)
Figura 20 – Fluxo de Migração de Software (fonte-própria).
e Implantação Contínua(Continuous Deployment - CD).
4.7.1 Atividades
As etapas de Entrega, Suporte e Feedback fazem parte da fase de Implantação.
Elas são executadas afim de agilizar e gerenciar as etapas de implantação dos serviços no
ambiente de produção, bem como obter um monitoramento eficaz dos serviços. A Entrega
é orientada pela a atividade da Manutenção e Implantação de Serviço. Conforme
ilustrado na Figura 21, a atividade de Entrega é destinada ao processo de integração
do código-fonte (CI), seguida por sua compilação, execução de testes automatizados e
da análise estática de código. Quando essas atividades são bem-sucedidas, a entrega dos
pacotes é realizada no ambiente de homologação (CDE). Por fim, quando a homologação
dos pacotes é concluída, eles são implantados no ambiente de produção (CD).
A etapa de Suporte e Feedback é conduzida pelas atividades de Uso e Moni-
toramento de Serviço, Descoberta de Serviço e Versionamento e Retirada de
Serviço. Conforme ilustra a Figura 22, a atividade Uso e Monitoramento de Serviço
é aplicada para registrar, recuperar, tratar e disponibilizar um conjunto de logs sobre o
estado de funcionamento dos serviço em produção.
Figura 21 – Fase Etapa de Entrega do SPReaD (fonte-própria).
Por sua vez, o Descoberta de Serviço é aplicado para fornecer um repositório

independente no qual serviços residentes em inventários podem ser facilmente descobertos.
Essas atividades podem ser conduzidas em paralelo e fornecem a base para a atividade de
Versionamento e Retirada de Serviço. Para garantir que o controle de versão de um
serviço possa ser realizado com o mínimo de impacto e interrupção para os consumidores
de serviços, a atividade de Versionamento e Retirada de Serviço exige a condução
de um processo formal de controle de versão (ERL; MERSON; STOFFERS, 2017).
4.7.2 Artefatos
Para a entrega de serviços, os pacotes de software são compilados para implantação
no ambiente de produção. Esse processo se dá de forma automatizada e gera uma série
de relatórios que contém informações sobre as etapas de integração e compilação do
código-fonte. De forma a verificar e validar a qualidade do software integrado, o relatório
apresenta indicadores sobre a cobertura de código por testes automatizados, bem como
custo da dívida técnica recalculado.
Figura 22 – Fase de Suporte e Feedback do SPReaD (fonte-própria).
Uma vez que os serviços são implantados de forma distribuída, o uso do Repositório
de Serviço é adotado para descobrir onde o serviço está sendo executado e quantas
instâncias estão disponíveis para o consumo. Além disso, o Repositório de serviço expõem
as capacidades dos serviços e detalhes do contrato. Para efeito de monitoramento do uso
dos serviços no ambiente de produção, uma série de logs são registrados, recuperados,
tratados e disponibilizados através de dashboard, que são utilizados por equipes de suporte
para o monitoramento da infraestrutura, bem como por equipes de gestão para entender a
dinâmica do negócio através do consumo de serviços.
4.7.3 Práticas
Ao decompor a aplicação monolítica em Inventários de serviços, é possível diminuir
o acoplamento entre as camadas da aplicação. Com isso, busca-se otimizar o uso de
recursos e potencializar a escalabilidade e desempenho do sistema, bem como diminuir os
impactos negativos de efeitos colaterais ocasionados por entregas mal sucedidas. Para isso,
o processo de implantação deve ser repensado para que Inventários de serviços possam ser
implantados em instâncias autossuficientes.
Figura 23 – Instâncias de microsserviços na estrutura de alocação da SET (fonte-própria).
A Figura 23 ilustra que, diferente da infraestrutura monolítica (ver 3), os serviços

podem ser distribuídos em “N” nós de rede. Esses, por sua vez, podem estar organizados
em diferentes zonas de disponibilidade. Isso é possível pela remoção do gerenciamento de
Estado de dentro do serviço para mecanismos de “cache”, bem como para componentes
transversais (cross-cuting) que abstraem o acesso a sistemas de arquivo, banco de dados,
servidores de identidade, tarefas agendadas, etc.
De modo a favorecer o balanceamento de carga e um mecanismo de segurança
unificado de acesso aos serviços, é preciso que as requisições de clientes sejam intermediadas
através de Gateway de serviço. Além disso, a distribuição de serviços exige o uso de
mecanismos que possibilitem a descoberta e monitoramento de serviços publicados em
produção. Esses aspectos ampliam a capacidade de realizar intervenções na infraestrutura,
como rápidas reparações, versionamento e retirada serviços. Além disso, colaboraram
com a redução do custo operacional de TI em relação ao tempo de implantação de novas
instâncias de serviço, bem como a eficiência e tempo de resposta da equipe para corrigir
problemas no sistema.

Neste capítulo foram apresentados os princípios e design de solução do processo
SPReaD, bem como as estratégias utilizadas para reunir abordagens tecnológicas de SOA,
Reengenharia de Software e DevOps. Numa perspectiva geral, foi apresentado como se dá
o ciclo iterativo do SPReaD, com o qual as fases do processo são organizadas de forma
iterativa com o intuito de otimizar o planejamento, modelagem, construção e entrega de
soluções orientadas a serviços.
Por fim, foram apresentadas as etapas desde a Comunicação, fase dedicada ao
levantamento de requisito; Planejamento dedicada a elaboração de um plano de migração;
Modelagem etapa destinada a aplicação de Análise e Design da solução; Construção na
qual foram realizadas atividades que incorporaram importantes técnicas de Reengenharia
de Software para migração de sistemas legados como Decomposição Funcional e Wrapping,
bem como o desenvolvimento de APIs de serviços; e Implantação na qual foram abordadas
técnicas de DevOps como integração contínua, entrega contínua e implantação contínua.
57
5 APLICAÇÃO DO SPREAD NO SISTEMA

UVT
Este capítulo apresenta a aplicação concreta do processo SPReaD para orientar

a Reengenharia do sistema UVT, descrevendo as abordagens adotadas para alcançar os
objetivos pretendidos pela SET. Nesse sentido, as seções a seguir demonstrarão a execução
do processo SPReaD a partir das fases de Modelagem, Construção e Implantação.
Dada sua relevância e por ser uma área “core” da SET, utilizaremos a migração dos
serviços legados da área de Arrecadação como exemplo para demonstrar a execução dessas
fases.
5.1 Modelagem
A fase de Modelagem foi conduzida pela execução da atividade de Análise de
Inventários de Serviço para guiar definição do Inventário de Arrecadação a partir da
delimitação dos serviços candidatos em contextos de negócio. Posteriormente, a Análise
Orientada a Serviço foi executada de modo a guiar a engenharia reversa dos serviços
legados de Débitos, Guias e Prefeituras. Por fim, o Design Orientado a Serviço e
Design de Lógica de Serviço foram executados para auxiliar a re-arquitetura e re-
modelagem desses serviços. Como resultado da etapa de Análise, foram gerados o blueprint
dos Inventários de Serviço de Arrecadação, evidenciando os contextos de Recolhimento
e Repasse; além de uma documentação de software voltada para explanação do escopo
de cada inventário e os seus serviços candidatos. Já o resultado da etapa de Design foi
a especificação dos componentes da arquitetura dos microsserviços de Recolhimento e
de Repasse, através de diagramas estruturais, como diagramas de classe e diagramas de
componentes da UML. Detalhamos cada uma dessas atividades na sequência.
Um vez que todos os serviços legados encontravam-se dentro de um mesmo núcleo
sem fronteiras pré-estabelecidas, a atividade de Análise de Inventários de Serviço foi
executada com o objetivo identificar os contextos de negócio dos serviços legados. Para isso,
a técnica de Contextos Delimitados (EVANS, 2003) foi aplicada no intuito de delimitar a
aplicabilidade de determinados modelos e mantê-los logicamente unificados e consistentes.
Na prática, a partir dos serviços legados foram identificados os Contextos Delimitados e
suas respectivas as capacidades de negócio. Por exemplo, os serviços legados de Débito e de
Guias fazem parte de um conjunto de operações que representam as regras de Recolhimento,
enquanto o serviço legado de Prefeituras representam as regras de Repasse, como ilustra a
Figura 24.
Capítulo 5. Aplicação do SPReaD no Sistema UVT 58
Recolhimento e Repasse são responsabilidades da área de Arrecadação da SET,

que por sua vez possui uma equipe de auditores e analistas de sistemas específicos para
atender demandas dessa área. Tendo em vista que a área de Arrecadação necessita de
um ciclo de desenvolvimento independente para construir e publicar serviços, ambos
os contextos precisaram ser extraídos para uma estrutura na qual contratos e serviços
pudessem ser mantidos de forma autônoma. Essa estrutura formou o Inventário de Serviços
de Arrecadação.
Figura 24 – Definição do Inventário de Serviços de Arrecadação (fonte-própria).
Cada Inventário pode possuir “N” Contextos Delimitados e cada contexto representa
um microsserviço. Por exemplo, a partir do Inventário de Serviço de Arrecadação derivaram
dois microsserviços: o microsserviço de Recolhimento, contendo as capacidades de geração
de Débito e recebimento de Guias; e o microsserviço de Repasse, contendo as capacidades
de gestão de repasses para as prefeituras.
Uma vez que as relações entre Contextos Delimitados assumem várias formas
(ver 4.5.3), foi preciso mapear suas estratégias de comunicação e suas relações de depen-
dência. Nesse sentido, foram mapeadas as comunicações dos contextos de Recolhimento e
Repasse do Inventário de Serviços de Arrecadação com domínios externos, bem como com
serviços internos da SET.
Como ilustra a Figura 25, o contexto de Recolhimento, por exemplo, comunica-se
com domínios externos como instituições bancárias através da estratégia Cliente-Fornecedor,
Figura 25 – Comunicação entre Inventários de Serviços da SET e contextos externos

(fonte-própria).
enviando (upstream) arquivos de remessa e recebendo (downstream) arquivos de retorno,

seguindo as especificações de comunicação estabelecidas entre a SET e as instituições
bancárias. Dentro do domínio da SET, esse mesmo contexto comunica-se com os serviços
de Extrato através de uma relação Conformista, uma vez que esse serviço apenas consome
(downstream) os modelos do contexto de Recolhimento sem alterá-los; e com o serviço
Parcelamento através da estratégia de Parceria, dado que os modelos que transitam
(upstream/downstream) entre esse serviço e o contexto de Recolhimento são definidos
de forma colaborativa por equipes distintas na SET. Por sua vez, a comunicação das
Prefeituras com o contexto de Repasse é intermediada por uma Camada de Anti-
Corrupção, uma vez que os modelos de requisições externas da prefeitura precisam ser
adaptadas para modelos alinhados ao domínio do contexto. Ambos os contextos também se
comunicam através de modelos de domínio comuns expostos por um Núcleo Compartilhado.
Essa organização por contextos e a definição de inventários de serviços possibilitou
que a Análise Orientada a Serviço alcançasse um escopo bem delimitado e possível de
ser realizado dentro de um processo evolucionário. A exemplo disso, dentro do escopo da
Análise Orientada a Serviço, foi aplicado a engenharia reversa dos serviços legados de
Débitos, que revelou que cada página desses serviços possuiam componentes “code-behind”
que acessavam a mesma entidade “Débito”. Revelou também que essa entidade acumulava
amplas responsabilidades, uma vez que ela conhecia todos os contextos de cada origem de
débito, bem como as estruturas de mapeamento relacional com o banco de dados, como
ilustra a Figura 26. Isso forçou o aumento da sua complexidade, linhas de código e o
risco de efeitos colaterais indesejados, uma vez que manutenções nessa entidade envolvia a
manipulação de atributos que eram compartilhados com diversos métodos na entidade.
Figura 26 – Engenharia reversa dos serviço legado de Débitos no escopo de Análise Orien-
tada a Serviço (fonte-própria).
Para lidar com as complexidades identificadas nos serviços legados, o Design

Orientado a Serviço e o Design de Lógica de Serivço, foram executados no intuito e
remodelar esses serviços para atender uma arquitetura de microsserviços, afim de oferecer
serviços com maior autonomia de recurso e com ciclo de desenvolvimento e implantação
mais independentes. Cada microsserviço é formado por uma API e componentes de negócio
que possui as lógicas de serviços e entidades migradas diretamente do serviço legado.
Como ilustra a Figura 27, o microsserviço de Recolhimento foi composto por dois
componentes de negócio: os Serviços de Débito e Serviços de Guias. Já o microsserviço
de Repasse recebeu os componentes de negócio migrados a partir dos serviços legados de
Prefeitura. Uma das capacidades do componente de Serviços de Débito, por exemplo, é
geração de boleto, executada pela lógica do serviço e entidade “Boleto” que contêm o fluxo
de orquestração do serviço e regras de negócio que envolvem essa geração.

Durante a migração desses componentes, algumas lógicas do serviço precisaram ser
“envelopadas” de modo a isolar esse código legado do código migrado. É o caso da lógica
de geração do arquivo de remessa no processo de geração de boleto, cujas estruturas de
software envolvidas nessa lógica já estavam validadas e homologadas pelas instituições
bancárias. Nesse sentido, os riscos e custos envolvidos para migrar essas estruturas são
um possível comprometimento da integridade dos arquivos de remessa e a necessidade
de re-homologação do software. Afim de evitar isso, os componentes responsáveis pela
geração de arquivos de remessa foram “envelopados” em componentes que abstraem as
estruturas de código legado.
Figura 27 – Design dos microsserviços de Recolhimento e Repasse do Inventário de Arre-

cadação (fonte-própria).
Outro custo a ser mensurado é relacionamento dos modelos migrados com as

entidades do banco de dados. Muitas vezes diante da impossibilidade da Reengenharia de
Software alcançar as entidades do banco de dados, é preciso um esforço para mapear os
novos componentes dos serviços migrados com a entidade relacional do banco de dados
legado. Tomando como exemplo o Componente de Negócio de Serviços de Débito do
microsserviço de Recolhimento, ilustrado na Figura 28, o modelo legado “Debito” foi
decomposto nos modelos DEBITO VIEW MODEL, EFD, GIM, ICMS, ITCD, TADF,
ALCOOL, SALINEIRA e BOLETO.
Figura 28 – Inventário de serviços da SET (fonte-própria).
Cada um desses modelos possuem os atributos e lógicas de negócio específicos para

sua execução, bem como mapeia apenas os campos do banco de dados legado que lhe são
necessários. Sendo assim, no caso da migração do sistema UVT, esse foi o limite até o qual
a Reengenharia de Software pode ser aplicada, o que demandou um esforço maior por
parte do time de desenvolvimento para lidar com as discrepâncias geradas entre os modelos
migrados e as entidades do banco de dados. Apesar dessa limitação, esse mapeamento
possivelmente pode ser revisitado no futuro com intuito de se definir estratégias para
migrações que envolvam a Reengenharia do banco de dados.
Por fim, as fachadas do microsserviço são separadas em três camadas distintas:
serviços de Entidade, serviços de Tarefa e serviços Utilitários. Essa distinção proporciona
um melhor controle sobre o consumo de recursos da API, bem como uma melhor organização
da API do serviço.
5.2 Construção
Para garantir que a fase de Codificação produzisse o Inventário de Serviços de
Arrecadação que atendesse as especificações de design, foram adotados durante a execução
da atividade de Desenvolvimento de Serviço um conjunto de padrões do Catálogo de

Padrões de Projetos SOA (ERL et al., 2012). Na atividade de Teste de Serviço, foram
aplicadas técnicas de Teste de Unidade, Testes de Integração e Testes de Aceitação afim
de validar a qualidade e conformidade dos serviços.
Como resultado direto da atividade do Desenvolvimento de Serviço, novas
soluções de software foram criadas e os Serviços de Débito, Serviços de Guias e Serviços
de Prefeituras foram migrados para essa nova estrutura. Além disso, os projetos das
APIs, contendo as fachadas dos serviços, os contratos e configurações necessárias para
implantação autônoma de microsserviços, foram criados para abstrair o acesso aos novos
componentes de negócio. Como resultado dos Testes de Serviço, um conjunto de testes
que representam as validações do Inventário de Serviço de Arrecadação foram gerados e
versionados para usos futuros, tanto no ciclo de implantação, quanto de manutenção de
software.
De modo a ilustrar como se deu a construção dos microsserviços do inventário de
Arrecadação, os pontos a seguir detalham o uso dos padrões do Catálogo de Padrões de
Projetos SOA durante a atividade de Desenvolvimento de Serviço.
Padrão de Inventário de Domínio

Cada Inventário de Serviço foi construído como uma solução de software isolada
utilizando o dotnet Framework, a linguagem C# e Templates de Solução da IDE Visual
Studio. Isso permitiu que os projetos de software e bibliotecas fossem organizados de forma
a representar os Contextos Delimitados do Inventário de serviços. A Figura 29 ilustra o
Template de Solução do Inventário de Arrecadação (Set.Arrecadacao) e a organização de
seus respectivos Contextos Delimitados (Recolhimento e Repasse) em pastas de Solução.
Padrão de Utilitários Transversais aos Domínios

A aplicação desse padrão proporciona o compartilhamento de recursos comuns e
agnósticos aos diversos contextos do domínio. Isso evita a reescrita de código e potencializa
a reutilização de componentes. A Figura 29 ilustra os tipos de recursos compartilhados
associados ao Inventário de Arrecadação como banco de dados, cache, filas, modelos de
domínio e sistemas de arquivos.
Padrão de Normalização de Serviços

Adotando esse padrão, os Inventários de Serviços foram projetados com ênfase no
alinhamento aos seus limites de escopo, respondendo assim, às principais capacidades de
negócio de um determinado Contexto Delimitado. Por exemplo, as capacidades de negócio
do contexto de Arrecadação foram organizadas em Serviços de Débitos e Serviços de Guias.
Figura 29 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicação

Padrão de Utilitários Transversais aos Domínios (fonte-própria).
A Figura 30 ilustra a criação das pastas de solução Serviços de Débitos e Serviços de Guias
dentro da pasta Recolhimento.

do Padrão de Normalização de Serviços (fonte-própria).
Padrão de Fachada de Serviço

No intuito de evitar o acoplamento da lógica de serviço à camada de apresentação
e aos recursos de infraestrutura, foi adotado como recurso para construção da API do
Serviço o Framework Asp.Net Web API, que fornece componentes e estruturas de Fa-
chada que servem como ponto de entrada dos serviços e manipulam as requisições vindas
dos clientes consumidores. A Figura 30 ilustra a criação do projeto Set.Recolhimento.Api,
que oferece mecanismos para construção de Fachadas para os serviços de Débito e de Guias.
Padrão de Segregação de Micro-Tarefas

Esse padrão propõe uma abordagem por meio da qual um conjunto de micros-
serviços é criado para hospedar as micro-tarefas segregadas, cada uma resolvendo um
conjunto distinto de requisições do consumidor. Ou seja, os fluxos de escrita e leitura
são segregados em dois componentes de baixa granularidade. Como consequência disso, a
aplicação é organizada para preservar o escopo funcional granular de um microsserviço e
ganha um grande potencial de escalabilidade. A Figura 31 ilustra a criação dos projetos
Set.Debitos.Query e Set.Debitos.Command na pasta de solução Serviços de Débitos. Esses
projetos recebem as Lógicas e Entidades dos serviços migrados do sistema legado. Além
disso, a compilação desses projetos geram bibliotecas de código (dotnet) que vão junto ao
pacote de publicação.

do Padrão de Segregação de Micro Tarefas (fonte-própria).
Padrão de Camadas de Serviço

O inventário é estruturado em duas ou mais camadas de serviço lógicas, cada
uma das quais é responsável por abstrair a lógica do serviço. Nesse sentido, seguindo
a arquitetura estabelecida, os serviços foram organizados nas camadas de Entidade, de
Tarefa e de Utilitários. Como ilustra a Figura 32, os serviços de débitos foram divididos
nessas camadas dentro do projeto API Set.Recolhimento.Api.
Padrão de Encapsulamento de Legado
Os serviços legados são encapsulados e sua chamada é intermediada por um contrato,
que extrai, encapsula e elimina detalhes técnicos da lógica dos componente legado. A

do Padrão de Camadas de Serviço (fonte-própria).
Figura 33 ilustra o exemplo do componente legado GeradorArquivoRemessaLegacy.cs, cuja

a lógica não foi reescrita, preservando seu código original. De forma a manter essa lógica
legada isolada, o componente legado implementa a Interface IGeradorArquivoRemessa.cs
que é injetada na classe ServicoGeracaoArquivoRemessa.cs, impedindo que o novo Serviço
conheça detalhes de implementação da lógica legada.

do Padrão de Encapsulamento de Legado (fonte-própria).
Testes
Além das técnicas de teste de unidade aplicadas durante o processo de codificação,

foram aplicados testes de integração nos inventários de serviço para validação de recursos
de serviços. Testes de aceitação também foram aplicados para garantir que os contratos
estabelecidos nas APIs estavam em conformidade com a especificação. Para isso, foi
necessário usar uma ferramenta cliente REST que oferecesse suporte a testes de escrita. A
ferramenta escolhida para essa finalidade foi o POSTMAN 1 , que fornece uma interface
gráfica que possibilita a escrita de requisições http, além de criar, gerenciar, documentar e
executar testes sobre as APIs REST.
5.3 Implantação
Visando tornar a Implantação e Manutenção de Serviço mais flexível, a
estrutura de alocação de sistemas da SET foi repensada para favorecer a Entrega contínua
de serviços, bem como o Suporte e Feedback a partir do uso. Nesse sentido, os
serviços de Recolhimento e Repasse foram construídos seguindo padrões de implantação de
microsserviços, afim de serem implantados e mantidos como um produto independentes, de
modo a favorecer seu Monitoramento, a Descoberta de suas capacidades, bem como o
Versionamento e Retirada de Serviço no ambiente de produção.
Para a entrega dos microsserviços, foram configurados na solução de software scripts
para integração de código e compilação de pacotes de implantação de microsserviços no
ambiente de produção: um pacote para o microsserviço de Recolhimento e um pacote de
implantação do microsserviço de Repasse. Para acompanhar o processo de implantação,
foram adotada ferramentas alinhadas com as práticas de DevOps que fornecessem relatórios
contendo logs das etapas de integração e compilação do código-fonte. Além disso, um
portal de Repositório de Serviço foi customizado para que as capacidades dos serviços
em produção fossem passíveis de descoberta. Por fim, foram adotadas ferramentas de
monitoramento para que as equipes de suporte acompanhem o consumo dos recursos de
infraestrutura, bem como para as equipes de gestão entender a dinâmica do negócio através
do consumo dos serviços. Detalhamos cada uma dessas fases na sequência.
Antes da migração, todo o núcleo do sistema UVT precisava ser completamente
compilado para a entrega de novas funcionalidades ou manutenções corretivas no sistema.
Ou seja, até mesmo um pequeno ajuste isolado forçava a recompilação e publicação do
sistema por inteiro. Um fato agravante nesse processo era a necessidade de parada do
sistema, provocada pelo uso inapropriado de mecanismos para lidar com o estado de sessão
e a ausência de distribuição.
Para lidar com essa complexidade e tornar a implantação e manutenção de servi-
ços mais flexível, os componentes de software dos serviços foram desenvolvidos seguindo
1
https://www.getpostman.com/
padrões de implantação de microsserviços, afim de serem mantidos como um produto

independente. Isso foi possível porque cada API é um projeto auto-compilável que en-
capsulam componentes de negócio e demais dependências em pacotes de publicação que
podem ser distribuídos, conteinerizado e replicados em servidores de aplicação web como
IIS, NGinx, Apache etc. A Figura 34 ilustra a capacidade de autonomia e distribuição dos
microsserviços de Recolhimento e Repasse na estrutura de alocação da SET.
Figura 34 – Estrutura de alocação de serviços SET - publicação de microsserviços de

Arrecadação e Prefeituras (fonte-própria).
No caso dos serviços da SET, esse processo de publicação foi suportado por
ferramentas automatizadas que dão suporte a práticas contínuas do DevOps. Esse novo
cenário demandou da equipe da SET uma melhor gerência de configuração para lidar com
integração contínua de código, associada à execução de testes automatizados, para garantir
a segurança e qualidade de implantação dos pacotes entregáveis. Nesse sentido, o processo
de publicação de serviços da SET precisaria ser assistido por ferramentas automatizadas
que dão suporte a práticas contínuas do DevOps.
Para esse propósito, foi adotada a solução TFS (Team Foundation Server) da
Microsoft, que fornece as principais operações vinculadas às práticas de DevOps, como
Integração Contínua (CI), Entrega Contínua (CDE) e Implantação Contínua (CD). Além
disso, o TFS fornece artefatos importantes para a gerência de configuração e é aderente e
extensível às ferramentas de desenvolvimento adotadas pela equipe do SET, como Git,

Jenkis, Visual Studio etc. A Figura 35 ilustra como o TFS apresenta as informações
detalhadas do processo e resultados associados a uma compilação.
Figura 35 – Detalhamento do processo de build no TFS (fonte-própria).
Definidas infraestrutura de alocação e as ferramentas para suporte de implantação

de serviços, o próximo passo foi configurar cada Inventário de serviços (Visual Studio
Solution) para responder a um processo de publicação independente, atendendo assim,
tanto ao princípio de Autonomia da Orientação a serviço, como a uma abordagem tática
para implantar microsserviços. Em relação ao monitoramento, foram adotadas ferramentas
para se obter dados sobre o uso dos serviços implantados no ambiente de produção. As
ferramentas utilizadas para este propósito foram o RabbitMQ, que enfileirava os objetos
de log das diversas instâncias de microsserviços; a pilha de tecnologia ELK (Elastic search,
Logstash e Kibana), uma solução ponta-a-ponta que fornece insights com base em dados
monitorados em tempo real e apresentados de forma iterativa através de dashboards, como
ilustra a Figura 36.
No tocante a Descoberta de serviços, foram gerados um conjunto de Metadados a
partir do código-fonte das APIs, que auxiliaram a formalização de contratos dos Inventários
de serviços e na descoberta das capacidades associadas a eles. O conjunto desses metadados
dos Inventários de serviços foram gerados a partir da especificação OpenAPI pelo suporte
da ferramenta Swagger 2 . Esses metadados são publicados juntos ao seu inventário e
compõem o Repositório de serviços da SET. Esse repositório tem sido uma importante
ferramenta no processo de análise de requisitos de negócio, uma vez que tem possibilitado
2
https://swagger.io/specification/
Figura 36 – Dashboard de monitoramento ativo de serviços da SET (fonte-própria).
aos agentes de negócio incorporar às novas demandas de software, serviços já disponíveis

na camada de serviços da SET, o que tem colaborado com uma melhor gestão dos recursos
de software, diminuído o custo de análise e evitado o retrabalho.
5.4 Consideração Finais

Este capítulo apresentou a aplicação do processo SPReaD, dando ênfase as ati-
vidades de Modelagem, Construção e Implantação. Dada algumas restrições e o caráter
confidencial do projeto, algumas informações e aspectos de implementação dos serviços
foram omitidos e o nome de algumas estruturas alteradas.
71
6 AVALIAÇÃO
Este capítulo apresenta os resultados obtidos através da aplicação do SPReaD

para a modernização do sistema UVT, a fim de avaliar nossa abordagem. Começamos
apresentando alguns resultados quantitativos e na sequência, discutimos os resultados
obtidos com a adoção da orientação a serviços.
6.1 Resultados da Reengenharia de Software aplicada ao Sistema

UVT
Como resultado das atividades de Reengenharia de Software, os aplicativos que
anteriormente estavam acoplados ao sistema legado do UVT, agora têm uma melhor
componentização, favorecendo assim o isolamento das lógicas de negócios das interfaces do
consumidor. Isso representou uma maior portabilidade, reuso e uma melhoria significativa
na manutenção do software. Isso é perceptível quando analisamos as métricas de qualidade
do sistema migrado, obtidas pela uso da ferramenta “NDepend” 1 .
A Tabela 3 apresenta os resultados comparativos da dívida técnica entre o sistema
legado e o sistema migrado em termos de Categorias de correção, do Esforço (em dias,
horas e minutos), de Custo (em R$) e quantidade de Correções 2 .
Tomando por base os resultados obtidos pela análise estática de código, obtivemos
uma redução significativa da dívida técnica no código migrado. Analisando a Tabela
3, podemos notar a redução em 58% na quantidade de correções necessárias. O esforço
necessário para realizar todas essas correções saiu de um patamar de 267 dias para 48 dias,
o que significou uma redução no custo de R$ 107 mil para R$ 19 mil.
Podemos notar ainda que na base de código migrado correções da categoria .Net
Framework / System.Threading já não são mais computados. Esse recurso do framework é
utilizado para criação de processamentos paralelos, geralmente associados a rotinas execu-
tadas em background. A ausência de ocorrências nessa categoria se deu pela transferência
desse tipo de operação dos serviços web para infraestruturas de processamento assíncrono
mais apropriadas.
1
A ferramenta NDepend foi aqui utilizada para demonstrar valores totais da dívida técnica, bem como
categorizar os tipos de correção associados a essa dívida. Sua escolha se deu também pelo fato de se
basear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediate
language (IL) do .net framwork, abarcando assim todas as linguagens da família .net framework (C#,
Visual Basic e F#) sob uma mesma ótica de análise (https://www.ndepend.com/)
2
O esforço é obtido pela relação de número homen-dia para desenvolver 1000 linhas de código. Por
padrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de código
escritas por desenvolvedor em um dia
Capítulo 6. Avaliação 72
Tabela 3 – Dívida técnica do sistema UVT antes e depois da migração.

Código Legado Código Migrado
Categoria Esforço Custo Correções Esforço Custo Correções
.NET Framework
System 6h45min 338 33 1d3h 596 36
Collection 2h10min 108 13 1d 408 49
Globalization 3d1h 1.25K 179 1d6h 742 105
Reflection 6h30min 325 39 1h50min 38 11
InteropServices 35min 29.2 7 30min 25 6
System.Threading 40min 33.3 1 - - -
System.Xml 3h50min 192 23 4h 200 24
Project Rules
Architecture 176d 70.6K 737 8d 3.21k 135
Code Smells 51d 20.6K 273 22d 8.87k 301
Dead Code - - - 6h30min 325 37
Design 4d1h 1.65K 449 4d5h 1.86k 363
Immutability 17d7h 7.17K 889 6h32min 327 53
Naming Conventions 1h25min 70.8 66 3d1h 1.29k 249
OOP Design 8d5h 3.46K 837 2d4h 1.05k 610
Source Organization 3h45min 15 188 7h 350 28
Visibility 2d4h 1.02K 656 4h22min 219 421
Total 267d 107K 4217 48d 19.6k 2428
Registramos também a diminuição expressiva de necessidade de correções na

categoria Architeture de 176 dias para 8 dias. Antes nessa categoria a regra “Camada de
interface do usuário não deve usar diretamente a camada DAL” apresentava 470 ocorrências
(ver 2), marcando uma dívida de 155 dias, sob um custo de R$ 62 mil; agora na base de
código migrada essa regra apresenta apenas uma ocorrência de 32 min, sobre um custo de
R$ 26,7.
Métricas como Code Smells, Immutability, OOP Design, Visibility também apresen-
taram diminuição da dívida. Isso indica que do ponto de vista da Reengenharia a migração
do software foi conduzida de modo a desenvolver código com melhor qualidade. Por outro
lado, métricas do tipo Naming Conventions, Source Organization e Design apresentaram
um relativo aumento. Além dessas métricas, também houve o registro na base de código
migrada, de ocorrências da categoria Dead Code. Isso pode indicar problemas na gestão
do código-fonte migrado, principalmente devido a sua granularidade e decomposição.
Para efeito de comparação dessa granularidade, a Tabela 4 apresenta as métricas de
LoC do sistema UVT antes da migração e dos Inventários de serviços criados no processo
de reengenharia. Nessa tabela, a coluna Avaliação apresenta uma escala de classificação
de sustentabilidade relacionada ao valor do índice de dívida técnica no projeto. Essa
classificação é baseada na relação entre o tamanho da base de código e o tempo estimado

para corrigir todos os problemas identificados. A classificação “A” indica que o custo
de correção pendente é menor que 5% do tempo estimado para correção, enquanto uma
classificação de “C” indica que esse custo está entre 11% e 20%. Já a coluna #LOCs
apresenta o número de linhas de código.
Tabela 4 – Métricas de LoC no código legado Vs código dos Inventários.
Avaliação UVT #LOCs

C Legacy Code 282K
Avaliação Inventário #LOCs

A Arrecadação 43K
A Documentos Fiscais 39K
A Cadastro Fiscal 29K
A Transportadoras 24K
A Fiscalização 41K
A Atendimento 11K
A Autenticidade 22K
A Extrato Fiscal 11K
A Parcelamentos 27K
247K
Podemos notar que o código legado do sistema UVT tem a classificação “C”, por
sua vez, os inventários foram avaliados na classificação “A” na escala de classificação de
sustentabilidade, o que indica uma dívida técnica muito baixa. Também é possível notar
que o número total de LoC em Inventários de serviço (247K) aproxima-se ao número de
LoC do sistema legado (282K). No entanto, como cada Inventário possui um ciclo de
manutenção independente, esse número cai consideravelmente.
Além das métricas de código, foram extraídas do ambiente de produção, métricas
de desempenho dos serviços implantados. A Tabela 5 apresenta alguns indicadores obtidos
por meio da infraestrutura de monitoramento ELK, do desempenho dos serviços. Essas
métricas foram extraídas entre os meses de Junho e Dezembro de 2017, e foram agrupadas
por quantidade total de requisições (#Requests) no mês, tempo médio de resposta (em
milissegundos) de todos os serviços e a quantidade de usuários (#Users) atendidos.
Nesse período, o projeto piloto da UVT foi lançado oficialmente em junho/2017
para uma base de usuários inicial com menos de 1.000 usuários. Em julho/2017 a base de
usuários foi substancialmente expandida (mais de 4.000 usuários), e enquanto o número
de requisições mais que dobrou (484.665 requisições contra 197.458 do período anterior); o
tempo de resposta permaneceu em torno de 200 milissegundos. Em agosto/2017, houve
um pequeno aumento no número de usuários (mais de 5.000 usuários) e no número de
requisições (652.455) com um tempo de resposta médio estável (199,21 milissegundos).
Tabela 5 – Resultados da eficiência de desempenho dos serviços).
Month #Requests Response time (ms) #Users

Jun/2017 197,458 222,00 939
Jul/2017 484,665 184.92 4,079
Aug/2017 652,455 199.21 5,162
Sep/2017 3,889,923 187.69 11,156
Oct/2017 4,039,758 242.07 11,347
Nov/2017 4,286,200 204.58 15,301
Dec/2017 4,447,635 203.31 14,519
Até agosto/2017, tanto o sistema legado quanto o novo sistema estavam ativos
paralelamente. No entanto, em setembro/2017, o sistema antigo foi desativado e a partir
desse momento todos os usuários passaram a consumir serviços no novo sistema UVT.
Dessa forma, tivemos um incremento de 116% na base de usuários (de 5.162 usuários
para 11.156 usuários) e um incremento de 496% no número de requisições (de 652.455
solicitações para 3.889.923 solicitações).
Este foi um momento de apreensão para a equipe, mas apesar do enorme aumento
na carga, o tempo médio de resposta permaneceu estável em torno de 200 milissegundos.
Além disso, os feedbacks recebidos pela equipe era de que havia uma sensação positiva em
relação ao desempenho do sistema como um todo, bem como havia feedbacks de aceitação
das nova interface gráfica do sistema Web e dos aplicativos para dispositivos móveis. Nos
meses seguintes, de outubro/2017 a dezembro/2017, o sistema apresentou um aumento de
557.712 requisições e 4.145 usuários. No entanto, o desempenho permaneceu próximo de
200 milissegundos.
É importante mencionar que entre os meses de junho/2017 e dezembro/2017, a
equipe de operações estava monitorando ativamente todo o ambiente como parte das
atividades da fase de implantação. Isso permitiu a identificação de gargalos na infraestrutura
e a realização de algumas mudanças pró-ativas, como o redimensionamento de recursos de
infraestrutura alocados para bancos de dados e serviços de cache, bem como a inclusão de
novas instâncias de serviços.
6.2 Resultados da adoção de SOA

A aplicação do SPReaD para orientar o projeto de migração de sistemas forneceu a
SET benefícios substanciais como o alcance do Service Aware Level, um dos níveis de ma-
turidade de organizações orientadas a serviços. Ao atingir esse nível, foi confirmado que os
requisitos e metas de negócios relevantes estão definidos e que a base organizacional global
necessária para a iniciativa de SOA está em vigor. Nesse sentido, é possível afirmar que a
SET atingiu esse nível de maturidade uma vez que os Auditores demandantes de solicitação
já apresentam um nível de compreensão sobre a arquitetura de serviços adotada pela SET
em seus projetos, bem como utilizam junto com os analistas de TI o repositório de serviços
como ferramenta para compor em suas requisições serviços agnósticos já existentes na
base de Inventários de serviços. Além desse benefício geral, adoção do SOA trouxe resulta-
dos positivos que impactaram o ciclo de vida de desenvolvimento de software da SET como:
Contrato de Serviço Padronizado: A partir das atividades de modelagem e constru-

ção de serviços, foram adotadas abordagens que promoveram a geração de uma série de
metadados que auxiliam na formalização de contratos dos inventários de serviços e na
descoberta de capacidades associadas a eles.
Monitoramento de serviço em tempo real: A necessidade de monitorar o estado dos

serviços motivou uma mudança nas operações de suporte. Antes da migração, a equipe
de TI trabalhava em uma abordagem reativa aos incidentes gerados pelo sistema. Com a
adoção desse monitoramento ativo, a equipe adotou uma postura mais preventiva, pois
o acesso às informações da operação e às falhas de serviço é monitorado a partir de um
painel de controle, em tempo real.
Monitorando a dinâmica dos negócios: Com o resultado do monitoramento de ser-

viços em tempo real, também foi possível entender a dinâmica do negócio a partir do
consumo de recursos por parte dos auditores, contribuinte, cidadãos etc. Também foi
possível medir o impacto desse uso na infraestrutura computacional do SET.
Alinhamento entre TI e negócios: Como resultado da criação do Repositório de

Serviços, os auditores e desenvolvedores da SET agora possuem uma base na qual podem
localizar serviços agnóstico com os quais podem definir novos processos de negócios em
conjunto. Isso motivou os auditores a redefinirem seus processos de especificação de
requisitos e organização de projetos, o que pode ser observado pela busca por ferramentas
como BPM e o interesse em colaborar com a organização dos serviços através da construção
de um catálogo de serviços da SET.
Os resultados obtidos foram apresentados aos analistas de negócios e à equipe
gerencial da SET, com reações muito positivas por parte da gestão da CODIN (Coordena-
doria de Informática) e do Secretário de Tributação, que foram convidada pelo BID para
a apresentar em um evento regional o projeto de migração do UVT como um dos caso de
sucesso de destaque, pelo cumprimento do prazo e gestão eficiente dos recursos.
O impacto desse projeto, vem transformando o modo da SET planejar e construir
soluções de software, uma vez que o paradigma SOA está consolidado e trouxe benefí-
cios como agilidade da organização em resposta as demandas de mercado, o retorno de
investimento pela reutilização de serviços e a diversificação de fornecedores de tecnologia.
Tudo isso tem impacto na eficiência da arrecadação do estado do Rio Grande do Norte.
Além disso, existem novas demandas para aplicação de SPReaD para outros sistemas de
SET, e um novo projeto está sendo executado (atualmente na fase de modelagem de nosso
processo).
77
7 TRABALHOS RELACIONADOS
Este capítulo apresenta alguns trabalhos da área relacionados aos problemas

explorados nesta pesquisa. Nesse sentido, os trabalhos citados a seguir são relatos sobre
a migração de sistemas legados, aplicação de SOA em contextos de Governo eletrônico
(e-gov), o uso de MSOAM como metodologia para projetos SOA e microsserviços.
7.1 Migração de Sistemas Legados

Por ter características de acoplamento flexível, interfaces publicadas e um modelo
de comunicação padrão, SOA permite que sistemas legados sejam expostos como servi-
ços (LEWIS; SMITH; KONTOGIANNIS, 2010). No entato, qualquer migração específica
requer uma análise concreta da viabilidade, risco e custo envolvidos. Nesse sentido, a
identificação estratégica e a extração de serviços do código legado também são cruciais.
Seguindo essa linha, artigos com relativa aproximação aos primórdios de SOA,
como (REDDY et al., 2009) e (SHEIKH; ABOALSAMH; ALBARRAK, 2011), consideram
os princípios fundamentais da Orientação a serviço como elementos de avaliação para
adequação dos ativos existentes para SOA, além de propor métricas e diretrizes existentes
que suportem a avaliação destes princípios. O objetivo dos pesquisadores é ajudar organi-
zações a compreender os esforços envolvidos em uma migração para SOA, auxiliando-as
na identificação de serviços a partir de ativos existentes. No entanto, essa abordagem é
demasiadamente abstrata e não apontam para instâncias de processos mais próximas da
implementação de serviços.
Por outro lado, artigos mais recentes como os de Baghdadi e Al-bulushi (BAGH-
DADI; AL-BULUSHI, 2015), afirmam que ao adaptar-se para atender demandas de
mercado, muitas empresas dispostas a migrar para SOA precisam enfrentar o desafio de
modernizar suas aplicações legadas. Para o autores, SOA é principalmente sobre reutiliza-
ção de ativos. Nesse sentido, é preciso levar em consideração que: (1) os aplicativos legados
estão em execução sem problemas e executando tarefas críticas, (2) a maioria das regras
de negócios estão acoplados dentro de funções sistêmicas, (3) aplicações legadas foram
construídos com alto custo, e precisamos preservar esses investimentos, e (4) a migração
para SOA pode dar nova vida a aplicativos legados.
Para atender esses pontos, evitar alto custo e preservar os investimento já realizados,
os autores esclarecem que devem ser utilizadas técnicas de wrapping, para estender a
lógica de negócios das aplicações legadas, preservando os investimentos, através da sua
migração para serviços Web e Ambientes SOA. Para isso, os autores categorizam três tipos
Capítulo 7. Trabalhos Relacionados 78
de técnicas para encapsulamento do sistema legado: encapsulamento baseado em sessão,

baseado em transação e baseado em dados. Essas técnicas dizem a respeito às três partes
distintas de um aplicação: apresentação, lógica e dados.
Essa categorização auxilia na decisão de uma técnica de encapsulamento adequada
para lidar com a migração de uma aplicação, bem como reforça a iniciativa de preservar o
custo inicial do seu desenvolvimento. No entanto, ao simplesmente encapsular uma lógica
legada em camadas de serviços, estamos fatalmente encapsulando sua dívida técnica, o
que pode levar essa estrutura para um rápido decaimento de software. Nesse sentido, a
técnica de wrapping aplicada indiscriminadamente pode antecipar a necessidade de novas
migrações e trazer novos custos associados, que poderiam ter sido melhor aplicados se
empregados em um processo de Reengenharia.
Diferente das propostas anteriores, nossa abordagem apresenta um processo que
lida com sistemas legados através da aplicação de Reengenharia de Software, pela qual
as lógicas da aplicação legada são migradas utilizando, além da técnica de wrapping, a
decomposição funcional. Além disso, nossa abordagem leva em consideração o índice de
endividamento técnico e atributos de qualidade necessários para o atendimento da lógica a
ser migrada. Dessa forma, a escolha da estratégia para migrar uma aplicação legada tende
a ser pautada não apenas pela necessidade de exposição de uma capacidade via serviço.
7.2 Aplicação de SOA em contextos de Governo eletrônico (e-gov)

As plataformas E-Government transformam o funcionamento e eficácia dos órgãos
governamentais, uma vez que visam prover interfaces para cidadãos realizar processos
complexos e lentos, bem como transformam o funcionamento e eficácia dos órgãos governa-
mentais (YAN; GUO, 2010). Para isso, E-Government devem focar no Core-Businesses e
abstrai-lo como serviços. Nesse sentido, Yan e Guo (YAN; GUO, 2010) também concordam
que SOA possui potencial para atender as demandas de modernização das aplicações e-gov
pela interoperabilidade entre sistemas legados e novos.
Diante disso, o artigo apresenta uma proposta arquitetural baseado em SOA para
criação de um Government Service Bus(GSB), visando obter uma plataforma uniforme
de serviços e modelos comuns para acessa-los, opera-los e gerência-los em ambientes
heterogêneos. Como resultado os autores propõem um modelo arquitetural baseado em
SOA para soluções e-gov, que engloba três módulos: Runtime platform module, Design
and Development Module and Software Management Module.
O Runtime platform module inclui a camada de implentação de serviço, GSB,
camada de interface de serviço e camada de apresentação. O Design and Development
Module fornece ambiente de desenvolvimento integrado, debugging, assembly, distribuição
and gerenciamento. Já o Software Management Module fornece um ambiente de gestão e
monitoramento das aplicações em produção.

Nesse sentido, a contribuição do artigo é a entrega de uma estrutura arquitetural
que evidencia as responsabilidades do Desenvolvimento, das Operações e Governança de
serviços, para ser aplicada num cenário de aplicações e-gov. Contudo, embora o artigo
delimite claramente os principais atributos técnicos para construção de serviços, a discussão
limita SOA a aplicação de Web services e a arquitetura proposta não expressa a importância
dada ao Core-Businesses.
Nossa abordagem adota SOA não apenas como estratégia arquitetural para constru-
ção de serviços, mas como paradigma que dá suporte à construção de soluções orientadas
a serviços, pelo atendimento dos princípios da orientação a serviços. Além disso, em nossa
pesquisa, ao adotar etapas de análise como Service Inventory Analysis e padrões como
Domain Inventory, nos aproximamos de uma proposta arquitetural que expressa de forma
mais contundente o Core-Businesses.
Já Benany e Beqqali (BENANY; BEQQALI, 2015), afirmam que governo eletrônico
continua sendo reconhecido como uma estratégia chave para melhorar os serviços do governo
e a eficácia das políticas e programas públicos. No entanto, a estrutura governamental
é complexa e fornece o desafio de compreender e desenvolver múltiplas capacidades de
interoperabilidade. Sobe esta ótica, os autores propõem a criação de um framework
arquitetural para interoperabilidade e integração de dados usando SOA. Nesse sentido,
o artigo apresenta uma abordagem SOA para facilitar a comunicação entre as esferas
governamentais.
Para isso, autores propõem um mecanismo de interoperabilidade para E-Government
baseado em Enterprise Architecture Framework (EAF), tendo SOA e BPEL como fer-
ramentas para orquestração de serviços em um Service Bus corporativo denominado de
E-Government Service Bus (eGSB). Os principais componentes do framework proposto
pelos autores são: ESB, Web Services, UDDI, bases de dados, portais de governo eletrônico,
aplicativos de negócios governamentais e aplicativos front-end.
O framework de interoperabilidade proposto pelos autores proporciona uma visão
clara das fronteiras de serviço num contexto governamental, ao delimitar cada esferas
de governo como um componente da arquitetura. Esse aspecto de modelagem facilita
abstrair particularidades de cada esfera de governo, bem como ressalta a necessidade da
padronização de contratos. Nossa abordagem complementa essa visão uma vez que pode
ser vista como uma lente de aumento sobre um desses componentes que representam uma
esfera de governo (no nosso caso governo estadual), revelando processos e práticas de
migração de sistemas e-gov legados para alcançar SOA.
7.3 Uso de MSOAM como metodologia para projetos SOA

Os autores Santika, Suhardi e Yustianto (SANTIKA; SUHARDI; YUSTIANTO,
2017), propõem o uso da Service Engineering Framework, um framework derivado de uma
abordagem que utiliza ferramentas de análise de negócios combinadas com MSOAM, para
evitar atividades redundantes entre a análise de processos de negócios e a metodologia SOA.
Esse framework de processo consiste em quatro fases (identificação, design, desenvolvimento
e implantação) e foi utilizado para construção de serviços de um sistema financeiro
governamental de esfera local (município), para fornecer serviços como concessões de
crédito e emissão de certidões.
Para identificar os serviços candidatos, durante a fase de design de arquitetura, são
seguidas etapas do Service Inventory Analysis da metodologia MSOAM: todo o processo
de negócios é decomposto em sua forma básica para definir operações e serviços candidatos.
Dentre os artefatos apresentados, destaca-se um diagrama arquitetural que define o design
de solução de serviços. Esses serviços estão separados em camada que seguem as definidas
no MSOAM (ERL et al., 2012).
Embora esta pesquisa busque alternativas para a implementação do SOA pelo uso o
MSOAM como abordagem metodológica para a entrega de projetos SOA, esse uso se resume
apenas as fases de análise da metodologia, desprezando as demais fases. Acreditamos que o
MSOAM, como uma metodologia, ainda merece ser revisitado com o propósito de migrar
sistemas legados, dada a sua vasta literatura e disseminação. Sendo assim, nossa proposta
pode ser vista como uma instanciação do MSOAM focada na Reengenharia de Software,
integrando o DevOps para lidar com algumas fases do MSOAM Deployment.
7.4 O uso de microsserviços

Abordagens recentes como microsserviços tem sido apresentadas como alternativas
para o desenvolvimento e entrega de serviços de software. Contudo uma arquitetura de
microsserviços ainda exige uma definição mais aprofundada sobre sua natureza dinâ-
mica (LEON, 2017). Na verdade, contando com serviços independentes com limites claros,
os microsserviços são semelhantes aos da SOA mais tradicional (JAMSHIDI et al., 2018).
Nesse sentido, microsserviços não constituem um novo estilo arquitetural diferente de SOA,
mas qualificam-se como SOA implementado de uma maneira particular com as práticas
atuais de engenharia de software (ZIMMERMANN, 2017). Alinhada a este conceito, nossa
abordagem adota como base os conceitos fundamentados nos padrões de SOA para lidar
com a construção e implantação de serviços, sem deixar de lado os aspectos modernos
de soluções baseadas em microsserviços e DevOps, como padrões, técnicas e ferramentas
associados a estas abordagens.

Este capítulo apresentou trabalhos da área relacionados aos problemas de migração
de sistemas legados, aplicação de SOA em contextos de Governo eletrônico (e-gov), o uso
de MSOAM como metodologia para projetos SOA e microsserviços.
Diferente das abordagens apresentadas, nossa proposta apresenta pontos de avan-
ços significativos, uma vez que é pautada em um processo que lida com as abstrações
da metodologia MSOAM, trazendo pra um patamar mais próximo da implementação,
atividades necessária para conduzir um processo de Reengenharia de Software que tenha
como paradigma alvo SOA, além de lidar com abordagens modernas como microsserviços
e DevOps.
Além disso, nosso processo está alinhada com as demandas da Agenda de Pes-
quisa para Arquitetura Orientada a Serviços (SOA) - Manutenção e Evolução
de Sistemas Orientados a Serviços (LEWIS; SMITH; KONTOGIANNIS, 2010), es-
pecificamente nos tópicos: Processo e Ciclo de Vida, Arquitetura e Design, Implantação,
Manutenção e Evolução, elaborada pela SEI (Software Engineering Institute).
82
8 CONCLUSÃO
Este capítulo conclui esta dissertação, apresentando um apanhado das principais

contribuições e resultados alcançados, seguido por uma breve discussão sobre suas limitações
e indicações de trabalhos futuros.
8.1 Contribuições e Resultados Alcançados

Esta pesquisa apresentou uma instanciação do MSOAM para lidar com as abstrações
associadas ao processo de migração de sistemas legados. De modo a atender as demandas
do projeto de migração do sistema UVT e alcançar uma solução orientada à serviço
moderna e bem-sucedida, a equipe de desenvolvimento da SET conduziu um processo de
Reengenharia de Software tendo SOA como paradigma estratégico, Microsserviços
como tática de implementação e DevOps como prática contínua de integração, entrega,
implantação e monitoramento. Dessa experiência foi extraído um novo processo chamado
SPReaD, que significa Service-oriented Process for Reengineering and DevOps.
Além disso apresentamos também um relato da indústria de um caso de reengenharia
de sistema legado para atender à SOA. O SPReaD foi aplicado para a modernização do
sistema de UVT, um sistema real mantido pela Secretaria de Estado de Tributação do
Rio Grande do Norte (SET), que oferece diferentes serviços para os contribuintes.
A migração do UVT melhorou vários atributos de qualidade, contribuindo para
reduzir a dívida técnica dos sistemas mantidos pelo SET. Como resultado da quebra da
estrutura monolítica do sistema UVT e o desacoplamento das regras de negócios das
camadas de apresentação, há uma maior agilidade e flexibilidade na entrega de serviço, o
que favorece a evolução do negócio. Além disso, o monitoramento em tempo real impactou
positivamente as operações de suporte, uma vez que a equipe de operações agora possui
um postura mais pró-ativa em relação as ocorrências de falha no sistema. A experiência
de migração do UVT em relação aos objetivos alcançados indica um cenário no qual o
paradigma orientado a serviços será adotado em toda a SET.
Desta forma, podemos observar, em um ambiente real, os benefícios da adoção da
Orientação a serviço, como melhorias na governança, o reuso de serviços colaborando com
redução do custo com TI e a possibilidade de diversificação de fornecedores de tecnologia.
Na verdade, a aplicação do SPReaD para orientar o projeto de migração seguindo os
fundamentos adequados da orientação a serviços forneceu benefícios substanciais, com a
SET começando agora a alcançar o nível “Service Aware” dentro dos níveis de maturidade
de organização da orientação a serviços. Por fim, a adoção da Orientação a Serviço
Capítulo 8. Conclusão 83
está pavimentando o caminho para o uso de ferramentas e técnicas de Business Process

Management (BPM), que vem sendo utilizadas pelos Auditores fiscais para promover um
forte alinhamento com a TI e atender demanda da SET em projetos futuros.
8.2 Limitações
Embora tenhamos obtido resultados relevantes com esta pesquisa, temas impor-
tantes e circundantes ao processo SPReaD não foram explorados, como uma melhor
descrição da gestão da dívida técnica dentro do ciclo de desenvolvimento. Dado que as
métricas de dívida técnica foram baseadas no uso apenas de uma abordagem e uma única
ferramenta, e dada a importância da gestão da dívida técnica como um dos objetivos do
SPReaD, é necessário que haja uma expansão desse tema e uma revisão das atividades
a ele relacionadas. Nesse sentido, uma vez que o processo SPReaD, extraído durante a
migração do sistema de UVT, foi aplicado em um único caso, ainda merece ser revisitado
e reaplicado em outros projetos para garantir sua efetividade e um maior amadurecimento
de todas as suas atividades realizadas.
Além disso, alguns problemas identificados no ambiente durante a condução desse
estudo não foram explorados nessa pesquisa. Como exemplo, o comprometimento da
autonomia de um microsserviço devido a relação entre modelos baseados em domínio ricos
versus modelos de dados legado. Esse problema diz respeito ao esforço que times de desen-
volvimento empregam em sistemas migrados para uma arquitetura de microsserviços, ao
tentar compatibilizar uma abordagem baseada em modelos de domínio e a impossibilidade
de migrar uma base de dados legada não escalável. Temas dessa natureza não só exigem
uma maior maturação do problema, como se esbarram em questões culturais, técnicas e
contratuais da SET.
8.3 Trabalhos Futuros

Com base nos resultados obtidos com a migração do sistema UVT, existem agora
novas demandas para aplicação do SPReaD em outros sistemas de SET. Isso proporcionará
os meios para a consolidação e evolução do SPReaD, que tem sido utilizado para promover
um forte alinhamento entre as áreas de negócio e TI. A despeito disso, sistemas legados
utilizados para operações internas como o Extranet2 e SIGAT agora são os novos alvos de
migração e candidatos a aplicação do SPReaD.
Dado o nível de maturidade alcançado pela SET em relação a adoção de soluções
de serviços, novos sistemas vêm sendo desenvolvidos sobre as fundações dos princípios,
padrões e ferramentas que possibilitaram a consolidação de SOA. Como exemplo, podemos
Capítulo 8. Conclusão 84
citar o projeto NFP (Nota Fiscal Potiguar) 1 , um sistema web e um aplicativo móvel
(para as plataformas Android e IOS) que permite o cidadão consultar todas as notas onde
informou seu CPF no momento da compra. Com isso, é necessário que haja um estudo
para avaliar o impacto no SPReaD na estrutura da SET.
Os resultados obtidos ainda motivam pesquisas com foco em automatização nesta
área, como a criação de frameworks para auxiliar a reengenharia de sistemas legados.
Questões relacionadas a aplicação de microsserviços e DevOps como descoberta automática
de serviços, auto-escala de um serviço específico com base em altos volumes de requisição,
modelos e estratégias para migração e decomposição de base de dados legadas, são temas
ainda a serem explorados em futuros trabalhos dentro da estrutura da SET.
Além disso, é necessário também a realização de um estudo sobre o uso de ferramen-
tas e técnicas de BPM em conjunto com o SPReaD. Nesse sentido, pesquisas qualitativas
podem ser conduzidas para explorar a relação entre BPM e SOA no contexto de aplicações
da SET.
1
https://nfp.set.rn.gov.br/
85
REFERÊNCIAS
BAGHDADI, Y.; AL-BULUSHI, W. A guidance process to modernize legacy applications

for soa. Service Oriented Computing and Applications, v. 9, n. 1, p. 41–58, 2015. ISSN
1863-2394. Disponível em: <http://dx.doi.org/10.1007/s11761-013-0137-3>. Citado na
página 77.
BASS, L.; WEBER, I.; ZHU, L. DevOps: A Software Architect’s Perspective. [S.l.]:
Addison-Wesley Professional, 2015. Citado 4 vezes nas páginas 15, 25, 26 e 27.
BENANY, M. M. E.; BEQQALI, O. E. Soa based e-government interoperability. In:

2015 IEEE/ACS 12th International Conference of Computer Systems and Applications
(AICCSA). [S.l.: s.n.], 2015. p. 1–2. Citado na página 79.
BENNETT, K. Legacy systems: Coping with success. IEEE software, IEEE, v. 12, n. 1, p.
19–23, 1995. Citado na página 14.
BENNETT, K. H.; RAJLICH, V. T. Software maintenance and evolution: a roadmap. In:

ACM. Proceedings of the Conference on the Future of Software Engineering. [S.l.], 2000. p.
73–87. Citado na página 14.
ERL, T. Service-oriented architecture (SOA): concepts, technology, and design. [S.l.]:

Prentice Hall, 2005. Citado 2 vezes nas páginas 16 e 27.
ERL, T. Soa: principles of service design. [S.l.]: Prentice Hall Upper Saddle River, 2008.
v. 1. Citado 3 vezes nas páginas 20, 21 e 27.
ERL, T. et al. SOA with REST: Principles, Patterns &Constraints for Building Enterprise
Solutions with REST. 1st. ed. Upper Saddle River, NJ, USA: Prentice Hall Press, 2012.
ISBN 0137012519, 9780137012510. Citado 5 vezes nas páginas 27, 43, 49, 63 e 80.
ERL, T. et al. Next Generation SOA: A Concise Introduction to Service Technology

& Service-Orientation. 1st. ed. Upper Saddle River, NJ, USA: Prentice Hall Press,
2014. ISBN 0133859045, 9780133859041. Citado 5 vezes nas páginas 9, 21, 22, 27 e 50.
ERL, T.; MERSON, P.; STOFFERS, R. Service-Oriented Architecture: Analysis and

Design for Services and Microservices. [S.l.]: Prentice Hall, 2017. Citado 9 vezes nas
páginas 9, 14, 16, 20, 22, 23, 24, 27 e 53.
EVANS. Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston,

MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. ISBN 0321125215.
Citado 7 vezes nas páginas 25, 36, 43, 45, 47, 51 e 57.
FOWLER, S. J. Production-Ready Microservices: Building Standardized Systems Across

an Engineering Organization. 1st. ed. [S.l.]: O’Reilly Media, Inc., 2016. ISBN 1491965975,
9781491965979. Citado 2 vezes nas páginas 25 e 27.
GRUBB, P.; TAKANG, A. A. Software maintenance: concepts and practice. [S.l.]: World
Scientific, 2003. Citado 2 vezes nas páginas 14 e 24.
Referências 86
JAMSHIDI, P. et al. Microservices: The journey so far and challenges ahead. IEEE
Software, v. 35, n. 3, p. 24–35, May 2018. ISSN 0740-7459. Citado 3 vezes nas páginas 15,
25 e 80.
LEON, A. F. Don’t believe the hype! SOA AND MSA are not the same. 2017. Website.
Disponível em: <https://www.academia.edu/34828240/Dont_believe_the_hype_SOA_
AND_MSA_are_not_the_same>. Citado 3 vezes nas páginas 14, 15 e 80.
LEWIS, G.; SMITH, D.; KONTOGIANNIS, K. A Research Agenda for Service-Oriented

Architecture (SOA): Maintenance and Evolution of Service-Oriented Systems. Pittsburgh,
PA, 2010. Disponível em: <http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=
9285>. Citado 2 vezes nas páginas 77 e 81.
MILLETT, S. Patterns, principles and practices of domain-driven design. [S.l.]: John

Wiley & Sons, 2015. Citado 2 vezes nas páginas 41 e 47.
NEWMAN, S. Building Microservices. 1st. ed. [S.l.]: O’Reilly Media, Inc., 2015. ISBN
1491950358, 9781491950357. Citado 3 vezes nas páginas 15, 25 e 27.
PARNAS, D. L. Software aging. In: IEEE. Software Engineering, 1994. Proceedings.

ICSE-16., 16th International Conference on. [S.l.], 1994. p. 279–287. Citado na página 14.
PRESSMAN, R. S.; MAXIM, B. A. Software Engineering: A Practitioner’s Approach, 8a

Edition. [S.l.]: McGraw Hill, 2016. Citado 4 vezes nas páginas 24, 25, 37 e 39.
REDDY, V. K. et al. Evaluating legacy assets in the context of migration to

soa. Software Quality Journal, v. 17, n. 1, p. 51–63, Mar 2009. Disponível em:
<https://doi.org/10.1007/s11219-008-9055-6>. Citado na página 77.
RICHARDS, M. Microservices vs. service-oriented architecture. [S.l.]: O’Reilly Media,

2015. Citado 2 vezes nas páginas 15 e 27.
SANTIKA, H.; SUHARDI; YUSTIANTO, P. Engineering local government financial

service system under good governanceprinciples: Case study: Cimahi government city.
In: 2017 5th International Conference on Information and Communication Technology
(ICoIC7). [S.l.: s.n.], 2017. p. 1–6. Citado na página 80.
SHAHIN, M.; BABAR, M. A.; ZHU, L. Continuous integration, delivery and deployment:
A systematic review on approaches, tools, challenges and practices. IEEE Access, v. 5, p.
3909–3943, 2017. ISSN 2169-3536. Citado 4 vezes nas páginas 9, 16, 25 e 26.
SHEIKH, M. A. A.; ABOALSAMH, H. A.; ALBARRAK, A. Migration of legacy

applications and services to service-oriented architecture (soa). In: The 2011 International
Conference and Workshop on Current Trends in Information Technology (CTIT 11). [S.l.:
s.n.], 2011. p. 137–142. ISSN 2377-5327. Citado na página 77.
TRIPATHY, P.; NAIK, K. Software evolution and maintenance. [S.l.]: John Wiley & Sons,
2014. Citado na página 24.
VERNON, V. Implementing Domain-Driven Design. [S.l.]: Pearson Education, Inc., 2013.

Citado 3 vezes nas páginas 43, 47 e 51.
Referências 87
WAGNER, C. Model-Driven Software Migration: A Methodology: Reengineering, Recovery

and Modernization of Legacy Systems. [S.l.]: Springer Science & Business Media,
2014. Citado 4 vezes nas páginas 9, 24, 25 e 50.
YAN, P.; GUO, J. Researching and designing the architecture of e-government based on
soa. In: 2010 International Conference on E-Business and E-Government. [S.l.: s.n.], 2010.
p. 512–515. Citado na página 78.
ZIMMERMANN, O. Microservices tenets. Computer Science - Research and

Development, v. 32, n. 3, p. 301–310, Jul 2017. ISSN 1865-2042. Disponível em:
<https://doi.org/10.1007/s00450-016-0337-0>. Citado 3 vezes nas páginas 15, 27 e 80.

YanDeLimaJustino DISSERT

Enviado por

Dados do documento

Título original

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

YanDeLimaJustino DISSERT

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Rio Grande do Norte

Instituto Metrópole Digital

Do monolito aos microsserviços:

Yan de Lima Justino

Do monolito aos microsserviços:

Dissertação de Mestrado apresentada ao Pro-

Universidade Federal do Rio Grande do Norte – UFRN

Orientador: Prof. Dr. Carlos Eduardo da Silva

Justino, Yan de Lima.

Dissertação (mestrado) - Universidade Federal do Rio Grande

1. Reengenharia de software - Dissertação. 2. Arquitetura

RN/UF/BCZM CDU 004.415.2.043

Elaborado por Kalline Bezerra da Silva - CRB-15/327

Do monolito aos microsserviços:

Dissertação de Mestrado apresentada ao Pro-

Trabalho aprovado. Brasil, 06 de agosto de 2018:

Prof. Dr. Carlos Eduardo da Silva

Prof. Dr. Eiji Adachi M. Barbosa

Prof. Dr. Nabor Mendonça

Agradeço primeiramente o apoio da a diretoria da IVIA Soluções e Tecnologia nas

Muito obrigado a todos!

Palavras-chave: SOA. Reengenharia de Software. DevOps. Reuso de Software. Evolução

Keywords: SOA. Software Reengineering. DevOps. Software Reuse. Software Evolution

Figura 1 –Diagrama da metodologia de pesquisa aplicada (fonte-própria) . . . . . 18

Tabela 1 – Métricas da dívida técnica do sistema UVT agrupadas pela categorias. 32

3 MIGRAÇÃO DO SISTEMA UVT . . . . . . . . . . . . . . . . . . . 28

5 APLICAÇÃO DO SPREAD NO SISTEMA UVT . . . . . . . . . . . 57

A evolução de software é a capacidade de alterar, de forma rápida e confiável, um

de aceleração e garantias de qualidade. Porém as estratégias tradicionais para se obter

1.1 Problemática e Motivação

aplicado no contexto de migração do sistema UVT da SET/RN. Para alcançar o objetivo

1. Extrair, formalizar e conduzir um processo de Reengenharia de Software que lide

2. Aplicar a implantação de um projeto SOA no contexto de migração do sistema UVT.

3. Avaliar os impactos da reengenharia do sistema UVT e implantação de SOA na

Com base nisso, a principal contribuição deste trabalho é a definição de um

Figura 1 – Diagrama da metodologia de pesquisa aplicada (fonte-própria)

dedicada ao compartilhamento dos resultados (prévios) da pesquisa em workshops internos

1.4 Organização do Documento

Este capítulo apresenta um conjunto de discussões difundidas no âmbito acadêmico

2.1 Orientação a serviço, SOA e MSOAM

Padronização de Contrato: “serviços dentro do mesmo escopo de negócio estão em

Baixo acoplamento: “Os contratos de prestação de serviços impõem baixos requisitos

Abstração: “os contratos de serviço contenham apenas informações essenciais publicadas

de execução subjacente” (ERL, 2008, p. 296);

Baixa Manutenção de Estado: “os serviços minimizam o consumo de recursos ao

Composição: “os serviços são participantes de composição eficazes, independentemente

Figura 2 – Diagrama dos níveis de implementação de SOA (ERL et al., 2014).

Figura 3 – Fases da metodologia MSOAM (ERL; MERSON; STOFFERS, 2017).

Plando de Adoção de SOA: “Durante esse estágio inicial, as decisões de planejamento

Análise de Inventário de Serviço: “Este estágio é dedicado a definir conceitualmente o

Análise Orientada a Serviço: “É geralmente realizada iterativamente, uma vez para

Design Orientado a Serviço: “Estágio dedicado a produção de contratos de serviços em

Design de Lógica de Serviço: “Estágio no qual o contrato de serviço é finalizado antes

Desenvolvimento de Serviço: “Depois de todas as especificações de design terem sido

Implantação e Manutenção de Serviço: “A implantação de serviço representa a im-

Uso e Monitoramento de Serviço: “O monitoramento contínuo do serviço ativo gera

Descoberta de Serviço: “Para garantir a reutilização consistente de serviços agnósticos

Versionamento e Retirada de Serviço: “Depois que um serviço tiver sido implemen-

2.2 Reengenharia de Software

Figura 4 – Modelo geral para Reengenharia de Software (WAGNER, 2014).

2.3 Microsserviços e DevOps

Figura 5 – A relação entre integração, entrega e implantação contínuas (SHAHIN; BABAR;

dade (NEWMAN, 2015). Apesar desses benefícios já serem endereçados e amplamente