Refatoração de Código em Ambientes Típicos de Desenvolvimento Ágil

Alessandro Alonso Ferreira Calu
REFATORAÇÃO DE CÓDIGO EM AMBIENTES

TÍPICOS DE DESENVOLVIMENTO ÁGIL
Monografia apresentada ao Programa de

Pós-Graduação em Engenharia de Software
da Pontifícia Universidade Católica de Minas
Gerais, Instituto de Educação Continuada.
Orientador: Humberto Torres Marques Neto
Belo Horizonte
2010
Aos meus pais, minha esposa e meus filhos
Pela paciência e apoio.
“...tempo de derrubar, e tempo de edificar...”
Rei Salomão
RESUMO
Esta monografia apresenta a importância da refatoração de código dentro de
ambientes típicos de desenvolvimento Ágil. São contrapostas características da
alteração de funcionalidades em software tratadas nos processos unificado e em
processos ágeis, destacando-se a importância da refatoração no último. São
apresentados os momentos adequados e os papéis responsáveis por realizar
refatoração de código. É realizado um estudo de caso de utilização de técnicas e
ferramentas de refatoração de código PHP em fontes de um projeto real de uma
fábrica de software.
Palavras-chave: Refatoração de código; Desenvolvimento Ágil; Manutenção
Adaptativa; Manutenibilidade; Gerência de Configuração.

LISTA DE FIGURAS
FIGURA 1 - O impacto das mudanças proposto por PRESSMAN …........ 16
FIGURA 2 - O custo das mudanças proposto em Extreme Programming. 17
FIGURA 3 - Processo de tarefa Controle de Mudanças …....................... 20
FIGURA 4 - Diagrama Classes antes da Refatoração …......................... 31
FIGURA 5 - Diagrama Sequência gera_pontuacao antes da Refatoração 32
FIGURA 6 - Código Fonte gera_pontuação antes da Refatoração …....... 33
FIGURA 7 - Diagrama Classes, Camada Persistência (Refatoração 1).... 36
FIGURA 8 - Diagrama de Classes do Software (Refatoração 2) ….......... 37
FIGURA 9 - Diagrama de Sequência (Refatoração 3) …............….......... 38
FIGURA 10 - Diagrama de Classes após Refatoração ..............….......... 39
FIGURA 11 - Diagrama de Sequência após Refatoração ….......….......... 40
FIGURA 12 - Código Fonte gera_pontuação após Refatoração............... 41

LISTA DE TABELAS
TABELA 1 - Caso de Uso: Gerar pontuação automática de mês …........... 30
TABELA 2 - Caso de Teste 1: Funcionário com pontos e sem férias …..... 44
TABELA 3 - Caso de Teste 2: Funcionário com pontos e com férias …..... 45
TABELA 4 - Caso de Teste 3: Funcionário somente com férias …............. 46

LISTA DE ABREVIATURAS
PDT - PHP Development Tools
ECO - Ordem de Mudança de Engenharia

LISTA DE SIGLAS
IDE – Ambiente de Desenvolvimento Integrado.
UP – Processo Unificado.
XP – Extreme Programming.
SUMÁRIO
1. INTRODUÇÃO …............................................................................ 10
1.1 JUSTIFICATIVA …............................................................................ 12
1.2 OBJETIVOS …..…............................................................................. 14
2. REVISÃO DA LITERATURA .................................................... 16
3. METODOLOGIA …..................................................................... 24
4. ESTUDO DE CASO ................................................................... 27

4.1 O SOFTWARE ….............................................................................. 28
4.2 O REQUISITO .….............................................................................. 29
4.3 O ESTADO INICIAL …...................................................................... 31
4.4 CRIANDO CASOS DE TESTE …..................................................... 34
4.5 REFATORANDO …..................…..................................................... 35
4.6 O ESTADO FINAL …........................................................................ 39
5. CONSIDERAÇÕES FINAIS …................................................ 42
REFERÊNCIAS .................................................................................. 43
APÊNDICE …...................................................................................... 44
10
1. INTRODUÇÃO
A presente monografia aborda um tema importante dentro do
desenvolvimento de software em ambientes típicos de processos ágeis. Num
primeiro momento, podemos entender um ambiente característico de
desenvolvimento ágil como um projeto com diversas entregas parciais para
utilização imediata pelo usuário final. Soma-se a isso a opção de mudança
significativa no escopo ou conjunto de requisitos do sistema durante o ciclo de
produção do mesmo.
Também inclui-se no ambiente de discussão desta monografia sistemas que
sofrem manutenção adaptativa contínua para atender a soluções de negócios
tempestuosos. Seriam empresas que mudam estratégias táticas e regras de fluxos
de processos de forma rápida e constante. Estes softwares precisam lançar novas
versões em intervalos curtos de tempo e com pequenas adaptações.
É importante deixar claro que não é objetivo desta monografia defender ou
discutir a utilização de metodologias ágeis. A refatoração de código pode e deve ser
utilizada dentro do Processo Unificado (UP) caso se faça necessário. O foco aqui é
na realidade a necessidade de planejamento e utilização de refatoração de código
em softwares que sofrem mudanças constantes de funcionalidades. Pretende-se
levantar importantes aspectos da refatoração de código como: o seu custo; o seu
impacto na qualidade do produto e do processo; a sua correta utilização dentro do
processo de desenvolvimento adotado e adaptado pela fábrica de software; e

11
algumas das técnicas e ferramentas conhecidas e oferecidas atualmente para
refatoração rápida e segura.

12
1.1 JUSTIFICATIVA
Equipes de desenvolvimento de software tem-se deparado com projetos de
soluções em tecnologia da informação direcionados para empresas clientes com
cenários de negócio instáveis. Estas empresas podem possuir dentre outras
características: estratégias de marketing agressivo, venda de serviços relacionados
a tecnologia de ponta, alta expansão de mercado, mudança constante de
posicionamento de mercado, investimento alto em novas tecnologias para redução
de custo na produção, adaptação constante a mudanças de leis governamentais e
outras necessidades que levam a mudança constante e rápida dos processos
internos e da forma como a informação é tratada. Organizações como estas não
podem esperar muito tempo por novas versões de software customizado que se
adaptem a suas mudanças. Esperar significaria perda de mercado, desatualização
tecnológica, desperdício de valores em custo de produção e quebra de leis.
As fabricas de software precisam atender satisfatoriamente a demanda de
clientes como os descritos acima. Desta forma, projetos de sistemas com liberação
de versões de uso em períodos menores que um ou dois meses são oferecidos. As
equipes de desenvolvimento destes projetos precisam se capacitar e adaptar para
exercer suas atividades de forma eficaz. Precisam sobreviver dentro do ciclo de vida
de um software produzido com várias entregas parciais e em constante manutenção
adaptativa. Fatores como a clareza dos requisitos das partes interessadas e sua
ordem de importância, conhecimento da arquitetura do sistema desenvolvido por

13
toda a equipe, boas práticas de programação e utilização de padrões de projeto na
escrita do código fonte são determinantes.
A refatoração de código ganha um brilho dourado dentro de projetos como
como os descritos acima. Sistemas com alterações, adaptações, correções e
anulações dos requisitos de tempos em tempos tendem a criar algumas distorções
em seu código fonte como: Emendas em fluxos lógicos e condicionais;
descaracterização da entradas, realizações e saídas das funções esperadas pelo
seu nome; perda de sentido da relação e hierarquia de classes e outros problemas
que serão tratados mais detalhadamente adiante.
A refatoração de código pretende manter o código fonte claro, cultivando boas
práticas de programação e utilização de padrões de projeto. Renomeia variáveis,
funções e classes a partir de seu significado. Muda uma função de uma classe para
outra de acordo com suas responsabilidades. Cria classes que se tornam
necessárias e destrói classes que se tornam desnecessárias. Muda hierarquia de
classes conforme mudança em suas relações. Enfim, a refatoração de código prove
manutenibilidade ao sistema produzido garantindo um menor custo nas versões
atual e futuras do mesmo.
Apesar de seus benefícios, a refatoração de código precisa ser realizada de
forma adequada e no momento adequado dentro do ciclo de desenvolvimento do
software. Para tanto é necessária a utilização de técnicas e ferramentas que
otimizam e garantam maior confiabilidade e segurança. É importante também a
determinação dos momentos adequados e os papéis responsáveis por realizar
refatoração de código dentro do processo de desenvolvimento da fábrica de
software.
14
1.2 OBJETIVOS
O objetivo principal desta monografia é apresentar a refatoração de código
como um importante aliado para equipes de desenvolvimento de software. Em
algum momento o programador precisará alterar código fonte para corrigir erros,
acrescentar, modificar ou retirar funcionalidades do sistema. Caso isso ocorra várias
vezes em um mesmo caso de uso, ou em um mesmo conjunto de classes, ou em
um mesmo grupo de arquivos fontes, refatorar é uma boa opção.
Normalmente o código fonte de um projeto é alterado por desenvolvedores
diferentes durante sua construção e manutenção. Manter boas práticas de
programação garante manutenibilidade ao software. Manter o código claro e
comunicativo aumenta a produtividade e diminui o risco de alterações do sistema.
Um dos objetivos específicos desta monografia é listar algumas das técnicas e
ferramentas conhecidas atualmente para refatorar código e mostrar como estas
técnicas podem diminuir o custo desta tarefa. Outro dos objetivos é avaliar como a
refatoração de código, por conseguinte, pode diminuir o custo de alterações e
lançamentos de novas versões de software.
É preciso apontar dentro da definição do processo de software de uma
fábrica, setor ou equipe de desenvolvimento quem, em qual momento e como se
realizará refatoração de código. Ou ainda se ficará a cargo da equipe de
programadores a utilização deste recurso nos momentos em que julgar necessário.
É também objetivo desta monografia localizar a refatoração de código dentro do
processo de desenvolvimento de software. Pretende-se propor ainda, um fluxo de

15
tarefas que realizadas viriam a cumprir a atividade de refatoração de código dentro
deste processo.
Enfim, um último objetivo seria mostrar e discutir requisitos para uma
ferramenta de refatoração de código eficaz. Ferramentas de refatoração adequadas
agilizam ainda mais esta atividade, tornando-a menos entediante, mais precisa e
consequentemente mais utilizada. Apresenta-se nesta monografia alguns dos
atributos necessários para adoção, aquisição ou mesmo construção de uma
ferramenta de refatoração.
16
2. REVISÃO DA LITERATUA
Uma das pré-suposições básicas do desenvolvimento Ágil é: custa menos
realizar alterações em sistemas com versões já em utilização do que tentar levantar
detalhadamente todos os requisitos desejados pelo cliente antes de começar a
construir a primeira versão software. Este é um dos pontos de diferença entre o
Processo Unificado (UP) é processos Ágeis como por exemplo o Extreme
Programming (XP).
PRESSMAN (2001) chama de mito a consideração de que mudanças de
software podem ser facilmente realizadas. Ele apresenta ainda um gráfico
representativo do custo de mudanças ao longo do ciclo de vida do sistema.
Figura 1: O impacto das mudanças proposto por PRESSMAN

Fonte: PRESSMAN, 2001
PRESSMAN sugere o Gerenciamento de Configuração para o controle de
mudanças de software durante o clico de desenvolvimento e vida do mesmo. As

17
atividades do Gerenciamento de Configuração seriam: “(1) Identificar Mudanças; (2)
Controlar Mudanças; (3) Garantir que mudanças sejam corretamente
implementadas; (4) Reportar mudanças as partes interessadas.” (PRESSMAN,
2001, p.225). PRESSMAN admite que mudanças em software são inevitáveis,
prepara-se para o tratamento destas mudanças, mas não deseja nem estimula a sua
ocorrência para o processo de desenvolvimento de software.
Como mostra KRUCHTEN (2003), o Processo Unificado (UP) provê
atividades para concepção e fechamento do escopo do projeto logo na primeira fase
de desenvolvimento do software com as seguintes características: seleção dos
requisitos mais importantes, visão geral do software, custo total, prazo, recursos
necessários e riscos previstos. Prossegue então o ciclo de vida de desenvolvimento
para a fase de elaboração onde então todo o restante dos requisitos são detalhados.
O Processo Unificado (UP) segue o mesmo critério quanto a mudanças defendido
por PRESSMAN. Procura definir todas as funcionalidades do software
detalhadamente antes de construir o mesmo para diminuir o risco de alterações na
arquitetura, no desenho ou no próprio código do sistema após desenvolvido.
Metodologias ágeis pensam de forma diferente. BECK propõe um outro
gráfico para variação do custo de mudanças no tempo de vida de um sistema:
Figura 2 - O custo das mudanças proposto em Extreme Programming

Fonte: BECK, 1999
18
BECK (1999) justifica o gráfico por um lado pela existência em ferramentas
que mapeiam as classes de um projeto, suas responsabilidades e a troca de
mensagens entre elas. Desta forma se torna menos trabalhoso verificar o impacto de
uma mudança de funcionalidade específica do projeto de software. Por outro lado
BECK baseia-se em três fatores relacionados ao processo Extreme Programming
(XP): o desenho simples; os testes automáticos e praticas padronizadas de
modificação de desenho.
O Desenho Simples é uma das práticas do Extreme Programming. BECK
(1999) descreve que o desenvolvimento extremo não precisa se preocupar em
antecipar mudanças no projeto de software, realizando na interação atual somente
os requisitos negociados com o cliente. Classes complexas, utilizadas como
fundamento estrutural do código no desenvolvimento de projetos longos, não são
bem recebidas no XP.
Os testes automáticos possibilitados por ferramentas adquiridas no mercado
ou construídas pela própria equipe de desenvolvimento conferem segurança na
realização de mudanças no código. BECK (1999) atribui ao programador ou a
equipe de programadores a responsabilidade de sempre realizar testes automáticos
unitários, registrando e acrescentando na lista novos testes concebidos durante o
desenvolvimento de novas funcionalidades. Somando-se aos testes automáticos,
BECK (1999) atribui ao cliente, que também participa da equipe de desenvolvimento
no XP, a responsabilidade de realizar testes funcionais nas alterações realizadas no
sistema.
19
O terceiro fator apontado por BECK (1999) são as praticas padronizadas de
modificação de desenho. Estas práticas estão ligadas aos padrões de desenho
apresentados pela Gangue dos Quatro:
Padrões de desenho tornam fácil o reuso com sucesso de desenhos de

arquiteturas. Expressando comprovadas técnicas como padrões de
desenho elas se tornam mais acessíveis para desenvolvedores de novos
sistemas. Padrões de desenho ajudam a você substituir desenhos
alternativos que venham comprometer a reusabilidade. (GAMMA, HELM,
JOHNSON, VLISSIDES, 1995, p.7)
Para garantir a manutenção do código fonte com um desenho padronizado,
BECK (1999) coloca como uma das práticas do XP a refatoração do código.
FOWLER oferece dois conceitos para refatoração de código:
Refatoração (substantivo): uma alteração feita na estrutura interna do

software para torna-lo mais fácil de ser entendido e menos custoso de ser
modificado sem alterar o seu comportamento observável. (FOWLER, 2004,
p.52)
Refatorar (verbo): reestruturar software aplicando uma série de refatorações

sem alterar seu comportamento observável. (FOWLER, 2004, p.53)
A Gangue dos Quatro (GAMMA, HELM, JOHNSON, VLISSIDES, 1995) afirma
que padrões de projeto são alvos para refatoração. Segundo FOWLER “Muitas
refatorações (…) são sobre a introdução de padrões em um sistema” (FOWLER,
2004, p.98) .
É importante perceber que tanto o UP quanto XP preveem mudanças e criam
meios para tratá-las. Ao trabalhar com mudanças mais rigidamente na Gerência de
Configuração do Processo Unificado ou mais intensamente nas diversas pequenas
interações dos processos ágeis, utilizar refatoração para manter o código segundo
padrões consagrados de desenho ajuda a diminuir os custos e a garantir a qualidade
do software. FOWLER (2004) lista quatro razões por que se deve refatorar.
A primeira razão apontada por FOWLER é que refatoração melhora o projeto
de software mantendo sua manutenibilidade. “Sem refatoração, o projeto do

20
programa termina por se deteriorar” (FOWLER, 2004, p.54). Descrevendo a tarefa
Controlar Mudanças da Atividade de Gerencia de Configuração, PRESSMAN (2001)
alerta que em projetos de softwares de longa duração não controlar mudanças leva
rapidamente para o caos. Apresenta então um processo sistemático para controle de
mudanças conforme a figura que pode ser vista abaixo:
Fonte: PRESSMAN, 2001
Neste processo quatro passos são semelhantes ou podem utilizar técnicas de
refatoração: Change report is generated (Relatório de mudanças gerado), Make the
change (Realizar mudança), Review (audit) the change (Revisar Mudança) e ECO
21
(Ordem de Mudança de Engenharia) generated (Gerar ECO). Segundo PRESSMAN,
o relatório da mudança é gerado a partir da avaliação da importância da mudança
versus seu impacto nos artefatos do projeto e nas funcionalidades do sistema. Após
a mudança ser realizada, ela é revisada segundo critérios definidos na ECO (Ordem
de Mudança de Engenharia).
A segunda razão apontada por FOWLER é “refatoração torna o software mais
fácil de entender” (FOWLER, 2004, p.54). Em Extreme Programming (XP) o
entendimento do código é um fator muito importante. Como o XP diminui a
quantidade de artefatos produzidos durante o desenvolvimento, o código ganha
status de documentação. Um código complexo ou confuso nesta situação inviabiliza
o processo. BECK (1999) descreve que dentro da equipe de desenvolvimento XP
os novos membros são cada vez mais e mais encorajados a aceitar
responsabilidades. Um dos quatro valores do Extreme Programming é a
comunicação. Um código complexo e confuso não comunica nada e desencoraja
qualquer um de colocar as mãos nele. Descrevendo sobre a atividade codificar, uma
das quatro atividades básicas do XP, BECK(1999) lista como um código bem escrito
pode comunicar: expressando intentos táticos do sistema, descrevendo algorítimos,
pontuando passos para uma futura expansão ou contração e indiretamente também
provendo uma especificação para o sistema em todos os seus níveis.
A terceira razão apontada por FOWLER é “refatorar ajuda a encontrar falhas”
(FOWLER, 2004, p.55). Como resultado “Refatorar me ajuda ajuda a ser muito mais
efetivo na escrita de código robusto” (FOWLER, 2004, p.55). Existe porém o risco da
própria refatoração introduzir erros no projeto. Podemos listar pelo menos duas
formas de se evitar isso. Uma é a criação de ferramentas automáticas de teste a

22
partir de casos de teste e também testes unitários. BECK (1999) lista dentro do
trabalho do programador, ou par de programadores, as atividades de refatoração de
código e realização de testes unitários. Estas atividades devem ser realizadas a
medida da necessidade e de forma entrelaçada.
A outra forma de se evitar erros na refatoração e a utilização de ferramentas
para esta atividade. ROBERTS e BRANT (2004) listam alguns critérios técnicos e
práticos necessários para uma ferramenta de refatoração. Como critérios técnicos
temos: “a habilidade de procurar diversas entidades do programa por todo
programa” (ROBERTS,BRANT, 2004, p. 342) que pode oferecida pela existência de
um Banco de Dados o Programa; Árvores de Análise Semântica que são “uma
estrutura de dados que representa a estrutura interna do próprio método”
(ROBERTS,BRANT, 2004, p. 343); e Acurácia de forma a manter o comportamento
do código após refatorado. Como critérios práticos temos velocidade na realização
automática de refatorações, a opção de desfazer refatorações voltando ao estado
anterior e a integração com outras ferramentas em um único ambiente de
desenvolvimento.
A quarta e última razão apontada por FOWLER é que refatoração aumenta a
velocidade de desenvolvimento do software. Segundo FOWLER (2004) isso
acontece em dois momentos. No próprio momento da alteração do código no
presente, onde o desenvolvedor estuda o código enquanto o refatora e, após
entender melhor o comportamento do código, implementa a alteração mais
rapidamente. Esta primeira situação é ilustrada hipoteticamente por BECK (1999)
que simula uma situação de alteração de código por um par de programadores onde
23
em um certo momento são realizadas refatorações para melhor entendimento do
código. E também em um momento futuro:
Um bom projeto é essencial na manutenção da velocidade de

desenvolvimento de software. Refatorar ajuda você a desenvolver software
mais rapidamente, porque evita que o projeto do sistema deteriore. A
refatoração pode até mesmo melhorar um projeto. (FOWLER, 2004, p.56)
24
3. METODOLOGIA
Como metodologia desta monografia adota-se a abordagem dedutiva:
Partindo-se das circunstâncias utilizadas como justificativa para Processos de
Desenvolvimento Ágil e caminhando-se para a defesa da refatoração de código. E
qualitativa: Realizando-se um estudo de caso onde utilizam-se técnicas e
ferramentas de refatoração.
Boa parte do conteúdo desta monografia é apresento no capítulo anterior,
Revisão da Literatura, isso porque o estudo teórico foi escolhido como uma das
modalidades de trabalho. Estuda-se a importância da refatoração de código. A outra
modalidade de trabalho, apresentada no próximo capítulo, é o Estudo de Caso. São
experimentadas técnicas de refatoração de código em um projeto real de software.
a) As etapas de pesquisa e elaboração desta monografia foram realizadas na
seguinte ordem:
• Estudo de referencial teórico em literatura sobre refatoração de código,
padrões de projeto de código, processos de desenvolvimento de software e
metodologias ágeis.
• Escolha de porção código de projeto de real para experimentação de técnicas
de refatoração de código.
• Preparação de ambiente para execução de técnicas de refatoração de código.
• Experimentação de técnicas de refatoração, registro de etapas e resultados.
• Elaboração de revisão de literatura de literatura de monografia.

25
• Análise de resultados de estudo de caso em contraponto com revisão de
literatura.
• Finalização de monografia com registro de análise de resultados e
conclusões.
b) Os métodos utilizados são:
• Estudo de referencial teórico.
• Avaliação de ferramentas de refatoração de código.
• Testes de funcionalidades de softwares antes e após refatoração.
• Avaliação de qualidade de código antes e após refatorado.
• Registro de problemas e medidas tomadas.
• Registros de resultados positivos e negativos em utilização de técnicas e
ferramentas de refatoração de código.
c) As ferramentas utilizadas são:
• Eclipse Galileo for PHP Developers (Build id: 20100218-1602), disponibilizado
para download em http://eclipse.org/ .
• PHPDoc 1.4.2 released, disponibilizado para download em http://phpdoc.org/ .
• Visual Paradigm for UMP Community Edition Version 6.4 (Build20081026),
disponibilizado para download em http://www.visual-paradigm.com/.
• BrOffice.org 3.1.0 (OOO310m11 Build: 9399), disponibilizado para download
em http://www.openoffice.org .
26
d) O ambiente utilizado para experimentação no estudo de caso possui as seguintes
configurações:
• Notebook Dell Inspiron 1545. Processador: Intel(R) Core(TM) 2 Duo CPU
T6500 @2.5GHz 2.10GHz. Memória RAM: 3,00 GB.
• Sistema Operacional: Windows Vista Home Edition Service Pack1.
• Servidor Web: Wamp Server Version 2.0, Created by Romain Bourdon
(romain@anaska.com), Sources are available at SourceForge. Disponibilizado
para download em http://www.wampserver.com

27
4. ESTUDO DE CASO
Esta seção contém refatoração de código utilizada na prática. O objetivo
principal é experimentar algumas das técnicas existentes de refatoração. O processo
será testar as funcionalidades do código existente, aplicar alguma técnica de
refatoração, testar novamente funcionalidades do código, aplicar mais algumas
técnicas de refatoração, testar mais uma vez funcionalidades do código, corrigir
eventuais erros, refatorar, e testar . Foi preparado um ambiente com o Eclipse como
ferramenta de desenvolvimento e refatoração e o Wamp, Apache + PHP + MySQL,
como Servidor Web. Outra ferramenta de refatoração utilizada é o PHPDocument.
Não é apresentado um estudo completo de técnicas nem de ferramentas de
refatoração pelo fato de não ser este o objetivo deste estudo de caso. Seria
necessário escrever um livro para testar exaustivamente técnicas de refatoração.
Também não foram encontradas muitas ferramentas de refatoração de código para
linguagem PHP. O PHPDocument auxilia a montar um banco de dados de classes,
atributos e métodos do programa a ser refatorado. O ambiente de Desenvolvimento
Integrado (IDE) Eclipse na versão instalada possui a ferramenta PDT 2.1(PHP
Development Tools 2.1) que oferece alguns recursos úteis para refatoração de
código.
Descreve-se primeiramente o software de cujo parte código sofrerá
refatoração. Depois é apresentado o requisito específico que será trabalhado, o caso
de uso relacionado a este requisito, um diagrama de classes que ajudará a entender
a estrutura desta parte do sistema e um diagrama de sequência que ajudará a

28
entender o seu funcionamento. Para fins de comparação, coloca-se uma porção do
código que será refatorado no seu estado inicial.
Antes de refatorar são elaborados casos de teste e é construída uma
ferramenta de testes automáticos que será executada a cada refatoração do código.
Durante a refatoração são exibidos diversos diagrama de classes, quando as
responsabilidades das classes mudam, diagrama de sequência, quando a sequência
de métodos muda e porções refatoradas de código quando necessário. Foram
priorizados os diagrama de classes e sequência ao código em si porque eles são
mais compactos e descrevem mais claramente a mudança.
Por fim coloca-se uma porção de código após refatorado, um diagrama de
classes e um diagrama de sequência com o objetivo de comparação com os seus
paralelos no estado inicial.
4.1 O SOFTWARE
O sistema objeto deste estudo de caso tem um propósito bem simples:
calcular pontuação de funcionários de uma equipe de trabalho e classificar estes
funcionários segundo a pontuação. Na realidade não é um sistema, mas um sub-
sistema, uma ferramenta que integra com um sistema de gerenciamento de projetos
para recuperar dados de apontamento de horas da equipe de colaboradores e então
calcula as pontuações segundo critérios pré-estabelecidos.

29
A equipe de recursos humanos da empresa cliente que solicitou o sub-
sistema, utiliza as informações de pontuação para premiar os funcionários com o
intuito de estimula-los a chegar pontualmente ao local de trabalho e também sair
após o horário esperado. Apesar da empresa não exigir um horário fixo de chegada
e saída dos seus funcionários, precisa da presença das equipes dos diversos
projetos dentro do horário comercial, onde seus clientes podem ter acesso a eles.
4.2 O REQUISITO
Abaixo o requisito transcrito da documentação do projeto de desenvolvimento
do sub-sistema de calculo de pontuações de funcionários:
Indicadores de Cumprimento de Horário: Serão distribuídos até 10

pontos por dia por funcionário, relacionado ao cumprimento de horários.
Até 5 (cinco) pontos para horário de chegada: chegando até as 09:00
horas, o funcionário recebe 5 (cinco) pontos; combinando com o gerente até
o dia anterior sobre eventuais atrasos, recebe 5 (cinco) pontos, limitado a 2
dias por mês; chegando das 9:00 hrs até as 9:30 hrs, avisando até 09:00
hrs sobre o atraso, recebe 4 (quatro) pontos; chegando das 9:00 hrs até as
9:30 hrs sem avisar sobre o atraso, recebe 3 (três) pontos; chegando das
9:30 hrs até as 10:00 hrs, avisando até as 09:00 hrs sobre o atraso, recebe
2 (dois) pontos; chegando das 9:30 hrs até as 10:00 hrs, sem avisar sobre o
atraso, recebe 1 (um) ponto; chegando das 10:00 hrs até as 10:30 hrs,
avisando até as 9:00 hrs sobre o atraso, recebe 1 (um) ponto; chegando
após às 10:00 hrs, sem avisar sobre o atraso, não recebe pontos.
Até 5 (cinco) pontos para horário de saída: combinando com o
gerente até o dia anterior sobre saídas mais cedo, recebe 5 (cinco) pontos,
limitado a 2 (dois) dias por mês; saindo após às 17:30 hrs, o funcionário
recebe 5 (cinco) pontos; saindo das 17:00 hrs até às 17:30 hrs, o
funcionário recebe 4 (quatro) pontos; saindo das 16:30 hrs até às 17:00 hrs,
o funcionário recebe 3 (três) pontos; saindo das 16:00 hrs até às 16:30 hrs,
o funcionário recebe 2 (dois) pontos; saindo antes das 16:00 hrs o
funcionário não recebe pontos.
Orientações gerais: combinando com o gerente até o dia anterior
sobre ausências de um período, o funcionário recebe 3 (três) pontos;
faltando a um período sem um aviso prévio o funcionário recebe 5 (cinco)
pontos; faltando a um dia sem aviso prévio o funcionário perde 10 (dez)
pontos; funcionários em férias ou em recesso recebem por dia a média de
pontos por dia obtida no mês anterior; ao final de cada mês, para cada hora
30
devedora no banco de horas o funcionário perderá 2 (dois) pontos.
(Documentação de Projeto de Software)
No projeto estudado, a empresa cliente solicitou o desenvolvimento do
sistema num prazo de uma semana. A equipe de recursos humanos haviam
anunciado o programa de pontos no mês anterior e desejavam realizar a primeira
premiação. Não foi elaborada nenhuma documentação além do requisito e do código
fonte. No entanto, um primeiro trabalho para entender melhor o código que se
pretende refatorar será elaborar um documento descritivo de caso de uso, um
diagrama de classes e um diagrama de sequência.
O descritivo de caso de uso é apresentado abaixo:

Descritivo de Caso de Uso: Gerar pontuação automática de mês
Descrição: Realizar calculo de pontuação mensal de funcionários durante o mês.
Condições Prévias:
- Integração com sistema de Gerenciamento de Projetos ter recuperado dados de apontamentos de
horas de funcionários em projetos.
Fluxo Básico:
1) Usuário inicia caso de uso.
2) Sistema exibe tela solicitando Mês para geração de pontuação.
3) Usuário informa Mês e confirma inicio de processamento.
4) Sistema busca lista de funcionários.
5) Para cada funcionário sistema busca apontamentos de horas no mês indicado.
6) Para cada dia de apontamento de horas do funcionários sistema calcula pontuação diária.
6.1) Sistema calcula pontuação por hora de chegada segundo regras: Até 5 (cinco) pontos para
horário de chegada: chegando até as 09:00 horas, o funcionário recebe 5 (cinco) pontos;
combinando com o gerente até o dia anterior sobre eventuais atrasos, recebe 5 (cinco) pontos,
limitado a 2 dias por mês; chegando das 9:00 hrs até as 9:30 hrs, avisando até 09:00 hrs sobre o
atraso, recebe 4 (quatro) pontos; chegando das 9:00 hrs até as 9:30 hrs sem avisar sobre o atraso,
recebe 3 (três) pontos; chegando das 9:30 hrs até as 10:00 hrs, avisando até as 09:00 hrs sobre o
atraso, recebe 2 (dois) pontos; chegando das 9:30 hrs até as 10:00 hrs, sem avisar sobre o atraso,
recebe 1 (um) ponto; chegando das 10:00 hrs até as 10:30 hrs, avisando até as 9:00 hrs sobre o
atraso, recebe 1 (um) ponto; chegando após às 10:00 hrs, sem avisar sobre o atraso, não recebe
pontos.
6.2) Sistema calcula pontuação por hora de saída segundo regras: Até 5 (cinco) pontos para horário
de saída: combinando com o gerente até o dia anterior sobre saídas mais cedo, recebe 5 (cinco)
pontos, limitado a 2 (dois) dias por mês; saindo após às 17:30 hrs, o funcionário recebe 5 (cinco)
pontos; saindo das 17:00 hrs até às 17:30 hrs, o funcionário recebe 4 (quatro) pontos; saindo das
16:30 hrs até às 17:00 hrs, o funcionário recebe 3 (três) pontos; saindo das 16:00 hrs até às 16:30
hrs, o funcionário recebe 2 (dois) pontos; saindo antes das 16:00 hrs o funcionário não recebe
pontos.
6.3) Sistema adiciona pontos relacionados a regra: combinando com o gerente até o dia anterior
sobre ausências de um período, o funcionário recebe 3 (três) pontos.
7) Sistema registra pontuação diária de funcionário.
8) Sistema verifica existência de período de férias do funcionário dentro do mês.
9) Sistema registra pontuação média diária de funcionário do mês anterior para cada dia do período
de férias.
10) Sistema calcula desconto de horas de funcionário relacionados a horas devedoras no mês
segundo regra: para cada hora devedora no banco de horas o funcionário perderá 2 (dois) pontos.
11) Caso existam mais funcionários para processar sistema retorna ao passo 5). Caso NÃO existam
finaliza o caso de uso.
Condições Posteriores:
- Pontuações mensais de funcionários registradas.
Tabela 1: Caso de Uso - Gerar pontuação automática de mês.
31
4.3 O ESTADO INICIAL
Através do código fonte de todo o projeto pode-se elaborar o diagrama de
classes apresentado abaixo:
Figura 4: Diagrama de Classes antes da Refatoração

32
Abaixo está o diagrama de sequencia do método gera_pontuacao() da classe
gera_pontuacao_automatica_mes:
Figura 5: Diagrama de Sequência método gera_pontuação antes da Refatoração.

33
Apresenta-se abaixo o código fonte PHP do método gera_pontuacao:
Function gera_pontuacao(){
if(!$dia_processamento)
{
$dia_processamento = date("Y-m-d");
}
$query = " SELECT cod_funcionario, cod_funcionario_interface FROM TB_FUNCIONARIO WHERE 1=1";

$result = $bd->SQL_query_result($query);
if ($bd->SQL_num_rows_result($result))
{
while(list($cod_funcionario, $cod_funcionario_interface) = $bd->SQL_fetch_result($result))
{
$motivo->remove_motivos_automaticos($cod_funcionario, $dia_processamento);
$query = " SELECT
MIN(hor_entrada) entrada, MAX(hor_saida) saida, dta_ponto
FROM TB_PONTO_FUNCIONARIO
WHERE
dta_ponto BETWEEN '" .$this->data_processamento_inico."'
AND '" .$this->data_processamento_fim."'
AND cod_funcionario = '" .$cod_funcionario."'
GROUP BY
cod_funcionario, dta_ponto" ;
$result2 = $bd->SQL_query_result($query);
if ($bd->SQL_num_rows_result($result2))
{
while($vet_ponto = $bd->SQL_fetch_assoc_result($result2))
{
if($vet_ponto["entrada"] > "09:00:00")
{
{
{
{
$interface->insere_motivo_funcionario($cod_funcionario, '4', $vet_ponto["dta_ponto"]);
}
}
else{
}
}
else{
}
}
else{
}
if($vet_ponto["saida"] < "17:30:00")
{
{
{
{
}
if($vet_ponto["saida"] > "16:00:00")
{
}
}
else{
}
}
else{
}
}
else{
}
}
}
$query_ferias = " SELECT
cod_usuario
FROM
" .BANCO_INTERFACE.".ferias
WHERE
flg_status_ferias = '1'
AND dth_inicio_ferias <= '" .$vet_ponto["dta_ponto"]."'
AND dth_fim_ferias >= '" .$vet_ponto["dta_ponto"]."'
AND cod_usuario = '" .$cod_funcionario_interface."'";
$result_ferias = $bd->SQL_query_result($query_ferias);
if ($bd->SQL_num_rows_result($result_ferias))
{
$interface->insere_pontos_ferias($cod_funcionario, $vet_ponto["dta_ponto"]);
}
}
}
echo "Processamento finalizado!";
}
Figura 6: Código Fonte gera_pontuacao antes da Refatoração

34
O Diagrama de Classes inclui as classes persistentes, tabelas do banco de
dados e as classes relacionadas a camada de controle do sistema que implementam
as regras de negócio. A classes da camada visual não foram documentadas por
fazerem parte de uma framework e estarem fora do âmbito deste estudo de caso
Através do Diagrama de Sequencia percebe-se alguns problemas no código
fonte relacionado a geração de pontuações de funcionário: a camada de persistência
do código esta entrelaçada com a camada de controle; as responsabilidades das
classes não estão bem estabelecidas; existe um forte acoplamento entre as classes
e o método gera_pontuacao é longo. Durante a refatoração será tratado cada um
destes problemas.
O código fonte do método gera_pontuacao além de longo tem um fluxo
complexo e não comunica exatamente o seu propósito. Durante a refatoração este
método será quebrado em vários métodos que terão nomes descritivos de cada
etapa da geração de pontuação.
4.4 CRIANDO CASOS DE TESTE
A partir do Descritivo de Caso de Uso, ver Tabela 1, foram elaborados três
casos de teste. Um caso de teste para funcionário com registro de pontos e sem
férias, um caso de teste para funcionário somente com férias e um caso de teste
para funcionário com férias e registro de pontos no mês. Nos registros de pontos dos
funcionários são realizados testes de fronteira. Foi criada uma ferramenta que
35
realiza os três casos teste de uma só vez no código, sinalizando caso ocorram erros.
Esta monografia não são explicadas as técnicas de testes de software, para saber
mais sobre assunto consulte MYERS (1985). Os casos de teste criados podem ser
vistos no Apêndice A.
4.5 REFATORANDO
Criados os casos de teste e construída a ferramente que executa
automaticamente os testes, o próximo passo é começar efetivamente a refatorar o
código para corrigir os problemas encontrados. É tratado cada um dos problemas de
por vez:
a) Resolvendo o problema - a camada de persistência do código esta
entrelaçada com a camada de controle: Para resolver este problema foram
criadas ou refatoradas as classes do tipo entidade que são responsáveis por manter
os dados do sistema. Foi criada uma classe para manter cada uma das tabelas com
atributos referentes aos campos da tabela e métodos para gravar, recuperar e
apagar registros. Foi utilizado o padrão de desenho Factory Method da Gangue dos
Quatro (GAMMA, HELM, JOHNSON, VLISSIDES, 1995), desta forma todas as
classes entidades descendem de uma nova classe tabela e são fabricadas por uma
classe fabrica_tabela. Para representar esta refatoração é exibido abaixo um
diagrama de classes somente com as classes entidade após a refatoração.

36
Figura 7: Diagrama de Classes de Camada de Persistência (Refatoração 1)
Após esta refatoração é possível mudar o Diagrama de Classes Inicial do
Software atualizando as classes de entidades e retirando a classe class_bd. Esta
classe, bem como a nova classe fabrica_tabela, podem ficar escondidas dentro de
um pacote de persistência do projeto. Para isso é preciso refatorar os métodos que
fazem acesso direto a classe class_bd para acessarem métodos das classes de
entidade. Isso pode ser feito utilizando o métodos de refatoração Extrair Método e
Criar um Método Padrão (FOWLER, 2004).
b) Resolvendo o problema - as responsabilidades das classes não estão
bem estabelecidas: Para resolver este problema todos os métodos das classes
foram avaliados e movidos de uma classe para outra de acordo com a

37
responsabilidades destas. Foi utilizado o método de refatoração Mover Método
(FOWLER, 2004). Alguns métodos estavam replicados e foram suprimidos. Foi
criada a classe data_hora para tratar de informações de data e hora. Abaixo a
diagrama de classes após estas movimentações de métodos.
Figura 8: Diagrama de Classes do Software (Refatoração 2)

38
c) Resolvendo o problema - existe um forte acoplamento entre as classes:
Para resolver este problema foi reorganizada a troca de mensagens entre as classes
utilizando-se as técnicas de refatoração Ocultar Delegação e Remover Intermediário
(FOWLER, 2004).
Figura 9: Diagrama de Sequência (Refatoração 3)
d) Resolvendo o problema - o método gera_pontuacao é longo: Para
resolver este problema o método gera_pontuacao foi quebrado em vários métodos
que terão nomes descritivos de cada etapa da geração de pontuação. Foi utilizada a
técnica de refatoração Extrair Método (FOWLER, 2004).

39
4.6 O ESTADO FINAL
Abaixo são apresentados os diagramas de classe e sequência e a porção de
código do método gera_pontuacao após a realização de todas as refatorações do
estudo de caso:
Figura 10: Diagrama de Classes após Refatoração

40
Figura 11: Diagrama de Sequência após Refatoração
Através dos diagramas de classe e de sequência percebe-se como as
responsabilidades das classes estão melhor distribuídas. Percebe-se que somente a
classes de controle gera_pontuacao_automatica_mes tem relação de dependência
com as classes do tipo entidade. Através do código fonte percebe-se mais
facilmente o objetivo do método gera_pontuacao. O desenho das classes e o código
fonte se tornaram menos complexos e mais comunicativos.

41
Function gera_pontuacao_ferias($cod_funcionario, $cod_funcionario_interface){
global $interface, $tb_funcionario_dia, $tb_motivo_funcionario_dia;
$lista_ferias = array();
$lista_ferias =
$interface->busca_ferias_funcionario($cod_funcionario, $this->data_processamento_inicio, $this->$data_processamento_fim);
$media_pontuacao_diaria =
$tb_funcionario_dia->get_media_pontos_mes_anterior($cod_funcionario, $this->data_processamento_inicio);
if (is_array($lista_ferias) && count($lista_ferias)){
for ($num_ferias = 0; $num_ferias < count($lista_ferias);$num_ferias++)
{
$tb_funcionario_dia->cod_funcionario = $cod_funcionario;
$tb_funcionario_dia->dia_funcionario_dia = $lista_ferias[$num_ferias]["dia"];
$tb_funcionario_dia->vlr_pontos_dia = $media_pontuacao_diaria;
$tb_motivo_funcionario_dia->cod_motivo_funcionario_dia = $tb_funcionario_dia->grava(0);
$tb_motivo_funcionario_dia->cod_funcionario = $cod_funcionario;
$tb_motivo_funcionario_dia->cod_motivo = '3'; //Motivo Férias
$tb_motivo_funcionario_dia->grava(0);
}
}
}
function calcula_motivo_entrada($hrs_entrada){
if($hrs_entrada > "09:00:00")
{
{
{
{
return '4'; //Motivo faltou ao periodo
}
return ''; // Sem Motivo pois chegou depois das 10:00
}
return '9'; //Motivo chegou entre 9:30 e 10:00
}
return '8'; // Motivo chegou entre 9:00 e 9:30
}
return '7'; //Motivo chegou até as 9:00
}
function calcula_motivo_saida($hrs_saida){
if($hrs_saida < "17:30:00")
{
if($hrs_saida < "17:00:00")
{
if($hrs_saida < "16:30:00")
{
if ($hrs_saida < "16:00:00")
{
if($hrs_saida < "13:00:00")
{
return '5'; //Motivo faltou ao periodo
}
return ''; // Sem Motivo pois saiu antes das 16:00
}
return '13'; // Motivo saiu entre 16:00 e 16:30
}
return '12'; //Motivo saiu entre 16:30 e 17:00
}
return '11'; // Motivo saiu entre 17:00 e 17:30
}
return '10'; //Motivo saiu após as 17:30
}
function gera_pontuacao(){
global $tb_funcionario, $tb_funcionario_dia, $tb_motivo_funcionario_dia;
$lista_funcionario = array();
$lista_funcionario = $tb_funcionario->buscar(0);
if (is_array($lista_funcionario) && count($lista_funcionario))

{
for ($num_funcionario = 0; count($num_funcionario); $num_funcionario++)
{
$cod_funcionario = $lista_funcionario[$num_funcionario]["cod_funcionario"];
$cod_funcionario_interface = $lista_funcionario[$num_funcionario]["cod_funcionario_interface"];
$tb_motivo_funcionario_dia->remove_motivos_automaticos($cod_funcionario, $this->data_processamento_inicio);
$lista_ponto = array();
$lista_ponto = $tb_ponto_funcionario->buscar(0);
if (is_array($lista_ponto) && count($lista_ponto))
{
for ($num_ponto = 0; count($num_ponto); $num_ponto++)
{
$tb_funcionario_dia->cod_funcionario = $cod_funcionario;
$tb_funcionario_dia->dia_funcionario_dia = $lista_ponto[$num_ponto]["dta_ponto"];
$cod_funcionario_dia = $tb_motivo_funcionario_dia->grava(0);
$tb_motivo_funcionario_dia->cod_motivo_funcionario_dia = $cod_funcionario_dia;
$tb_motivo_funcionario_dia->cod_motivo = $this->calcula_motivo_entrada($lista_ponto[$num_ponto]["hor_entrada"]);
$tb_motivo_funcionario_dia->cod_motivo_funcionario_dia = $cod_funcionario_dia;
$tb_motivo_funcionario_dia->cod_motivo = $this->calcula_motivo_saida($lista_ponto[$num_ponto]["hor_saida"]);
}
}
$this->gera_pontuacao_ferias($cod_funcionario, $cod_funcionario_interface);
}
}
echo "Processamento finalizado!";
}
Figura 12: Código Fonte gera_pontuação após Refatoração

42
5. CONSIDERAÇÕES FINAIS
A refatoração de código realizada com as técnicas adequadas e com
ferramentas poderosas podem facilitar muito o trabalho de equipes de
desenvolvimento de projetos que sofrem mudanças constantes. No entanto,
diferente do que os agilístas esperam, o código pode não comunicar de maneira
eficaz os objetivos do software. Durante o estudo de caso percebeu-se a
necessidade de desenhar diagramas de classe, para representar a estrutura do
código de uma forma compacta. Também foram necessários diagramas de
sequência para representar melhor o comportamento dos métodos. Desenhar o
código que se pretende refatorar pode acelerar o processo de refatoração.
Outro aspecto a favor do desenho e contra o código no momento da
comunicação é a universalidade. Diagramas UML podem ser entendidos por um
conjunto bem maior de pessoas que códigos escritos em uma linguagem particular.
Por outro lado o código fonte esta mais perto do programador que é o responsável e
maior interessado da refatoração de código. Uma alternativa seria a utilização de
ferramentas de refatoração que apresentam integração entre desenho e código
fonte.
Por fim, é importante ressaltar a necessidade de criar um processo, ainda que
simples, para a refatoração de código. A equipe de software precisa ser capaz de
detectar os momentos corretos e as locais no código fonte onde é vantajoso
refatorar. Também é necessário definir como uma prática saudável e esperada a
refatoração de código dentro da fábrica de software.

43
REFÊRENCIAS
PRESSMAN, Roger S. Software Engineering: A practitioner's approach. 5th ed.

McGraw-Hill, 2001. 860p.
KRUCHTEN, Philipe. The Rational Unified Process: An introduction, 3th ed.

Addison-Wesley, 2003. 336p.
BECK, Kent. Extreme Programming Explained: Embrace change. Addison-

Wesley, 1999. 137p.
FOWLER, Martin et al. Refatoração: Aperfeiçoando o Projeto de Código Existente.

Tradução Acuan Fernandes – Porto Alegre: Bookman 2004. 365p.
ROBERTS, Don; BRANT, J. Ferramentas de Refatoração. In: FOWLER, Martin et al.

Refatoração: Aperfeiçoando o Projeto de Código Existente. Tradução Acuan
Fernandes – Porto Alegre: Bookman 2004. 365p.
GAMMA, E.; HELM, R.; JOHNSON R.; VLISSIDES, J.; Design Patterns: Elements
of Reusable Object Oriented Software. Addison-Wesley, 1995. 358p.
MYERS, G.J. The Art of Software Testing 1st ed. Wiley Interscience, 1985.
44
APÊNDICE
APÊNDICE A – Casos de Testes
Primeiro Caso: Funcionário com registro de pontos e sem férias

Pontos de Funcionário
Avisou Avisou Combinou
Data Chegada Dia Anterior Antes das 9:00 Saída saída cedo Pontos Dia
01/02/10 09:00:00 Não Importa Não Importa 17:30:00 Não 10
02/02/10 09:01:00 Não Não 17:30:00 Não 8
03/02/10 09:01:00 Sim Não Importa 17:30:00 Não 10
04/02/10 09:30:00 Não Sim 17:30:00 Não 9
06/02/10 Sábado
07/02/10 Domingo
08/02/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 10
09/02/10 09:01:00 Não Não 17:00:00 Não 7
10/02/10 09:30:00 Não Sim 17:00:00 Não 8
11/02/10 09:31:00 Não Não 17:30:00 Não 6
12/02/10 10:00:00 Não Sim 17:30:00 Não 7
13/02/10 Sábado
14/02/10 Domingo
15/02/10 Recesso Carnaval
16/02/10 Feriado Carnaval
18/02/10 10:01:00 Não Não Importa 16:59:00 Não 3
19/02/10 10:01:00 Não Não Importa 16:30:00 Sim 5
20/02/10 Sábado
21/02/10 Domingo
26/02/10 09:01:00 Não Não 12:00:00 Não 3
27/02/10 Sábado
28/02/10 Domingo
Total de Pontos Mês: 124
Tabela 2 – Caso de Teste 1: Funcionário com pontos e sem férias
45
Casos de Teste Gerar Pontuação Automática de Mês
Segundo Caso: Funcionário com registro de pontos e com férias
02/01/10 Sábado
03/01/10 Domingo
05/01/10 09:01:00 Não Não 17:00:00 Não 7
06/01/10 09:30:00 Não Sim 17:00:00 Não 8
07/01/10 09:31:00 Não Não 17:30:00 Não 6
08/01/10 10:00:00 Não Sim 17:30:00 Não 7
09/01/10 Sábado
10/01/10 Domingo
12/01/10 09:01:00 Não Não 17:00:00 Não 7
13/01/10 09:30:00 Não Sim 17:00:00 Não 8
14/01/10 09:31:00 Não Não 17:30:00 Não 6
15/01/10 10:00:00 Não Sim 17:30:00 Não 7
16/01/10 Sábado
17/01/10 Domingo
19/01/10 09:01:00 Não Não 17:00:00 Não 7
20/01/10 09:30:00 Não Sim 17:00:00 Não 8
21/01/10 09:31:00 Não Não 17:30:00 Não 6
22/01/10 10:00:00 Não Sim 17:30:00 Não 7
23/01/10 Sábado
24/01/10 Domingo
26/01/10 09:01:00 Não Não 17:00:00 Não 7
27/01/10 09:30:00 Não Sim 17:00:00 Não 8
28/01/10 09:31:00 Não Não 17:30:00 Não 6
29/01/10 10:00:00 Não Sim 17:30:00 Não 7
30/01/10 Sábado
31/01/10 Domingo
Total de Pontos Mês Janeiro: 150
01/02/10
02/02/10
03/02/10 Férias
04/02/10
05/02/10 40
06/02/10 Sábado
07/02/10 Domingo
09/02/10 09:01:00 Não Não 17:00:00 Não 7
10/02/10 09:30:00 Não Sim 17:00:00 Não 8
11/02/10 09:31:00 Não Não 17:30:00 Não 6
12/02/10 10:00:00 Não Sim 17:30:00 Não 7
13/02/10 Sábado
14/02/10 Domingo
19/02/10 10:01:00 Não Não Importa 16:30:00 Sim 5
20/02/10 Sábado
21/02/10 Domingo
26/02/10 09:01:00 Não Não 12:00:00 Não 3
27/02/10 Sábado
28/02/10 Domingo
Tabela 3 – Caso de Teste 2: Funcionário com pontos e com férias
46
Casos de Teste Gerar Pontuação Automática de Mês
Terceiro Caso: Funcionário com registro de pontos e com férias
02/01/10 Sábado
03/01/10 Domingo
05/01/10 09:01:00 Não Não 17:00:00 Não 7
06/01/10 09:30:00 Não Sim 17:00:00 Não 8
07/01/10 09:31:00 Não Não 17:30:00 Não 6
08/01/10 10:00:00 Não Sim 17:30:00 Não 7
09/01/10 Sábado
10/01/10 Domingo
12/01/10 09:01:00 Não Não 17:00:00 Não 7
13/01/10 09:30:00 Não Sim 17:00:00 Não 8
14/01/10 09:31:00 Não Não 17:30:00 Não 6
15/01/10 10:00:00 Não Sim 17:30:00 Não 7
16/01/10 Sábado
17/01/10 Domingo
19/01/10 09:01:00 Não Não 17:00:00 Não 7
20/01/10 09:30:00 Não Sim 17:00:00 Não 8
21/01/10 09:31:00 Não Não 17:30:00 Não 6
22/01/10 10:00:00 Não Sim 17:30:00 Não 7
23/01/10 Sábado
24/01/10 Domingo
26/01/10 09:01:00 Não Não 17:00:00 Não 7
27/01/10 09:30:00 Não Sim 17:00:00 Não 8
28/01/10 09:31:00 Não Não 17:30:00 Não 6
29/01/10 10:00:00 Não Sim 17:30:00 Não 7
30/01/10 Sábado
31/01/10 Domingo
Total de Pontos Mês Janeiro: 150
01/02/10
02/02/10
03/02/10 Férias
04/02/10
05/02/10 40
06/02/10 Sábado
07/02/10 Domingo
08/02/10
09/02/10
10/02/10 Férias
11/02/10
12/02/10 40
13/02/10 Sábado
14/02/10 Domingo
17/02/10
18/02/10 Férias
19/02/10 24
20/02/10 Sábado
21/02/10 Domingo
22/02/10
23/02/10
24/02/10 Férias
25/02/10
26/02/10 40
27/02/10 Sábado
28/02/10 Domingo
Tabela 4 – Caso de Teste 3: Funcionário somente com férias

Refatoração de Código em Ambientes Típicos de Desenvolvimento Ágil

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Refatoração de Código em Ambientes Típicos de Desenvolvimento Ágil

Enviado por

Direitos autorais:

Formatos disponíveis

Alessandro Alonso Ferreira Calu

REFATORAÇÃO DE CÓDIGO EM AMBIENTES

Monografia apresentada ao Programa de

Orientador: Humberto Torres Marques Neto

Esta monografia apresenta a importância da refatoração de código dentro de

ambientes típicos de desenvolvimento Ágil. São contrapostas características da

alteração de funcionalidades em software tratadas nos processos unificado e em

processos ágeis, destacando-se a importância da refatoração no último. São

apresentados os momentos adequados e os papéis responsáveis por realizar

refatoração de código. É realizado um estudo de caso de utilização de técnicas e

ferramentas de refatoração de código PHP em fontes de um projeto real de uma

Palavras-chave: Refatoração de código; Desenvolvimento Ágil; Manutenção

Adaptativa; Manutenibilidade; Gerência de Configuração.

FIGURA 1 - O impacto das mudanças proposto por PRESSMAN …........ 16

FIGURA 2 - O custo das mudanças proposto em Extreme Programming. 17

FIGURA 3 - Processo de tarefa Controle de Mudanças …....................... 20

FIGURA 4 - Diagrama Classes antes da Refatoração …......................... 31

FIGURA 5 - Diagrama Sequência gera_pontuacao antes da Refatoração 32

FIGURA 6 - Código Fonte gera_pontuação antes da Refatoração …....... 33

FIGURA 7 - Diagrama Classes, Camada Persistência (Refatoração 1).... 36

FIGURA 8 - Diagrama de Classes do Software (Refatoração 2) ….......... 37

FIGURA 9 - Diagrama de Sequência (Refatoração 3) …............….......... 38

FIGURA 10 - Diagrama de Classes após Refatoração ..............….......... 39

FIGURA 11 - Diagrama de Sequência após Refatoração ….......….......... 40

FIGURA 12 - Código Fonte gera_pontuação após Refatoração............... 41

TABELA 1 - Caso de Uso: Gerar pontuação automática de mês …........... 30

TABELA 2 - Caso de Teste 1: Funcionário com pontos e sem férias …..... 44

TABELA 3 - Caso de Teste 2: Funcionário com pontos e com férias …..... 45

TABELA 4 - Caso de Teste 3: Funcionário somente com férias …............. 46

PDT - PHP Development Tools

ECO - Ordem de Mudança de Engenharia

IDE – Ambiente de Desenvolvimento Integrado.

2. REVISÃO DA LITERATURA .................................................... 16

4. ESTUDO DE CASO ................................................................... 27

5. CONSIDERAÇÕES FINAIS …................................................ 42

A presente monografia aborda um tema importante dentro do

desenvolvimento de software em ambientes típicos de processos ágeis. Num

primeiro momento, podemos entender um ambiente característico de

desenvolvimento ágil como um projeto com diversas entregas parciais para

utilização imediata pelo usuário final. Soma-se a isso a opção de mudança

significativa no escopo ou conjunto de requisitos do sistema durante o ciclo de

Também inclui-se no ambiente de discussão desta monografia sistemas que

sofrem manutenção adaptativa contínua para atender a soluções de negócios

tempestuosos. Seriam empresas que mudam estratégias táticas e regras de fluxos

de processos de forma rápida e constante. Estes softwares precisam lançar novas

versões em intervalos curtos de tempo e com pequenas adaptações.

É importante deixar claro que não é objetivo desta monografia defender ou

discutir a utilização de metodologias ágeis. A refatoração de código pode e deve ser

na realidade a necessidade de planejamento e utilização de refatoração de código

em softwares que sofrem mudanças constantes de funcionalidades. Pretende-se

levantar importantes aspectos da refatoração de código como: o seu custo; o seu

impacto na qualidade do produto e do processo; a sua correta utilização dentro do

processo de desenvolvimento adotado e adaptado pela fábrica de software; e

refatoração rápida e segura.

Equipes de desenvolvimento de software tem-se deparado com projetos de

soluções em tecnologia da informação direcionados para empresas clientes com

cenários de negócio instáveis. Estas empresas podem possuir dentre outras

características: estratégias de marketing agressivo, venda de serviços relacionados

a tecnologia de ponta, alta expansão de mercado, mudança constante de

posicionamento de mercado, investimento alto em novas tecnologias para redução

de custo na produção, adaptação constante a mudanças de leis governamentais e

outras necessidades que levam a mudança constante e rápida dos processos