Domonolitoaosmicrosserviços ......Palavras-chave:SOA.ReengenhariadeSoftware.DevOps.ReusodeSoftware.Evolução eManutençãodeSoftware.ArquiteturadeSoftware. ... ausência de um processo

Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital

Programa de Pós-graduação em Engenharia de SoftwareMestrado Profissional em Engenharia de Software

Do monolito aos microsserviços:um relato de migração de sistemas legadosda Secretaria de Estado da Tributação do

Rio Grande do Norte

Yan de Lima Justino

Natal-RNAgosto/2018

Yan de Lima Justino

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

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa obtenção do grau de Mestre em Engenhariade 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

Brasil2018

Justino, Yan de Lima. Do monolito aos microsserviços: um relato de migração desistemas legados da Secretaria de Estado da Tributação do RioGrande do Norte / Yan de Lima Justino. - 2018. 87 f.: il.

Dissertação (mestrado) - Universidade Federal do Rio Grandedo 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. ArquiteturaOrientada a Serviço - SOA - Dissertação. 3. SoftwareReengineering - Dissertação. 4. DevOps - Dissertação. I. Silva,Carlos Eduardo da. II. Título.

RN/UF/BCZM CDU 004.415.2.043

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

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

Yan de Lima Justino

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

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa obtenção do grau de Mestre em Engenhariade Software.

Trabalho aprovado. Brasil, 06 de agosto de 2018:

Prof. Dr. Carlos Eduardo da SilvaOrientador

Prof. Dr. Eiji Adachi M. BarbosaExaminador interno

Prof. Dr. Nabor MendonçaExaminador externo

Brasil2018

Este trabalho é dedicado a minha amada esposa Andréia M. Sakakima e a meu amadofilho 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 naspessoas de Márcio Braga, Alexandre Menezes e Edgy Paiva; e a gerência local nas pessoasde Diego Soares dos Santos, Gilberto Coelho de Azevedo Neto e Carolina Cavalcante. Aconcretizaçã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 doSecretário André Horta Melo; do Secretário Adjunto Fernando José Oliveira de Amorim; eda Coordenadora de Informática Adriana Assunção Silva, pela confiança cedida e liberdadede atuação.

Ao meu orientador, Prof. Dr. Carlos Eduardo da Silva, pela paciência, coragem ehoras 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 áreade desenvolvimento da IVIA lotados na SET, que com profissionalismo e compromissoresponderam 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)

RESUMOA Orientação a Serviço fornece um paradigma de projeto baseado em um conjunto demetas estratégicas para o alinhamento entre tecnologia da informação (TI) e negócios,promovendo eficiência, agilidade e produtividade. Nesse contexto, a reengenharia desistemas legados para uma arquitetura orientada a serviços (SOA) pode ser justificada pararesolver problemas como a demanda por interoperabilidade e a necessidade de fornecer umainterface robusta de serviço de alta disponibilidade. No entanto, a implantação de SOA emum ambiente corporativo é uma tarefa desafiadora, pois pode envolver o uso de diferentestécnicas, como a modernização de sistemas com alto endividamento técnico e altos custosde manutenção. Para isso, é necessário um processo que forneça um conjunto apropriado detécnicas que minimizem os riscos e, ao mesmo tempo, garantam a qualidade dos sistemasdurante o processo de migração. Neste sentido, este trabalho apresenta a aplicação deum processo de reengenharia de sistemas legados para suportar a implementação de umprojeto SOA. O SPReaD (Service-oriented process for Reengineering and Devops) é umainstanciação da Mainstream SOA Methodology, com foco na reengenharia de sistemaslegados, integrando os aspectos de DevOps para o direcionamento de SOA. Esse processofoi criado durante um projeto real de reengenharia de software para evolução de sistemaslegados de uma Secretaria de Estado de Tributação. O uso do SPReaD tem apresentadoresultados significativos em relação à conquista de importantes metas de qualidade como apadronização de contratos de serviços para efeitos de interoperabilidade; a gestão da dívidatécnica, tendo em vista uma melhor manutenibilidade e portabilidade de componentes;uma maior escalabilidade e melhora no desempenho como um todo para suportar umagrande carga de requisições.

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

ABSTRACTService-orientation provides a design paradigm based on a set of strategic goals towardsthe alignment between information technology and business, promoting efficiency, agilityand productivity. In this context, the reengineering of legacy systems to a service-orientedarchitecture (SOA) can be justified to solve problems such as the demand for interoperabilityand the need to provide a robust high-availability service interface. However, the deploymentof SOA into an enterprise environment is challenging task, as it may involve the use ofdifferent techniques, such as the modernization of systems with high technical debt andhigh maintenance costs. To this end, a process is required that provides an appropriate setof techniques that minimize risks and at the same time ensure the quality of the systemsduring the migration process. In this sense, this work presents the application of a processfor the reengineering legacy systems to support the implementation of an SOA project.This process has been identified during a real software reengineering project for evolutionof legacy systems of a Secretariat of State for Taxation. The SPReaD (SOA Process forReengineering and DevOps) is an instantiation of the mainstream SOA methodologyfocusing on the reengineering of legacy systems integrating DevOps aspects for targetingSOA. The use of SPReaD have presented significant results regarding the achievement ofimportant quality goals. The use of SPReaD has presented significant results in relationto achieving important quality goals such as the standardization of service contractsfor interoperability purposes; technical debt management, for better maintainability andportability of components; scalability and performance improvement to support a largeload of requests.

Keywords: SOA. Software Reengineering. DevOps. Software Reuse. Software Evolutionand Maintenance. Software Architecture

LISTA DE ILUSTRAÇÕES

Figura 1 – Diagrama da metodologia de pesquisa aplicada (fonte-própria) . . . . . 18Figura 2 – Diagrama dos níveis de implementação de SOA (ERL et al., 2014). . . 21Figura 3 – Fases da metodologia MSOAM (ERL; MERSON; STOFFERS, 2017). . 22Figura 4 – Modelo geral para Reengenharia de Software (WAGNER, 2014). . . . . 25Figura 5 – A relação entre integração, entrega e implantação contínuas (SHAHIN;

BABAR; ZHU, 2017). . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 6 – Arquitetura monolítica (fonte-própria) . . . . . . . . . . . . . . . . . . 29Figura 7 – Estrutura monolítica do sistema UVT (fonte-própria) . . . . . . . . . . 30Figura 8 – Relação das camadas de tecnologias do processo SPReaD (fonte-própria). 35Figura 9 – Estratégia e Táticas do SPReaD (fonte-própria). . . . . . . . . . . . . . 36Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman

e Maxin (fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 11 – Estrutura completa do processo SPReaD (fonte-própria). . . . . . . . . 38Figura 12 – Fase de Comunicação do SPReaD (fonte-própria). . . . . . . . . . . . . 40Figura 13 – Fase de Planejamento do SPReaD (fonte-própria). . . . . . . . . . . . . 42Figura 14 – Fase de Análise do SPReaD (fonte-própria). . . . . . . . . . . . . . . . 44Figura 15 – Fase de Design do SPReaD (fonte-própria). . . . . . . . . . . . . . . . 45Figura 16 – Aplicação da Análise de Inventário de Serviço (fonte-própria). . . . . . 46Figura 17 – Aplicação da Análise Orientada a Serviço (fonte-própria). . . . . . . . . 47Figura 18 – Práticas da Análise Orientada a Serviço (fonte-própria). . . . . . . . . 48Figura 19 – Fase de Construção do SPReaD (fonte-própria). . . . . . . . . . . . . . 50Figura 20 – Fluxo de Migração de Software (fonte-própria). . . . . . . . . . . . . . 52Figura 21 – Fase Etapa de Entrega do SPReaD (fonte-própria). . . . . . . . . . . . 53Figura 22 – Fase de Suporte e Feedback do SPReaD (fonte-própria). . . . . . . . . 54Figura 23 – Instâncias de microsserviços na estrutura de alocação da SET (fonte-

própria). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 24 – Definição do Inventário de Serviços de Arrecadação (fonte-própria). . . 58Figura 25 – Comunicação entre Inventários de Serviços da SET e contextos externos

(fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 26 – Engenharia reversa dos serviço legado de Débitos no escopo de Análise

Orientada a Serviço (fonte-própria). . . . . . . . . . . . . . . . . . . . . 60Figura 27 – Design dos microsserviços de Recolhimento e Repasse do Inventário de

Arrecadação (fonte-própria). . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 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

Figura 30 – Template de Solução Visual Studio do Inventário de Arrecadação -Aplicação do Padrão de Normalização de Serviços (fonte-própria). . . . 64

Figura 31 – Template de Solução Visual Studio do Inventário de Arrecadação -Aplicação do Padrão de Segregação de Micro Tarefas (fonte-própria). . 65

Figura 32 – Template de Solução Visual Studio do Inventário de Arrecadação -Aplicação do Padrão de Camadas de Serviço (fonte-própria). . . . . . . 66

Figura 33 – Template de Solução Visual Studio do Inventário de Arrecadação -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çosde Arrecadação e Prefeituras (fonte-própria). . . . . . . . . . . . . . . . 68

Figura 35 – Detalhamento do processo de build no TFS (fonte-própria). . . . . . . 69Figura 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. 32Tabela 2 – Métricas da dívida técnica da categoria “Architecture”. . . . . . . . . . 32Tabela 3 – Dívida técnica do sistema UVT antes e depois da migração. . . . . . . 72Tabela 4 – Métricas de LoC no código legado Vs código dos Inventários. . . . . . . 73Tabela 5 – Resultados da eficiência de desempenho dos serviços). . . . . . . . . . . 74

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1 Problemática e Motivação . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . 19

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 202.1 Orientação a serviço, SOA e MSOAM . . . . . . . . . . . . . . . . . 202.2 Reengenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Microsserviços e DevOps . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 MIGRAÇÃO DO SISTEMA UVT . . . . . . . . . . . . . . . . . . . 283.1 Arquitetura do Sistema UVT . . . . . . . . . . . . . . . . . . . . . . . 283.2 Processo adhoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 PROCESSO SPREAD . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Extração do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.5 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.5.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.5.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.6 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.6.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.7.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.7.3 Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.8 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 APLICAÇÃO DO SPREAD NO SISTEMA UVT . . . . . . . . . . . 575.1 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.4 Consideração Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.1 Resultados da Reengenharia de Software aplicada ao Sistema UVT 716.2 Resultados da adoção de SOA . . . . . . . . . . . . . . . . . . . . . . 74

7 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 777.1 Migração de Sistemas Legados . . . . . . . . . . . . . . . . . . . . . . 777.2 Aplicação de SOA em contextos de Governo eletrônico (e-gov) . . . 787.3 Uso de MSOAM como metodologia para projetos SOA . . . . . . . 807.4 O uso de microsserviços . . . . . . . . . . . . . . . . . . . . . . . . . . 807.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.1 Contribuições e Resultados Alcançados . . . . . . . . . . . . . . . . . 828.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.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, umsistema de software para adaptá-lo às mudanças do ambiente, aos novos usuários e àsnecessidades do mercado, bem como manter seu desempenho operacional em um nívelsatisfató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úcleodo sistema, realizando apenas adaptações através de técnicas como wrappers de entradase saídas. Consequentemente, os sistemas tornam-se cada vez mais desatualizados e nãoatendem mais às necessidades dos usuários.

Muitas vezes, esses sistemas legados são vitais para os objetivos estratégicos dasorganizaçõ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, elaspodem investir na tentativa de reverter o processo de decaimento do software, ansiando porrestaurar sua capacidade de desenvolvimento, ou podem optar por reestruturar os recursosdo sistema legado em um novo sistema de software, geralmente em tecnologias maisatualizadas, através de um processo de reengenharia. Neste trabalho, nos concentramosnesse último processo.

Um dos principais desafios da Reengenharia de Software é garantir a equivalênciafuncional na nova versão (GRUBB; TAKANG, 2003), ou seja, a nova versão do sistema devefornecer as mesmas funcionalidades existentes do sistema legado, além de poder atender demaneira rápida e confiável novas solicitações. Além disso, o processo de reengenharia deveestar alinhado com os objetivos estratégicos da organização, ajudando a criar processos denegócios revisados e que melhor atendam a esses objetivos.

Em muitos casos, a migração de sistemas legados para SOA (Service-orientedArchitecture) tem sido uma estratégia de reengenharia adotada para se alcançar umconjunto de metas e benefícios que prometem reduzir o custo do portfólio de aplicativos emaximizar o retorno sobre o investimento (ROI) (ERL; MERSON; STOFFERS, 2017). Oseja, embora a aplicação de SOA esteja associada a um esforço inicial, visando benefíciosfuturos, uma vez que o esforço tenha sido alcançado, os benefícios são maiores que ocusto (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 umaarquitetura 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 obterSOA são tidas como opções pesadas e complexas para criação de soluções orientadas aserviço (LEON, 2017; JAMSHIDI et al., 2018). Isso levou a SET a cogitar a adoção deuma arquitetura alinhada com design, padrões e práticas emergentes que abraçasse novastecnologias e favorecessem uma entrega ágil de software.

Vistos como a mais recente alternativa para o design, desenvolvimento e entrega deserviços de software, os microsserviços são uma abordagem de software e de arquiteturade sistemas que se baseia em conceitos bem estabelecidos de modularização e limitestécnicos (JAMSHIDI et al., 2018). Além disso, compartilham dos mesmos princípios dedesign 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 umaevoluçã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 seafaste 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 suanatureza dinâmica (LEON, 2017). Na verdade, contando com serviços independentes comlimites claros, os microsserviços são semelhantes aos da SOA mais tradicional (JAMSHIDIet al., 2018) e, segundo Zimmermann (ZIMMERMANN, 2017), “não constituem um novoestilo arquitetural diferente de SOA, mas qualificam-se como SOA implementado e serviçosrealizados de uma maneira particular com as práticas de engenharia de software de últimageração”.

Dado esse contexto, Este autor, na condição de Arquiteto de Software da IVIASoluções e Tecnologia, empresa contratada para suprir as demandas de desenvolvimentode software da SET, foi escolhido como arquiteto responsável pelo projeto de migraçãodo sistema UVT. Contudo essa migração apresentou um grande desafio de projeto: aausência de um processo de Reengenharia de Software que conduzisse a migração deum sistema monolítico com alto endividamento técnico para Arquitetura Orientada aServiç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 processode migração de sistemas legados para o paradigma orientado a serviços. Essa pesquisa foiconduzida entre os anos de 2016 e 2018 no âmbito da SET concomitante ao projeto demigração do sistema UVT.


1.1 Problemática e MotivaçãoCom 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, bemcomo adquiriu um alto grau de endividamento técnico e, consequentemente, um alto custode manutenção e evolução. Além disso, o desejo da SET por modernização da interfacegráfica e pela disponibilização de serviços tributários em aplicativos móveis, demandaramuma maior interoperabilidade, o que levaria a uma reengenharia de sua arquitetura paraprover serviços de software.

Essa a ausência de um processo de migração de um sistema legado com altoendividamento técnico, baseando-se em uma abordagem de microsserviços tem se mostradoum grande desafio de projeto. Diante do alto nível de abstração e complexidades envolvidasem um processo de Reengenharia de software, a adoção de metodologias já consolidadaspode ser uma resposta no que diz respeito a organizar os esforços relacionados à conduçãodesse projeto.

A despeito disso, a MSOAM (Mainstream SOA Methodology) é um modelo dereferência estabelecido por Thomas Erl como parte de uma metodologia abrangentecaracterizada 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çãoe 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 oMSOAM por si só não é suficiente para lidar com o nível de abstração e complexidadesenvolvidas na reengenharia de um sistema legado.

Ou seja, é preciso instâncias mais concretas que possibilitem a metodologia MSOAMlidar com abordagens modernas como microsserviços e práticas contínuas como as deDevOps. Essas necessidades motivaram a condução de uma pesquisa no âmbito da indústriaque colaborasse com a adoção de SOA a partir da Reengenharia de Software utilizandomicrosserviços como tática para construção de soluções orientadas a serviço e DevOpspara se obter sistemas com melhor garantia de qualidade e monitoramento no processo deintegraçã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 desenvolvimentoque suporte a reengenharia de sistemas legados e práticas contínuas relacionadas ao DevOpstendo como alvo o paradigma SOA.

1.2 ObjetivosO 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 objetivogeral desta pesquisa emergem os seguintes objetivos específicos:

1. Extrair, formalizar e conduzir um processo de Reengenharia de Software que lidecom sistemas legados afim de construir soluções orientadas a serviços e implantá-lasatravé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 naSET/RN.

Com base nisso, a principal contribuição deste trabalho é a definição de umprocesso de Reengenharia de Software orientado a serviços: O Service-oriented Process forReengineering and DevOps (SPReaD). O SPReaD é uma instanciação de um processo deReengenharia 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 (UnidadeVirtual de Tributação) da SET/RN. A aplicação desse processo apresentou resultadossignificativos em relação à conquista de importantes metas do projeto, bem como metasde qualidade de software como manutenibilidade, escalabilidade e desempenho.

1.3 MetodologiaDada 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, ametodologia adotada para a condução desta pesquisa foi a Pesquisa-ação. Essa escolhase 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 emmicrosserviços, dentro de um processo interativo de investigação.

Como ilustrado na Figura 1, a pesquisa foi iniciada com a Escolha do referencialteórico. Nessa fase foram aplicadas a coleta e a leitura de textos da base teórica dosestudos relacionados a SOA, Reengenharia de Software e DevOps, detalhados no capítulo2 . Já a Aplicação do caso foi marcada inicialmente pela execução de um processo adhoc, cuja finalidade foi a identificação de um processo mais organizado. O resultado dissofoi a extração de um processo denominado SPReaD, que foi refinado e documentadodurante as iterações.

Os artefatos gerados durante as iterações do processo SPReaD, foram coletadose 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çãode 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 internosda organização, eventos da indústria e eventos acadêmicos.

No tocante aos eventos da indústria, o tema foi submetido e aceito como palestranos dois principais eventos de desenvolvimento de software que ocorrem no país: a QConSão Paulo, conferência internacional de desenvolvimento de software realizada pela InfoQ1, realizada em maio de 2016; e na TDC 2017 2 (The developer’s conference), conferêncianacional de desenvolvimento de software, realizada em Julho de 2017, também em SãoPaulo.

Já em Julho de 2018 o tema foi submetido e aprovado na TDC 2018, na trilhaarquitetura dotnet, sob o título Reengenharia de sistemas legados para arquitetura deserviços: Metodologia, Processos e técnicas aplicadas ao .Net Framework. O tema foi bemaceito pelo publico-alvo da trilha e proporcionou uma série de discussões, motivadas pelagrande parcela de participantes que atualmente estão passando por algum processo demigração de legado.

No âmbito acadêmico, o tema foi submetido ao EPOCA 2017 (Escola Potiguar deComputação e suas Aplicações), evento regional realizado pela UFRN, no qual este trabalhofoi premiado na categoria Artigos longos; este estudo também foi submetido na trilhaSEIP (Software Engineering in Practice) da 40a edição do ICSE (International ConferenceOn Software Engineering) 3, realizado em 2018 Gotemburgo/Suécia. O trabalho foi aceitocomo poster, e publicado como resumo expandido nos anais do ICSE4. A Divulgação se1 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 feedbacksobtidos eram retro-alimentados na Aplicação do caso, colaborando inicialmente norefinamento do processo e posteriormente na sua formalização.

1.4 Organização do DocumentoEste 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 odesenvolvimento da pesquisa. Em seguida, no Capítulo 3 contextualiza o sistema legadoque foi modernizado por meio da aplicação do SPReaD. Nosso processo orientado a serviçospara reengenharia e DevOps é apresentado no Capítulo 4 e detalhado, no contexto demigração do sistema UVT no Capítulo 5. Uma avaliação deste caso é apresentada noCapítulo 6, enquanto o Capítulo 7 apresenta uma discussão sobre o trabalho relacionado afim 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êmicoe 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 MSOAMUm 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 recursossão agrupados em unidades lógica que representam um contexto funcional. A Orientaçãoa Serviço atua como paradigma de design que compreende essas unidades lógicas comorepresentações de recursos corporativos que podem ser modelados como serviços queapoiam a realização dos objetivos estratégicos da Computação Orientada a Serviçoque são: o aumento da interoperabilidade intrínseca, o aumento da governança, maiordiversificação de fornecedores, maior alinhamento entre negócios e tecnologia, aumentodo 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çãode oito princípios de design:

Padronização de Contrato: “serviços dentro do mesmo escopo de negócio estão emconformidade 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 requisitosde 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 publicadasnos contratos de serviços” (ERL, 2008, p. 214);

Reusabilidade: “os serviços que contêm e expressam uma lógica agnóstica, possam serposicionados 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 aoadiar 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 quaiseles podem ser efetivamente descobertos e interpretados” (ERL, 2008, p. 368);

Composição: “os serviços são participantes de composição eficazes, independentementedo 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 umaarquitetura tecnológica com características distintas, capaz de acomodar comportamentose requisitos que possibilitem alcançar as metas da Computação Orientada a Serviço (ERLet al., 2014). Para Erl (ERL et al., 2014, p. 13), esta arquitetura “é a Service-orientedarchitecture”(SOA), que segundo o autor, “pode existir em quatro escopos ou níveisdiferentes 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ãoclassificados como: Arquitetura de Serviço, que representa a arquitetura de um únicoserviço; Arquitetura de Composição de Serviço, que é a arquitetura de um conjunto deserviç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 formaindependente;e Arquitetura de Empresa Orientada a Serviço que representa a arquiteturada 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 arealização de projetos SOA. Como ilustra a Figura 3, essa metodologia é composta porum conjunto comum de etapas que fazem a transição da concepção de serviços para aimplementaçã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 planejamentofundacional 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ériede fatores” (ERL; MERSON; STOFFERS, 2017, p. 95).

Análise de Inventário de Serviço: “Este estágio é dedicado a definir conceitualmente oinventário de serviços para que os serviços candidatos individuais possam ser identificadose atribuídos a contextos funcionais apropriados em relação uns aos outros. Isso garanteque os serviços (dentro do limite do inventário de serviços) sejam normalizados, pois nãose sobrepõem.” (ERL; MERSON; STOFFERS, 2017, p. 96).

Análise Orientada a Serviço: “É geralmente realizada iterativamente, uma vez paracada processo de negócios. Normalmente, a entrega de um inventário de serviços determinaum escopo que representa um domínio significativo da empresa ou da empresa como umtodo. Todas as iterações de uma Análise Orientada a Serviços pertencem a esse escopo, comcada 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 emapoio 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 antesda arquitetura de serviço subjacente e da lógica que será responsável por executar afuncionalidade 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 sidoconcluí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õesde design personalizados, os desenvolvedores de serviço geralmente terão uma direçãoclara 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 testee garantia de qualidade que os aplicativos tradicionais personalizados. No entanto, alémdisso, há novos requisitos que introduzem a necessidade de métodos e esforços de testeadicionais” (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-sea atualizações ou alterações que precisam ser feitas no ambiente de implementação, comoparte 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 geramé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 (comono 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ósticose recursos de serviço, as equipes de projeto executam um processo de Descoberta de Serviçoseparado 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çõesna lógica de serviço existente ou aumentar o escopo funcional do serviço. Em casos comoesse, uma nova versão da lógica de serviço e / ou do contrato de serviço provavelmenteprecisará 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 maiorcustomização quando incorporadas a ambientes corporativos.

2.2 Reengenharia de SoftwareDependendo do escopo do projeto de SOA, diferentes abordagens podem ser consi-

deradas (ERL; MERSON; STOFFERS, 2017). Por exemplo, técnicas de Reengenhariade Software para modernização de sistemas legados. Segundo Pressman e Maxim (PRES-SMAN; MAXIM, 2016, p. 795), “A Reengenharia de Software abrange as atividades deanálise de inventários, reestruturação de documentos engenharia reversa, reestruturaçãode programas e dados e engenharia direta”. Para Wagner (WAGNER, 2014), ela ofereceuma estratégia de modernização de sistemas pelo atendimento de importantes propósitoscomo portar sistemas para uma nova plataforma, introduzir novas tecnologias, extrairconhecimentos, 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 commaior qualidade e melhor manutenibilidade.

Conforme ilustrado na Figura 4, esse processo pode ser compreendido por trêsfases distintas (TRIPATHY; NAIK, 2014): Abstração, na qual as técnicas de Engenhariareversa (Reverse Engineering) como análise de código, análise de documentos, coleta derequisitos e extração de modelos são aplicados; Refinamento, com o qual as atividadesEngenharia direta (Forward engineering) são aplicadas. Esta fase visa atingir um sistemaalvo com melhor qualidade, em comparação ao sistema original; a fase de Alteração é arelação entre abstração e refinamento para repensar os modelos conceituais, re-especificarrequisitos, re-desenhar e re-codificar uma nova implementação;

Um dos principais desafios desse processo é garantir a equivalência funcional nanova versão (GRUBB; TAKANG, 2003). Para a nova versão do sistema deve fornecer asmesmas funcionalidades existentes do sistema legado, além de poder atender de maneirarápida e confiável novas solicitações.


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

2.3 Microsserviços e DevOpsA 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 entregade serviços (JAMSHIDI et al., 2018). Emergidos de conceitos como Domain-DrivenDesign (EVANS, 2003), Continuous delivery, On-demand virtualization, Infrastructureautomation, Small autonomous teams, System scale (NEWMAN, 2015), microsserviços sebaseiam no conceito bem definido de modularização.

Ou seja, cada microsserviço é implementado e operado como um pequeno sistemaindependente, oferecendo acesso à lógica e dados através de uma interface de rede bemdefinida (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). ParaFowler (FOWLER, 2016), “com a arquitetura de microsserviço, um aplicativo pode serfacilmente dimensionado horizontalmente e verticalmente, a produtividade e a velocidadedo desenvolvedor aumentam drasticamente, e tecnologias antigas podem ser facilmentetrocadas para as mais novas”. Para isso, é preciso a adoção de práticas contínuas, ouseja, integração, entrega, implantação e monitoramento contínuos para permitir que asorganizações liberem novos recursos com freqüência e confiabilidade, garantindo a altaqualidade 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êsmodalidades (SHAHIN; BABAR; ZHU, 2017): Continuous Integration (CI): práticaem que os membros de uma equipe integram o trabalho de desenvolvimento frequentemente;


Continuous Delivery (CDE): prática adotada para a garantir que um aplicativo estejasempre em estado preparado para a produção depois de passar com êxito por testesautomatizados e controles de qualidade; Continuous Deployment (CD): prática deimplantação contínua dá um passo adiante e implanta de forma automática e contínua oaplicativo para ambientes de produção. É importante notar que a prática de CD implicana 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 timede desenvolvimento realizando commits na base de código. Essa ação notifica o servidor deCI que executa o build e os testes automatizados da aplicação. Em seguida, as etapas deCDE e CD são executadas para preparar pacotes de software para a entrega e implantá-losem ambiente de produção. Os resultados de cada etapa são notificados para o time dedesenvolvimento.

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 acordocom Bass (BASS; WEBER; ZHU, 2015, p. 4), “é um conjunto de práticas destinadas areduzir o tempo entre executar uma alteração em um sistema e a mudança ser colocada emproduçã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, quefornece identificação de falhas, identificação da degradação do desempenho, o planejamentodas 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 construirmicroserviços e como implantá-los.

Sendo assim, os benefícios associados a adoção de Microsserviços e DevOps são aconstruçã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 amplamentediscutidos numa perspectiva da Service-Oriented Architecture (ERL, 2008; ZIMMER-MANN, 2017), para Newman (NEWMAN, 2015, p. 8), “há uma falta de consenso sobrecomo fazer SOA bem”.

Talvez essa percepção resida no fato de que literaturas proeminentes de SOAcomo 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 asfornecidas 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çoscomo uma abordagem tática.

Vale salientar que embora os microsserviços e DevOps reflitam filosofias que remetama uma estrutura de pequenas equipes independentes, a maioria das organizações tem umgrande sistema de missão crítica que não é arquitetado dessa maneira. Essas organizaçõesprecisam decidir se desejam migrar suas arquiteturas para arquiteturas de microsserviço equais migrar (BASS; WEBER; ZHU, 2015).

2.4 Considerações FinaisEste 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 SETadotá-los como elementos para alcançar as metas de qualidade esperadas na migração dosistema legado UVT.

28

3 MIGRAÇÃO DO SISTEMA UVT

Uma das principais responsabilidades da administração pública fazendária é aprevenção e a detecção de evasão fiscal. No estado do Rio Grande do Norte, a Secretaria deEstado da Tributação (SET) desenvolve sistemas para apoiar essas atividades, auxiliandoauditores 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 decomunicaçã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 pesquisaacadêmica.

O sistema UVT foi projetado para fornecer serviços “abertos”, que não necessitamde 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çõespúblicas de um cadastro de contribuinte, sem que haja a necessidade de identificação, umavez 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 afazê-lo. São exemplos de serviços da área restrita, a emissão de extratos fiscais e a baixade Documentos Fiscais eletrônicos (DF-e) como a Nota Fiscal eletrônica (NF-e) e LivrosFiscais.

Desenvolvido entre os anos de 2008 e 2010 utilizando a linguagem de programaçãoVisual Basic e o Framework Webforms (ambas da Microsoft), o sistema UVT tinha comoobjetivo técnico migrar para uma única solução algumas funcionalidades que originalmenteforam construídas utilizando tecnologias que naquele momento encontravam-se legadascomo Oracle Forms 2 e ASP (Clássico). A SET esperava com essa migração reunirem 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 UVTSeguindo padrões de desenvolvimento de aplicações web vigentes na época e

utilizando Frameworks web baseados em componentes, o sistema UVT foi construído sobreuma estrutura na qual: a) todos os serviços estavam contidos em um núcleo indecomponível1 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 interestaduale 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 executadoem um único nó de processamento (Single thread); c) havia um acúmulo de múltiplasresponsabilidades como a renderização da camada de apresentação, controle de estado dosobjetos complexos, longos processamentos (síncronos) em background, processamento delógicas de negócio, acesso a banco de dados e outros componentes de infraestrutura, comoilustra a Figura 6.

As escolhas realizadas para o desenvolvimento dessa estrutura trouxeram algumasconsequê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 areinicializaçã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 threadde processamento e seu controle de estado de sessão não foi projetado para funcionar deforma distribuída; efeitos colaterais indesejados em serviços que não foram alteradosdevido a manutenções em áreas comuns do sistema; o baixo desempenho ocasionadopelo uso indiscriminado de alguns recursos do Framework web como o uso gerenciávelde sessão para guarda de objetos muito complexos por muito tempo; por fim, o altoacoplamento pela ausência de isolamento da lógica do serviço ocasionada pelo mal uso deferramentas baseada em conceito RAD (Rapid Application Development), o que permitia


que um desenvolvedor “arrastasse” um componente para uma “página” e lhe atribuísse umcomportamento do serviço em uma classe chamada Code-behind, a qual estava diretamenteassociada 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 entreos componentes de interface visual (página aspx) e a classe do code-behind. Devido esse altoacoplamento na camada de apresentação, o reaproveitamento de serviços tornou-se algoextremamente complexo, dada a total dependência das classes do serviços aos componentesde interface gráfica do framework web.

Outro aspecto negativo, é o compartilhamento de uma mesma entidade de negóciopara todos os serviços de um mesmo contexto do domínio. Esse tipo de abordagem podeprovocar ambiguidades sobre a entidade modelada, efeitos colaterais indesejados peloalto risco de constantes mudanças e uma sobrecarga de responsabilidades, uma vez que aentidade precisa conhecer todos os comportamentos e propriedades de todos os cenáriosdos quais ela participa.

Com o passar dos anos, essa estrutura e a falta de boas práticas de engenharia desoftware, como a ausência de padrões e princípios de design, comprometeram a qualidadedo 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 computacionaise 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 dosistema UVT. Nessa avaliação a equipe decidiu quantificar a dívida técnica do sistema afimde 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 identificaros problemas que afetam a base de código do sistema UVT 3. Essa avaliação revelou umacumulo da dívida técnica e indicou um preocupante quadro de decaimento na qualidadede software. O impacto negativo desse decaimento ficou evidente ao analisar as métricasobtidas.

A Tabela 1 apresenta a apuração dos registros da dívida técnica agrupados porcategorias 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 paradesenvolver 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 quequantificam 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) podemosobservar 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 causamdependência circular e baixa coesão no empacotamento de componentes.

Totalizando esses dados, são 4.217 correções registradas, o que correspondem a 267dias de esforço necessários para realizar as correções do sistemas UVT, o que corresponde aum custo total R$ 107K Hora/Homen. Em termos de severidade, as métricas obtidas pelaferramenta também indicaram que há uma necessidade de esforço para melhorar a qualidadedo 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 de3 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 sebasear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediatelanguage (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. Porpadrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de códigoescritas por desenvolvedor em um dia

5 Os valores configurados para o calculo do custo foram: R$ 50,00 Hora/Homem, jornada de 8 horasdiárias e 240 dias por ano


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

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

Tabela 2 – Métricas da dívida técnica da categoria “Architecture”.

Regras Correções Esforço CustoUI layer shouldn’t use directly DAL layer 470 issues 155d 62.1KUI layer shouldn’t use directly DB types 166 issues 17d 3h 6.96KAvoid namespaces mutually dependent 93 issues 3d 0h 1.24KAvoid namespaces dependency cycles 3 issues 6h 0min 300Namespaces 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ínuae monitoramento durante o ciclo de vida do sistema UVT, o que tornava a implantação deversõ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 comos conflitos gerados durante o desenvolvimento, reduziu a qualidade de verificação docódigo integrado, favorecendo o surgimento de bugs com maior frequência no ambiente deproduçã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çosem 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 UVTexigiu uma revisão da arquitetura do sistema e adequação da infraestrutura, considerandoum re-design com foco no reuso, bem como uma reformulação nas abordagens empregadaspara 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 necessitavapassar pela criação de um conjunto de serviços flexíveis e de fácil manutenção, robustose capazes de responder a cenários de alta disponibilidade, bem como suportar grandescargas de solicitações, garantindo coexistência com os sistemas existentes.

3.2 Processo adhocDada 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 sistemaresponder satisfatoriamente aos requisitos de qualidade esperados como manutenibilidadee 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 nocontexto do projeto PROFISCO-RN 6, financiado pelo BID (Banco Inter-Americano deDesenvolvimento).

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, comvisual moderno e com a possibilidade de inclusão de novos serviços. Além disso, proporcionarmais mobilidade aos usuários internos e externos através do desenvolvimento de aplicaçõespróprias para dispositivos móveis como smartphones e tablets. Numa perspectiva visandobenefícios futuros, a migração do sistema legado UVT é uma oportunidade de lidar comas problemáticas existentes, assim como uma oportunidade de se obter: a) os benefíciosadvindos da implantação bem-sucedida de um projeto SOA (ver 2.1); b) uma melhormanutenibilidade pelo pagamento contínuo da dívida técnica (ver 2.2); bem como, c) osbenefí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 daSET optou pela adoção de um processo de Reengenharia de Software para lidar coma crescente dívida técnica do sistema; SOA para lidar a falta reuso de aplicações e aausência de interoperabilidade; e microsserviços e DevOps para lidar com a inflexibilidadeda arquitetura monolítica e com processos complexos e não automatizado de implantaçãode sistemas. Esse processo inicialmente foi realizado de forma adhoc. No entanto, algumas6 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 desistemas legados num contexto de pesquisa, foram direcionando esse processo para umaformalização que será tratada no Capítulo 4.

3.3 Considerações FinaisNeste 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 suaqualidade. Foram explanadas as problemáticas relacionadas à Dívida Técnica, Ausênciade interoperabilidade, Arquitetura monolítica de sistema e processos de implantaçãoinflexí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çaruma solução orientada à serviço moderna e bem-sucedida, a equipe de desenvolvimentoda SET conduziu um processo de Reengenharia de Software tendo SOA como paradigmaestratégico, microsserviços como tática de implementação e DevOps como prática contínuade integração, entrega, implantação e monitoramento. Dessa experiência, suportada pelapesquisa 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çãodesse processo. Para isso, uma rápida apresentação é descrita na Seção 4.1. Já a seção 4.2apresenta como se deu a extração do processo e explana de forma geral como foi a definiçãode 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 GeralO SPReaD consiste em uma instanciação do MSOAM para lidar com sistemas

monolíticos legados. Esta instanciação é focada na Reengenharia de Software, incorporandoaspectos do DevOps como meio para otimizar a entrega, implantação e monitoramento deserviç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. Paraisso, o SPReaD estabelece um conjunto de medidas: Adotar a Orientação a serviçocomo paradigma capaz guiar a Reengenharia de Software na identificação e modelagem deserviços a partir da engenharia reversa do sistema legado. Aplicar Reengenharia deSoftware para decompor o sistema monolítico em pequenos componentes de serviço de fácilmanutenção, maior autonomia, reuso e capacidade de compor modernas soluções orientadasa serviço; Adotar práticas contínuas para melhorar a qualidade de implantação emonitoramento 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 procederpara migrar sistemas monolíticos legados para uma solução orientada a serviço. Nessesentido, o SPReaD adota os padrões do catálogo SOA para estruturar inventários deserviço afim de construir soluções utilizando tanto abordagens clássicas de SOA comoEnterprise Service Bus (ESB), ou abordagens mais recentes como microsserviços.

Em resposta a um cenário no qual serviços necessitam de mais autonomia nodesenvolvimento e implantação - para satisfazer as exigências das mudanças de negóciocada vez mais dinâmicas - as abordagems escolhidas foram a de microsserviços, DevOps eDomain-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 queserá demonstrado nas práticas relacionadas as atividades do processo.


4.2 Extração do ProcessoPara 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 etapasde um projeto de reengenharia como foco na implantação de SOA. A forma adotadapara alcançar esse processo foi a acomodação do MSOAM no framework de processogenérico descrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016), que compreendecinco fases metodológicas: Comunicação, Planejamento , Modelagem, Construçãoe 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 Designem 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 fasede Comunicação, que recebeu um conjunto de atividades específicas para lidar com acoleta de requisitos e gestão da dívida técnicas, não abarcadas pelo MSOAM. A Figura 10representa as etapas de acomodação das atividades do MSOAM no framework de processodescrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016).

Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman eMaxin (fonte-própria).

O objetivo dessa acomodação foi estabelecer a base de um processo de Reengenhariade Software completo, pelo qual camadas de tecnologias como SOA e DevOps possamse 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 doMSOAM 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 comoEngenharia Reversa e Engenharia Direta, bem como as relacionadas a DevOps comoPrática Contínuas (CI, CDE, CD) e Monitoramento. A identificação de todas essasfases possibilitou ao MSOAM alcançar uma abstração mais próxima da instanciação deum 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 seguinteforma: A fase Comunicação é dedicada à compreensão dos objetivos dos Stakeholderspara o projeto e à coleta de requisitos que auxiliem na compreensão das funcionalidadesde software e atributos de qualidades esperados. Esta fase marca o início do projeto demigração. Por sua vez, a fase de Planejamento envolve a atividade de Plano de Adoçãode 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 organizadasem um plano.

Dado o foco em reengenharia, a fase de Modelagem é dedicada a aplicação dasatividades de Análise e Design para identificar modelos que atendam as necessidades dedesenvolvimento de software. A Análise compreende o uso de Engenharia Reversa para seobter do sistema legado informações que colaborem na identificação de serviços candidatosque compartilem os mesmos limites conceituais. Para isso, são executadas as atividades deAná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 aServiç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 deserviços. A fase Construção é marcada pela implementação das estruturas modeladas noDesign. Para isso, a Codificação e o Teste são conduzidos respectivamente pela atividadesde 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 sistemalegado e as encapsular em novas estruturas.

A fase de Implantação, está dividida em duas partes: na primeira são executadasas atividades de Implantação e Manutenção de Serviço, responsáveis pela entrega desoftware como entidade completa ou como incremento. Essa fase está associada às práticascontínuas do DevOps. Em seguida, a etapa de Suporte e Feedback é conduzida pelasatividades de Uso e Monitoramento de Serviço, Descoberta de Serviço e Versio-namento e Retirada de Serviços, respectivamente para realização do monitoramentocontínuo dos serviços e infraestrutura, descoberta de serviços em seus inventários, bemcomo para identificação da necessidade de alteração na versão do serviço ou sua retiradade um inventário.

As fases do SPReaD, descritas anteriormente são conduzidas num fluxo de umprocesso evolucionário, “um modelo iterativo que possibilita desenvolver versões cada vezmais 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áriodetermina um escopo de uma ou mais iterações, com cada iteração contribuindo com aampliação do blueprint de Inventário de serviços.

Essa visão geral captura a essência do processo SPReaD, aplicado nos últimos anospara modernizar o sistema UVT. As seções a seguir detalharão as atividades, artefatos epraticas 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 processoSPReaD em si. Sendo assim, elas estão aqui descritas no intuito de serem registradas comofases importantes que precisam ser executadas. Já as fases de Modelagem, Construção eImplantação serão apresentadas com um nível maior de profundidade.

4.3 ComunicaçãoA 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 paraatingir 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 stakeholdersdo projeto para se obter informações, experiências e requisitos iniciais que auxiliem nafragmentação do problema em partes menores e mais gerenciáveis. Uma vez que o foco doprocesso é 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çãoque 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 daDívida Técnica Atual do Sistema Legado. Ao Comunicar essa Dívida Técnicaaos stakeholders é fornecido um “retrato” da qualidade atual do sistema legado. O intuitodisso é conscientizar a todos sobre os pontos críticos do sistema e quais as práticas quedevem ser revistas durante o ciclo de desenvolvimento de software. Por fim, os princípios daOrientação a Serviço são utilizados como referência durante a Definição de RequisitosGerais (ver 2.1) para antecipar a identificação de elementos que favoreceram a formalizaçãode contratos, serviços reutilizáveis e composição.

4.3.2 Artefatos

Um dos artefatos produzidos nessa fase é o Documento de Visão Geral, quefornece um conjunto de requisitos para executar a migração do sistema legado, bem comoum 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 comprometidose 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 é sugeridoque as reuniões do Grupo de foco busquem a ampliar o foco em problemas de domínioe 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 softwarecom base em padrões e metodologias consolidados de qualidade (ISO, SQALE), bemcomo apresente as métricas numa linguagem adaptada para os públicos técnicos e denegócio. Por fim, na Coleta de Requisitos Gerais recomenda-se utilizar técnicas queampliem a compreensão dos requisitos como Class Responsibility Collaboration Cards(CRC), Prototipagem rápida, Event Storming, Mapas mentais e de impacto, BusinessModel Canvas etc 1 .

4.4 PlanejamentoEm 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, naperspectiva da equipe de TI, é um guia para organizar o cronograma de desenvolvimento eimplantação, bem como dimensionar quais partes do sistema legado devem ser priorizadas;na perspectiva dos patrocinadores, o planejamento ajuda a estimar os recursos necessáriospara 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 basenesse escopo são definidos os marcos de entrega, os recursos necessários para migrar esseconjunto 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 cronogramageral de projeto, insumos a serem fornecidos, instalações, equipamentos exigidos, localde execução etc. Para isso, deve ser estipulado uma plano de trabalho com as equipesde projeto. Esse plano visa oferecer aos patrocinadores uma visão geral do cronograma e1 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 deReuniã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 entregasincrementais antecipadas. Nesse sentido, deve ser adotado um processo iterativo no qualplanejamentos de curto prazo precisam ser realizado a cada ciclo. O foco desse planejamentoda iteração é organizar e estimar os escopos de trabalho do ciclo, promover um maior focono objetivo da entrega, reduzir custos de mudança durante o processo de reengenhariade software, alinhar a equipes de negócio e de TI, bem como promover entregas maisfrequentes de software. Para realização de um planejamento iterativo, recomenda-se aadoção de ferramentas para gestão de projetos ágeis para gerenciar a migração do sistemalegado 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 (longoprazo) 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 projetosde software como o controle do ciclo de vida do desenvolvimento. De modo a manter umregistro 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 ModelagemEsta 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áliseOrientada a Serviço, para aplicação de Engenharia Reversa; e Design Orientado aServiç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 deInventá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 ContextosDelimitados e Mapeamento de Contexto (EVANS, 2003; VERNON, 2013) para auxiliarna identificação das fronteiras dos componentes de negócio, bem como as estratégias decomposição de serviços.

A Análise Orientada a Serviço consiste na coleta de informações por meio detécnicas de engenharia reversa, envolvendo análise de código legado e documentação desoftware. Como resultado dessa engenharia reversa, uma nova documentação de software(Diagramas de Classe, Diagramas de Entidade Relacional, Casos de Usos etc) é criadapara suportar o processo de engenharia direta.

A Figura 15 ilustra o fluxo das atividades de Design Orientado a Serviço e Design daLógica de Serviço. ODesign Orientado a Serviço tem por objetivo o re-design da soluçãode software com foco na reutilização, bem como uma redefinição da arquitetura de softwarepara expressar as novas características de design. Em suporte ao re-design, os serviços sãocategorizados como: serviços de entidade, que é um serviço reutilizável com contextofuncional agnóstico associado a uma ou mais entidades empresariais relacionadas (ERL etal., 2012); serviço de tarefa, que é um contexto funcional não-agnóstico que geralmentecorresponde à 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 funcionalagnóstico, mas intencionalmente não derivado de especificações e modelos de análise denegócios" (ERL et al., 2012).

Por sua vez, a atividade de Design da Lógica de Serviço, é responsável porcompletar 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 APIsetc.

4.5.2 Artefatos

Como resultado da Análise, são gerados o blueprint dos inventários de serviçoindicando os principais contextos de domínio; e uma documentação de software voltadapara explanação do escopo de cada inventário e os seus serviços candidatos. Uma formapara representar esse blueprint é a criação de um mapa mental, no qual os nós de primeironível podem representar os inventários identificados e o segundo nível os serviços candidatosdesse inventário.

Já o resultado do Design é a especificação dos componentes da arquitetura deserviço em termos da sua modelagem através de diagramas estruturais, como diagramasde classe e diagramas de componentes da UML. Além disso, um conjunto de metadadoscriados juntos ao código-fonte do novo serviço, o que permitirá a construção dos contratosde 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 aabordagem de Contextos Delimitados (EVANS, 2003) a partir da engenharia reversa dosistema legado. Como ilustra a Figura 16, isso se dá pela definição de Contextos Delimitadosa partir do agrupamento dos serviços candidatos que estão logicamente unificados, porémsem fronteiras estabelecidas dentro dos sistema legado. Após essa definição, o ContextoDelimitado deve ser nomeado e extraído para Inventários de Serviço. Cada ContextoDelimitado equivale a um microsserviço, e cada serviço identificado no sistema legadopassa a ser uma capacidade a ser oferecida pelo microsserviço identificado. Um inventáriopode conter um ou mais Contextos Delimitados dependendo do escopo de negócio doInventário.

Identificados os Inventários e seus serviços candidatos, a prática a ser adotadana Análise Orientada a Serviço, seguindo a linha da engenharia reversa, é o inícioda 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 doisfocos de análise: um foco para identificar comportamentos e modelos que satisfazem aslógicas associadas à interface gráfica; e o outro voltado à lógica de serviço, com o qual sãoidentificados as capacidades e entidades de negócio do serviço. Nesse processo, é necessárioidentificar os modelos de software que contenham múltiplas responsabilidades e separá-losem classes distintas, afim isolar capacidades de negócio para obter uma melhor autonomiae manutenção dessas classes.

Em relação às entidades relacionais no banco de dados, a equipe deve levar emconsideração o custo de migração dessas entidades para contextos separados, bem como ocusto de continuar com as entidades compartilhadas. Se por um lado o custo e o riscosenvolvidos na migração de um banco legado podem ser demasiadamente alto, o custode preservar a estrutura de banco de dados exige um maior esforço para mapear essasentidades relacionais nos inventários de serviço. Para isso, é preciso adotar técnicas deMapeamento Objeto Relacional (ORM), e estratégias para lidar com problemas como aconcorrência por uma mesma instância (Tupla) de uma entidade, bem como lidar como versionamento e migração da base de dados num cenário onde o sistemas distribuídosestã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 vezque esses componentes compartilhavam um mesmo núcleo. Ao decompor esse núcleo emContextos Delimitados e distribuí-los em microsserviços, é preciso que haja estratégias decomunicação entre eles. Uma vez que as relações entre Contextos Delimitados assumemvárias formas, o Domain-Driven Design (EVANS, 2003; VERNON, 2013; MILLETT, 2015)provê uma abordagem chamada de Mapeamento de Contextos (Context Mapping), queespecifica o uso de um padrão (DDD relational pattern) para identificação de cinco possíveisestratégias de relacionamento entre Contextos Delimitados:

• camada de anti-corrupção (Anticorruption Layer (ACL)), que representa umacamada de tradução/adaptação de modelos externos (downstream) ao domínio paraa 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 ouadapta-los;

• cliente-fornecedor (Customer-Suplier), que revela a relação entre dois contextosdo domínio no qual o fornecedor realiza o envio de informação (upstream) enquantoo cliente apenas recebe (downstream) essa informação;


• parceria (Partnership) que representa contextos auto-dependentes mas que sãodesenvolvidos de forma separada (sem compartilhamento de código) e que realizamtransferências mútuas (upstream/downstream) de informação;

• núcleo compartilhado (Shared Kernel), que representa dois contextos acopladospelo compartilhamento de um subconjunto de modelos.

De forma a organizar os componentes de uma solução orientada a serviço, a fasede Design do SPReaD propõe um modelo arquitetural no qual os microsserviços possamser construídos baseando-se nos princípios que regem SOA. A Figura 18 ilustra essemodelo 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, oque significa que as interfaces gráficas dos Clientes não estão “presas” às lógicas de serviçosimplantadas no Provedor. Esses serviços residem em instâncias autônomas denominadasde microsserviços, que expõem capacidades de negócio separadas por camadas (serviçosde Entidade , serviços de Tarefa e serviços Utilitários), além de representar uma abstraçãode 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 capacidadesde negócio e detalhes das instâncias de serviços ativas. A Figura 18 expõe a definiçãode como deve ser uma estrutura de um microsserviço, que é composta por uma camadade 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 deServiç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 fluxode escrita denominado Command, no qual reside modelos de domínio e serviços para lidarcom as lógicas de negócio; e um fluxo de Query, no qual residem objetos de transporte dedados (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 paraabstrair recursos de infraestrutura, bem como para lidar com a manutenção de estado deobjetos 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 eespecializado de cada microsserviço, bem como uma melhor componentização das camadasde aplicações e abstração da camada de cross-cutting favorecem a sua portabilidade emanutenibilidade. Por fim, ao transferir o estado de objetos para camadas de infraestruturae adotar estratégias de separação dos fluxos da aplicação em escrita e leitura pela adoção deCQRS, o sistema ganha um potencial para alcançar uma ampla escalabilidade horizontal emelhorar significativamente seu desempenho. Detalhes de implementação dessa arquiteturaserão abordados no Capítulo 5.

4.6 ConstruçãoEsta 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 doMSOAM. Elas também completam o ciclo da engenharia direta dentro do processo daReengenharia 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 fluxodessas 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 deum 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 iniciadona atividade de Design Orientado a Serviço e completada na atividade de Designda Lógica de Serviço.Em seguida, a implementação da lógica do serviço é finalizadae as preocupações com segurança são aplicadas, afim de garantir que apenas os clientesautorizados 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écnicaspodem ser aplicadas: a Decomposição funcional ou Wrapping (WAGNER, 2014). A Decom-posição Funcional é utilizada para alcançar uma melhor separação das responsabilidadesno software legado. Além disso tem o intuito de "quebrar"grandes problemas em problemasmenores e melhor administráveis (ERL et al., 2014). A técnica de Wrapping é utilizadapara encapsular softwares legados com alta complexidade e com um alto custo de migraçãoassociado, 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 pelacriação de uma Fachada do serviço (Façade), que oculta toda a complexidade existente nosoftware.

Além dos testes dentro do processo de desenvolvimento de software, a atividadede Teste de Serviço é executada para garantir que os serviços estejam respondendo aosresultados esperados e estabelecidos no contrato do serviço. Para isso, são aplicados testesem serviços agnósticos para verificar se estão prontos para uso repetitivo, bem como emserviç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. Comoresultado dos Testes de Serviço, um conjunto de testes que representam as validaçõesdo 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 daatividade do Desenvolvimento de Serviço: um fluxo é o de migração de software eum fluxo de construção da API por primeiro. A Figura 20 ilustra os passos do fluxo demigração: primeiro, o serviço legado é decomposto para extrair entidades e lógicas deserviços. Em seguida, são criados componentes de negócio que correspondam a arquiteturade serviços projetada, enquanto que os recursos compartilhados e classes de acesso ainfraestrutura ou serviços externos são envolvidos por wrappers. Por fim, o componentede negócio é envolvido por uma API web responsável por expor as capacidades de cadaserviço através de contratos padronizados.

Em alguns casos, o contrato do serviço precisa ser disponibilizado antes da lógicado serviço em si. Por exemplo, equipes externas contratadas para o desenvolvimento dofront-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 Testesde integridade podem demandar a exposição prévia de contratos. Nesse cenário, a APIweb é disponibilizada antes da construção do componente de negócio.

4.7 ImplantaçãoA 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 noambiente 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. Conformeilustrado na Figura 21, a atividade de Entrega é destinada ao processo de integraçãodo código-fonte (CI), seguida por sua compilação, execução de testes automatizados eda análise estática de código. Quando essas atividades são bem-sucedidas, a entrega dospacotes é realizada no ambiente de homologação (CDE). Por fim, quando a homologaçãodos 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 deServiç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 oestado 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órioindependente 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 deVersionamento e Retirada de Serviço. Para garantir que o controle de versão de umserviço possa ser realizado com o mínimo de impacto e interrupção para os consumidoresde serviços, a atividade de Versionamento e Retirada de Serviço exige a conduçãode 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çãono ambiente de produção. Esse processo se dá de forma automatizada e gera uma sériede relatórios que contém informações sobre as etapas de integração e compilação docódigo-fonte. De forma a verificar e validar a qualidade do software integrado, o relatórioapresenta indicadores sobre a cobertura de código por testes automatizados, bem comocusto 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óriode Serviço é adotado para descobrir onde o serviço está sendo executado e quantasinstâncias estão disponíveis para o consumo. Além disso, o Repositório de serviço expõemas capacidades dos serviços e detalhes do contrato. Para efeito de monitoramento do usodos 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 suportepara o monitoramento da infraestrutura, bem como por equipes de gestão para entender adinâ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 diminuiro acoplamento entre as camadas da aplicação. Com isso, busca-se otimizar o uso derecursos e potencializar a escalabilidade e desempenho do sistema, bem como diminuir osimpactos 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çospodem ser distribuídos em “N” nós de rede. Esses, por sua vez, podem estar organizadosem diferentes zonas de disponibilidade. Isso é possível pela remoção do gerenciamento deEstado de dentro do serviço para mecanismos de “cache”, bem como para componentestransversais (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çaunificado de acesso aos serviços, é preciso que as requisições de clientes sejam intermediadasatravés de Gateway de serviço. Além disso, a distribuição de serviços exige o uso demecanismos que possibilitem a descoberta e monitoramento de serviços publicados emproduçã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, colaboraramcom a redução do custo operacional de TI em relação ao tempo de implantação de novasinstâncias de serviço, bem como a eficiência e tempo de resposta da equipe para corrigirproblemas no sistema.


4.8 Considerações FinaisNeste 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 formaiterativa com o intuito de otimizar o planejamento, modelagem, construção e entrega desoluções orientadas a serviços.

Por fim, foram apresentadas as etapas desde a Comunicação, fase dedicada aolevantamento 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 naqual foram realizadas atividades que incorporaram importantes técnicas de Reengenhariade 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 abordadastécnicas de DevOps como integração contínua, entrega contínua e implantação contínua.

57

5 APLICAÇÃO DO SPREAD NO SISTEMAUVT

Este capítulo apresenta a aplicação concreta do processo SPReaD para orientara Reengenharia do sistema UVT, descrevendo as abordagens adotadas para alcançar osobjetivos pretendidos pela SET. Nesse sentido, as seções a seguir demonstrarão a execuçãodo 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 dosserviços legados da área de Arrecadação como exemplo para demonstrar a execução dessasfases.

5.1 ModelagemA 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 dadelimitação dos serviços candidatos em contextos de negócio. Posteriormente, a AnáliseOrientada a Serviço foi executada de modo a guiar a engenharia reversa dos serviçoslegados de Débitos, Guias e Prefeituras. Por fim, o Design Orientado a Serviço eDesign de Lógica de Serviço foram executados para auxiliar a re-arquitetura e re-modelagem desses serviços. Como resultado da etapa deAnálise, foram gerados o blueprintdos Inventários de Serviço de Arrecadação, evidenciando os contextos de Recolhimentoe Repasse; além de uma documentação de software voltada para explanação do escopode cada inventário e os seus serviços candidatos. Já o resultado da etapa de Design foia especificação dos componentes da arquitetura dos microsserviços de Recolhimento ede Repasse, através de diagramas estruturais, como diagramas de classe e diagramas decomponentes 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úcleosem fronteiras pré-estabelecidas, a atividade de Análise de Inventários de Serviço foiexecutada 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 aaplicabilidade de determinados modelos e mantê-los logicamente unificados e consistentes.Na prática, a partir dos serviços legados foram identificados os Contextos Delimitados esuas respectivas as capacidades de negócio. Por exemplo, os serviços legados de Débito e deGuias 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 aFigura 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 paraatender demandas dessa área. Tendo em vista que a área de Arrecadação necessita deum ciclo de desenvolvimento independente para construir e publicar serviços, ambosos contextos precisaram ser extraídos para uma estrutura na qual contratos e serviçospudessem ser mantidos de forma autônoma. Essa estrutura formou o Inventário de Serviçosde 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 representaum microsserviço. Por exemplo, a partir do Inventário de Serviço de Arrecadação derivaramdois microsserviços: o microsserviço de Recolhimento, contendo as capacidades de geraçãode Débito e recebimento de Guias; e o microsserviço de Repasse, contendo as capacidadesde 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 eRepasse do Inventário de Serviços de Arrecadação com domínios externos, bem como comserviços internos da SET.

Como ilustra a Figura 25, o contexto de Recolhimento, por exemplo, comunica-secom 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çõesbancárias. Dentro do domínio da SET, esse mesmo contexto comunica-se com os serviçosde 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çoParcelamento 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 definidosde forma colaborativa por equipes distintas na SET. Por sua vez, a comunicação dasPrefeituras 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 seradaptadas para modelos alinhados ao domínio do contexto. Ambos os contextos também secomunicam 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 possibilitouque a Análise Orientada a Serviço alcançasse um escopo bem delimitado e possível deser realizado dentro de um processo evolucionário. A exemplo disso, dentro do escopo daAnálise Orientada a Serviço, foi aplicado a engenharia reversa dos serviços legados deDé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 acumulavaamplas responsabilidades, uma vez que ela conhecia todos os contextos de cada origem dedébito, bem como as estruturas de mapeamento relacional com o banco de dados, comoilustra a Figura 26. Isso forçou o aumento da sua complexidade, linhas de código e orisco de efeitos colaterais indesejados, uma vez que manutenções nessa entidade envolvia amanipulaçã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 DesignOrientado a Serviço e o Design de Lógica de Serivço, foram executados no intuito eremodelar esses serviços para atender uma arquitetura de microsserviços, afim de oferecerserviços com maior autonomia de recurso e com ciclo de desenvolvimento e implantaçãomais independentes. Cada microsserviço é formado por uma API e componentes de negócioque 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 doiscomponentes de negócio: os Serviços de Débito e Serviços de Guias. Já o microsserviçode Repasse recebeu os componentes de negócio migrados a partir dos serviços legados dePrefeitura. 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ógicade geração do arquivo de remessa no processo de geração de boleto, cujas estruturas desoftware envolvidas nessa lógica já estavam validadas e homologadas pelas instituiçõesbancárias. Nesse sentido, os riscos e custos envolvidos para migrar essas estruturas sãoum possível comprometimento da integridade dos arquivos de remessa e a necessidadede re-homologação do software. Afim de evitar isso, os componentes responsáveis pelageração de arquivos de remessa foram “envelopados” em componentes que abstraem asestruturas 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 asentidades do banco de dados. Muitas vezes diante da impossibilidade da Reengenharia deSoftware alcançar as entidades do banco de dados, é preciso um esforço para mapear osnovos componentes dos serviços migrados com a entidade relacional do banco de dadoslegado. Tomando como exemplo o Componente de Negócio de Serviços de Débito domicrosserviço de Recolhimento, ilustrado na Figura 28, o modelo legado “Debito” foidecomposto 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 parasua execução, bem como mapeia apenas os campos do banco de dados legado que lhe sãonecessários. Sendo assim, no caso da migração do sistema UVT, esse foi o limite até o quala Reengenharia de Software pode ser aplicada, o que demandou um esforço maior porparte do time de desenvolvimento para lidar com as discrepâncias geradas entre os modelosmigrados e as entidades do banco de dados. Apesar dessa limitação, esse mapeamentopossivelmente pode ser revisitado no futuro com intuito de se definir estratégias paramigraçõ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 proporcionaum melhor controle sobre o consumo de recursos da API, bem como uma melhor organizaçãoda API do serviço.

5.2 ConstruçãoPara 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 dePadrões de Projetos SOA (ERL et al., 2012). Na atividade de Teste de Serviço, foramaplicadas técnicas de Teste de Unidade, Testes de Integração e Testes de Aceitação afimde validar a qualidade e conformidade dos serviços.

Como resultado direto da atividade do Desenvolvimento de Serviço, novassoluções de software foram criadas e os Serviços de Débito, Serviços de Guias e Serviçosde Prefeituras foram migrados para essa nova estrutura. Além disso, os projetos dasAPIs, contendo as fachadas dos serviços, os contratos e configurações necessárias paraimplantação autônoma de microsserviços, foram criados para abstrair o acesso aos novoscomponentes de negócio. Como resultado dos Testes de Serviço, um conjunto de testesque representam as validações do Inventário de Serviço de Arrecadação foram gerados eversionados para usos futuros, tanto no ciclo de implantação, quanto de manutenção desoftware.

De modo a ilustrar como se deu a construção dos microsserviços do inventário deArrecadação, os pontos a seguir detalham o uso dos padrões do Catálogo de Padrões deProjetos 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 isoladautilizando o dotnet Framework, a linguagem C# e Templates de Solução da IDE VisualStudio. Isso permitiu que os projetos de software e bibliotecas fossem organizados de formaa representar os Contextos Delimitados do Inventário de serviços. A Figura 29 ilustra oTemplate de Solução do Inventário de Arrecadação (Set.Arrecadacao) e a organização deseus 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 eagnósticos aos diversos contextos do domínio. Isso evita a reescrita de código e potencializaa reutilização de componentes. A Figura 29 ilustra os tipos de recursos compartilhadosassociados ao Inventário de Arrecadação como banco de dados, cache, filas, modelos dedomí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 noalinhamento aos seus limites de escopo, respondendo assim, às principais capacidades denegócio de um determinado Contexto Delimitado. Por exemplo, as capacidades de negóciodo 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çãoPadrã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 Guiasdentro da pasta Recolhimento.

Figura 30 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicaçãodo 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çãoe aos recursos de infraestrutura, foi adotado como recurso para construção da API doServiç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 vindasdos 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 umconjunto distinto de requisições do consumidor. Ou seja, os fluxos de escrita e leiturasão segregados em dois componentes de baixa granularidade. Como consequência disso, aaplicação é organizada para preservar o escopo funcional granular de um microsserviço eganha um grande potencial de escalabilidade. A Figura 31 ilustra a criação dos projetosSet.Debitos.Query e Set.Debitos.Command na pasta de solução Serviços de Débitos. Essesprojetos recebem as Lógicas e Entidades dos serviços migrados do sistema legado. Alémdisso, a compilação desses projetos geram bibliotecas de código (dotnet) que vão junto aopacote de publicação.

Figura 31 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicaçãodo 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, cadauma das quais é responsável por abstrair a lógica do serviço. Nesse sentido, seguindoa arquitetura estabelecida, os serviços foram organizados nas camadas de Entidade, deTarefa e de Utilitários. Como ilustra a Figura 32, os serviços de débitos foram divididosnessas 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


Figura 32 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicaçãodo Padrão de Camadas de Serviço (fonte-própria).

Figura 33 ilustra o exemplo do componente legado GeradorArquivoRemessaLegacy.cs, cujaa lógica não foi reescrita, preservando seu código original. De forma a manter essa lógicalegada isolada, o componente legado implementa a Interface IGeradorArquivoRemessa.csque é injetada na classe ServicoGeracaoArquivoRemessa.cs, impedindo que o novo Serviçoconheça detalhes de implementação da lógica legada.

Figura 33 – Template de Solução Visual Studio do Inventário de Arrecadação - Aplicaçãodo 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 recursosde serviços. Testes de aceitação também foram aplicados para garantir que os contratosestabelecidos nas APIs estavam em conformidade com a especificação. Para isso, foinecessário usar uma ferramenta cliente REST que oferecesse suporte a testes de escrita. Aferramenta escolhida para essa finalidade foi o POSTMAN 1, que fornece uma interfacegráfica que possibilita a escrita de requisições http, além de criar, gerenciar, documentar eexecutar testes sobre as APIs REST.

5.3 ImplantaçãoVisando 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ínuade serviços, bem como o Suporte e Feedback a partir do uso. Nesse sentido, osserviços de Recolhimento e Repasse foram construídos seguindo padrões de implantação demicrosserviços, afim de serem implantados e mantidos como um produto independentes, demodo a favorecer seu Monitoramento, a Descoberta de suas capacidades, bem como oVersionamento e Retirada de Serviço no ambiente de produção.

Para a entrega dos microsserviços, foram configurados na solução de software scriptspara integração de código e compilação de pacotes de implantação de microsserviços noambiente de produção: um pacote para o microsserviço de Recolhimento e um pacote deimplantaçã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órioscontendo logs das etapas de integração e compilação do código-fonte. Além disso, umportal de Repositório de Serviço foi customizado para que as capacidades dos serviçosem produção fossem passíveis de descoberta. Por fim, foram adotadas ferramentas demonitoramento para que as equipes de suporte acompanhem o consumo dos recursos deinfraestrutura, bem como para as equipes de gestão entender a dinâmica do negócio atravésdo 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 completamentecompilado 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 dosistema por inteiro. Um fato agravante nesse processo era a necessidade de parada dosistema, provocada pelo uso inapropriado de mecanismos para lidar com o estado de sessãoe 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 seguindo1 https://www.getpostman.com/


padrões de implantação de microsserviços, afim de serem mantidos como um produtoindependente. 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 quepodem ser distribuídos, conteinerizado e replicados em servidores de aplicação web comoIIS, NGinx, Apache etc. A Figura 34 ilustra a capacidade de autonomia e distribuição dosmicrosserviç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 deArrecadação e Prefeituras (fonte-própria).

No caso dos serviços da SET, esse processo de publicação foi suportado porferramentas automatizadas que dão suporte a práticas contínuas do DevOps. Esse novocenário demandou da equipe da SET uma melhor gerência de configuração para lidar comintegração contínua de código, associada à execução de testes automatizados, para garantira segurança e qualidade de implantação dos pacotes entregáveis. Nesse sentido, o processode publicação de serviços da SET precisaria ser assistido por ferramentas automatizadasque dão suporte a práticas contínuas do DevOps.

Para esse propósito, foi adotada a solução TFS (Team Foundation Server) daMicrosoft, que fornece as principais operações vinculadas às práticas de DevOps, comoIntegração Contínua (CI), Entrega Contínua (CDE) e Implantação Contínua (CD). Alémdisso, 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çõesdetalhadas 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çãode serviços, o próximo passo foi configurar cada Inventário de serviços (Visual StudioSolution) 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áticapara implantar microsserviços. Em relação ao monitoramento, foram adotadas ferramentaspara se obter dados sobre o uso dos serviços implantados no ambiente de produção. Asferramentas utilizadas para este propósito foram o RabbitMQ, que enfileirava os objetosde 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 dadosmonitorados em tempo real e apresentados de forma iterativa através de dashboards, comoilustra a Figura 36.

No tocante aDescoberta de serviços, foram gerados um conjunto de Metadados apartir do código-fonte das APIs, que auxiliaram a formalização de contratos dos Inventáriosde serviços e na descoberta das capacidades associadas a eles. O conjunto desses metadadosdos Inventários de serviços foram gerados a partir da especificação OpenAPI pelo suporteda ferramenta Swagger 2. Esses metadados são publicados juntos ao seu inventário ecompõem o Repositório de serviços da SET. Esse repositório tem sido uma importanteferramenta no processo de análise de requisitos de negócio, uma vez que tem possibilitado2 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íveisna camada de serviços da SET, o que tem colaborado com uma melhor gestão dos recursosde software, diminuído o custo de análise e evitado o retrabalho.

5.4 Consideração FinaisEste 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áterconfidencial do projeto, algumas informações e aspectos de implementação dos serviçosforam 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 SPReaDpara a modernização do sistema UVT, a fim de avaliar nossa abordagem. Começamosapresentando alguns resultados quantitativos e na sequência, discutimos os resultadosobtidos com a adoção da orientação a serviços.

6.1 Resultados da Reengenharia de Software aplicada ao SistemaUVTComo resultado das atividades de Reengenharia de Software, os aplicativos que

anteriormente estavam acoplados ao sistema legado do UVT, agora têm uma melhorcomponentização, favorecendo assim o isolamento das lógicas de negócios das interfaces doconsumidor. Isso representou uma maior portabilidade, reuso e uma melhoria significativana manutenção do software. Isso é perceptível quando analisamos as métricas de qualidadedo sistema migrado, obtidas pela uso da ferramenta “NDepend” 1.

A Tabela 3 apresenta os resultados comparativos da dívida técnica entre o sistemalegado 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, obtivemosuma redução significativa da dívida técnica no código migrado. Analisando a Tabela3, podemos notar a redução em 58% na quantidade de correções necessárias. O esforçonecessá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 .NetFramework / 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ênciadesse tipo de operação dos serviços web para infraestruturas de processamento assíncronomais 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 sebasear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediatelanguage (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. Porpadrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de códigoescritas 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 MigradoCategoria Esforço Custo Correções Esforço Custo Correções.NET FrameworkSystem 6h45min 338 33 1d3h 596 36Collection 2h10min 108 13 1d 408 49Globalization 3d1h 1.25K 179 1d6h 742 105Reflection 6h30min 325 39 1h50min 38 11InteropServices 35min 29.2 7 30min 25 6System.Threading 40min 33.3 1 - - -System.Xml 3h50min 192 23 4h 200 24Project RulesArchitecture 176d 70.6K 737 8d 3.21k 135Code Smells 51d 20.6K 273 22d 8.87k 301Dead Code - - - 6h30min 325 37Design 4d1h 1.65K 449 4d5h 1.86k 363Immutability 17d7h 7.17K 889 6h32min 327 53Naming Conventions 1h25min 70.8 66 3d1h 1.29k 249OOP Design 8d5h 3.46K 837 2d4h 1.05k 610Source Organization 3h45min 15 188 7h 350 28Visibility 2d4h 1.02K 656 4h22min 219 421Total 267d 107K 4217 48d 19.6k 2428

Registramos também a diminuição expressiva de necessidade de correções nacategoria Architeture de 176 dias para 8 dias. Antes nessa categoria a regra “Camada deinterface 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 decódigo migrada essa regra apresenta apenas uma ocorrência de 32 min, sobre um custo deR$ 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çãodo software foi conduzida de modo a desenvolver código com melhor qualidade. Por outrolado, métricas do tipo Naming Conventions, Source Organization e Design apresentaramum relativo aumento. Além dessas métricas, também houve o registro na base de códigomigrada, de ocorrências da categoria Dead Code. Isso pode indicar problemas na gestãodo 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 deLoC do sistema UVT antes da migração e dos Inventários de serviços criados no processode reengenharia. Nessa tabela, a coluna Avaliação apresenta uma escala de classificaçãode 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 estimadopara corrigir todos os problemas identificados. A classificação “A” indica que o custode correção pendente é menor que 5% do tempo estimado para correção, enquanto umaclassificação de “C” indica que esse custo está entre 11% e 20%. Já a coluna #LOCsapresenta 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 #LOCsC Legacy Code 282K

Avaliação Inventário #LOCsA Arrecadação 43KA Documentos Fiscais 39KA Cadastro Fiscal 29KA Transportadoras 24KA Fiscalização 41KA Atendimento 11KA Autenticidade 22KA Extrato Fiscal 11KA Parcelamentos 27K

247K

Podemos notar que o código legado do sistema UVT tem a classificação “C”, porsua vez, os inventários foram avaliados na classificação “A” na escala de classificação desustentabilidade, o que indica uma dívida técnica muito baixa. Também é possível notarque o número total de LoC em Inventários de serviço (247K) aproxima-se ao número deLoC do sistema legado (282K). No entanto, como cada Inventário possui um ciclo demanutenção independente, esse número cai consideravelmente.

Além das métricas de código, foram extraídas do ambiente de produção, métricasde desempenho dos serviços implantados. A Tabela 5 apresenta alguns indicadores obtidospor meio da infraestrutura de monitoramento ELK, do desempenho dos serviços. Essasmétricas foram extraídas entre os meses de Junho e Dezembro de 2017, e foram agrupadaspor quantidade total de requisições (#Requests) no mês, tempo médio de resposta (emmilissegundos) 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/2017para uma base de usuários inicial com menos de 1.000 usuários. Em julho/2017 a base deusuários foi substancialmente expandida (mais de 4.000 usuários), e enquanto o númerode requisições mais que dobrou (484.665 requisições contra 197.458 do período anterior); otempo de resposta permaneceu em torno de 200 milissegundos. Em agosto/2017, houveum pequeno aumento no número de usuários (mais de 5.000 usuários) e no número derequisiçõ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) #UsersJun/2017 197,458 222,00 939Jul/2017 484,665 184.92 4,079Aug/2017 652,455 199.21 5,162Sep/2017 3,889,923 187.69 11,156Oct/2017 4,039,758 242.07 11,347Nov/2017 4,286,200 204.58 15,301Dec/2017 4,447,635 203.31 14,519

Até agosto/2017, tanto o sistema legado quanto o novo sistema estavam ativosparalelamente. No entanto, em setembro/2017, o sistema antigo foi desativado e a partirdesse 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áriospara 11.156 usuários) e um incremento de 496% no número de requisições (de 652.455solicitações para 3.889.923 solicitações).

Este foi um momento de apreensão para a equipe, mas apesar do enorme aumentona 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 emrelação ao desempenho do sistema como um todo, bem como havia feedbacks de aceitaçãodas nova interface gráfica do sistema Web e dos aplicativos para dispositivos móveis. Nosmeses seguintes, de outubro/2017 a dezembro/2017, o sistema apresentou um aumento de557.712 requisições e 4.145 usuários. No entanto, o desempenho permaneceu próximo de200 milissegundos.

É importante mencionar que entre os meses de junho/2017 e dezembro/2017, aequipe de operações estava monitorando ativamente todo o ambiente como parte dasatividades da fase de implantação. Isso permitiu a identificação de gargalos na infraestruturae a realização de algumas mudanças pró-ativas, como o redimensionamento de recursos deinfraestrutura alocados para bancos de dados e serviços de cache, bem como a inclusão denovas instâncias de serviços.

6.2 Resultados da adoção de SOAA 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 osrequisitos e metas de negócios relevantes estão definidos e que a base organizacional globalnecessá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çãojá apresentam um nível de compreensão sobre a arquitetura de serviços adotada pela SETem seus projetos, bem como utilizam junto com os analistas de TI o repositório de serviçoscomo ferramenta para compor em suas requisições serviços agnósticos já existentes nabase 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 demetadados que auxiliam na formalização de contratos dos inventários de serviços e nadescoberta de capacidades associadas a eles.

Monitoramento de serviço em tempo real: A necessidade de monitorar o estado dosserviços motivou uma mudança nas operações de suporte. Antes da migração, a equipede TI trabalhava em uma abordagem reativa aos incidentes gerados pelo sistema. Com aadoção desse monitoramento ativo, a equipe adotou uma postura mais preventiva, poiso acesso às informações da operação e às falhas de serviço é monitorado a partir de umpainel 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 doconsumo de recursos por parte dos auditores, contribuinte, cidadãos etc. Também foipossí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 deServiços, os auditores e desenvolvedores da SET agora possuem uma base na qual podemlocalizar serviços agnóstico com os quais podem definir novos processos de negócios emconjunto. Isso motivou os auditores a redefinirem seus processos de especificação derequisitos e organização de projetos, o que pode ser observado pela busca por ferramentascomo BPM e o interesse em colaborar com a organização dos serviços através da construçãode um catálogo de serviços da SET.

Os resultados obtidos foram apresentados aos analistas de negócios e à equipegerencial 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 paraa apresentar em um evento regional o projeto de migração do UVT como um dos caso desucesso 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 deinvestimento 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 deSET, e um novo projeto está sendo executado (atualmente na fase de modelagem de nossoprocesso).

77

7 TRABALHOS RELACIONADOS

Este capítulo apresenta alguns trabalhos da área relacionados aos problemasexplorados nesta pesquisa. Nesse sentido, os trabalhos citados a seguir são relatos sobrea 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 LegadosPor 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íficarequer uma análise concreta da viabilidade, risco e custo envolvidos. Nesse sentido, aidentificaçã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), consideramos princípios fundamentais da Orientação a serviço como elementos de avaliação paraadequação dos ativos existentes para SOA, além de propor métricas e diretrizes existentesque 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-asna 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 daimplementaçã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 demercado, muitas empresas dispostas a migrar para SOA precisam enfrentar o desafio demodernizar 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 legadosestão em execução sem problemas e executando tarefas críticas, (2) a maioria das regrasde negócios estão acoplados dentro de funções sistêmicas, (3) aplicações legadas foramconstruídos com alto custo, e precisamos preservar esses investimentos, e (4) a migraçãopara 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 alógica de negócios das aplicações legadas, preservando os investimentos, através da suamigraçã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 partesdistintas de um aplicação: apresentação, lógica e dados.

Essa categorização auxilia na decisão de uma técnica de encapsulamento adequadapara lidar com a migração de uma aplicação, bem como reforça a iniciativa de preservar ocusto inicial do seu desenvolvimento. No entanto, ao simplesmente encapsular uma lógicalegada em camadas de serviços, estamos fatalmente encapsulando sua dívida técnica, oque pode levar essa estrutura para um rápido decaimento de software. Nesse sentido, atécnica de wrapping aplicada indiscriminadamente pode antecipar a necessidade de novasmigrações e trazer novos custos associados, que poderiam ter sido melhor aplicados seempregados em um processo de Reengenharia.

Diferente das propostas anteriores, nossa abordagem apresenta um processo quelida com sistemas legados através da aplicação de Reengenharia de Software, pela qualas lógicas da aplicação legada são migradas utilizando, além da técnica de wrapping, adecomposição funcional. Além disso, nossa abordagem leva em consideração o índice deendividamento técnico e atributos de qualidade necessários para o atendimento da lógica aser migrada. Dessa forma, a escolha da estratégia para migrar uma aplicação legada tendea 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 processoscomplexos 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 eabstrai-lo como serviços. Nesse sentido, Yan e Guo (YAN; GUO, 2010) também concordamque SOA possui potencial para atender as demandas de modernização das aplicações e-govpela interoperabilidade entre sistemas legados e novos.

Diante disso, o artigo apresenta uma proposta arquitetural baseado em SOA paracriação de um Government Service Bus(GSB), visando obter uma plataforma uniformede serviços e modelos comuns para acessa-los, opera-los e gerência-los em ambientesheterogêneos. Como resultado os autores propõem um modelo arquitetural baseado emSOA para soluções e-gov, que engloba três módulos: Runtime platform module, Designand 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 DevelopmentModule fornece ambiente de desenvolvimento integrado, debugging, assembly, distribuiçãoand 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 arquiteturalque evidencia as responsabilidades do Desenvolvimento, das Operações e Governança deserviços, para ser aplicada num cenário de aplicações e-gov. Contudo, embora o artigodelimite claramente os principais atributos técnicos para construção de serviços, a discussãolimita SOA a aplicação de Web services e a arquitetura proposta não expressa a importânciadada 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 orientadasa serviços, pelo atendimento dos princípios da orientação a serviços. Além disso, em nossapesquisa, ao adotar etapas de análise como Service Inventory Analysis e padrões comoDomain Inventory, nos aproximamos de uma proposta arquitetural que expressa de formamais contundente o Core-Businesses.

Já Benany e Beqqali (BENANY; BEQQALI, 2015), afirmam que governo eletrônicocontinua sendo reconhecido como uma estratégia chave para melhorar os serviços do governoe 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 deinteroperabilidade. Sobe esta ótica, os autores propõem a criação de um frameworkarquitetural para interoperabilidade e integração de dados usando SOA. Nesse sentido,o artigo apresenta uma abordagem SOA para facilitar a comunicação entre as esferasgovernamentais.

Para isso, autores propõem ummecanismo de interoperabilidade para E-Governmentbaseado em Enterprise Architecture Framework (EAF), tendo SOA e BPEL como fer-ramentas para orquestração de serviços em um Service Bus corporativo denominado deE-Government Service Bus (eGSB). Os principais componentes do framework propostopelos 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ãoclara das fronteiras de serviço num contexto governamental, ao delimitar cada esferasde governo como um componente da arquitetura. Esse aspecto de modelagem facilitaabstrair particularidades de cada esfera de governo, bem como ressalta a necessidade dapadronização de contratos. Nossa abordagem complementa essa visão uma vez que podeser vista como uma lente de aumento sobre um desses componentes que representam umaesfera de governo (no nosso caso governo estadual), revelando processos e práticas demigração de sistemas e-gov legados para alcançar SOA.


7.3 Uso de MSOAM como metodologia para projetos SOAOs autores Santika, Suhardi e Yustianto (SANTIKA; SUHARDI; YUSTIANTO,

2017), propõem o uso da Service Engineering Framework, um framework derivado de umaabordagem que utiliza ferramentas de análise de negócios combinadas com MSOAM, paraevitar 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, desenvolvimentoe implantação) e foi utilizado para construção de serviços de um sistema financeirogovernamental de esfera local (município), para fornecer serviços como concessões decrédito e emissão de certidões.

Para identificar os serviços candidatos, durante a fase de design de arquitetura, sãoseguidas etapas do Service Inventory Analysis da metodologia MSOAM: todo o processode 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 designde solução de serviços. Esses serviços estão separados em camada que seguem as definidasno MSOAM (ERL et al., 2012).

Embora esta pesquisa busque alternativas para a implementação do SOA pelo uso oMSOAM como abordagem metodológica para a entrega de projetos SOA, esse uso se resumeapenas as fases de análise da metodologia, desprezando as demais fases. Acreditamos que oMSOAM, como uma metodologia, ainda merece ser revisitado com o propósito de migrarsistemas legados, dada a sua vasta literatura e disseminação. Sendo assim, nossa propostapode 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çosAbordagens recentes como microsserviços tem sido apresentadas como alternativas

para o desenvolvimento e entrega de serviços de software. Contudo uma arquitetura demicrosserviç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áticasatuais de engenharia de software (ZIMMERMANN, 2017). Alinhada a este conceito, nossaabordagem adota como base os conceitos fundamentados nos padrões de SOA para lidarcom a construção e implantação de serviços, sem deixar de lado os aspectos modernosde soluções baseadas em microsserviços e DevOps, como padrões, técnicas e ferramentasassociados a estas abordagens.


7.5 Considerações FinaisEste 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 usode 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çõesda metodologia MSOAM, trazendo pra um patamar mais próximo da implementação,atividades necessária para conduzir um processo de Reengenharia de Software que tenhacomo paradigma alvo SOA, além de lidar com abordagens modernas como microsserviçose 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çãode 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 principaiscontribuições e resultados alcançados, seguido por uma breve discussão sobre suas limitaçõese indicações de trabalhos futuros.

8.1 Contribuições e Resultados AlcançadosEsta 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 demandasdo projeto de migração do sistema UVT e alcançar uma solução orientada à serviçomoderna e bem-sucedida, a equipe de desenvolvimento da SET conduziu um processo deReengenharia de Software tendo SOA como paradigma estratégico, Microsserviçoscomo 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 chamadoSPReaD, que significa Service-oriented Process for Reengineering and DevOps.

Além disso apresentamos também um relato da indústria de um caso de reengenhariade sistema legado para atender à SOA. O SPReaD foi aplicado para a modernização dosistema de UVT, um sistema real mantido pela Secretaria de Estado de Tributação doRio Grande do Norte (SET), que oferece diferentes serviços para os contribuintes.

A migração do UVT melhorou vários atributos de qualidade, contribuindo parareduzir a dívida técnica dos sistemas mantidos pelo SET. Como resultado da quebra daestrutura monolítica do sistema UVT e o desacoplamento das regras de negócios dascamadas de apresentação, há uma maior agilidade e flexibilidade na entrega de serviço, oque favorece a evolução do negócio. Além disso, o monitoramento em tempo real impactoupositivamente as operações de suporte, uma vez que a equipe de operações agora possuium postura mais pró-ativa em relação as ocorrências de falha no sistema. A experiênciade migração do UVT em relação aos objetivos alcançados indica um cenário no qual oparadigma orientado a serviços será adotado em toda a SET.

Desta forma, podemos observar, em um ambiente real, os benefícios da adoção daOrientação a serviço, como melhorias na governança, o reuso de serviços colaborando comreduçã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 osfundamentos adequados da orientação a serviços forneceu benefícios substanciais, com aSET começando agora a alcançar o nível “Service Aware” dentro dos níveis de maturidadede 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 ProcessManagement (BPM), que vem sendo utilizadas pelos Auditores fiscais para promover umforte alinhamento com a TI e atender demanda da SET em projetos futuros.

8.2 LimitaçõesEmbora tenhamos obtido resultados relevantes com esta pesquisa, temas impor-

tantes e circundantes ao processo SPReaD não foram explorados, como uma melhordescrição da gestão da dívida técnica dentro do ciclo de desenvolvimento. Dado que asmétricas de dívida técnica foram baseadas no uso apenas de uma abordagem e uma únicaferramenta, e dada a importância da gestão da dívida técnica como um dos objetivos doSPReaD, é necessário que haja uma expansão desse tema e uma revisão das atividadesa ele relacionadas. Nesse sentido, uma vez que o processo SPReaD, extraído durante amigração do sistema de UVT, foi aplicado em um único caso, ainda merece ser revisitadoe reaplicado em outros projetos para garantir sua efetividade e um maior amadurecimentode todas as suas atividades realizadas.

Além disso, alguns problemas identificados no ambiente durante a condução desseestudo não foram explorados nessa pesquisa. Como exemplo, o comprometimento daautonomia de um microsserviço devido a relação entre modelos baseados em domínio ricosversus 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, aotentar compatibilizar uma abordagem baseada em modelos de domínio e a impossibilidadede migrar uma base de dados legada não escalável. Temas dessa natureza não só exigemuma maior maturação do problema, como se esbarram em questões culturais, técnicas econtratuais da SET.

8.3 Trabalhos FuturosCom 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 promoverum forte alinhamento entre as áreas de negócio e TI. A despeito disso, sistemas legadosutilizados para operações internas como o Extranet2 e SIGAT agora são os novos alvos demigraçã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çõesde 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 ondeinformou seu CPF no momento da compra. Com isso, é necessário que haja um estudopara 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áticade 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 temasainda 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 qualitativaspodem ser conduzidas para explorar a relação entre BPM e SOA no contexto de aplicaçõesda SET.

1 https://nfp.set.rn.gov.br/

85

REFERÊNCIAS

BAGHDADI, Y.; AL-BULUSHI, W. A guidance process to modernize legacy applicationsfor soa. Service Oriented Computing and Applications, v. 9, n. 1, p. 41–58, 2015. ISSN1863-2394. Disponível em: <http://dx.doi.org/10.1007/s11761-013-0137-3>. Citado napá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 EnterpriseSolutions 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 andDesign for Services and Microservices. [S.l.]: Prentice Hall, 2017. Citado 9 vezes naspá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 Acrossan 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.]: WorldScientific, 2003. Citado 2 vezes nas páginas 14 e 24.

http://dx.doi.org/10.1007/s11761-013-0137-3

Referências 86

JAMSHIDI, P. et al. Microservices: The journey so far and challenges ahead. IEEESoftware, 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-OrientedArchitecture (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.]: JohnWiley & Sons, 2015. Citado 2 vezes nas páginas 41 e 47.

NEWMAN, S. Building Microservices. 1st. ed. [S.l.]: O’Reilly Media, Inc., 2015. ISBN1491950358, 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 tosoa. 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 financialservice 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 legacyapplications and services to service-oriented architecture (soa). In: The 2011 InternationalConference 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.

https://www.academia.edu/34828240/Dont_believe_the_hype_SOA_AND_MSA_are_not_the_same

https://www.academia.edu/34828240/Dont_believe_the_hype_SOA_AND_MSA_are_not_the_same

http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9285

http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9285

https://doi.org/10.1007/s11219-008-9055-6

Referências 87

WAGNER, C. Model-Driven Software Migration: A Methodology: Reengineering, Recoveryand 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 onsoa. 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 andDevelopment, 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.

https://doi.org/10.1007/s00450-016-0337-0

Documents

Domonolitoaosmicrosserviços ......Palavras-chave:SOA.ReengenhariadeSoftware.DevOps.ReusodeSoftware.Evolução eManutençãodeSoftware.ArquiteturadeSoftware. ... ausência de um processo