Rodrigo Santana Camargo

Desenvolvimento de Módulo de Exigências

Nutricionais de Galinhas Poedeiras

São Cristovão
2017, v-1.3
 Rodrigo Santana Camargo

Desenvolvimento de Módulo de Exigências Nutricionais

de Galinhas Poedeiras

Este relatório final tem como objetivo apresen-

tar os resultados da reengenharia de software
aplicada em um caso real.

Universidade Federal de Sergipe – UFS

PIBIC - CNPq

São Cristovão
2017, v-1.3
 Resumo
Este relatório tem por objetivo apresentar os resultados dos processos de reengenharia apli-
cado em um sistema legado, desenvolvido em VBA, para simular as exigências nutricionais
de galinhas poedeiras e codificado em linguagem Java SE para web. Essa reengenharia foi
desenvolvida para modernizar a aplicação, diminuir custo, manter, facilitar modificações e
novas evoluções.
Palavras-chaves: Reengenharia de software, Sistema legado, Documentação.
 Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Sistema legado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Reengenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Reengenharia de sistema legado . . . . . . . . . . . . . . . . . . . . . 6

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . 10

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introdução

O sistema computacional defasado tecnologicamente e fundamental para uma

organização é classificado como sistema legado. Muitas organizações utilizam sistemas
legados que foram desenvolvidos há décadas. Estes, conforme vão envelhecendo, criam
problemas aos profissionais de computação para serem mantidos. Eventualmente, as
desvantagens dos sistemas legados pesam no custo financeiro às organizações, com isso
os recursos de software devem ser modernizados, onde passa a ser realizada através da
reengenharia de software(STEHLE, 2014).
A reengenharia trata-se de um processo eficaz em termos de custo e evolução. Não
sendo aplicado apenas em softwares, mas também em organizações para melhorar seus
processos (HAMMER; STANTON, 1996). Aplicabilidade da reengenharia em um sistema
legado tem objetivo de reescrever, reestruturar e documentar para aumentar o ciclo de
vida do sistema. Os riscos são reduzidos em relação ao se desenvolver um novo sistema.
As atividades nos processos da engenharia progressiva consistem nas especificações
e na implementação, resultando em um novo sistema. A reengenharia vem como o oposto
da engenharia progressiva, e o processo se inicia a partir de um software existente com o
propósito de analisá-lo para extrair informações necessárias para reconstruí-lo(PRESSMAN;
MAXIM, 2016).
O software legado “calculador das tabelas para aves e suínos” é específico para
calcular exigências nutricionais e simular o ganho energético pelos alimentos. O sistema foi
desenvolvido utilizando VBA, uma linguagem pouco usual com alto nível de complexidade.
O uso do sistema depende da plataforma Excel, e ocorrem incompatibilidades entre as
versões, com isso trás diversos problemas de mal funcionamento e individualização do
serviço. Seguindo os processos da reengenharia o software é modernizado, suas funciona-
lidades reescritas em uma nova linguagem e migrado para arquitetura cliente-servidor,
assim, centralizando o serviço e generalizando soluções.
2 Revisão da Literatura

2.1 Sistema legado

Diversos dos softwares usado por organizações atualmente são categorizados como
sistema legado, cujo consiste em um sistema defasado tecnologicamente (SNEED, 2006).
Conforme a tecnologia de software evolui, os sistemas caminham em direção à tornarem
sistemas legados. Segundo Sneed (2006) como parte da evolução tecnológica, retrata que
se uma organização usa uma tecnologia por mais de cinco anos, então se tem um sistema
legado.
Sommerville et al. (2008) diz que os sistemas legados incorporam um grande
número de alterações que foram feitas durantes muitos anos. Muitas pessoas diferentes se
envolveram na realização dessas mudanças, e é incomum que qualquer pessoa tenha uma
compreensão completa do sistema.
Para Warren et al. (2012) sistema legado é um sistema antigo que permanece em
operação dentro de uma organização. Os sistemas legados, tipicamente, foram desenvolvidos
de acordo com práticas e tecnologias de desenvolvimento datadas. Também tiveram vidas
longas e sofreram mudanças consideráveis.
Há diversas razões para que uma organização persista em usar um sistema legado.
O sistema tem um bom funcionamento, atende as necessidade da organização e é confiável.
Grandes sistemas representam um investimento financeiro muito grande. Anos de uso
garante que todas as funcionalidade foram devidamente testadas. O sistema legado pode
realizar funções críticas de uma organização. De acordo com Bisbal (1999) ’Os sistemas
legados geralmente são a espinha dorsal de um fluxo de informações das organizações
e o principal veículo para consolidar informações comerciais’. Os gerentes relutam em
incorrer no custo e no risco envolvido com a substituição de sistemas confiáveis e caros,
críticos para empresa, mas as desvantagens de sistemas legados pode eventualmente pesar
as vantagens.
Sistema legado pode ser difícil de manter devido a dificuldade de entender o sistema
e as tecnologias antigas. Os desenvolvedores do software podem não estar mais disponíveis
e a documentação pode ser insuficiente ou inexistente. A falta de entendimento causa
dificuldade em modificar e dar continuidade. Pode ser difícil encontrar engenheiros quem
sejam proficientes em linguagens e tecnologias do sistema legado. Mesmo que o código
possa ser entendido, o sistema pode depender de um hardware específico. Hardware antigo
pode ser difícil de manter e peças de reposição podem não estar mais disponíveis. O
desempenho do hardware mais antigo pode não ser aceitável(STEHLE, 2014).
2.2 Reengenharia
Quando um sistema não é fácil de ser mantido, porém é de grande utilidade, deve
ser reconstruído. O processo dessa reconstrução, partindo do sistema existente, seja via
código fonte, interface ou ambiente, onde são abstraídas suas funcionalidades, construídos
o modelo de análise e o projeto do software, dá-se o nome de reengenharia de software.
Reengenharia nada mais é do que reorganizar e modificar o software com o objetivo
de torná-lo mais fácil de manter. A partir do momento em que um sistema começa a
ser utilizado, ele entra num processo contínuo de mudanças, mesmo tendo sido criado
aplicando técnicas de projeto. Ao passo que novas tecnologias surgem, os sistemas vão se
tornando obsoletos(ALMEIDA, 2009).
De acordo com Piekarski e Quináia (2000) a reengenharia está relacionado com a
reconstrução de algo do mundo real, e independentemente de sua aplicação, o seu principal
propósito é a busca por melhorias que permitam produzir algo de qualidade melhor ou,
pelo menos, de qualidade comparável ao produto inicial.
Segundo Pressman e Maxim (2016), a reengenharia, também chamada de recupera-
ção ou renovação, recupera informações de projeto de um software existente e usa essas
informações para alterar ou reconstituir o sistema, preservando as funções existentes, ao
mesmo tempo em que adiciona novas funções ao software, num esforço para melhorar sua
qualidade global.
Para Sommerville et al. (2008), a reengenharia de software é descrita como a
reorganização e modificação de sistemas de software existentes, parcial ou totalmente, para
torná-los mais manuteníveis.
Há uma clara distinção entre o desenvolvimento de um novo software e reengenharia
de software. A distinção está relacionada ao ponto de partida de cada um dos processos. O
desenvolvimento de um novo software inicia-se com uma especificação escrita do software
que será construído, enquanto que a reengenharia inicia-se tomando como base um sistema
já desenvolvido.

2.3 Reengenharia de sistema legado

Companhias investem muito dinheiro em sistemas e querem ter o retorno do
investimento, para isso os sistemas tem que ser utilizável por anos. Muitos desses sistemas
são considerados crítico para o negócio, isto é, qualquer falha do sistema pode causar muitos
problemas. Grande parte desses sistemas foram desenvolvido a décadas ou fazem uso de
tecnologias antigas. Esses sistemas são definidos como sistemas legados(SOMMERVILLE
et al., 2008).
 Naturalmente com o tempo as organizações evoluem. Estas evoluções geralmente
forçam as organizações a alterarem os processos de negócio que consequentemente reflete
em novas modificações no sistema. Por outro lado, a rápida evolução tecnológica também
induz uma forte pressão para modificar o sistema, a fim de torná-lo capaz de suportar
novos requisitos que sistema legado não consegue atender(HAINAUT et al., 2008).
Com base em uma pesquisa da indústria informal, Sommerville et al. (2008) sugere
que 85-90% dos custos do software são os custos de evolução. Outras pesquisas sugerem
que cerca de dois terços dos custos de software são custos de evolução. Com certeza, os
custos de mudança de software são uma grande parte do orçamento de TI para todas as
empresas.
Para tornar os sistemas de software legados mais fáceis de manter, é aplicado reen-
genharia nestes sistemas para melhorar sua estrutura e compreensão. A reengenharia pode
envolver redocumentar o sistema, refatorar a arquitetura do sistema, traduzir programas
para uma linguagem de programação moderna e modificar e atualizar a estrutura e os
valores dos dados do sistema. A funcionalidade do software não é alterada e, normalmente,
você deve tentar evitar mudanças importantes na arquitetura do sistema(SOMMERVILLE
et al., 2008).
O problema de manutenção de sistemas legados é complexo porque, geralmente,
esses sistemas não são simples programas, desenvolvidos e mantidos. Muitos deles são
compostos de outros diferentes programas que, de alguma forma, compartilham dados.
Também ocorre que esses programas foram desenvolvidos por diferentes pessoas ao longo
dos anos, as quais não estão mais na organização.
Aplicando-se a reengenharia de software, o sistema pode ser redocumentado ou
reestruturado, os programas podem ser traduzidos para uma linguagem de programação
mais moderna e implementados em uma plataforma distribuída, bem como seus dados
podem ser migrados para uma base de dados diferente. A reengenharia de software objetiva
fazer sistemas flexíveis, fáceis de modificar, frente às constantes mudanças das necessidades
dos usuários.
3 Metodologia

O presente estudo é do tipo descritivo, com enfoque sob o estudo de exigências

nutricionais de aves, os processos de desenvolvimento do módulo de galinhas poedeiras
utilizando os métodos formais de reengenharia de software.
Durante o processo de software foram usadas técnicas de reengenharia de software.
Esses processos foram divididos em quarto atividades sendo análise do módulo de galinhas
poedeiras, documentação, desenvolvimento e testes.
A primeira atividade do processo de recuperação do sistema legado é a mais crítica
de todas as atividades, qualquer erro se persistirá por todas etapas da reengenharia. Então
o módulo de galinhas poedeiras foi analisado minuciosamente para extrair informações
sobre as funções, regras de negócios e requisitos existentes no sistema. Os requisitos obtidos
através da analise do sistema legado e por meio de entrevistas com o idealizador do sistema
para garantir uma maior quantidade de detalhes. Este processo foi finalizado com um
total de 46 requisitos funcionais sendo deste total 16 requisitos funcionais para exigência
nutricional. Os requisitos responsáveis pelo módulo galinhas poedeiras são 5, sendo elas:

• RF24 - O software deverá ser capaz de determinar a exigência nutricional para aves
de poedeira e reposição.

• RF34 - O software deverá exibir os seguintes resultados peso médio(kg), ganho de

peso(g/dia), energia metabolizável(kcal/dia), energia metabolizável(kcal/kg), con-
sumo de ração estimado(g/dia), ganho por período(kg), consumo por período(kg),
conversão alimentar(kg/kg), lisina digestível(g/dia), fósforo disponível(g/dia), fósforo
digestível(g/dia), lisina(%), metionina(%), metionina + cisteína(%), treonina(%),
triptofano(%), arginina(%), glicina + serina(%), valina(%), isoleucina(%), leucina(%),
histidina(%), fenilalanina(%), fenilalanina + tirosina(%), nitrogênio essencial digestí-
vel(%).

• RF36 - O Resultados deverão ser divididos em tabelado e simulado.

• RF37 - O software deverá permitir que o usuário grave a simulação de exigência

nutricional.

• RF45 - O software deverá permitir que o usuário gere um relatório com os resultados
da exigência nutricional para aves e suínos.

Em paralelo, foi realizado um estudo detalhado baseado nas Tabelas Brasileiras de

Rostagno et al. (2017) com auxilio de especialistas em nutrição animal sobre exigência
nutricional de galinhas poedeiras para determinar formulas matemática ideais para criar
recomendações a partir dos parâmetros de categoria, peso kg, consumo de ração g/dia,
percentual de produção de ovo, peso do ovo em grama e uma opcional energia metabo-
lizável em kcal/kg do alimento. Com isso, foi possível determinar os valores enérgicos e
porcentagens de nutrientes para compor uma determinada dieta ideal de galinha poedeira.
Agregando essas novas especificações no do sistema.
Seguindo o fluxo do processo da reengenharia, a atividade de documentação foi
realizado, pois o sistema legado não havia qualquer tipo de documentação. A documentação
foi elaborada seguindo a norma IEEE 1998/830 para desenvolver um único documento
contendo os requisitos do sistema, regras de negócio, casos de uso, diagrama de classe da
Figura 1, protótipos de telas e decisões arquiteturais.

Figura 1 - Diagrama de classes de aves.

O módulo foi desenvolvido seguindo a documentação. Durante o desenvolvimento

foram utilizados ferramentas e frameworks para compor o módulo de galinha poedeira.
Foi usado durante todo o processo de desenvolvimento a IDE Eclipse Neon V.3 para
desenvolver os algoritmos, MariaDB 10.2.6 Stable responsável por armazenar os dados de
alimentos, nutrientes e seus respectivos valores energéticos e os resultados das simulações
de exigências nutricionais. O uso de contêiner foi necessários para criação de um servidor
tomcat 8.0.44 responsável por oferecer o serviço ao usuário.
A atividade de validação do módulo foi feito através de testes por softwares e testes
por clientes, bugs foram identificados e corrigidos, com isso garantido boa usabilidade e
confiabilidades nas simulações de exigências nutricionais de galinhas poedeiras.
4 Resultados e Discussão

Os resultados serão apresentados seguindo a mesma sequência do fluxo dos processo

formais da reengenharia de software, análise, documentação, desenvolvimento e testes.
Antes de fato ter iniciado a análise, foram realizados diagnósticos no sistema em
geral e não apenas no módulo proposto neste trabalho, assim, com o objetivo de coletar o
maior número de informações para que em conjunto com as teorias de reengenharia fosse
possível decidir qual melhor caminho o sistema deveria seguir. Ao concluir o diagnóstico
percebeu-se ser inviável prosseguir com o sistema da Figura 2, pois mantê-lo funcional
seria gasto muito recurso financeiro e de tempo.

Figura 2 - Software legado.

Seguindo assim o mesmo modelo de reconstrução definido por Pressman e Maxim

(2016) com intuito de migrar o sistema legado para uma nova linguagem e arquitetura.
Possibilitando a manutenibilidade mais fácil em relação de custo e o tempo gasto para
concluir uma modificação.
Devido aos constantes problemas que existiam relacionados a incompatibilidade
com as versões da plataforma para qual o sistema legado foi desenvolvido. Foi feita a
alteração arquitetural para sanar esses problemas. A solução arquitetural empregada foi
a cliente/servidor, no qual o usuário não precisa instalar nada ou se preocupar com a
versão dos softwares de terceiros. Esta arquitetura garante que o serviço do sistema seja
fornecido de acordo com as requisições do usuário. As modificações não geram versões,
assim uma vez aplicada serve para todos, sendo o responsável pela atualização do sistema o
desenvolvedor. As modificações no sistema legado não eram simples pois geravam versões,
fazendo do usuário o responsável por atualizar a sua aplicação, e isso, cada usuário teria
que fazer esse mesmo procedimento.
O processo inicial da reconstrução do sistema de análise foi realizado com muita
cautela, pois a primeira fase do processo é a mais crítica e qualquer informação errada
ou falta de informação geraria uma sucessão de erros nas fases seguintes. Os processo
de análise do software resultou em todas as especificações necessárias para desenvolver o
sistema. Essas especificações foram essenciais para desenvolver os documentos de regra de
negócios, caso de uso e diagrama de classe da que resultou em um único documento IEEE
1998/830.
O desenvolvimento foi feito seguindo os requisitos e a modelagem do diagrama de
classes encontrado no documento feito no processo anterior. O módulo do sistema legado da
Figura 3 está fragmentada a quatro funcionalidades diferentes de exigências de aves, sendo
que as poedeiras leves e poedeiras semipesadas são trabalhadas no mesmo módulo. Durante
análise do sistema legado essas funcionalidades são separadas para melhor usabilidade
do novo sistema, assim modularizando as funcionalidades e facilitando as modificações
futuras, pois cada módulo é específico para uma categoria de ave.

Figura 3 - Tela de simulação de aves do sistema legado.

As Figura 4,5,6 e 7 são resultantes do desenvolvimento. O módulo completamente

reestruturado na nova arquitetura cliente/servidor. Foram adicionadas colunas com as
mesmas funções para fim de comparação dos resultados, assim o usuário pode comparar 4
simulações diferentes e analisar os resultados.
Na fase final do processo da reengenharia foram realizados testes para verificação
da funcionalidade do módulo, garantindo assim, que todas as especificações descritas na
documentação fossem atendidas, e satisfatórias. Segue exemplificado nas figuras 5, 6 e 7.
O uso da reengenharia trouxe diversos benefícios como a modernização e re-
documentação do sistema legado. O resultado desse processo possibilita o aumento do ciclo
Figura 4 - Tela de simulação de exigência nutricionais de galinhas poedeiras do SIBNAS.

de vida do sistema que foi completamente reestruturado com por meio de novas técnicas e
tecnologias. Com isso, facilitando no processo de novas evoluções, modificações e o menor
tempo para desenvolver essas soluções.

Figura 5 - Resultado da simulação com sugestões de porcentagens nutrientes.

Figura 6 - Resultado da simulação com sugestões de porcentagens aminoácidos digestiveis.

Figura 7 - Resultado da simulação com sugestões de porcentagens aminoácidos totais.

5 Conclusões

Sobre o presente trabalho, pode-se concluir o êxito no processo de reengenharia

aplicada vide sistema tabelas brasileiras de nutrição animal. O processo garante que o
sistema tenha um maior ciclo de vida e diminuição no custo para se manter atual.
Por meio da reengenharia transformamos um sistema legado sem documentação
qualquer em um software de fato, pois o sistema foi reestruturado e desenvolvido a
documentação associado ao novo.
A documentação associada a este sistema possibilitará fácil manutenibilidade,
garantindo maior vida útil. Os benefícios da reengenharia possibilitou que o sistema se
transformasse em uma nova ferramenta e agregasse maior valor para o uso de simulações
em nutrição animal. Portanto, modificações futuras terão um custo mais baixo e levará
menor tempo para serem desenvolvidas.
O novo sistema foi migrado para uma arquitetura cliente-servidor, assim possibili-
tando que o sistema possa ser acessado de qualquer lugar e sem problema de compatibilidade
que era recorrente no sistema legado. Desse modo, o atual serviço trás associado inovação
tecnológica, fácil acessibilidade, melhoria em custos e tempo, proporcionando ao usuário
vantagens e recursos que vem a tratar com objetividade e rentabilidade ao seu negócio.
 Referências

ALMEIDA, R. F. de. Aplicação Prática de Técnica de Reengenharia de Software. [S.l.],

2009. Citado na página 6.

BISBAL, e. a. J. Legacy information systems: issues and directions. IEEE Software, 1999.
Citado na página 5.

HAINAUT, J.-L. et al. Migration of legacy information systems. Software Evolution.

Mens, T. and Demeyer, S. (Eds), Springer, pp. 107-138, 2008. Citado na página 7.

HAMMER, M.; STANTON, S. A. The Reengineering Revolution. HarperCollins,

1996. ISBN 9780887307362. Disponível em: <https://books.google.com.br/books?id=
B2ueQgAACAAJ>. Citado na página 4.

PIEKARSKI, A. E. T.; QUINáIA, M. A. Reengenharia de software: o que, por quê e

como. Revista Ciências Exatas e Naturais, v. 2, 2000. Citado na página 6.

PRESSMAN, R.; MAXIM, B. Engenharia de Software - 8a Edição:. [s.n.], 2016.

ISBN 9788580555349. Disponível em: <https://books.google.com.br/books?id=
wexzCwAAQBAJ>. Citado 3 vezes nas páginas 4, 6 e 10.

ROSTAGNO, H. S. et al. Tabelas Brasileiras Para Aves e Suínos. [S.l.]: Editora UFV,
2017. Citado na página 8.

SNEED, H. M. Integrating legacy Software into a Service oriented Architecture. [S.l.]:

Conference on Software Maintenance and Reengineering (CSMR’06), 2006. Citado na
página 5.

SOMMERVILLE, I. et al. Engenharia de software. ADDISON WESLEY BRA,

2008. ISBN 9788588639287. Disponível em: <https://books.google.com.br/books?id=
ifIYOgAACAAJ>. Citado 3 vezes nas páginas 5, 6 e 7.

STEHLE, e. a. E. Migration of legacy software to service oriented architecture.

Philadelphia, PA 19104, 2014. Citado 2 vezes nas páginas 4 e 5.

WARREN, I. et al. The Renaissance of Legacy Systems: Method Support for Software-
System Evolution. Springer London, 2012. (Practitioner Series). ISBN 9781447108177.
Disponível em: <https://books.google.com.br/books?id=KevSBwAAQBAJ>. Citado na
página 5.