Instituto Metrópole Digital
Programa de Pós-graduação em Engenharia de Software Mestrado Profissional em Engenharia de Software
Do monolito aos microsserviços:
um relato de migração de sistemas legados
da Secretaria de Estado da Tributação do
Rio Grande do Norte
Yan de Lima Justino
Natal-RN Agosto/2018
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 de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Universidade Federal do Rio Grande do Norte – UFRN Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Prof. Dr. Carlos Eduardo da Silva
Brasil
2018
Justino, Yan de Lima.
Do monolito aos microsserviços: um relato de migração de sistemas legados da Secretaria de Estado da Tributação do Rio Grande do Norte / Yan de Lima Justino. - 2018.
87 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital - IMD, Programa de Pós-Graduação em Engenharia de Software. Natal, RN, 2018.
Orientador: Prof. Dr. Carlos Eduardo da Silva.
1. Reengenharia de software - Dissertação. 2. Arquitetura Orientada a Serviço - SOA - Dissertação. 3. Software
Reengineering - Dissertação. 4. DevOps - Dissertação. I. Silva, Carlos Eduardo da. II. Título.
RN/UF/BCZM CDU 004.415.2.043
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
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 de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Trabalho aprovado. Brasil, 06 de agosto de 2018:
Prof. Dr. Carlos Eduardo da Silva
Orientador
Prof. Dr. Eiji Adachi M. Barbosa
Examinador interno
Prof. Dr. Nabor Mendonça
Examinador externo
Brasil
2018
filho Pedro Sakakima Justino,
Agradeço primeiramente o apoio da a diretoria da IVIA Soluções e Tecnologia nas pessoas de Márcio Braga, Alexandre Menezes e Edgy Paiva; e a gerência local nas pessoas de Diego Soares dos Santos, Gilberto Coelho de Azevedo Neto e Carolina Cavalcante. A concretização desse projeto não seria possível sem a sua ajuda.
À Secretaria de Estado da Tributação do Rio Grande do Norte (SET) nas pessoas do Secretário André Horta Melo; do Secretário Adjunto Fernando José Oliveira de Amorim; e da Coordenadora de Informática Adriana Assunção Silva, pela confiança cedida e liberdade de atuação.
Ao meu orientador, Prof. Dr. Carlos Eduardo da Silva, pela paciência, coragem e horas dedicadas com muito afinco para “lapidar” essa pesquisa. Foi uma jornada enrique-cedora.
Por fim, agradecimentos especiais são direcionados a todos os analistas da área de desenvolvimento da IVIA lotados na SET, que com profissionalismo e compromisso responderam com extraordinária dedicação aos desafios desse projeto.
A Orientação a Serviço fornece um paradigma de projeto baseado em um conjunto de metas estratégicas para o alinhamento entre tecnologia da informação (TI) e negócios, promovendo eficiência, agilidade e produtividade. Nesse contexto, a reengenharia de sistemas legados para uma arquitetura orientada a serviços (SOA) pode ser justificada para resolver problemas como a demanda por interoperabilidade e a necessidade de fornecer uma interface robusta de serviço de alta disponibilidade. No entanto, a implantação de SOA em um ambiente corporativo é uma tarefa desafiadora, pois pode envolver o uso de diferentes técnicas, como a modernização de sistemas com alto endividamento técnico e altos custos de manutenção. Para isso, é necessário um processo que forneça um conjunto apropriado de técnicas que minimizem os riscos e, ao mesmo tempo, garantam a qualidade dos sistemas durante o processo de migração. Neste sentido, este trabalho apresenta a aplicação de um processo de reengenharia de sistemas legados para suportar a implementação de um projeto SOA. O SPReaD (Service-oriented process for Reengineering and Devops) é uma instanciação da Mainstream SOA Methodology, com foco na reengenharia de sistemas legados, integrando os aspectos de DevOps para o direcionamento de SOA. Esse processo foi criado durante um projeto real de reengenharia de software para evolução de sistemas legados de uma Secretaria de Estado de Tributação. O uso do SPReaD tem apresentado resultados significativos em relação à conquista de importantes metas de qualidade como a padronização de contratos de serviços para efeitos de interoperabilidade; a gestão da dívida técnica, tendo em vista uma melhor manutenibilidade e portabilidade de componentes; uma maior escalabilidade e melhora no desempenho como um todo para suportar uma grande carga de requisições.
Palavras-chave: SOA. Reengenharia de Software. DevOps. Reuso de Software. Evolução
Service-orientation provides a design paradigm based on a set of strategic goals towards the alignment between information technology and business, promoting efficiency, agility and productivity. In this context, the reengineering of legacy systems to a service-oriented architecture (SOA) can be justified to solve problems such as the demand for interoperability and the need to provide a robust high-availability service interface. However, the deployment of SOA into an enterprise environment is challenging task, as it may involve the use of different techniques, such as the modernization of systems with high technical debt and high maintenance costs. To this end, a process is required that provides an appropriate set of techniques that minimize risks and at the same time ensure the quality of the systems during the migration process. In this sense, this work presents the application of a process for the reengineering legacy systems to support the implementation of an SOA project. This process has been identified during a real software reengineering project for evolution of legacy systems of a Secretariat of State for Taxation. The SPReaD (SOA Process for Reengineering and DevOps) is an instantiation of the mainstream SOA methodology focusing on the reengineering of legacy systems integrating DevOps aspects for targeting SOA. The use of SPReaD have presented significant results regarding the achievement of important quality goals. The use of SPReaD has presented significant results in relation to achieving important quality goals such as the standardization of service contracts for interoperability purposes; technical debt management, for better maintainability and portability of components; scalability and performance improvement to support a large load of requests.
Keywords: SOA. Software Reengineering. DevOps. Software Reuse. Software Evolution
Figura 1 – Diagrama da metodologia de pesquisa aplicada (fonte-própria) . . . 18
Figura 2 – Diagrama dos níveis de implementação de SOA (ERL et al., 2014). . . 21
Figura 3 – Fases da metodologia MSOAM (ERL; MERSON; STOFFERS, 2017). . 22
Figura 4 – Modelo geral para Reengenharia de Software (WAGNER, 2014). . . 25
Figura 5 – A relação entre integração, entrega e implantação contínuas (SHAHIN; BABAR; ZHU, 2017). . . 26
Figura 6 – Arquitetura monolítica (fonte-própria) . . . 29
Figura 7 – Estrutura monolítica do sistema UVT (fonte-própria) . . . 30
Figura 8 – Relação das camadas de tecnologias do processo SPReaD (fonte-própria). 35 Figura 9 – Estratégia e Táticas do SPReaD (fonte-própria). . . 36
Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman e Maxin (fonte-própria). . . 37
Figura 11 – Estrutura completa do processo SPReaD (fonte-própria). . . 38
Figura 12 – Fase de Comunicação do SPReaD (fonte-própria). . . 40
Figura 13 – Fase de Planejamento do SPReaD (fonte-própria). . . 42
Figura 14 – Fase de Análise do SPReaD (fonte-própria). . . 44
Figura 15 – Fase de Design do SPReaD (fonte-própria). . . 45
Figura 16 – Aplicação da Análise de Inventário de Serviço (fonte-própria). . . 46
Figura 17 – Aplicação da Análise Orientada a Serviço (fonte-própria).. . . 47
Figura 18 – Práticas da Análise Orientada a Serviço (fonte-própria). . . 48
Figura 19 – Fase de Construção do SPReaD (fonte-própria). . . 50
Figura 20 – Fluxo de Migração de Software (fonte-própria). . . 52
Figura 21 – Fase Etapa de Entrega do SPReaD (fonte-própria). . . 53
Figura 22 – Fase de Suporte e Feedback do SPReaD (fonte-própria). . . 54
Figura 23 – Instâncias de microsserviços na estrutura de alocação da SET (fonte-própria). . . 55
Figura 24 – Definição do Inventário de Serviços de Arrecadação (fonte-própria). . . 58
Figura 25 – Comunicação entre Inventários de Serviços da SET e contextos externos (fonte-própria). . . 59
Figura 26 – Engenharia reversa dos serviço legado de Débitos no escopo de Análise Orientada a Serviço (fonte-própria). . . 60
Figura 27 – Design dos microsserviços de Recolhimento e Repasse do Inventário de Arrecadação (fonte-própria). . . 61
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ços de Arrecadação e Prefeituras (fonte-própria).. . . 68
Figura 35 – Detalhamento do processo de build no TFS (fonte-própria). . . 69
Tabela 1 – Métricas da dívida técnica do sistema UVT agrupadas pela categorias. 32
Tabela 2 – Métricas da dívida técnica da categoria “Architecture”. . . 32
Tabela 3 – Dívida técnica do sistema UVT antes e depois da migração. . . 72
Tabela 4 – Métricas de LoC no código legado Vs código dos Inventários. . . 73
1 INTRODUÇÃO . . . 14 1.1 Problemática e Motivação . . . 16 1.2 Objetivos . . . 16 1.3 Metodologia . . . 17 1.4 Organização do Documento . . . 19 2 REFERENCIAL TEÓRICO . . . 20
2.1 Orientação a serviço, SOA e MSOAM . . . 20
2.2 Reengenharia de Software . . . 24
2.3 Microsserviços e DevOps . . . 25
2.4 Considerações Finais . . . 27
3 MIGRAÇÃO DO SISTEMA UVT . . . 28
3.1 Arquitetura do Sistema UVT . . . 28
3.2 Processo adhoc . . . 33 3.3 Considerações Finais . . . 34 4 PROCESSO SPREAD . . . 35 4.1 Visão Geral . . . 35 4.2 Extração do Processo . . . 37 4.3 Comunicação . . . 39 4.3.1 Atividades . . . 39 4.3.2 Artefatos . . . 40 4.3.3 Práticas . . . 41 4.4 Planejamento . . . 41 4.4.1 Atividades . . . 41 4.4.2 Artefatos . . . 41 4.4.3 Práticas . . . 42 4.5 Modelagem . . . 43 4.5.1 Atividades . . . 43 4.5.2 Artefatos . . . 44 4.5.3 Práticas . . . 45 4.6 Construção . . . 49 4.6.1 Atividades . . . 49 4.6.2 Artefatos . . . 51 4.6.3 Práticas . . . 51
4.7.1 Atividades . . . 52
4.7.2 Artefatos . . . 53
4.7.3 Práticas . . . 54
4.8 Considerações Finais . . . 56
5 APLICAÇÃO DO SPREAD NO SISTEMA UVT . . . 57
5.1 Modelagem . . . 57
5.2 Construção . . . 62
5.3 Implantação . . . 67
5.4 Consideração Finais . . . 70
6 AVALIAÇÃO . . . 71
6.1 Resultados da Reengenharia de Software aplicada ao Sistema UVT 71 6.2 Resultados da adoção de SOA . . . 74
7 TRABALHOS RELACIONADOS . . . 77
7.1 Migração de Sistemas Legados . . . 77
7.2 Aplicação de SOA em contextos de Governo eletrônico (e-gov) . . . 78
7.3 Uso de MSOAM como metodologia para projetos SOA . . . 80
7.4 O uso de microsserviços . . . 80
7.5 Considerações Finais . . . 81
8 CONCLUSÃO . . . 82
8.1 Contribuições e Resultados Alcançados . . . 82
8.2 Limitações . . . 83
8.3 Trabalhos Futuros . . . 83
1 INTRODUÇÃO
A evolução de software é a capacidade de alterar, de forma rápida e confiável, um sistema de software para adaptá-lo às mudanças do ambiente, aos novos usuários e às necessidades do mercado, bem como manter seu desempenho operacional em um nível satisfatório (BENNETT; RAJLICH, 2000). Quando um software não é mais viável, é considerado envelhecido, em decaimento ou legado (BENNETT; RAJLICH,2000;PARNAS,
1994). Nesse estágio, as equipes de desenvolvimento tendem a evitar modificações no núcleo do sistema, realizando apenas adaptações através de técnicas como wrappers de entradas e saídas. Consequentemente, os sistemas tornam-se cada vez mais desatualizados e não atendem mais às necessidades dos usuários.
Muitas vezes, esses sistemas legados são vitais para os objetivos estratégicos das organizações e não podem ser simplesmente encerrados e descartados (BENNETT, 1995), o que leva essas organizações a decidir como lidar com esses sistemas. Diante disso, elas podem investir na tentativa de reverter o processo de decaimento do software, ansiando por restaurar sua capacidade de desenvolvimento, ou podem optar por reestruturar os recursos do sistema legado em um novo sistema de software, geralmente em tecnologias mais atualizadas, através de um processo de reengenharia. Neste trabalho, nos concentramos nesse último processo.
Um dos principais desafios da Reengenharia de Software é garantir a equivalência funcional na nova versão (GRUBB; TAKANG,2003), ou seja, a nova versão do sistema deve fornecer as mesmas funcionalidades existentes do sistema legado, além de poder atender de maneira rápida e confiável novas solicitações. Além disso, o processo de reengenharia deve estar alinhado com os objetivos estratégicos da organização, ajudando a criar processos de negócios revisados e que melhor atendam a esses objetivos.
Em muitos casos, a migração de sistemas legados para SOA (Service-oriented
Architecture) tem sido uma estratégia de reengenharia adotada para se alcançar um
conjunto de metas e benefícios que prometem reduzir o custo do portfólio de aplicativos e maximizar o retorno sobre o investimento (ROI) (ERL; MERSON; STOFFERS, 2017). O seja, embora a aplicação de SOA esteja associada a um esforço inicial, visando benefícios futuros, uma vez que o esforço tenha sido alcançado, os benefícios são maiores que o custo (LEON, 2017).
Nesse sentido, a Secretaria de Estado da Tributação do Rio Grande do Norte (SET) diante da necessidade de migração do sistemas UVT (Unidade Virtual de Tributação) - a principal interface de comunicação entre o contribuinte e a SET - optou por uma arquitetura de serviços moderna e robusta que suprisse as necessidades de escala, capacidade
de aceleração e garantias de qualidade. Porém as estratégias tradicionais para se obter SOA são tidas como opções pesadas e complexas para criação de soluções orientadas a serviço (LEON, 2017; JAMSHIDI et al., 2018). Isso levou a SET a cogitar a adoção de uma arquitetura alinhada com design, padrões e práticas emergentes que abraçasse novas tecnologias e favorecessem uma entrega ágil de software.
Vistos como a mais recente alternativa para o design, desenvolvimento e entrega de serviços de software, os microsserviços são uma abordagem de software e de arquitetura de sistemas que se baseia em conceitos bem estabelecidos de modularização e limites técnicos (JAMSHIDI et al., 2018). Além disso, compartilham dos mesmos princípios de design de SOA (RICHARDS, 2015) e sua adoção pode trazer benefício como desenvolvi-mento e tempo de comercialização mais rápidos, reação rápida à mudanças, dinamismo, redução de custos econômicos e aplicações mais robustas (LEON, 2017). Nesse contexto, metodologias como desenvolvimento ágil e práticas contínuas como DevOps (integração, entrega, implantação e monitoramento contínuos), pavimentam o caminho para uma evolução convergente de SOA chamada de microsserviços (LEON, 2017; NEWMAN, 2015;
BASS; WEBER; ZHU, 2015).
Convergente, porque a indústria não possui uma definição uniforme sobre que se afaste completamente daquelas estabelecidas por SOA. Ou seja, uma arquitetura de micros-serviços ainda exige uma definição e padronização mais aprofundada e compatível com sua natureza dinâmica (LEON,2017). Na verdade, contando com serviços independentes com limites claros, os microsserviços são semelhantes aos da SOA mais tradicional (JAMSHIDI et al., 2018) e, segundo Zimmermann (ZIMMERMANN, 2017), “não constituem um novo
estilo arquitetural diferente de SOA, mas qualificam-se como SOA implementado e serviços realizados de uma maneira particular com as práticas de engenharia de software de última geração”.
Dado esse contexto, Este autor, na condição de Arquiteto de Software da IVIA
Soluções e Tecnologia, empresa contratada para suprir as demandas de desenvolvimento
de software da SET, foi escolhido como arquiteto responsável pelo projeto de migração do sistema UVT. Contudo essa migração apresentou um grande desafio de projeto: a ausência de um processo de Reengenharia de Software que conduzisse a migração de um sistema monolítico com alto endividamento técnico para Arquitetura Orientada a Serviço, baseando-se em abordagem modernas como microsserviços. Diante desse desavio, foi proposto a condução de uma pesquisa no âmbito da indústria para definir um processo de migração de sistemas legados para o paradigma orientado a serviços. Essa pesquisa foi conduzida entre os anos de 2016 e 2018 no âmbito da SET concomitante ao projeto de migração do sistema UVT.
1.1
Problemática e Motivação
Com o passar dos anos e a ausência de boas práticas de Engenharia de Software, o sistema UVT começou a apresentar decaimento na qualidade de suas operações, bem como adquiriu um alto grau de endividamento técnico e, consequentemente, um alto custo de manutenção e evolução. Além disso, o desejo da SET por modernização da interface gráfica e pela disponibilização de serviços tributários em aplicativos móveis, demandaram uma maior interoperabilidade, o que levaria a uma reengenharia de sua arquitetura para prover serviços de software.
Essa a ausência de um processo de migração de um sistema legado com alto endividamento técnico, baseando-se em uma abordagem de microsserviços tem se mostrado um grande desafio de projeto. Diante do alto nível de abstração e complexidades envolvidas em um processo de Reengenharia de software, a adoção de metodologias já consolidadas pode ser uma resposta no que diz respeito a organizar os esforços relacionados à condução desse projeto.
A despeito disso, a MSOAM (Mainstream SOA Methodology) é um modelo de referência estabelecido por Thomas Erl como parte de uma metodologia abrangente caracterizada pela aplicação de fases sequenciais para a implantação de projetos SOA (ERL,
2005). No entanto, é reconhecido que a implantação de SOA é única em cada organização e pode considerar o uso de diferentes abordagens (ERL; MERSON; STOFFERS,2017), dependendo da natureza e escopo do projeto. Sendo assim, o uso de metodologias como o MSOAM por si só não é suficiente para lidar com o nível de abstração e complexidades envolvidas na reengenharia de um sistema legado.
Ou seja, é preciso instâncias mais concretas que possibilitem a metodologia MSOAM lidar com abordagens modernas como microsserviços e práticas contínuas como as de DevOps. Essas necessidades motivaram a condução de uma pesquisa no âmbito da indústria que colaborasse com a adoção de SOA a partir da Reengenharia de Software utilizando microsserviços como tática para construção de soluções orientadas a serviço e DevOps para se obter sistemas com melhor garantia de qualidade e monitoramento no processo de integração, entrega e implantação contínua(SHAHIN; BABAR; ZHU,2017). Neste sentido, o desafio considerado por este trabalho é a necessidade de um processo de desenvolvimento que suporte a reengenharia de sistemas legados e práticas contínuas relacionadas ao DevOps tendo como alvo o paradigma SOA.
1.2
Objetivos
O objetivo geral deste trabalho é definir um processo de Reengenharia de Software aplicado a sistemas legados para apoiar a implantação de projetos SOA. Esse processo foi
aplicado no contexto de migração do sistema UVT da SET/RN. Para alcançar o objetivo geral desta pesquisa emergem os seguintes objetivos específicos:
1. Extrair, formalizar e conduzir um processo de Reengenharia de Software que lide com sistemas legados afim de construir soluções orientadas a serviços e implantá-las através de práticas contínuas de DevOps.
2. Aplicar a implantação de um projeto SOA no contexto de migração do sistema UVT. 3. Avaliar os impactos da reengenharia do sistema UVT e implantação de SOA na
SET/RN.
Com base nisso, a principal contribuição deste trabalho é a definição de um processo de Reengenharia de Software orientado a serviços: O Service-oriented Process for
Reengineering and DevOps (SPReaD). O SPReaD é uma instanciação de um processo de
Reengenharia de Software com foco no desenvolvimento de soluções orientadas a serviços, que foi identificado nos últimos dois anos durante a migração do sistema UVT (Unidade
Virtual de Tributação) da SET/RN. A aplicação desse processo apresentou resultados
significativos em relação à conquista de importantes metas do projeto, bem como metas de qualidade de software como manutenibilidade, escalabilidade e desempenho.
1.3
Metodologia
Dada a complexidade e abrangência que envolve um processo de Reengenharia de Software, bem como a necessidade de realizar a pesquisa no ambiente de sua aplicação, a metodologia adotada para a condução desta pesquisa foi a Pesquisa-ação. Essa escolha se deu pela necessidade de definição de um processo de reengenharia de sistemas legados, com alto endividamento técnico, para uma arquitetura orientada a serviços baseada em microsserviços, dentro de um processo interativo de investigação.
Como ilustrado na Figura1, a pesquisa foi iniciada com a Escolha do referencial
teórico. Nessa fase foram aplicadas a coleta e a leitura de textos da base teórica dos estudos relacionados a SOA, Reengenharia de Software e DevOps, detalhados no capítulo
2 . Já a Aplicação do caso foi marcada inicialmente pela execução de um processo ad
hoc, cuja finalidade foi a identificação de um processo mais organizado. O resultado disso
foi a extração de um processo denominado SPReaD, que foi refinado e documentado durante as iterações.
Os artefatos gerados durante as iterações do processo SPReaD, foram coletados e organizados em duas categorias: artefatos de concepção e criação, e artefatos de mo-nitoramento. Essa divisão serviu para direcionar a fase de Avaliação na identificação de resultados qualitativos, bem como quantitativos. Por fim, a fase de Divulgação foi
Figura 1 – Diagrama da metodologia de pesquisa aplicada (fonte-própria)
dedicada ao compartilhamento dos resultados (prévios) da pesquisa em workshops internos da organização, eventos da indústria e eventos acadêmicos.
No tocante aos eventos da indústria, o tema foi submetido e aceito como palestra nos dois principais eventos de desenvolvimento de software que ocorrem no país: a QCon São Paulo, conferência internacional de desenvolvimento de software realizada pela InfoQ
1, realizada em maio de 2016; e na TDC 20172 (The developer’s conference), conferência
nacional de desenvolvimento de software, realizada em Julho de 2017, também em São Paulo.
Já em Julho de 2018 o tema foi submetido e aprovado na TDC 2018, na trilha arquitetura dotnet, sob o título Reengenharia de sistemas legados para arquitetura de
serviços: Metodologia, Processos e técnicas aplicadas ao .Net Framework. O tema foi bem
aceito pelo publico-alvo da trilha e proporcionou uma série de discussões, motivadas pela grande parcela de participantes que atualmente estão passando por algum processo de migração de legado.
No âmbito acadêmico, o tema foi submetido ao EPOCA 2017 (Escola Potiguar de Computação e suas Aplicações), evento regional realizado pela UFRN, no qual este trabalho foi premiado na categoria Artigos longos; este estudo também foi submetido na trilha SEIP (Software Engineering in Practice) da 40a edição do ICSE (International Conference
On Software Engineering) 3, realizado em 2018 Gotemburgo/Suécia. O trabalho foi aceito
como poster, e publicado como resumo expandido nos anais do ICSE4. A Divulgação se
1 https://www.infoq.com/
2 http://www.thedevelopersconference.com.br/ 3 https://www.icse2018.org/
mostrou uma atividade fundamental na iteração da metodologia, uma vez que os feedbacks obtidos eram retro-alimentados na Aplicação do caso, colaborando inicialmente no refinamento do processo e posteriormente na sua formalização.
1.4
Organização do Documento
Este trabalho está organizado da seguinte maneira. O capítulo 2 apresenta um conjunto de discussões difundidas no âmbito acadêmico e na industria sobre SOA, Re-engenharia de Software e DevOps, que serviram como referencial teórico para nortear o desenvolvimento da pesquisa. Em seguida, no Capítulo 3contextualiza o sistema legado que foi modernizado por meio da aplicação do SPReaD. Nosso processo orientado a serviços para reengenharia e DevOps é apresentado no Capítulo 4 e detalhado, no contexto de migração do sistema UVT no Capítulo 5. Uma avaliação deste caso é apresentada no Capítulo 6, enquanto o Capítulo7 apresenta uma discussão sobre o trabalho relacionado a fim de motivar nossa abordagem. O Capítulo 8conclui o trabalho.
2 REFERENCIAL TEÓRICO
Este capítulo apresenta um conjunto de discussões difundidas no âmbito acadêmico e na industria sobre Orientação a serviço, SOA, MSOAM, Reengenharia de Software, microsserviços e DevOps, que serviram como referencial teórico para nortear o desenvolvi-mento da pesquisa.
2.1
Orientação a serviço, SOA e MSOAM
Um Serviço é um software publicado via API, que faz parte de um contrato e que pode fornecer uma coleção de recursos (ERL; MERSON; STOFFERS,2017). Esses recursos são agrupados em unidades lógica que representam um contexto funcional. A Orientação
a Serviço atua como paradigma de design que compreende essas unidades lógicas como
representações de recursos corporativos que podem ser modelados como serviços que apoiam a realização dos objetivos estratégicos da Computação Orientada a Serviço que são: o aumento da interoperabilidade intrínseca, o aumento da governança, maior diversificação de fornecedores, maior alinhamento entre negócios e tecnologia, aumento do Retorno do investimento (ROI), maior agilidade organizacional e redução do custo TI. Segundo Erl (ERL, 2008), a Orientação a serviço pode ser compreendida pela aplicação de oito princípios de design:
Padronização de Contrato: “serviços dentro do mesmo escopo de negócio estão em
conformidade com os padrões de design de contrato” (ERL, 2008, p. 130);
Baixo acoplamento: “Os contratos de prestação de serviços impõem baixos requisitos
de acoplamento ao consumidor e são eles próprios dissociados do seu ambiente circun-dante” (ERL, 2008, p. 168);
Abstração: “os contratos de serviço contenham apenas informações essenciais publicadas
nos contratos de serviços” (ERL, 2008, p. 214);
Reusabilidade: “os serviços que contêm e expressam uma lógica agnóstica, possam ser
posicionados como recursos empresariais reutilizáveis” (ERL,2008, p. 258);
de execução subjacente” (ERL, 2008, p. 296);
Baixa Manutenção de Estado: “os serviços minimizam o consumo de recursos ao
adiar o gerenciamento das informações do estado quando necessário” (ERL, 2008, p. 332);
Descoberta:, “os serviços são complementados com metadados comunicativos pelos quais
eles podem ser efetivamente descobertos e interpretados” (ERL, 2008, p. 368);
Composição: “os serviços são participantes de composição eficazes, independentemente
do tamanho e complexidade da composição” (ERL, 2008, p. 392);
Para entregar serviços baseados nos princípios da Orientação a Serviço, é preciso uma arquitetura tecnológica com características distintas, capaz de acomodar comportamentos e requisitos que possibilitem alcançar as metas da Computação Orientada a Serviço (ERL et al., 2014). Para Erl (ERL et al., 2014, p. 13), esta arquitetura “é a Service-oriented architecture”(SOA), que segundo o autor, “pode existir em quatro escopos ou níveis diferentes de implementação, sendo que alguns níveis abrangem os outros” (ERL et al.,
2014, p. 15), como ilustra a Figura 2.
Segundo Erl (ERL et al., 2014), esses escopos ou níveis de implementação são classificados como: Arquitetura de Serviço, que representa a arquitetura de um único serviço; Arquitetura de Composição de Serviço, que é a arquitetura de um conjunto de serviços relacionados através de em uma composição; Arquitetura de Inventário de Serviço, que apoia uma coleção de serviços co-relatos e que são padronizados e gerenciados de forma independente;e Arquitetura de Empresa Orientada a Serviço que representa a arquitetura da empresa em si, em qualquer extensão que seja orientada a serviços.
Esta arquitetura requer a compreensão de como projetos SOA bem-sucedidos de-vem ser conduzidos (ERL; MERSON; STOFFERS,2017, p. 91). Nessa linha, A MSOAM (Mainstream SOA Methodology) é um modelo de referência idealizado para proporcionar a realização de projetos SOA. Como ilustra a Figura 3, essa metodologia é composta por um conjunto comum de etapas que fazem a transição da concepção de serviços para a implementação e para a evolução, através de um ciclo de vida pré-definido (ERL; MERSON; STOFFERS, 2017). As etapas do projeto desse ciclo de vida são as seguintes:
Figura 3 – Fases da metodologia MSOAM (ERL; MERSON; STOFFERS,2017).
Plando de Adoção de SOA: “Durante esse estágio inicial, as decisões de planejamento
fundacional são tomadas. Essas decisões moldarão todo o projeto, e é por isso que esse é considerado um estágio crítico que pode exigir financiamento e tempo alocados separada-mente para realizar estudos significativos necessários para avaliar e determinar uma série de fatores” (ERL; MERSON; STOFFERS,2017, p. 95).
Análise de Inventário de Serviço: “Este estágio é dedicado a definir conceitualmente o
inventário de serviços para que os serviços candidatos individuais possam ser identificados e atribuídos a contextos funcionais apropriados em relação uns aos outros. Isso garante que os serviços (dentro do limite do inventário de serviços) sejam normalizados, pois não se sobrepõem.” (ERL; MERSON; STOFFERS, 2017, p. 96).
Análise Orientada a Serviço: “É geralmente realizada iterativamente, uma vez para
cada processo de negócios. Normalmente, a entrega de um inventário de serviços determina um escopo que representa um domínio significativo da empresa ou da empresa como um todo. Todas as iterações de uma Análise Orientada a Serviços pertencem a esse escopo, com cada iteração contribuindo para o blueprint de inventário de serviço.” (ERL; MERSON; STOFFERS, 2017, p. 99).
Design Orientado a Serviço: “Estágio dedicado a produção de contratos de serviços em
apoio a abordagem Contract-first para o desenvolvimento de software” (ERL; MERSON; STOFFERS, 2017, p. 101).
Design de Lógica de Serviço: “Estágio no qual o contrato de serviço é finalizado antes
da arquitetura de serviço subjacente e da lógica que será responsável por executar a funcionalidade expressa no contrato de serviço” (ERL; MERSON; STOFFERS, 2017, p. 103).
Desenvolvimento de Serviço: “Depois de todas as especificações de design terem sido
concluídas, a programação real do serviço pode começar. Como a arquitetura de serviço já terá sido bem definida como resultado dos estágios anteriores e do envolvimento de padrões de design personalizados, os desenvolvedores de serviço geralmente terão uma direção clara sobre como construir as várias partes da arquitetura de serviço” (ERL; MERSON; STOFFERS, 2017, p. 103).
Teste de Serviço: “Os serviços precisam passar pelos mesmos tipos de ciclos de teste
e garantia de qualidade que os aplicativos tradicionais personalizados. No entanto, além disso, há novos requisitos que introduzem a necessidade de métodos e esforços de teste adicionais” (ERL; MERSON; STOFFERS, 2017, p. 103).
Implantação e Manutenção de Serviço: “A implantação de serviço representa a
im-plementação real de um serviço no ambiente de produção. Manutenção de serviço refere-se a atualizações ou alterações que precisam ser feitas no ambiente de implementação, como parte da implementação inicial ou subsequentemente” (ERL; MERSON; STOFFERS,
2017, p. 105).
Uso e Monitoramento de Serviço: “O monitoramento contínuo do serviço ativo gera
métricas necessárias para medir o uso do serviço para manutenção evolutiva (como es-calabilidade, confiabilidade, etc.), bem como para fins de avaliação de negócios (como no cálculo do custo de propriedade e do ROI)” (ERL; MERSON; STOFFERS,2017, p. 105).
Descoberta de Serviço: “Para garantir a reutilização consistente de serviços agnósticos
e recursos de serviço, as equipes de projeto executam um processo de Descoberta de Serviço separado e explicitamente definido” (ERL; MERSON; STOFFERS, 2017, p. 106).
Versionamento e Retirada de Serviço: “Depois que um serviço tiver sido
implemen-tado e usado em ambientes de produção, pode surgir a necessidade de fazer alterações na lógica de serviço existente ou aumentar o escopo funcional do serviço. Em casos como esse, uma nova versão da lógica de serviço e / ou do contrato de serviço provavelmente precisará ser introduzida” (ERL; MERSON; STOFFERS, 2017, p. 106).
De acordo com Erl (ERL; MERSON; STOFFERS, 2017), esta metodologia ofe-rece um conjunto de processos genéricos e práticas que quase sempre requerem maior customização quando incorporadas a ambientes corporativos.
2.2
Reengenharia de Software
Dependendo do escopo do projeto de SOA, diferentes abordagens podem ser consi-deradas (ERL; MERSON; STOFFERS, 2017). Por exemplo, técnicas de Reengenharia de Software para modernização de sistemas legados. Segundo Pressman e Maxim ( PRES-SMAN; MAXIM, 2016, p. 795), “A Reengenharia de Software abrange as atividades de
análise de inventários, reestruturação de documentos engenharia reversa, reestruturação de programas e dados e engenharia direta”. Para Wagner (WAGNER,2014), ela oferece uma estratégia de modernização de sistemas pelo atendimento de importantes propósitos como portar sistemas para uma nova plataforma, introduzir novas tecnologias, extrair conhecimentos, design e quebrar arquiteturas monolíticas. O consenso entre esses autores, é que o objetivo a Reengenharia de Software é a criação de versões dos programas com maior qualidade e melhor manutenibilidade.
Conforme ilustrado na Figura 4, esse processo pode ser compreendido por três fases distintas (TRIPATHY; NAIK,2014): Abstração, na qual as técnicas de Engenharia reversa (Reverse Engineering) como análise de código, análise de documentos, coleta de requisitos e extração de modelos são aplicados; Refinamento, com o qual as atividades Engenharia direta (Forward engineering) são aplicadas. Esta fase visa atingir um sistema alvo com melhor qualidade, em comparação ao sistema original; a fase de Alteração é a relação entre abstração e refinamento para repensar os modelos conceituais, re-especificar requisitos, re-desenhar e re-codificar uma nova implementação;
Um dos principais desafios desse processo é garantir a equivalência funcional na nova versão (GRUBB; TAKANG,2003). Para a nova versão do sistema deve fornecer as mesmas funcionalidades existentes do sistema legado, além de poder atender de maneira rápida e confiável novas solicitações.
Figura 4 – Modelo geral para Reengenharia de Software (WAGNER, 2014).
2.3
Microsserviços e DevOps
A constante necessidade de entregas mais rápidas e confiáveis demandam respostas ágeis em um ambiente de negócio cada vez mais fluido (PRESSMAN; MAXIM, 2016, p. 67). Nesse contexto, a abordagem de software e arquitetura de sistemas denominada “Microsserviços” tem se demonstrado uma tendência no design, desenvolvimento e entrega de serviços (JAMSHIDI et al., 2018). Emergidos de conceitos como Domain-Driven
Design (EVANS, 2003), Continuous deliver y, On-demand virtualization, Infrastructure
automation, Small autonomous teams, System scale (NEWMAN, 2015), microsserviços se baseiam no conceito bem definido de modularização.
Ou seja, cada microsserviço é implementado e operado como um pequeno sistema independente, oferecendo acesso à lógica e dados através de uma interface de rede bem definida (JAMSHIDI et al., 2018). Como consequência, há um aumento na agilidade, uma vez que cada microsserviço torna-se uma unidade autônoma de desenvolvimento, implantação, operação, versionamento e dimensionamento (JAMSHIDI et al., 2018). Para Fowler (FOWLER, 2016), “com a arquitetura de microsserviço, um aplicativo pode ser facilmente dimensionado horizontalmente e verticalmente, a produtividade e a velocidade do desenvolvedor aumentam drasticamente, e tecnologias antigas podem ser facilmente trocadas para as mais novas”. Para isso, é preciso a adoção de práticas contínuas, ou seja, integração, entrega, implantação e monitoramento contínuos para permitir que as organizações liberem novos recursos com freqüência e confiabilidade, garantindo a alta qualidade do sistema implantado durante todo o seu ciclo de vida (BASS; WEBER; ZHU,
2015).
Essas práticas da Continuous Software Engineering podem ser classificadas em três modalidades (SHAHIN; BABAR; ZHU, 2017): Continuous Integration (CI): prática em que os membros de uma equipe integram o trabalho de desenvolvimento frequentemente;
Continuous Delivery (CDE): prática adotada para a garantir que um aplicativo esteja
sempre em estado preparado para a produção depois de passar com êxito por testes automatizados e controles de qualidade; Continuous Deployment (CD): prática de implantação contínua dá um passo adiante e implanta de forma automática e contínua o aplicativo para ambientes de produção. É importante notar que a prática de CD implica na prática de CDE, mas a inversa não é verdadeira.
Como ilustrado na Figura5, a relação dessas práticas contínuas inicia-se com o time de desenvolvimento realizando commits na base de código. Essa ação notifica o servidor de CI que executa o build e os testes automatizados da aplicação. Em seguida, as etapas de CDE e CD são executadas para preparar pacotes de software para a entrega e implantá-los em ambiente de produção. Os resultados de cada etapa são notificados para o time de desenvolvimento.
Figura 5 – A relação entre integração, entrega e implantação contínuas (SHAHIN; BABAR; ZHU, 2017).
Na indústria, estas práticas contínuas são rotuladas como DevOps, que de acordo com Bass (BASS; WEBER; ZHU, 2015, p. 4), “é um conjunto de práticas destinadas a
reduzir o tempo entre executar uma alteração em um sistema e a mudança ser colocada em produção, garantindo ao mesmo tempo alta qualidade”. Ainda para Bass (BASS; WEBER; ZHU,2015, cap. 7) associa-se às práticas contínuas do DevOps o Monitoramento, que fornece identificação de falhas, identificação da degradação do desempenho, o planejamento das capacidades de recursos, identificação da dinâmica do negócio e detecção de intrusão. Essas práticas em conjunto ajudam a moldar as decisões tomadas sobre como construir microserviços e como implantá-los.
Sendo assim, os benefícios associados a adoção de Microsserviços e DevOps são a construção de serviços que apresentam heterogeneidade de tecnologias, resiliência, escala, fácil implantação, alinhamento organizacional, passividade de composição, e
substituibili-dade (NEWMAN, 2015). Apesar desses benefícios já serem endereçados e amplamente discutidos numa perspectiva da Service-Oriented Architecture (ERL, 2008; ZIMMER-MANN,2017), para Newman (NEWMAN, 2015, p. 8), “há uma falta de consenso sobre
como fazer SOA bem”.
Talvez essa percepção resida no fato de que literaturas proeminentes de SOA como as providas por Erl (ERL, 2005; ERL, 2008; ERL et al., 2012; ERL et al., 2014;
ERL; MERSON; STOFFERS, 2017) concentram seus esforços para explicar os princípios, padrões, análise e design do paradigma orientado a serviços; enquanto literaturas como as fornecidas por Newman (NEWMAN,2015), Mark (RICHARDS,2015) e Fowler (FOWLER,
2016) apresentam um catálogo de práticas que se aproximam da implementação de serviços. Sob essa ótica, é possível admitir SOA como uma abordagem estratégica e microsserviços como uma abordagem tática.
Vale salientar que embora os microsserviços e DevOps reflitam filosofias que remetam a uma estrutura de pequenas equipes independentes, a maioria das organizações tem um grande sistema de missão crítica que não é arquitetado dessa maneira. Essas organizações precisam decidir se desejam migrar suas arquiteturas para arquiteturas de microsserviço e quais migrar (BASS; WEBER; ZHU, 2015).
2.4
Considerações Finais
Este capítulo apresentou conceitos de SOA, MSOAM, Reengenharia de Software, microsserviços e DevOps, que serviram de referencial teórico para nortear o o desenvolvi-mento desta pesquisa. No Capítulo 3 serão apresentadas as motivações que levaram a SET adotá-los como elementos para alcançar as metas de qualidade esperadas na migração do sistema legado UVT.
3 MIGRAÇÃO DO SISTEMA UVT
Uma das principais responsabilidades da administração pública fazendária é a prevenção e a detecção de evasão fiscal. No estado do Rio Grande do Norte, a Secretaria de Estado da Tributação (SET) desenvolve sistemas para apoiar essas atividades, auxiliando auditores fiscais e contribuintes a realizarem suas obrigações fiscais e tributárias. O UVT (Unidade Virtual de Tributação) é um desses sistemas. Ele é a principal interface de comunicação entre contribuintes e a SET 1. Neste capítulo apresentaremos o sistema UVT, sua arquitetura e métricas, contextualizando sua migração antes do início da pesquisa acadêmica.
O sistema UVT foi projetado para fornecer serviços “abertos”, que não necessitam de um mecanismo de autenticação e autorização, bem como serviços de acesso “restrito”. Qualquer cidadão pode emitir uma certidão negativa ou consultar algumas informações públicas de um cadastro de contribuinte, sem que haja a necessidade de identificação, uma vez que estas informações não configuram dados protegidos pelo sigilo fiscal. Entretanto, contribuintes, contadores e auditores fiscais podem utilizar uma área restrita do sistema, na qual é possível acessar informações e serviços específicos, desde que autorizados a fazê-lo. São exemplos de serviços da área restrita, a emissão de extratos fiscais e a baixa de Documentos Fiscais eletrônicos (DF-e) como a Nota Fiscal eletrônica (NF-e) e Livros Fiscais.
Desenvolvido entre os anos de 2008 e 2010 utilizando a linguagem de programação
Visual Basic e o Framework Webforms (ambas da Microsoft), o sistema UVT tinha como
objetivo técnico migrar para uma única solução algumas funcionalidades que originalmente foram construídas utilizando tecnologias que naquele momento encontravam-se legadas como Oracle Forms 2 e ASP (Clássico). A SET esperava com essa migração reunir
em uma única página Web todos os serviços disponíveis ao contribuinte, contabilistas, transportadores e demais atores que interagem com a Secretaria de Tributação do RN.
3.1
Arquitetura do Sistema UVT
Seguindo padrões de desenvolvimento de aplicações web vigentes na época e utilizando Frameworks web baseados em componentes, o sistema UVT foi construído sobre uma estrutura na qual: a) todos os serviços estavam contidos em um núcleo indecomponível
1 Contribuinte é qualquer pessoa, seja física ou jurídica, que efetue, normalmente em volume que
carac-terize finalidade comercial, operações de movimentação de bens ou serviços de transporte interestadual e intermunicipal.
Figura 6 – Arquitetura monolítica (fonte-própria)
que permitia a comunicação irrestrita entre os componentes; b) todo o sistema era executado em um único nó de processamento (Single thread); c) havia um acúmulo de múltiplas responsabilidades como a renderização da camada de apresentação, controle de estado dos objetos complexos, longos processamentos (síncronos) em background, processamento de lógicas de negócio, acesso a banco de dados e outros componentes de infraestrutura, como ilustra a Figura 6.
As escolhas realizadas para o desenvolvimento dessa estrutura trouxeram algumas consequência como: a implantação de um novo serviço ou uma nova versão exigia a
re-distribuição da solução por inteiro; ajustes nos parâmetros de aplicação forçavam a reinicialização do sistema para atualizações das configuração; uma baixa esca-labilidade, uma vez que o sistema foi construído para ser executado em uma única thread
de processamento e seu controle de estado de sessão não foi projetado para funcionar de forma distribuída; efeitos colaterais indesejados em serviços que não foram alterados devido a manutenções em áreas comuns do sistema; o baixo desempenho ocasionado pelo uso indiscriminado de alguns recursos do Framework web como o uso gerenciável de sessão para guarda de objetos muito complexos por muito tempo; por fim, o alto
acoplamento pela ausência de isolamento da lógica do serviço ocasionada pelo mal uso de
que um desenvolvedor “arrastasse” um componente para uma “página” e lhe atribuísse um comportamento do serviço em uma classe chamada Code-behind, a qual estava diretamente associada a página.
Figura 7 – Estrutura monolítica do sistema UVT (fonte-própria)
A Figura 7ilustra a relação desses componentes estruturais da arquitetura monolí-tica do sistema UVT. Nela é possível observar o forte acoplamento, através da relação entre os componentes de interface visual (página aspx) e a classe do code-behind. Devido esse alto acoplamento na camada de apresentação, o reaproveitamento de serviços tornou-se algo extremamente complexo, dada a total dependência das classes do serviços aos componentes de interface gráfica do framework web.
Outro aspecto negativo, é o compartilhamento de uma mesma entidade de negócio para todos os serviços de um mesmo contexto do domínio. Esse tipo de abordagem pode provocar ambiguidades sobre a entidade modelada, efeitos colaterais indesejados pelo alto risco de constantes mudanças e uma sobrecarga de responsabilidades, uma vez que a entidade precisa conhecer todos os comportamentos e propriedades de todos os cenários dos quais ela participa.
Com o passar dos anos, essa estrutura e a falta de boas práticas de engenharia de software, como a ausência de padrões e princípios de design, comprometeram a qualidade do sistema UVT. Além disso, os constantes efeitos colaterais ocasionados por bugs, o
aumento substancial de linhas de código, o uso indiscriminado dos recursos computacionais e a baixa escalabilidade do sistema o levaram a uma significativa queda do seu desempenho, o que tornou sua manutenção e usabilidade cada vez mais complexas.
Esses fatos motivaram a equipe a realizar uma avaliação crítica sobre a qualidade do sistema UVT. Nessa avaliação a equipe decidiu quantificar a dívida técnica do sistema afim de levantar os principais pontos de comprometimento da sua qualidade e manutenabilidade. Para isso foi adotado o uso de ferramentas de análise estática de código afim de identificar os problemas que afetam a base de código do sistema UVT 3. Essa avaliação revelou um acumulo da dívida técnica e indicou um preocupante quadro de decaimento na qualidade de software. O impacto negativo desse decaimento ficou evidente ao analisar as métricas obtidas.
A Tabela 1 apresenta a apuração dos registros da dívida técnica agrupados por categorias de correções. Nelas os dados são dispostos nas colunas Categorias, que re-presentam as categorias das regras violadas; esforço 4, que quantifica o esforço para desenvolver o elemento de código (apresentado em dias/horas/minutos); o custo (em R$), que representa o valor total de horas/homem 5 gastos com a correção; e as colunas que quantificam as correções por severidade Críticas, Altas, Médias e Baixas.
Analisando os dados da Tabela1é possível perceber que a categoria “Architecture” é a que apresenta maior endividamento técnico no que diz respeito a esforço e custo, respectivamente 176 dias e R$ 70.6 mil. Expandindo esta categoria (ver Tabela 2) podemos observar que o sistema precisa de correções de alto impacto como remover o acesso à camada de Dados a partir da Interface Gráfica de Usuário, relacionamentos que causam dependência circular e baixa coesão no empacotamento de componentes.
Totalizando esses dados, são 4.217 correções registradas, o que correspondem a 267 dias de esforço necessários para realizar as correções do sistemas UVT, o que corresponde a um custo total R$ 107K Hora/Homen. Em termos de severidade, as métricas obtidas pela ferramenta também indicaram que há uma necessidade de esforço para melhorar a qualidade do sistema UVT para resolver 72 correções críticas, 1.710 correções de alta-prioridade, 2.372 correções de média-prioridade e 63 correções de baixa prioridade.
Outro fator de impacto negativo levantado pela análise da equipe foi a ausência de
3 A ferramenta NDepend foi aqui utilizada para demonstrar valores totais da dívida técnica, bem como
categorizar os tipos de correção associados a essa dívida. Sua escolha se deu também pelo fato de se basear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediate language (IL) do .net framwork, abarcando assim todas as linguagens da família .net framework (C#, Visual Basic e F#) sob uma mesma ótica de análise (https://www.ndepend.com/)
4 O esforço é obtido pela relação de número homen-dia para desenvolver 1000 linhas de código. Por
padrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de código escritas por desenvolvedor em um dia
5 Os valores configurados para o calculo do custo foram: R$ 50,00 Hora/Homem, jornada de 8 horas
Tabela 1 – Métricas da dívida técnica do sistema UVT agrupadas pela categorias.
Dívida Correções
Catégoria Esforço Custo Críticas Altas Médias Baixas Total
.NET Framework System 6h45min 338 - 29 4 - 33 Collection 2h10min 108 - - 13 - 13 Globalization 3d1h 1.25K - - 179 - 179 Reflection 6h 30min 325 - 38 1 - 39 InteropServices 35min 29.2 - 3 4 - 7 System.Threading 40min 33.3 - 1 0 - 1 System.Xml 3h50min 192 - - 23 - 23 Project Rules Architecture 176d 70.6K 72 660 0 5 737 Code Smells 51d 20.6K - 108 164 1 273 Design 4d1h 1.65K - - 434 15 449 Immutability 17d7h 7.17K - 854 35 - 889
Naming Conventions 1h25min 70.8 - - 27 39 66
OOP Design 8d5h 3.46K - 2 832 3 837
Source Organization 3h45min 188 - 15 - - 15
Visibility 2d4h 1.02K - - 656 - 656
Total 267d 107K 72 1710 2372 63 4217
Tabela 2 – Métricas da dívida técnica da categoria “Architecture”.
Regras Correções Esforço Custo
UI layer shouldn’t use directly DAL layer 470 issues 155d 62.1K UI layer shouldn’t use directly DB types 166 issues 17d 3h 6.96K Avoid namespaces mutually dependent 93 issues 3d 0h 1.24K Avoid namespaces dependency cycles 3 issues 6h 0min 300 Namespaces with poor cohesion (RelationalCohesion) 5 issues 50min 41.7
Práticas contínuas como integração de código, entrega contínua, implementação contínua
e monitoramento durante o ciclo de vida do sistema UVT, o que tornava a implantação de versões do sistema um processo complexo e com baixa garantia de qualidade. Por exemplo, a ausência de mecanismos automatizados de integração de código-fonte para lidar com os conflitos gerados durante o desenvolvimento, reduziu a qualidade de verificação do código integrado, favorecendo o surgimento de bugs com maior frequência no ambiente de produção, algumas vezes provocando efeitos colaterais indesejados.
Nesse sentido, o alto endividamento técnico, a ausência de práticas contínuas, somados as demandas por renovação visual de seu portal Web e de prestação de serviços em dispositivos móveis intensificaram o desejo de modernização do sistema UVT. Contudo, essa modernização requereu muito mais do que a renovação de interfaces visuais (GUI) e a
adoção de técnicas de desenvolvimento para dispositivos móveis.
Na verdade, a ausência de uma camada de interoperabilidade do sistema UVT exigiu uma revisão da arquitetura do sistema e adequação da infraestrutura, considerando um re-design com foco no reuso, bem como uma reformulação nas abordagens empregadas para a construção e entrega de soluções de software orientadas a serviço. Nesse sentido, para a equipe de desenvolvimento da SET, a reestruturação do sistema UVT necessitava passar pela criação de um conjunto de serviços flexíveis e de fácil manutenção, robustos e capazes de responder a cenários de alta disponibilidade, bem como suportar grandes cargas de solicitações, garantindo coexistência com os sistemas existentes.
3.2
Processo adhoc
Dada a importância do sistema UVT para as atividades de arrecadação e fiscaliza-ção de tributos do Estado do Rio Grande do Norte, diante da insuficiência desse sistema responder satisfatoriamente aos requisitos de qualidade esperados como manutenibilidade e desempenho, além da crescente demanda por modernização visual e por interoperabi-lidade, a SET se viu diante da necessidade de uma migração iminente do sistema UVT. Para isso, em 2015 a SET manifestou sua intenção de reestruturar o sistema UVT no contexto do projeto PROFISCO-RN 6, financiado pelo BID (Banco Inter-Americano de
Desenvolvimento).
Num plano geral, o objetivo dessa reestruturação era proporcionar uma nova vida útil ao sistema UVT, tornando-a uma central de serviços mais segura, simples de usar, com visual moderno e com a possibilidade de inclusão de novos serviços. Além disso, proporcionar mais mobilidade aos usuários internos e externos através do desenvolvimento de aplicações próprias para dispositivos móveis como smartphones e tablets. Numa perspectiva visando benefícios futuros, a migração do sistema legado UVT é uma oportunidade de lidar com as problemáticas existentes, assim como uma oportunidade de se obter: a) os benefícios advindos da implantação bem-sucedida de um projeto SOA (ver 2.1); b) uma melhor manutenibilidade pelo pagamento contínuo da dívida técnica (ver 2.2); bem como, c) os benefícios pela adoção das práticas contínuas de DevOps(ver 2.3).
No intuito de alcançar essa metas de qualidade, a equipe de desenvolvimento da SET optou pela adoção de um processo de Reengenharia de Software para lidar com a crescente dívida técnica do sistema; SOA para lidar a falta reuso de aplicações e a ausência de interoperabilidade; e microsserviços e DevOps para lidar com a inflexibilidade da arquitetura monolítica e com processos complexos e não automatizado de implantação de sistemas. Esse processo inicialmente foi realizado de forma adhoc. No entanto, algumas
6 projeto de númeero BR-L1207: Projeto de Integração da Modernização da Administração Fiscal do Rio
iterações e a crescente maturidade adquirida sobre temas circundantes à migração de sistemas legados num contexto de pesquisa, foram direcionando esse processo para uma formalização que será tratada no Capítulo 4.
3.3
Considerações Finais
Neste capítulo foi contextualizada a migração do sistema UVT e apresentadas algumas características de projeto que limitam o reuso de software e comprometem a sua qualidade. Foram explanadas as problemáticas relacionadas à Dívida Técnica, Ausência de interoperabilidade, Arquitetura monolítica de sistema e processos de implantação inflexíveis. Além disso, foram apresentadas as motivações para a migração do sistema UVT, bem como as motivações para adoção de SOA, processos de Reengenharia de Software, microsserviços e DevOps.
4 PROCESSO SPREAD
Para atender as demandas do projeto de migração do sistema UVT e alcançar uma solução orientada à serviço moderna e bem-sucedida, a equipe de desenvolvimento da SET conduziu um processo de Reengenharia de Software tendo SOA como paradigma estratégico, microsserviços como tática de implementação e DevOps como prática contínua de integração, entrega, implantação e monitoramento. Dessa experiência, suportada pela pesquisa acadêmica, foi extraído um novo processo chamado SPReaD, que significa
Service-oriented Process for Reengineering and DevOps. Este capítulo é dedicado a explanação
desse processo. Para isso, uma rápida apresentação é descrita na Seção 4.1. Já a seção 4.2
apresenta como se deu a extração do processo e explana de forma geral como foi a definição de suas fases e atividades, que nas seções 4.3,4.4,4.5, 4.6 e 4.7 são detalhadas.
4.1
Visão Geral
O SPReaD consiste em uma instanciação do MSOAM para lidar com sistemas monolíticos legados. Esta instanciação é focada na Reengenharia de Software, incorporando aspectos do DevOps como meio para otimizar a entrega, implantação e monitoramento de serviços. A Figura 8ilustra a relação dessas “camadas” de tecnologias.
Figura 8 – Relação das camadas de tecnologias do processo SPReaD (fonte-própria).
é importante que se trace estratégias para que ele atinja as metas de qualidade desejadas, bem como sua dívida técnica seja diminuída e passe a ser gerenciada continuamente. Para isso, o SPReaD estabelece um conjunto de medidas: Adotar a Orientação a serviço como paradigma capaz guiar a Reengenharia de Software na identificação e modelagem de serviços a partir da engenharia reversa do sistema legado. Aplicar Reengenharia de
Software para decompor o sistema monolítico em pequenos componentes de serviço de fácil
manutenção, maior autonomia, reuso e capacidade de compor modernas soluções orientadas a serviço; Adotar práticas contínuas para melhorar a qualidade de implantação e monitoramento do sistema. As medidas antes descritas podem ser observadas na Figura 9.
Figura 9 – Estratégia e Táticas do SPReaD (fonte-própria).
Além disso, é preciso que hajam elementos táticos que indiquem como proceder para migrar sistemas monolíticos legados para uma solução orientada a serviço. Nesse sentido, o SPReaD adota os padrões do catálogo SOA para estruturar inventários de serviço afim de construir soluções utilizando tanto abordagens clássicas de SOA como
Enterprise Service Bus (ESB), ou abordagens mais recentes como microsserviços.
Em resposta a um cenário no qual serviços necessitam de mais autonomia no desenvolvimento e implantação - para satisfazer as exigências das mudanças de negócio cada vez mais dinâmicas - as abordagems escolhidas foram a de microsserviços, DevOps e
Domain-Driven Design (DDD) (EVANS, 2003). A definição do que venha ser um serviço “micro” na visão do SPReaD aqui é estabelecido pelos conceitos de Contextos Delimitados (Bounded Context) (EVANS,2003) definidos dentro de um Inventário de Serviço, o que
4.2
Extração do Processo
Para lidar com essas abstrações do MSOAM é preciso um processo adaptável que possibilite a escolha de um conjunto apropriado de ações e tarefas que absorva as etapas de um projeto de reengenharia como foco na implantação de SOA. A forma adotada para alcançar esse processo foi a acomodação do MSOAM no framework de processo genérico descrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016), que compreende cinco fases metodológicas: Comunicação, Planejamento , Modelagem, Construção e Implantação.
Essas fases principais do framework de processo descrito por Pressman e Ma-xim (PRESSMAN; MAXIM, 2016) englobam um conjunto de etapas: Análise e Design em suporte a Modelagem; Codificação, Teste em suporte a Construção; e Entrega,
Suporte e Feedback em suporte a Implantação. Uma atenção deve ser reservada a fase
de Comunicação, que recebeu um conjunto de atividades específicas para lidar com a coleta de requisitos e gestão da dívida técnicas, não abarcadas pelo MSOAM. A Figura 10
representa as etapas de acomodação das atividades do MSOAM no framework de processo descrito por Pressman e Maxim (PRESSMAN; MAXIM, 2016).
Figura 10 – Processo de encaixe do MSOAM no framework de processo de Pressman e Maxin (fonte-própria).
O objetivo dessa acomodação foi estabelecer a base de um processo de Reengenharia de Software completo, pelo qual camadas de tecnologias como SOA e DevOps possam se manter coesas e o desenvolvimento de software possa ser conduzido de forma racio-nal (PRESSMAN; MAXIM,2016). Como resultado disso a identificação das atividades do MSOAM dentro de um processo tornou-se mais contundente.
na qual foram acrescentadas atividades pertinentes a Reengenharia de Software como
Engenharia Reversa e Engenharia Direta, bem como as relacionadas a DevOps como Prática Contínuas (CI, CDE, CD) e Monitoramento. A identificação de todas essas
fases possibilitou ao MSOAM alcançar uma abstração mais próxima da instanciação de um processo de software que contempla a relação entre SOA, Reengenharia e DevOps. Esta instância denominamos de SPReaD (SOA Process, Reengineering and DevOps). A Figura 11 ilustra a estrutura completa desse processo.
Figura 11 – Estrutura completa do processo SPReaD (fonte-própria).
De forma geral, as fases do processo SPReaD podem ser compreendidas da seguinte forma: A fase Comunicação é dedicada à compreensão dos objetivos dos Stakeholders para o projeto e à coleta de requisitos que auxiliem na compreensão das funcionalidades de software e atributos de qualidades esperados. Esta fase marca o início do projeto de migração. Por sua vez, a fase de Planejamento envolve a atividade de Plano de Adoção de SOA, que descreve o escopo do projeto, os recursos necessários, os riscos envolvidos, um cronograma de trabalho e os produtos resultantes. Estas atividades são organizadas em um plano.
Dado o foco em reengenharia, a fase de Modelagem é dedicada a aplicação das atividades de Análise e Design para identificar modelos que atendam as necessidades de desenvolvimento de software. A Análise compreende o uso de Engenharia Reversa para se obter do sistema legado informações que colaborem na identificação de serviços candidatos que compartilem os mesmos limites conceituais. Para isso, são executadas as atividades de
Análise de Inventário de Serviço; e Análise Orientada a Serviço.
No tocante ao Design, são executadas as atividades de Design Orientado a
Serviço e Design da Lógica de Serviço, que marcam o início da Engenharia Direta,
cujo foco é o re-design e re-arquitetura da solução, bem como a elaboração de contratos de serviços. A fase Construção é marcada pela implementação das estruturas modeladas no Design. Para isso, a Codificação e o Teste são conduzidos respectivamente pela atividades de Desenvolvimento de Serviço e Teste de Serviço, que completam a Engenharia
Direta pela geração de código e testes necessários para migrar as funcionalidades do sistema legado e as encapsular em novas estruturas.
A fase de Implantação, está dividida em duas partes: na primeira são executadas as atividades de Implantação e Manutenção de Serviço, responsáveis pela entrega de software como entidade completa ou como incremento. Essa fase está associada às práticas contínuas do DevOps. Em seguida, a etapa de Suporte e Feedback é conduzida pelas atividades de Uso e Monitoramento de Serviço, Descoberta de Serviço e
Versio-namento e Retirada de Serviços, respectivamente para realização do monitoramento
contínuo dos serviços e infraestrutura, descoberta de serviços em seus inventários, bem como para identificação da necessidade de alteração na versão do serviço ou sua retirada de um inventário.
As fases do SPReaD, descritas anteriormente são conduzidas num fluxo de um processo evolucionário, “um modelo iterativo que possibilita desenvolver versões cada vez mais completas do software” (PRESSMAN; MAXIM,2016, p. 45). Nesse fluxo o SPReaD é aplicado iterativamente executando todas as fases do processo para planejar, modelar, construir e entregar Inventários de serviços. Nesse sentido, a entrega de um Inventário determina um escopo de uma ou mais iterações, com cada iteração contribuindo com a ampliação do blueprint de Inventário de serviços.
Essa visão geral captura a essência do processo SPReaD, aplicado nos últimos anos para modernizar o sistema UVT. As seções a seguir detalharão as atividades, artefatos e praticas de cada fase do processo. Ressaltamos que as fases de Comunicação e
Planeja-mento foram executadas dentro de um processo adhoc, antes da formalização do processo SPReaD em si. Sendo assim, elas estão aqui descritas no intuito de serem registradas como fases importantes que precisam ser executadas. Já as fases de Modelagem, Construção e Implantação serão apresentadas com um nível maior de profundidade.
4.3
Comunicação
A comunicação é uma das primeiras fases do processo SPReaD. Nela os requisitos iniciais do projeto são coletados e documentados no intuito de definir as necessidades para atingir os objetivos pretendidos pelos stakeholders.
4.3.1
Atividades
Como ilustrado na Figura12, esta fase executa a atividade da Coleta de
Requi-sitos que inicia-se com a Definição de um Grupo de Foco envolvendo os stakeholders
do projeto para se obter informações, experiências e requisitos iniciais que auxiliem na fragmentação do problema em partes menores e mais gerenciáveis. Uma vez que o foco do processo é a reengenharia do sistemas legados, é importante que sejam extraídas métricas
Figura 12 – Fase de Comunicação do SPReaD (fonte-própria).
desse sistema no início do processo de migração para que haja um ponto de comparação que evidencie se a equipe alcançou ou não seus objetivos de migração.
Nesse sentido, a fase de comunicação do SPReaD adota como métrica o Calculo da
Dívida Técnica Atual do Sistema Legado. Ao Comunicar essa Dívida Técnica
aos stakeholders é fornecido um “retrato” da qualidade atual do sistema legado. O intuito disso é conscientizar a todos sobre os pontos críticos do sistema e quais as práticas que devem ser revistas durante o ciclo de desenvolvimento de software. Por fim, os princípios da Orientação a Serviço são utilizados como referência durante a Definição de Requisitos
Gerais(ver2.1) para antecipar a identificação de elementos que favoreceram a formalização de contratos, serviços reutilizáveis e composição.
4.3.2
Artefatos
Um dos artefatos produzidos nessa fase é o Documento de Visão Geral, que fornece um conjunto de requisitos para executar a migração do sistema legado, bem como um conjunto de metas e atributos de qualidade a serem alcançados. Além disso, também é gerado um Relatório da Dívida Técnica, cujo principal objetivo é deixar claro qual é o ponto de partida da migração, quais são os atributos de qualidade mais comprometidos e o impacto disso no sistema em sua versão atual.
