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 Horizonte2010

Aos meus pais, minha esposa e meus filhosPela 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 …............................................................................ 101.1 JUSTIFICATIVA …............................................................................ 121.2 OBJETIVOS …..…............................................................................. 14

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

3. METODOLOGIA …..................................................................... 24

4. ESTUDO DE CASO ................................................................... 274.1 O SOFTWARE ….............................................................................. 284.2 O REQUISITO .….............................................................................. 294.3 O ESTADO INICIAL …...................................................................... 314.4 CRIANDO CASOS DE TESTE …..................................................... 344.5 REFATORANDO …..................…..................................................... 354.6 O ESTADO FINAL …........................................................................ 39

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

REFERÊNCIAS .................................................................................. 43

APÊNDICE …...................................................................................... 44

101. 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

11algumas das técnicas e ferramentas conhecidas e oferecidas atualmente para

refatoração rápida e segura.

121.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

13toda 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.

141.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

15tarefas 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.

162. 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

17atividades 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

18BECK (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.

19O 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

20programa 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

22partir 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

23em 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)

243. 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 .

26d) 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

274. 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

28entender 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.

29A 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

30devedora 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:

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

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.

314.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

32Abaixo 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.

33Apresenta-se abaixo o código fonte PHP do método gera_pontuacao:

Figura 6: Código Fonte gera_pontuacao antes da Refatoração

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")

{ if($vet_ponto["entrada"] > "09:30:00")

{ if($vet_ponto["entrada"] > "10:00:00")

{ if($vet_ponto["entrada"] > "12:00:00")

{ $interface->insere_motivo_funcionario($cod_funcionario, '4', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '9', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '8', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '7', $vet_ponto["dta_ponto"]);

} if($vet_ponto["saida"] < "17:30:00")

{ if($vet_ponto["saida"] < "17:00:00")

{ if($vet_ponto["saida"] < "16:30:00")

{ if($vet_ponto["saida"] < "13:00:00")

{ $interface->insere_motivo_funcionario($cod_funcionario, '5', $vet_ponto["dta_ponto"]);

} if($vet_ponto["saida"] > "16:00:00")

{ $interface->insere_motivo_funcionario($cod_funcionario, '13', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '12', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '11', $vet_ponto["dta_ponto"]);

}}

else{ $interface->insere_motivo_funcionario($cod_funcionario, '10', $vet_ponto["dta_ponto"]);

}}

} $query_ferias = " SELECT

cod_usuarioFROM

" .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_motivo_funcionario($cod_funcionario, '6', $vet_ponto["dta_ponto"]); $interface->insere_pontos_ferias($cod_funcionario, $vet_ponto["dta_ponto"]);

}}

} echo "Processamento finalizado!";

}

34O 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

35realiza 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

37responsabilidades 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)

38c) 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).

394.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

Figura 12: Código Fonte gera_pontuação após Refatoração

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")

{ if($hrs_entrada > "09:30:00")

{ if($hrs_entrada > "10:00:00")

{ if($hrs_entrada > "12: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_funcionario = $cod_funcionario; $tb_motivo_funcionario_dia->cod_motivo = $this->calcula_motivo_entrada($lista_ponto[$num_ponto]["hor_entrada"]); $tb_motivo_funcionario_dia->grava(0); $tb_motivo_funcionario_dia->cod_motivo_funcionario_dia = $cod_funcionario_dia; $tb_motivo_funcionario_dia->cod_funcionario = $cod_funcionario; $tb_motivo_funcionario_dia->cod_motivo = $this->calcula_motivo_saida($lista_ponto[$num_ponto]["hor_saida"]); $tb_motivo_funcionario_dia->grava(0);

}}

$this->gera_pontuacao_ferias($cod_funcionario, $cod_funcionario_interface);}

} echo "Processamento finalizado!";

}

425. 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.

43REFÊ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

Tabela 2 – Caso de Teste 1: Funcionário com pontos e sem férias

Pontos de Funcionário

Data Chegada Saída Pontos Dia01/02/10 09:00:00 Não Importa Não Importa 17:30:00 Não 1002/02/10 09:01:00 Não Não 17:30:00 Não 803/02/10 09:01:00 Sim Não Importa 17:30:00 Não 1004/02/10 09:30:00 Não Sim 17:30:00 Não 905/02/10 09:00:00 Não Importa Não Importa 17:29:00 Não 906/02/10 Sábado07/02/10 Domingo08/02/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1009/02/10 09:01:00 Não Não 17:00:00 Não 710/02/10 09:30:00 Não Sim 17:00:00 Não 811/02/10 09:31:00 Não Não 17:30:00 Não 612/02/10 10:00:00 Não Sim 17:30:00 Não 713/02/10 Sábado14/02/10 Domingo15/02/10 Recesso Carnaval16/02/10 Feriado Carnaval17/02/10 10:01:00 Sim Não Importa 17:00:00 Não 918/02/10 10:01:00 Não Não Importa 16:59:00 Não 319/02/10 10:01:00 Não Não Importa 16:30:00 Sim 520/02/10 Sábado21/02/10 Domingo22/02/10 13:00:00 Sim Não Importa 16:29:00 Não 523/02/10 13:00:00 Não Não Importa 16:00:00 Não 224/02/10 09:00:00 Não Importa Não Importa 15:59:00 Não 525/02/10 09:00:00 Não Importa Não Importa 12:00:00 Sim 826/02/10 09:01:00 Não Não 12:00:00 Não 327/02/10 Sábado28/02/10 Domingo

Total de Pontos Mês: 124

Primeiro Caso: Funcionário com registro de pontos e sem férias

AvisouDia Anterior

Avisou Antes das 9:00

Combinou saída cedo

45

Tabela 3 – Caso de Teste 2: Funcionário com pontos e com férias

Casos de Teste Gerar Pontuação Automática de Mês

Pontos de Funcionário

Data Chegada Saída Pontos Dia01/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 902/01/10 Sábado03/01/10 Domingo04/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 905/01/10 09:01:00 Não Não 17:00:00 Não 706/01/10 09:30:00 Não Sim 17:00:00 Não 807/01/10 09:31:00 Não Não 17:30:00 Não 608/01/10 10:00:00 Não Sim 17:30:00 Não 709/01/10 Sábado10/01/10 Domingo11/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 912/01/10 09:01:00 Não Não 17:00:00 Não 713/01/10 09:30:00 Não Sim 17:00:00 Não 814/01/10 09:31:00 Não Não 17:30:00 Não 615/01/10 10:00:00 Não Sim 17:30:00 Não 716/01/10 Sábado17/01/10 Domingo18/01/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1019/01/10 09:01:00 Não Não 17:00:00 Não 720/01/10 09:30:00 Não Sim 17:00:00 Não 821/01/10 09:31:00 Não Não 17:30:00 Não 622/01/10 10:00:00 Não Sim 17:30:00 Não 723/01/10 Sábado24/01/10 Domingo25/01/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1026/01/10 09:01:00 Não Não 17:00:00 Não 727/01/10 09:30:00 Não Sim 17:00:00 Não 828/01/10 09:31:00 Não Não 17:30:00 Não 629/01/10 10:00:00 Não Sim 17:30:00 Não 730/01/10 Sábado31/01/10 Domingo

Total de Pontos Mês Janeiro: 15001/02/10

Férias40

02/02/1003/02/1004/02/1005/02/1006/02/10 Sábado07/02/10 Domingo08/02/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1009/02/10 09:01:00 Não Não 17:00:00 Não 710/02/10 09:30:00 Não Sim 17:00:00 Não 811/02/10 09:31:00 Não Não 17:30:00 Não 612/02/10 10:00:00 Não Sim 17:30:00 Não 713/02/10 Sábado14/02/10 Domingo15/02/10 Recesso Carnaval16/02/10 Feriado Carnaval17/02/10 10:01:00 Sim Não Importa 17:00:00 Não 918/02/10 10:01:00 Não Não Importa 16:59:00 Não 319/02/10 10:01:00 Não Não Importa 16:30:00 Sim 520/02/10 Sábado21/02/10 Domingo22/02/10 13:00:00 Sim Não Importa 16:29:00 Não 523/02/10 13:00:00 Não Não Importa 16:00:00 Não 224/02/10 09:00:00 Não Importa Não Importa 15:59:00 Não 525/02/10 09:00:00 Não Importa Não Importa 12:00:00 Sim 826/02/10 09:01:00 Não Não 12:00:00 Não 327/02/10 Sábado28/02/10 Domingo

Total de Pontos Mês: 118

Segundo Caso: Funcionário com registro de pontos e com férias

AvisouDia Anterior

Avisou Antes das 9:00

Combinou saída cedo

46

Tabela 4 – Caso de Teste 3: Funcionário somente com férias

Casos de Teste Gerar Pontuação Automática de Mês

Pontos de Funcionário

Data Chegada Saída Pontos Dia01/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 902/01/10 Sábado03/01/10 Domingo04/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 905/01/10 09:01:00 Não Não 17:00:00 Não 706/01/10 09:30:00 Não Sim 17:00:00 Não 807/01/10 09:31:00 Não Não 17:30:00 Não 608/01/10 10:00:00 Não Sim 17:30:00 Não 709/01/10 Sábado10/01/10 Domingo11/01/10 09:00:00 Não Importa Não Importa 17:29:00 Não 912/01/10 09:01:00 Não Não 17:00:00 Não 713/01/10 09:30:00 Não Sim 17:00:00 Não 814/01/10 09:31:00 Não Não 17:30:00 Não 615/01/10 10:00:00 Não Sim 17:30:00 Não 716/01/10 Sábado17/01/10 Domingo18/01/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1019/01/10 09:01:00 Não Não 17:00:00 Não 720/01/10 09:30:00 Não Sim 17:00:00 Não 821/01/10 09:31:00 Não Não 17:30:00 Não 622/01/10 10:00:00 Não Sim 17:30:00 Não 723/01/10 Sábado24/01/10 Domingo25/01/10 09:00:00 Não Importa Não Importa 17:29:00 Sim 1026/01/10 09:01:00 Não Não 17:00:00 Não 727/01/10 09:30:00 Não Sim 17:00:00 Não 828/01/10 09:31:00 Não Não 17:30:00 Não 629/01/10 10:00:00 Não Sim 17:30:00 Não 730/01/10 Sábado31/01/10 Domingo

Total de Pontos Mês Janeiro: 15001/02/10

Férias40

02/02/1003/02/1004/02/1005/02/1006/02/10 Sábado07/02/10 Domingo08/02/10

Férias40

09/02/1010/02/1011/02/1012/02/1013/02/10 Sábado14/02/10 Domingo15/02/10 Recesso Carnaval16/02/10 Feriado Carnaval17/02/10

Férias24

18/02/1019/02/1020/02/10 Sábado21/02/10 Domingo22/02/10

Férias40

23/02/1024/02/1025/02/1026/02/1027/02/10 Sábado28/02/10 Domingo

Total de Pontos Mês: 144

Terceiro Caso: Funcionário com registro de pontos e com férias

AvisouDia Anterior

Avisou Antes das 9:00

Combinou saída cedo