Reengenharia de um sistema de software de gestão e rastreabilidade logística

Universidade do Minho Escola de Engenharia Departamento de Informática Luís Carlos da Silva Marques Reengenharia de um sistema de software de gestão e rastreabilidade logística Outubro 2019 Universidade do Minho Escola de Engenharia Departamento de Informática Luís Carlos da Silva Marques Reengenharia de um sistema de software de gestão e rastreabilidade logística Dissertação de Mestrado Mestrado Integrado em Engenharia Informática Dissertação supervisionada por Professor Doutor João Miguel Fernandes Outubro 2019 DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. i AGRADECIMENTOS A dissertação que agora se apresenta resultou de um trajeto longo do qual fui recebendo o maior apoio e estímulo de muitos. Nesse sentido, os méritos que ela possa ter, devem-se aos contributos dessas pessoas. Aproveito esta oportunidade para agradecer a essas pessoas, começando pelos meus pais, sempre presentes, pelo constante apoio e suporte nas mais diversas etapas deste meu trajeto. De seguida agradeço à Patrícia Carvalho pelo incentivo constante e motivação em momentos de maior fragilidade. Gostaria de agradecer também a todos aqueles que me acompanharam no meu percurso académico, com especial apreço a João Gonçalves e Carina Carvalho. Agradeço também ao Professor Doutor João Miguel Fernandes pela orientação e disponibilidade exibidas durante o processo de redação desta dissertação. Por fim, agradeço ao meu supervisor na empresa, Eng. Tiago Martins, por todos os ensinamentos que me transmitiu e pela orientação nesta minha jornada, na Bosch CM. ii DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducentes à sua elaboração. Mais declaro que conheço e que respeito o Código de Conduta Ética da Universidade do Minho. iii RESUMO Ninguém consegue ficar indiferente à importância da tecnologia no nosso dia-a-dia. A Bosch, como líder de mercado e parte desta evolução, no âmbito de um projeto em parceria com a Universidade do Minho desenvolveu um sistema capaz de monitorizar toda a cadeia de abastecimento interno. A este sistema deram o nome de Smart Internal Supply Chain. Este sistema utiliza a tecnologia RFID para localizar as caixas Bosch, que transportam a matéria prima, dentro da Bosch. Devido à importância do SISC na industria 4.0, a Bosch CM decidiu investir fortemente em hardware, sobre na tecnologia RFID, e em desenvolvimento de processos e software. Com o passar do tempo, o SISC foi-se deteriorando, tornando-se lento e mal estruturado, devido ao elevado número de manutenções que foi sofrendo. Estes problemas tiveram um grande impacto negativo na operação logística colocando em causa a viabilidade do sistema e os seus benefícios. Detetados estes problemas e devido ao elevado investimento já efectuado, o autor decidiu estudar e aplicar um processo de reengenharia ao SISC, com o objetivo de aumentar o seu desempenho e resolver o problema do grande volume de dados. Durante este processo, foram descartadas funcionalidades obsoletas que criavam entropia no sistema, bem como eliminadas repetições de dados e funcionalidades e foram eliminados vários codesmells. Palavras-chave: Reengenharia, Sistemas, Software, Logística, Rastreabilidade, Reestruturação. iv ABSTRACT No one can remain indifferent to the importance of technology in our daily lives. Bosch, as a market leader is part of this evolution, in one partnership project with University of Minho, Bosch has developed a system capable of monitoring the entire internal supply chain. They named this system as Smart Internal Supply Chain. This system uses RFID technology to locate Bosch containers carrying the raw material within Bosch. Due to the importance of SISC in industry 4.0, Bosch CM has decided to invest heavily in hardware, RFID technology, and software and process development. Over time, the SISC has deteriorated, becoming slow and poorly structured due to the high number of maintenance it has undergone. These problems had a major negative impact on the logistics operation by undermining the viability of the system and its benefits. Having detected these problems and due to the high investment already made, the development team decided to study and apply a reengineering process to SISC in order to increase its performance and solve the problem of having a high volume of data. During this process, obsolete features that created system entropy were discarded, data repetitions and features were eliminated, and several codesmells were deleted. Keywords: Reengineering, Systems, Software, Logistics, Traceability, Refactoring. v CONTEÚDO 1 introdução 1 1.1Contextualização 1 1.2Motivação 1 1.3Objetivos da dissertação 3 1.4Estrutura do documento 4 2 estado da arte da reengenharia de software 5 2.1Introdução à reengenharia 5 2.2Motivação para a reengenharia 6 2.3Como efetuar reengenharia de software 7 2.4Engenharia reversa 7 2.4.1Dificuldades inerentes à engenharia reversa 8 2.5Engenharia direta e reestruturação 8 2.5.1Identificação das falhas e as áreas a reestruturar 9 2.5.2Reestruturação, técnicas e formalismos 10 2.5.3Programas 11 2.5.4Requisitos do sistema 12 2.5.5Arquitetura de software 12 3 definição e análise do sistema atual 16 3.1Análise do processo 16 3.2Análise da integração com outros sistemas 17 3.3Análise arquitetural e tecnológica 20 3.3.1Arquitetura do sistema 20 3.3.2Deployment da aplicação 26 4 problemas,factos e objetivos para uma novas soluçãos 28 4.1Métricas e impacto do sistema anterior na envolvente 28 4.2Factos a ter em conta para novas soluções 30 5 desenho e desenvolvimento de uma nova solução 32 5.1Alterações ao processo 32 5.2Definição da integração com outros sistemas 33 5.3Análise económica 35 5.4Seleção das tecnologias a utilizar 36 5.5Especificação da nova solução 36 5.5.1Arquitetura do sistema 36 5.5.2Deployment da aplicação 41 6 soluções encontradas e respetivo impacto 43 6.1Solução encontrada para cada problema 43 6.2Resultados obtidos e comparação entre as métricas dos sistemas 45 7 conclusão 47 vi Conteúdo vii Apêndice a remoção de codesmells 48 Apêndice b configuration app 49 1.2. Motivação 2 Dada a elevada importância deste projeto, a Bosch CM tomou a decisão de implementar este software no chão de fábrica, tendo-se iniciado pela implementação de um piloto que superou os objetivos esperados. Este piloto rastreava quatro materiais em dois supermercados, o que representava cerca de 0,14% dos pedidos diários de abastecimento do armazém para as linhas de produção. Com estes resultados, a Bosch CM tomou a decisão de equipar todos os supermercados e etiquetar todas as caixas Bosch com etiquetas RFID, para assim começar a aumentar gradualmente o número de materiais a serem rastreadas. Ao fim de um mês o SISC rastreava cerca de trinta materiais, o que representava aproximadamente de 1,2% dos pedidos diários. Apesar do notório aumento dos materiais e da rastreabilidade, o aumento da carga no sistema SISC não foi benéfico e, devido à sua complexidade, novos problemas foram surgindo. Com tantos ajustes e correções, o SISC revelou-se mal estruturado, lento e com um código-fonte cheio de codesmells. Motivados pelo elevado investimento no hardware, sobretudo na tecnologia RFID, pelo tempo despendido em desenvolvimento de processos, bem como pela importância da rastreabilidade no contexto da indústria 4.0, o autor decidiu estudar e aplicar um processo de reengenharia ao sistema. 1.3. Objetivos da dissertação 3 1.3 objetivos da dissertação Como anteriormente identificado, o sistema SISC é o resultado de um esforço conjunto entre a Bosch CM e a UM, tendo sido criado especificamente pela necessidade de rastrear o fluxo da MP na cadeia de abastecimento interna desde o armazém até ao seu consumo nas linhas de produção. A reengenharia do SISC destina-se a melhorar aspetos considerados cruciais para o desempenho do sistema e a manutenção do mesmo. Neste seguimento, a presente secção visa descrever os objetivos que se pretendem alcançar com esta reestruturação: •Melhorar o desempenho do sistema SISC Com o objetivo de solucionar os problemas descritos anteriormente, uma das etapas passa por reformular os processos complexos de forma a aumentar o desempenho do sistema e reduzir o impacto no ambiente em que se integra. •Reduzir o Mean Time to Repair (MTTR) e aumentar o Mean Time to Failure (MTTF) Aquando do desenvolvimento do SISC, a equipa não teve em conta a manutenção do software, o que provoca atualmente atrasos nas manutenções e põe em causa o fluxo de abastecimento interno, não só pelo elevado número de máquinas, como também pela má estruturação do software. Portanto é necessário aumentar o Mean Time between Failures (MTBF), dado pela expressão algébrica: MTBF =MTTF +MTTR (1) Por outras palavras, o objetivo passa por maximizar o MTBF, minimizando o MTTR. •Melhorar o processo de rastreabilidade da MP A melhoria dos dois parâmetros acima referidos desencadeia a melhoria da rastreabilidade da MP. A atual dificuldade de rastreabilidade da MP, devido a problemas do sistema, dificulta o processo de planeamento da produção e o processo de abastecimento das linhas de produção. Em casos extremos pode ainda causar atrasos na produção devido à falta de MP. O grande objetivo desta reestruturação é resolver este problema. 1.4. Estrutura do documento 4 1.4 estrutura do documento Após analisar Von Alan et al. (2004) decidiu-se que a presente dissertação assentaria na metodologia Design Science Research, que visa a construção de soluções tecnológicas para um dado problema, passíveis de demonstração através de métodos de avaliação bem definidos. Desta forma, este documento encontra-se dividido em sete capítulos que descrevem os principais passos adotados no desenvolvimento da solução proposta: •OCapítulo 1apresenta uma breve contextualização do ambiente, bem como a motivação e os objetivos de investigação do projeto. •OCapítulo 2apresenta o estado da arte da reengenharia de software. •OCapítulo 3apresenta a definição e análise do sistema alvo de reengenharia de software. •OCapítulo 4apresenta a formulação dos problemas subjacentes a esta dissertação bem como os factos importantes definidos pela organização a ter em vista na resolução dos problemas levan. •OCapítulo 5descreve o design da arquitetura, assim como o desenvolvimento dos processos utilizados na solução proposta. •OCapítulo 6apresenta os principais resultados decorrentes da implementação da nova solução, sendo ainda efetuada uma comparação entre as métricas derivadas do sistema proposto com as métricas do sistema atual. •OCapítulo 7apresenta as conclusões da dissertação, como também potenciais soluções para trabalho futuro. 2 ESTADO DA ARTE DA REENGENHARIA DE SOFTWARE Atualmente, a investigação e a inovação de sistemas são de extrema importância para as organizações inseridas em contextos competitivos. Nestes contextos, torna-se assim necessária a adoção de novas tecnologias de processos que sustentem, de forma eficiente, a gestão das cadeias de abastecimento das organizações. No que concerne à implementação de novos processos, a adoção de práticas de melhoria contínua (do conceito lean management) é encarada como uma ferramenta indispensável na otimização de processos, particularmente na implementação de metodologias sistemáticas que visam a eliminação de desperdícios e de atividades sem valor acrescentado (Freitas et al., 2017). O conceito de melhoria contínua tem vindo a acompanhar todo o desenvolvimento tecnológico e oferece às empresas vantagens competitivas relevantes de modo a poderem responder aos seus clientes, de forma rápida e confiável (Brintrup et al., 2010; Powell and Skjelstad, 2013). No entanto, Powell and Skjelstad (2013) e Riezebos et al. (2009) defendem que a adoção e implementação de princípios lean devem ser combinados com o desenvolvimento tecnológico, com o intuito de permitir uma gestão cada vez mais eficiente das cadeias de abastecimento. O conhecimento do estado dos materiais em trânsito, ao longo da cadeia de abastecimento, requer a recolha sistemática de grandes quantidades de informação. Neste sentido o uso de sistemas automáticos de identificação, como o RFID, permitem a obtenção de grandes quantidades de dados em tempo real (McFarlane and Sheffi, 2003). A simbiose entre a tecnologia e o processo é particularmente importante nas cadeias de abastecimento com diversos materiais, nas quais a gestão e controlo de inventários dependem não só de mecanismos capazes de monitorizar o fluxo de materiais, mas também na criação de mecanismos inteligentes capazes de agilizar a interação entre os diversos membros da cadeia (MacDougall, 2014). Na construção de tais mecanismos, a reengenharia de software desempenha um papel fundamental na criação de soluções funcionais associadas a um alto desempenho e fiabilidade Pressman (2015). Na próxima secção, serão apresentados alguns dos conceitos mais importantes no domínio da reengenharia de software. 2.1 introdução à reengenharia Ao longo do tempo, as tecnologias de informação estão, cada vez mais, a dominar as operações e atividades do quotidiano. De uma forma geral, os softwares estão contidos implicita ou explicitamente nas mais diversas operações e contextos industriais, fazendo com que a engenharia de software represente um domínio de investigação extremamente importante (Pfleeger and Atlee, 2010, p.1). Conceptualmente, a engenharia de software resolve problemas relacionados com o estabelecimento 5 2.2. Motivação para a reengenharia 6 de processos, métodos, técnicas e ferramentas para o desenvolvimento de software. Em particular, a engenharia de software revela-se uma ferramenta importante na adaptabilidade dos sistemas a mudanças ao nível da tecnologias e/ou dos requisitos de negócio que, por sua vez, são praticamente inevitáveis face à crescente competitividade dos mercados e indústrias tecnológicas (Sommerville, 2016, p.61). Todavia, de forma a permitir que um dado sistema se torne escalável e flexível face às necessidades dos utilizadores, a manutenção do software a ele associada deve ser encarada como um atributo importante para garantir a eficiência do sistema. Segundo Chikofsky and Cross (1990), a variedade de problemas que envolve manutenção de software cresce constantemente, uma vez que as soluções não acompanham essa evolução. Estes problemas são, muitas vezes, resultantes de código fonte e documentação mal elaborados, para além da falta de compreensão do sistema. Seguindo a lei da mudança contínua (Pressman, 2015, p.796), um dado software deve ser continuamente adaptado, independentemente das técnicas e metodologias aplicadas aquando da criação do projeto. A dificuldade em atualizar continuamente o software tem motivado a investigação de soluções que diminuam o seu custo de desenvolvimento, garantam um tempo de vida maior e facilitem a sua manutenção (Nierstrasz et al., 2005). Neste contexto, surge assim o contexto de reengenharia de software que, seguindo Chikofsky and Cross (1990), pode ser definida como o "processo de análise e alteração de um sistema, reconstruindo-o e reimplementando-o com novas tecnologias”. À luz do anteriormente exposto, os processos de reengenharia de software tornam-se numa condição necessária para a sustentabilidade e funcionalidade do sistema no ambiente dinâmico em que se encontra. Não obstante, a condução de processos de reengenharia de software pode revelar-se uma tarefa bastante complexa dada a eventual necessidade de redocumentação do sistema, de reestruturação da sua arquitetura, ou mesmo de uma mudança ao nível das linguagens de programação utilizadas na sua conceção. 2.2 motivação para a reengenharia Regra geral, os processos das empresas são influenciados por diversos fatores, tais como a necessidade de melhoria da qualidade dos serviços e produtos oferecidos, a explosão tecnológica, o rápido crescimento do conhecimento humano, ou ainda a maturidade dos mercados de consumo (Hammer and Champy, 2009). Outros fatores estão relacionados com a complexidade das atividades empresariais, tais como a procura da produtividade, a flexibilidade face às constantes mudanças, a concentração no ramo de negócio, ou até os relacionamentos com clientes e meio envolvente. Assim, a natureza bastante errática de muitos destes fatores motiva, direta ou indiretamente, a reengenharia dos softwares existentes nas empresas (Hammer and Champy, 2009). Para além disso, todos os sistemas tem um tempo de vida limitado, sendo que cada alteração efetuada pode degenerar a sua estrutura, fazendo com que as manutenções se tornem cada vez mais difíceis e dispendiosas (Jacobson and Lindström, 1991). 2.3. Como efetuar reengenharia de software 7 2.3 como efetuar reengenharia de software O processo de reengenharia de software é constituído por duas fases distintas - engenharia reversa e engenharia direta - que se relacionam segundo a expressão Reengenharia =Engenharia Reversa +Engenharia Direta Na primeira, o software objeto de reengenharia, é criteriosamente estudado, para que seja compreendido o seu funcionamento. Na segunda fase, o software é reconstruído, da forma desejada, sendo incluídos os ajustes necessários de forma a cumprir os novos requisitos. O processo de reengenharia é ilustrado na Fig. 1. Figura 1.: Processo reengenharia de software. Na Tabela 1podemos analisar e comparar as duas etapas de um processo de reengenharia ao longo das diversas fases do seu ciclo de vida. Os processos de engenharia reversa e direta são descritos, com mais detalhe, nas secções seguintes. Tabela 1.: Ciclos do processo de reengenharia (Barbosa and Cândido, 2017). Ciclo do processo Engenharia Reversa Engenharia Direta Início Análise do sistema atual para obter uma visão mais abstrata do sistema. Estudo da documentação do projeto para planear a reestruturação do sistema. Desenvolvimento Documentar o sistema a partir dos resultados obtidos com a análise inicial. Reestruturação do sistema antigo ou criação de um novo. Conclusão Documentação do projeto atualizada e coerente com a realidade do sistema. Novo sistema ou partes do código reestruturadas e condizentes com a documentação do projeto. 2.4 engenharia reversa A engenharia reversa teve origem na análise do hardware de sistemas comerciais ou militares (Chikofsky and Cross, 1990). Uma vez que não existe conhecimento sobre a sua conceção original, o 2.5. Engenharia direta e reestruturação 8 objetivo da engenharia reversa é deduzir as decisões tomadas acerca do design dos produtos. Nos dias de hoje esta técnica é fortemente usada em sistemas de software. A engenharia reversa de software foca-se não só no estudo das metodologias e tecnologias utilizadas no desenvolvimento de sistemas de software, mas também na qualidade e na produtividade dos sistemas a desenvolver (Rugaber, 1995). Chikofsky and Cross (1990) define engenharia reversa como o processo de identificação das componentes do software e das suas relações. A engenharia reversa é tipicamente utilizada em três das grandes atividades da engenharia: •Redocumentação Envolve a criação ou revisão da documentação de um sistema de software. •Reestruturação É a transformação lateral do sistema mantendo as funcionalidades e a semântica. •Reengenharia Numa primeira etapa utiliza a engenharia reversa e numa etapa posterior utiliza a engenharia direta. Na maioria dos casos o processo de reengenharia envolve redocumentação e reestruturação. 2.4.1Dificuldades inerentes à engenharia reversa A complexidade associada à engenharia reversa surge, maioritariamente, das seguintes dificuldades (Rugaber, 1995): •Domínio da aplicação -> Linguagem de programação É extremamente complexo perceber o que está programado conhecendo apenas o domínio da aplicação. •Detalhes do programa -> Abstração e design de alto nível Conceitos simples e abstratos facilmente se perdem nos detalhes minuciosos dos programas. •Estruturação original do sistema -> Sistema Atual Mesmo com boa documentação referente à estrutura original do sistema, com o passar dos tempos a manutenção provoca um decaimento na sua estrutura. Atualmente a engenharia reversa é altamente dependente da interação humana. Apesar de existirem ferramentas de apoio, estas não são suficientemente automatizadas. 2.5 engenharia direta e reestruturação Como visto anteriormente, os diversos sistemas de software carecem de uma constante manutenção de forma a satisfazerem os requisitos funcionais, ou não funcionais, ditados pelo(s) utilizador(es) do sistema. Ao mesmo tempo, tal manutenção de um dado sistema de software aumenta os custos totais de desenvolvimento para a organização (Coleman et al., 1994). Neste contexto, surge o conceito de reengenharia de um sistema, comummente conhecido como refactoring (Fowler, 2018). A Reestruturação é um tipo de engenharia direta que Chikofsky and Cross (1990) define como sendo a transformação de uma forma de representação para outra no mesmo nível de abstração, 2.5. Engenharia direta e reestruturação 9 preservando o comportamento externo do sistema. Este tema foi introduzido, pela primeira vez, por Opdyke (1992) que definiu Reestruturação como sendo o "processo de mudança de um sistema de software, de tal forma que não altera o comportamento externo do código, mas melhora a sua estrutura interna". Embora a reestruturação crie novas versões que implementam ou propõem alterações ao sistema, normalmente não envolvem modificações causadas pelos novos requisitos. No entanto, pode levar a observações importantes que sugerem mudanças para futuras melhorias do sistema. São vários os casos em que se deve aplicar refactoring, sendo os mais comuns a deterioração dos sistemas e as alterações de paradigmas (Fanta and Rajlich, 1999). As principais atividades da reestruturação de software prendem-se com: identificar as falhas e as áreas a reestruturar; definir e documentar as alterações a aplicar; garantir que as funcionalidades e a semântica se mantêm intactas; avaliar os efeitos da reestruturação na qualidade do software; manter a consistência do sistema. Cada um destes tópicos é explicitado nas próximas secções. 2.5.1Identificação das falhas e as áreas a reestruturar Primeiramente determina-se com exatidão qual o nível de abstração que o refactoring deve atingir. Posto isto, e com base na abstração determinada, é necessário executar duas atividades: 1. Identificar quais as partes do programa que necessitam de reestruturação; 2. Definir as alterações a aplicar nas partes identificadas. Provavelmente a técnica mais comum para detetar quais as partes do programa que necessitam de reestruturação é a identificação de codesmells. Segundo Fowler (2018), impulsionador deste tema, codesmells são pedaços de código que, atendendo à sua estruturação, motivam uma reestruturação. Fowler (2018) associa informalmente codesmells ao refactoring, contudo realça que identificação dos locais do código com necessidade de refactoring é altamente dependente do domínio da aplicação. Garantir que as funcionalidades e a semântica se mantêm intactas Por definição, uma reestruturação não deve alterar o comportamento do software. A definição clássica de preservação do comportamento estabelece que para um conjunto de valores de entrada, o sistema deve devolver os mesmos valores de saída antes e depois da reestruturação (Opdyke, 1992). No entanto, verifica-se que tal definição não é suficiente uma vez que muitos aspetos do comportamento do sistema podem ser importantes, ou seja, não se pode olhar só para o início e para o fim de um processo. Exemplos de alguns aspetos específicos do domínio do software são: •Para um software integrado, é necessário avaliar as condições de memória e energia; •Para um software de segurança crítica, é importante analisar as rules do sistema; •Para um software em tempo real, é necessário ter em consideração os tempos de execução; 2.5. Engenharia direta e reestruturação 10 Avaliar os efeitos da reestruturação na qualidade do software Em qualquer software é possível definir os atributos de qualidade externos ou de utilizador, sendo eles: •Robustez; •Extensibilidade; •Reutilização; •Desempenho; •Segurança; •Escalabilidade. Uma reestruturação tem como objetivo aumentar os valores dos atributos de qualidade externos. Por isso, a reestruturação a aplicar deve ser focalizada consoante o tipo de atributo da qualidade a melhorar. Uma reestruturação pode melhorar os atributos externos, mas também pode alterar os atributos de qualidade interna, podendo agravar: •o tamanho da aplicação; •a complexidade; •o acoplamento; •a coesão. A característica mais importante que pode ser melhorada com a reestruturação é o desempenho. Demeyer (2002) concluiu que o desempenho do programa melhoraria depois de uma reestruturação devido ao polimorfismo dos métodos. No contexto da lógica de programas funcionais, a reestruturação tem o objetivo de melhorar o desempenho do programa mantendo a sua semântica. 2.5.2Reestruturação, técnicas e formalismos Existe uma grande variedade de técnicas de reestruturação. Algumas delas são: •Melhorar a composição dos métodos; •Mover recursos entre objetos; •Melhorar a organização dos dados; •Simplificar as expressões condicionais; •Simplificar as chamadas de métodos; •Generalizar as funcionalidades. De seguida aprofundar-se-á cada uma destas técnicas, sendo que numa reestruturação podem e devem ser utilizadas várias técnicas. 2.5. Engenharia direta e reestruturação 11 Melhorar a composição dos métodos Uma grande parte de uma reestruturação é dedicada à correção da composição dos métodos. Na maioria dos casos, métodos excessivamente longos são a raíz dos problemas. Os pedaços de código dentro desses métodos escondem a lógica da execução e tornam o método extremamente difícil de entender e mais difícil de mudar. Esta técnica simplifica os métodos, remove a duplicação de código e simplifica melhorias futuras. Mover recursos entre objetos Esta técnica aplica-se em casos em que se tenha optado por distribuir funcionalidades por várias classes diferentes de uma forma defeituosa. Mostra como mover com segurança funcionalidades entre classes, criar novas classes e ocultar detalhes de implementação de acesso público. Melhorar a organização dos dados Estas técnicas de refactoring ajudam na reestruturação da base de dados. Outro formalismo desta técnica é substituir tipos primitivos por uma enorme gama de classes. Por outro lado, outro resultado importante desta técnica prende-se com o desmembramento das associações entre classes, o que torna as classes mais portáteis e reutilizáveis. Simplificar expressões condicionais As condições tendem a ficar, logicamente, mais complicadas ao longo do tempo. Esta técnica pretende combater isso. Simplificar as chamadas de métodos Estas técnicas tornam as chamadas de métodos mais simples e fáceis de entender. Isto, por sua vez, simplifica as interfaces para a interação entre classes. Generalizar as funcionalidades A abstração tem o seu próprio grupo de técnicas de reestruturação, principalmente associadas às funcionalidades e aos atributos ao longo da hierarquia de herança de classes, criando novas classes e interfaces e substituíndo a herança pela atribuição e vice-versa. 2.5.3Programas Com o decorrer dos anos, já foram efetuadas reestruturações em todas as linguagens e paradigmas de programação. Algumas delas foram até alvos de estudos, como podemos ver na Tabela 2. 3.2. Análise da integração com outros sistemas 18 retornado pelo SAP for inferior ao valor da quantidade recebido do KALO, o reembalamento não pode ser efetuado. Caso contrário, o SISC fica à espera da informação referente à uma leitura RFID proveniente do CrossTalk, com a informação referente à etiqueta RFID e ao posto onde foi lida. De seguida, o SISC executa o Pairing, criando uma Transfer Order (TO) em SAP para que a caixa com o material reembalado seja transportada do reembalamento para o supermercado. Para finalizar, o SISC envia a informação referente ao Pairing para o KALO, e para o CrossTalk que por sua vez irá reencaminhar para o SAP. Na Fig. 5está representado o diagrama de sequência deste processo. Figura 5.: Diagrama de sequência do processo de pairing. •Pórtico de reabastecimento Com a passagem das caixas no pórtico de reabastecimento, as TOs criadas no reebalamento são confirmadas. Nesta Zona o SISC ao receber as leituras RFID provenientes do CrossTalk, faz um pedido de confirmação de TO para cada uma das caixas lidas. 3.2. Análise da integração com outros sistemas 19 Na Fig. 6está representado o diagrama de sequência deste processo. Figura 6.: Diagrama de sequência do processo do pórtico de reabastecimento. •supermercados Quando é feito o movimento de putaway de uma caixa no supermercado, o CrossTalk envia a leitura da caixa e da posição no supermercado para o SISC, para que assim possa ser feita a gestão e digitalização do supermercado. Na Fig. 7está representado o diagrama de sequência deste processo. Figura 7.: Diagrama de sequência do processo nos supermercados. •Pórtico de consumo Com a passagem no pórtico de consumo, o SISC recebe do CrossTalk as leituras das caixas para que seja feito o movimento de picking do supermercado. Ao receber as leituras, o SISC irá também fazer um pedido de esvaziamento do Kanban para o KALO, para que este possa efetuar um novo pedido de material ao armazém. Na Fig. 8está representado o diagrama de sequência deste processo. 3.3. Análise arquitetural e tecnológica 20 Figura 8.: Diagrama de sequência do processo do pórtico de consumo. 3.3 análise arquitetural e tecnológica As decisões tomadas durante o desenvolvimento do SISC tiveram um grande impacto no problema que tentamos solucionar nesta reestruturação. O autor tentou utilizar as melhores tecnologias do momento e optar por uma arquitetura orientada a microsserviços, contudo a falta de know-how levou à errada utilização das mesmas, gerando um elevado número de irregularidades técnicas que, por consequência, provocaram um mau desempenho do sistema. Para efectuar a gestão do projecto, o autor utilizou o software standard da Bosch SuperOPL e para controlo de versões do código-fonte utilizou um repositório Subversion instalado num dos servidores da Bosch. Para o desenvolvimento foi utilizado MariaDB como servidor de base de dados e Spring Data(JPA) para a comunicação com a mesma. Para criar, testar e executar a aplicação foi utilizado oApache Maven uma vez que se trata de um projeto JHipster. A comunicação entre serviços tomou diversas formas, REST, SOAP e KAFKA. No desenvolvimento do back-end utilizaram Spring Boot (Java 7)e no front-end utilizaram AngularJS (JavaScript). Finalmente, para gerar a documentação utilizou-se Javadock. 3.3.1Arquitetura do sistema Desenvolvimento de uma aplicação com o Jhipster Existem várias frameworks de desenvolvimento de microsserviços. O JHipster é das mais utilizadas nos dias de hoje e combina Spring Boot eAngular para criar sistemas de software. No caso das aplicações orientadas a arquiteturas de microsserviços, é utilizado o padrão arquitetural API Gateway. Na Fig. 9está representado um esquema deste padrão arquitetural. 3.3. Análise arquitetural e tecnológica 21 Figura 9.: Padrão arquitetural API Gateway (JHipster, 2019). Quando o gateway e os microsserviços são iniciados, eles registam-se no JhipsterRegistry. A gateway fará automaticamente o proxy de todos os pedidos HTTP para os microsserviços, usando o nome do microsserviço em causa. A gateway utiliza o JhipsterRegistry para reconhecer os microsserviços. No caso de existir mais que uma instância do mesmo microsserviço a correr, a gateway ira balancear a carga pelas várias instâncias. Individualmente todos microsserviços seguem o padrão arquitetural Spring MVC. Na Fig. 10 está representado um esquema deste padrão arquitetural posteriormente explicado. 3.3. Análise arquitetural e tecnológica 22 Figura 10.: Padrão arquitetural MVC. 1. É recebido um pedido HTTP através de um URL. Este pedido cai no DispatcherServlet que é o distribuidor central para a estrutura Spring MVC. Este distribuidor central recebe todos os pedidos HTTP do cliente e atribui responsabilidades a outros componentes para o processamento do pedido. 2. O HandlerMapping decide qual é o próximo passo para o tratamento do pedido efetuado. Ele atua como consultor do DispatcherServlet pois é ele quem conhece o mapeamento das operações. O HandlerMapping analisa o URL do pedido para tomar decisões e o DispatcherServlet atribui o pedido ao controlador indicado. 3. A responsabilidade do controlador é processar as informações recebidas dos pedidos. Normalmente, um controlador está associado a uma ou mais classes de serviço que, por sua vez, podem ter classes de repositório associadas. As classes de repositório comunicam diretamente com a base de dados em conformidade com as regras do negócio. São as classes de serviço que contêm o ponto crucial do processamento. A classe do controlador simplesmente transporta as informações recebidas de uma ou mais classes de serviço para o utilizador. No entanto, as respostas das classes do controlador partem num estado “bruto”, chamadas de modelos, e podem não ser amigáveis ao utilizador. 4. Posto isto, o controlador envia estes dados para o DispatcherServlet. 5. O DispatcherServlet consulta o ViewResolver para mapear qual a visualização adequada para responder ao pedido efetuado. 6. De seguida, o DispatcherServlet atribui a responsabilidade de renderizar os dados do modelo à implementação da visualização atribuída pelo ViewResolver. 7. A implementação da visualização finalmente leva a resposta de volta ao navegador do cliente. 3.3. Análise arquitetural e tecnológica 23 Neste sentido, o SISC foi desenvolvido numa arquitetura orientada a microsserviços, com o Jhipster, sendo este composto por cinco microserviços e um gateway. Na Fig. 11 está representada a arquitectura da aplicação. Figura 11.: Arquitetura do sistema atual. Na Fig. 12 está representado o diagrama de fluxo de dados posteriormente explicado. 3.3. Análise arquitetural e tecnológica 24 Figura 12.: Diagrama de fluxo de dados atual. Todos os microsserviços e o gateway seguem os padrões de uma arquitetura Spring MVC: •Converter Este microsserviço tem a responsabilidade de receber leituras RFID do CrossTalk e de seguida converter essas leituras em mensagens XML formato SISC, que posteriormente, são enviadas para o microsserviço EventParser. Na Fig. 13 está representado o diagrama de classes do microsserviço Converter. Figura 13.: Diagrama de classes do microsserviço Converter. •EventParser Este microsserviço recebe mensagens formato SISC do microsserviço Converter. Estas mensagens contêm informação sobre o leitor e a etiqueta lida. O EventeParser tem a finalidade de validar este leitor e esta etiqueta. No caso da etiqueta e o leitor serem válidos, a informação é enviada para o microsserviço EventHandler. Na Fig. 14 está representado o diagrama de classes do microsserviço EventParser. 3.3. Análise arquitetural e tecnológica 25 Figura 14.: Diagrama de classes do microsserviço Event Parser. •EventHandler De todos os microsserviços, o microsserviço EventHandler é o mais complexo, uma vez que apresenta muitas funcionalidades e múltiplos pontos de input eoutput. O EventHandler recebe informação referente às etiquetas kalo do KALO e recebe informação referente às leituras RFID, proveniente do EventParser. As principais funcionalidades do EventHandler são: –Gerir o processo de Pairing; –Gerir os supermercados e a digitalização dos mesmos; –Confirmar TOs aquando da passagem das caixas no pórtico de reabastecimento; –Evaziamento do Kanban e efetuar o movimento de Picking das caixas do supermercado aquando da passagem das caixas no pórtico de consumo. Durante estes processos, o EventHandler vai trocando informação com o microsserviço SoapWebService referente a dados provenientes do SAP. Após a conclusão de qualquer funcionalidade, o EventHandler envia informação referente à execução da funcionalidade para o microsserviço EventDataSync. Na Fig. 15 está representado o diagrama de classes do microsserviço EventHandler. Figura 15.: Diagrama de classes do microsserviço EventHandler. 3.3. Análise arquitetural e tecnológica 26 •EventDataSync É responsável pela gestão dos principais dados para composição da aplicação web. O EventDataSync troca informação com o EventHandler, com o EventParser e, como já referido, com a WebApp. •SoapWebService Este recebe pedidos do EventHandler e tem como principal funcionalidade estabelecer comunicações com o SAP. Na Fig. 16 está representado o diagrama de classes do microsserviço SoapWebService. Figura 16.: Diagrama de classes do microsserviço SoapWebService. •WebApp AWebApp para além de ser a interface do sistema SISC é também o seu gateway. A WebApp troca informação com o EventDataSync. 3.3.2Deployment da aplicação Os microsserviços so SISC foram distribuídos por quatro servidores e utilizam a tecnologia Apache KAFKA para comunicarem entre si. Existe ainda um outro servidor onde foi instalada a base de dados. Para comunicar com outros sistemas, o SISC utiliza REST e SOAP. A Fig. 17 retrata o diagrama de deployment do SISC. 3.3. Análise arquitetural e tecnológica 27 Figura 17.: Diagram de deployment do sistema atual. 5.2. Definição da integração com outros sistemas 34 obtida, o SISC executa o Pairing. Para finalizar, o SISC envia a informação referente ao Pairing para o KALO, para o PROCON e para o CrossTalk que, de seguida, irá reencaminhar para o SAP. Na Fig. 19 está representado o diagrama de sequência deste processo. Figura 19.: Diagrama de sequência do novo processo de pairing. •Pórtico de reabastecimento Com a passagem das caixas no pórtico de reabastecimento, as TOs criadas no reebalamento são confirmadas. Nesta nova solução o SISC não tem qualquer funcionalidade nesta zona, uma vez que o CrossTalk confirma as TOs diretamente no SAP. •Supermercados Quando é feito o movimento de putaway de uma caixa no supermercado, o CrossTalk envia a leitura da caixa e da posição no supermercado para o PROCON, para que assim possa ser feita a digitalização do supermercado. Nesta nova solução o SISC não tem qualquer funcionalidade nesta zona, uma vez que o PROCON é agora o responsável pela gestão dos supermercados. •Pórtico de consumo Com a passagem no pórtico de consumo, o SISC recebe do CrossTalk as leituras das caixas 5.3. Análise económica 35 para que seja feito um pedido de esvaziamento do Kanban para o KALO, para que este possa efectuar um novo pedido de material ao armazém. Neste ponto, o CrossTalk envia também as leituras para o PROCON, para que seja feito o movimento de picking das caixas do supermercado. Na Fig. 20 está representado o diagrama de sequência deste processo. Figura 20.: Diagrama de sequência do novo processo do pórtico de consumo. 5.3 análise económica Teoricamente, qualquer projeto de reengenharia é economicamente viável e necessário, uma vez que uma das características de um sistema obsoleto é o elevado custo de manutenção e suporte. Por outro lado, o processo de reengenharia é igualmente vantajoso pois reutiliza o negócio, a tecnologia e a infraestrutura do projeto obsoleto. 5.4. Seleção das tecnologias a utilizar 36 5.4 seleção das tecnologias a utilizar A Bosch tem muitas equipas de desenvolvimento espalhadas pelo mundo. Numa tentativa de uniformizar estas equipas foram definidos alguns standards a nível tecnológico. Um dos requisitos para esta nova solução passa por utilizar as versões mais recentes das várias tecnologias. Na seleção das tecnologias a usar nesta nova solução foram tidos em conta os factos acima referidos. Em alguns casos foram utilizadas as mesmas tecnologias das versões anteriores, porém noutras houve alterações significativas. Na Tabela 5podemos analisar as alterações nas tecnologias e versões escolhidas. Tabela 5.: Comparação entre as tecnologias utilizadas. Solução anterior Nova solução Ambiente de desenvolvimento integrado Eclipse Visual Studio Code Base de dados MariaDB MySQL Automação de tarefas Jhipster 3.5.1JHipster 6.1.2 Tecnologia de cache – Ehcache CI/CD – Jenkins Análise da qualidade do código – SonarQube Comunicação entre serviços Apache Kafka 0.10.1Apache Kafka 2.1.0 Framework e linguagem de Programação Back-end Spring Boot (Java 7) Spring Boot (Java 8) Linguagem de Programação Front-end AngularJS (JavaScript) Angular (TypeScript) 5.5 especificação da nova solução 5.5.1Arquitetura do sistema A decisão continua a passar por uma arquitetura orientada a microsserviços, segundo o padrão API Gateway, sendo composto por quatro microserviços e uma gateway. Na Fig. 21 está representada a arquitectura da aplicação. 5.5. Especificação da nova solução 37 Figura 21.: Nova arquitetura da aplicação. Na Fig. 22 está representado o diagrama de fluxo de dados posteriormente explicado. 5.5. Especificação da nova solução 38 Figura 22.: Diagrama do novo fluxo de dados. Na reestruturação dos microsserviços não foram usados, rigidamente, padrões de design já estudados, no entanto toda a estrutura de classes dos microsserviços foi desenhada com base em alguns desses padrões, como por exemplo o Facade, o Mediator, o Chain of Responsability, o Strategy e o Template Method. De seguida será explicado com mais detalhe a estrutura de cada microsserviço onde será perceptível algumas semelhanças com alguns dos padrões de design enumerados. Todos os microsserviços e gateway seguem os padrões de uma arquitetura Spring MVC: •RFIDMessageParser Este microsserviço recebe leituras RFID do CrossTalk, através de um post REST. Após receber estas leituras, o RFIDMessageParser converte-as em mensagens XML formato SISC. Estas mensagens contêm informação sobre o leitor e a etiqueta lida. O RFIDMessageParser tem a finalidade de validar este leitor e esta etiqueta. Só se a etiqueta e o leitor forem válidos é que a informação é disponibilizada num tópico KAFKA. No contexto do sistema SISC, esta informação segue para os microsserviçoes ManagerService. Na Fig. 23 está representado o diagrama de classes do microsserviço RFIDMessageParser. 5.5. Especificação da nova solução 39 Figura 23.: Diagrama de classes do microsserviço MessageParser. •ManagerService O microsserviço ManagerService é de todos os microsserviços o mais complexo, pois tem múltiplos pontos de input eoutput. O ManagerService recebe informação referente as etiquetas KALO através de um post REST. Recebe ainda informação referente a leituras RFID, também por KAFKA, provenientes do RFIDMessageParser. Posto isto, efetua o processo de pairing como descrito na Fig. 19. Durante este processo, o ManagerService troca informação com o microsserviço SAPWebService, através de tópicos KAFKA, referente a dados provenientes do SAP. O microsserviço ManagerService é também responsável pelo esvaziamento do Kanban descrito na Fig. 20. Este pedido de esvaziamento é efetuado através de um post REST para o KALO. Na Fig. 24 está representado o diagrama de classes do microsserviço ManagerService. 5.5. Especificação da nova solução 40 Figura 24.: Diagrama de classes do microsserviço MagerService. •SAPWebService O microsserviço SAPWebService recebe pedidos, por KAFKA, do ManagerService e tem como principal funcionalidade estabelecer comunicações com o SAP. Todas as comunicações com o SAP são efectuadas pela tecnologia SOAP. Na Fig. 25 está representado o diagrama de classes do microsserviço SAPWebService. Figura 25.: Diagrama de classes do microsserviço WebService. 5.5. Especificação da nova solução 41 •ConfigurationAPP AConfigurationAPP para além de ser a interface de configuração do sistema SISC é também a sua gateway. As configurações registadas através da ConfigurationAPP são passadas diretamente ao microsserviço RFIDMessageParser. No Apêndice B podem ser analisadas imagens desta aplicação. 5.5.2Deployment da aplicação Para ganhar redundância, decidiu-se criar duas instâncias de cada microsserviço. Todas as comunicações HTTP (REST, SOAP) passam pela gateway que funciona como um distribuidor. Desta forma torna-se possível colocar várias instâncias dos vários microsserviços em máquinas diferentes. A gestão dos microsserviços e dos pedidos é efetuada através da gateway e do JhipsterRegistry. Quando chega um pedido HTTP àgateway, este pedido segue para uma instância do microsserviço que dá resposta à necessidade em causa. A gestão é feita de forma a que não exista replicação da resposta ao pedido, ou seja, apenas uma das instâncias recebe o pedido e dá resposta ao mesmo. Esta definição tem em vista a distribuição da carga pelas várias instâncias. Neste sentido optou-se por ter dois servidores em que um é o clone do outro, ou seja, ambos têm os mesmos microsserviços a correr. Com a solução obtida iremos ter no servidor BRGVM086 uma instância do microsserviço RFIDMessageParser, do ManagerService e do SAPWebService. O servidor BRGVM085 irá conter os mesmos microsserviços. No servidor BRGVM084 ficará instalada uma instância da ConfigurationAPP(gateway), do JhipsterRegistry e o servidor KAFKA. Existe ainda um outro servidor, o BRGVM066, onde foi instalada a base de dados. Na Fig. 26 temos retratado o diagrama de deployment do SISC. 5.5. Especificação da nova solução 42 Figura 26.: Diagram de deployment da nova solução. 6 SOLUÇÕES ENCONTRADAS E RESPETIVO IMPACTO 6.1 solução encontrada para cada problema Após a conclusão da reestruturação o sistema foi testado, onde foram obtidos bons resultados. Posto isto o sistema foi colocado em produtivo e só assim é que se conseguiu atingir a "carga"máxima. Uma vez colocado em produtivo, o SISC foi estudado durante dois meses com o intuito de calcular o real impacto do processo de reengenharia aplicado. Seguidamente, são explicitados os processo de resolução dos problemas identificados no Capítulo 4. Posteriormente, são apresentados os resultados derivados do processo de reengenharia, bem como o respectivo impacto na cadeia de abastecimento. [S1] Elevado número de servidores (vide P1,F5,M∗ 1,M∗ 2) Uma vez que a ocupação do CPU dos servidores era reduzida, decidiu-se agrupar os microsserviços numa única máquina. Esta decisão trouxe consigo o problema de falhas deste servidor, ou seja, caso este servidor falhe, todos os microsseriços irão falhar. Neste sentido decidiu-se ter, como explicado anteriormente, um outro servidor clone deste primeiro de modo a garantir a redundância necessária. Na distribuição dos serviços pelos vários servidores, temos: – Servidor 1(BRGVM066) Base de dados MySQL – Servidor 2(BRGVM084) Servidor KAKFA, JhipsterRegistry eGateway – Servidor 3(BRGVM085) RFIDMessageParser,PairingService eSAPWebService – Servidor 4(BRGVM086) RFIDMessageParser,PairingService eSAPWebService Desta forma conseguiu-se diminuir o número de servidores passando a ser necessário quatro servidores ao invés dos cinco necessários na solução anterior. [S2] Crescimento elevado de dados (vide P2,F1,F2,F5,M∗ 3-M∗ 6) Em relação ao elevado crescimento de dados, a exclusão do EventDataSync, da arquitetura, facilitou a resolução deste problema. O EventDataSync tinha 64 das 116 tabelas da base de dados da solução anterior. Na solução anterior existiam cerca de 60% de dados replicados, sendo que oEventDataSync era responsável por 90%, destes 60%. 43 50 BIBLIOGRAFIA Barbosa, P. L. S. and Cândido, A. L. (2017). Diferenças entre engenharia reversa e reengenharia nos sistemas de informação. Revista Interfaces: Saúde, Humanas e Tecnologia,4(13):243–253. Brintrup, A., Ranasinghe, D., and McFarlan, D. (2010). RFID opportunity analysis for leaner manufacturing. International Journal of Production Research,48(9):2745–2764. Chikofsky, E. J. and Cross, J. H. (1990). Reverse engineering and design recovery: A taxonomy. IEEE software,7(1):13–17. Cinnéide, M. O. and Nixon, P. (2000). Composite refactorings for java programs. In Workshop on Formal Techniques for Java Programs, ECOOP, pages 129–135. Coleman, D., Ash, D., Lowther, B., and Oman, P. (1994). Using metrics to evaluate software system maintainability. Computer,27(8):44–49. Demeyer, S. (2002). Maintainability versus performance: What’s the effect of introducing polymorphism. Edegem, Belgium: Universiteit Antwerpe. Fanta, R. and Rajlich, V. (1999). Restructuring legacy C code into C++. In Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM’99).’Software Maintenance for Business Change’(Cat. No. 99CB36360), pages 77–85. IEEE. Fernandes, J. M. and Machado, R. J. (2016). Requirements in engineering projects. Springer. Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine. Fields, J., Harvie, S., Fowler, M., and Beck, K. (2009). Refactoring: Ruby Edition. Pearson Education. Fowler, M. (2018). Refactoring: improving the design of existing code. Addison-Wesley Professional. Fowler, M. and Lewis, J. (2014). https://martinfowler.com/articles/microservices.html. (accessed: 27.08.2019). Freitas, A. C., Maio, A. F., Maia, P., Gomes, N., Nogueira, A., Fernandes, J. M., Carvalho, M. S., Alves, A. C., Costa, A., Afonso, P., Silva, P. V., Barbosa, D., and Machado, S. (2017). Savings in internal logistics using a RFID-based software system in a lean context. Curran Associates, Inc. Garrido, A. and Johnson, R. (2002). Challenges of refactoring c programs. In Proceedings of the international workshop on Principles of software evolution, pages 6–14. ACM. Hammer, M. and Champy, J. (2009). Reengineering the Corporation: Manifesto for Business Revolution, A. Zondervan. 51 Bibliografia 52 IEEE Computer Society, S. E. S. C. (2000). IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, volume IEEE Std 1471-2000. The Institute of Electrical and Electronics Engineers. Jacobson, I. and Lindström, F. (1991). Reengineering of old systems to an object-oriented architecture. In ACM Sigplan Notices, volume 26, pages 340–350. ACM. JHipster (2019). The JHipster API Gateway. https://www.jhipster.tech/api-gateway/, (accessed: 04.10.2019). Komondoor, R. and Horwitz, S. (2000). Semantics-preserving procedure extraction. In Proceedings of the 27th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 155–169. ACM. Lämmel, R. (1999). Reuse by program transformation. In Scottish Functional Programming Workshop, pages 144–153. Li, H., Reinke, C., and Thompson, S. (2003). Tool support for refactoring functional programs. In Proceedings of the 2003 ACM SIGPLAN workshop on Haskell, pages 27–38. ACM. MacDougall, W. (2014). Industrie 4.0Smart Manufacturing for the Future. Germany Trade and Invest, 1st edition. Martin, R. C. and Martin, M. (2006). Agile principles, patterns, and practices in C# (Robert C. Martin). Prentice Hall PTR. McFarlane, D. and Sheffi, Y. (2003). The impact of automatic identification on supply chain operations. The International Journal of Logistics Management,14(1):1–17. Monteiro, M. P. and Fernandes, J. M. (2006). Towards a catalogue of refactorings and code smells for AspectJ. In Transactions on aspect-oriented software development I, pages 214–258. Springer. Montesi, F. and Weber, J. (2016). Circuit breakers, discovery, and api gateways in microservices. arXiv preprint arXiv:1609.05830. Najjar, R., Counsell, S., Loizou, G., and Mannock, K. (2003). The role of constructors in the context of refactoring object-oriented systems. In Seventh European Conference onSoftware Maintenance and Reengineering, 2003. Proceedings., pages 111–120. IEEE. Newman, S. (2015). Building microservices: designing fine-grained systems. O’Reilly Media, Inc. Nierstrasz, O., Ducasse, S., and Demeyer, S. (2005). Object-oriented reengineering patterns—an overview. In International Conference on Generative Programming and Component Engineering, pages 1–9. Springer. Opdyke, W. F. (1992). Refactoring Object-oriented Frameworks. PhD thesis, University of Illinois at Urbana-Champaign, Champaign, IL, USA. Pfleeger, S. L. and Atlee, J. M. (2010). Software engineering: theory and practice. Prentice Hall (4th ed.). Bibliografia 53 Powell, D. and Skjelstad, L. (2013). RFID for the extended lean enterprise. International Journal of Lean Six Sigma,3(3):172–186. Pressman, R. S. (2015). Software engineering: a practitioner’s approach. McGraw-Hill (8th ed.). Riezebos, J., Klingenberg, W., and Hicks, C. (2009). Lean production and information technology: Connection or contradiction? Journal Computers in Industry,60(2009):237–247. Rugaber, S. (1995). Program comprehension. Encyclopedia of Computer Science and Technology,35:341– 368. Russo, A., Nuseibeh, B., and Kramer, J. (1998). Restructuring requirements specifications for managing inconsistency and change: A case study. In Proceedings of IEEE International Symposium on Requirements Engineering: RE’98, pages 51–60. Sommerville, I. (2016). Software Engineering. Pearson Education Limited. Thönes, J. (2015). Microservices. IEEE software,32(1):116–116. Tokuda, L. and Batory, D. (1995). Automated software evolution via design pattern transformations. In Proceedings of the 3rd International Symposium on Applied Corporate Computing. Citeseer. Tokuda, L. and Batory, D. (2001). Evolving object-oriented designs with refactorings. Automated Software Engineering,8(1):89–120. Vittek, M. (2003). Refactoring browser with preprocessor. In Seventh European Conference onSoftware Maintenance and Reengineering, 2003. Proceedings., pages 101–110. IEEE. Von Alan, R. H., March, S. T., Park, J., and Ram, S. (2004). Design science in information systems research. MIS quarterly,28(1):75–105. A presente dissertação foi desenvolvida no âmbito de um estágio curricular na Bosch Car Multimedia.