Automação de Testes - Engenharia de Software - Edição 29 PDF

Modstia parte, sua
melhor opo para

se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
So programas voltados para a
formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
P S - G R A D UA O
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
G R A D UA O
Engenharia de Computao
Anlise e Desenv. de Sistemas
FORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
EDITORIAL
utomatizar os testes nada mais do que repassar para o computador as atividades de testes que normalmente so realizadas de forma manual. A automao de
testes deve ser iniciada a partir de um processo manual de teste j estabelecido e
maduro. Vrias so as ferramentas disponveis no mercado para as empresas, entre pagas

e gratuitas.
A automao de testes possui alta capacidade para reduzir esforos. Com isso, pensar em
mecanismos para automao dos testes consiste em pensar em mecanismo para reduzir o
Ano 3 - 29 Edio - 2010
Impresso no Brasil
esforo desta atividade no contexto geral de um projeto de software.

importante termos em mente que automao por si s no resulta em reduo de
esforo nos testes ou aumento da qualidade desta atividade. A automao simplesmente
Corpo Editorial
torna automtica algumas tarefas do processo de testes, mas ela no faz milagres. Como
assim? Uma ferramenta de testes apenas automatiza o nosso conhecimento tcnico sobre
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
teste de software. Sendo assim, se no tivermos conhecimento tcnico adequado sobre

teste de software, o conjunto de casos de teste gerado para avaliar nosso sistema no ter
cobertura ou qualidade suficiente, de forma que a ferramenta ir apenas automatizar a execuo do conjunto de testes inadequados, ou seja, no termos qualquer ganho com isso.
Se tivermos um processo de teste bem definido e um bom conhecimento sobre estrat-
Capa
Romulo Araujo - romulo@devmedia.com.br
gias de teste, a automao pode trazer grandes benefcios a um projeto de software.

Neste contexto, a Engenharia de Software Magazine destaca nesta edio duas
Diagramao
Janete Feitosa
matrias:
Automao dos Testes: um lobo na pele de cordeiro?: cujo objetivo apresentar uma
Coordenao Geral
Daniella Costa - daniella@devmedia.com.br
reflexo sobre os cuidados que devem ser levados em considerao na aplicao da au-
Revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
rincia prtica de executar um processo de teste em um projeto de software desenvolvido
tomao de testes.
Processo e automao de testes de Software: cujo objetivo apresentar uma expecom base na Programao Exploratria, utilizando ferramentas para automao de testes.
Alm destas matrias, esta edio traz mais seis artigos:
Na Web
www.devmedia.com.br/esmag
O dia em que virei um Ninja

Apoio
Acompanhamento de projetos geis distribudo atravs do Daily Meeting

Requisitos em SOA Parte 2
Diagramas de Sequncia: Uma Abordagem Prtica
Refatorao para Padres - Parte 2
Qualidade de Software.
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
Daniela Maciel e Flvia Aparecido Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Cristiany Queiroz
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo
voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a
vontade para entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc
gostaria de publicar:
Rodrigo Oliveira Spnola - Colaborador
rodrigo.devmedia@gmail.com
Rodrigo Oliveira Spnola

rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e
Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
UFRJ. Colaborador da Engenharia de Software Magazine.

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos
Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spnola

eduspinola@gmail.com
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS)
onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
NDICE
Por trs do obvio
06 O dia em que virei um Ninja
Glnio Cabral
Agilidade
07 - Acompanhamento de projetos geis distribudo atravs do Daily Meeting
Para esta edio, temos um conjunto de 5 vdeo aulas.

Estas vdeo aulas esto disponveis para download no Portal
da Engenharia de Software Magazine e certamente traro
uma significativa contribuio para seu aprendizado. A lista
de aulas publicadas pode ser vista abaixo:
Hernan Julho Muoz e Teresa M Medeiros Maciel
Engenharia
15 - Requisitos em SOA Parte 2
Joo Caldas Jnior
20 - Automao dos Testes: um lobo na pele de cordeiro?

Daniel Scaldaferri Lages
26 - Processo e automao de testes de Software

Eliane Collins e Luana Lobo
Tipo: Processo
Ttulo: Atividades da Gerncia de Projetos Partes 10 a 14
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: A gerncia de projetos possui um conjunto de atividades
associadas aos processos da gerncia. Nesta srie de 5 vdeo aulas conheceremos algumas dessas principais atividades destacando seus objetivos,
tarefas desempenhadas e resultados esperados. Alguns dos assuntos tratados
sero: planejamento de cronograma, planejamento de recursos humanos e
planejamento de riscos.
34 - Qualidade de Software
Lenildo Morais
Desenvolvimento
39 - Diagramas de Sequncia: Uma Abordagem Prtica
Geraldo Magela Dutra Gonalves
46 - Refatorao para Padres Parte 2

Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Existem coisas
que no conseguimos
ficar sem!
...s pra lembrar,
sua assinatura pode
estar acabando!
AMIGO
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes:
www.devmedia.com.br/central
Edio 05 - Engenharia de Software Magazine
Pos trs do bvio
O dia em que virei um

Ninja
Engenharia de Software - O dia em que virei um Ninja
Glnio Cabral
gleniocabral@yahoo.com.br
D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
D
s
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
Feedback
eu
sobre e
s
motivacionais. No duvido que tais eventos possam trazer

real proveito para as pessoas, mas tudo tem seu limite. Tentar
compensar falta de contedo com bizarrices dessa natureza
um desrespeito s pessoas que pagaram e que esperam o
retorno do seu investimento. Segundo, solues mgicas e
imediatas para problemas complexos no passam de enganao. Problemas difceis no so resolvidos da noite para o dia,
uma vez que exigem esforo, experincia e aperfeioamento.
Isso leva tempo. Terceiro, aprendi algo til para economizar
meu dinheiro, pois aps essa experincia fico sempre com um
p atrs quando vejo anncios mirabolantes de cursos ou de
palestras. E quarto, definitivamente no legal ser batizado
por um esprito chamado Shaulin.
Portanto, estarmos atentos a venda de solues fceis e suspeitas fundamental para que evitemos surpresas desagradveis.
Temos visto muitas dessas solues (verdadeiras balas de prata)
sendo vendidas tambm quando tratamos do desenvolvimento
de software. O problema que so to bem vendidas que corremos o srio risco de acreditarmos em sua eficcia.
edio
ta
oi uma noite inesquecvel. L estava eu, louco pra sentarme na primeira fila para assistir a palestra Tcnicas Ninja
para sua empresa. O palestrante era um japons que se
dizia mestre das artes marciais e que agora aplicava as tcnicas
de luta para gerenciar melhor os seus negcios. Todo mundo
dizia que sua empresa dera um salto de produo depois disso,
por isso o auditrio estava lotado. Assim que entrei fui logo recepcionado por um homem trajado como um ninja, com espada
e tudo. Ele deu um grito estarrecedor, comeou a gesticular
freneticamente e me entregou uma espada de madeira, dizendo
IAKI!. Sentei me sentindo um Karat Kid.
Olhei para a espada de madeira em minha mo e disse pra
mim mesmo: abra a mente, abra a mente. De repente, as luzes
do auditrio se apagaram. Um som ao fundo dizia pra gritarmos como nunca havamos gritado antes em nossas vidas. Era
engraado observar aqueles engravatados empunhando uma
espada de madeira aos berros, como se fossem criaturas bizarras sadas de um RPG. Depois de dez segundos da mais pura
histeria, o palestrante apareceu no palco encoberto por uma
nuvem de fumaa e empunhando uma espada gigantesca. Pausadamente, ele falou: Sou o mestre Okhaio, e a partir de agora
convoco o esprito de Shaulim para batiz-los e transform-los
em Ninjas Guerreiros. Assim que terminou de falar isso, um
caldeiro de gua misturada com flores foi derramado sobre
todos ns, sabe-se l de onde. Pronto, fomos batizados pelo
esprito de Shaulim. S ento o palestrante comeou a exibir
uma srie de golpes de artes marciais mostrando como poderamos aplic-los ao nosso dia-dia nas organizaes.
Sinceramente, no vi sentido algum em nada daquilo. Pra
falar a verdade, estava me sentindo um perfeito idiota, todo
encharcado e com uma espada de brinquedo na mo.
Apesar disso, aprendi preciosas lies com essa experincia.
Primeiro, que h muita picaretagem no universo das palestras
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Acompanhamento de projetos geis

distribudo atravs do Daily Meeting
De que se trata o artigo?
Neste artigo veremos os principais problemas associados ao acompanhamento de projetos geis
num ambiente distribudo, dando nfase prtica
Daily Meeting do Scrum. Em seguida discutiremos
como as ferramentas fornecem apoio a essa prtica. Por fim, uma abordagem proposta para dar
o suporte necessrio ao Daily Meeting distribudo
com o apoio de um ambiente para a realizao das
reunies dirias.
Hernan Julho Muoz

hernan99@gmail.com
Mestrando em Engenharia de Software

pela Universidade Federal de Pernambuco.
Especializao em Sistema de Informao
com nfase em Componentes Web Distribudos pela Faculdade Ruy Barbosa. Alm
de certicados Java como SCJP, SCWCD,
SCBCD. Atualmente atua como analista
de sistemas na Universidade Estadual da
Bahia (Uneb).
Teresa M Medeiros Maciel

tmmaciel@gmail.com
Mestre em Engenharia de Software e doutoranda pela UFPE. Professora do DEINFO/

UFRPE e pesquisadora do Instituto Nacional
Tecnolgico para Engenharia de Software INES. Atua no desenvolvimento de software
h cerca de 20 anos, tendo dedicado os
ltimos 10 anos rea de qualidade. Estruturou e liderou a gerncia de qualidade
do C.E.S.A.R durante 8 anos, onde conduziu projetos de melhoria de processos de
software. Desde 2008 vem desenvolvendo
projetos de P&D aplicando a pesquisa em
problemas reais da indstria de software,
especialmente sobre a adoo de metodologias geis em ambientes diversos.
o cenrio atual, os sistemas possuem funcionalidades cada vez

mais complexas, os requisitos
mudam constantemente, e a entrega
feita em um tempo cada vez mais curto.
Tais fatos motivaram a adoo de metodologias mais flexveis, que promovesse
maior rapidez e qualidade ao software
produzido. A adoo das metodologias
geis de desenvolvimento cresceu nos
ltimos anos pelo fato de os projetos
que usavam os chamados mtodos
tradicionais apresentarem os mesmos
problemas, dentre eles: extrapolao dos
prazos de entrega do software, custo acima do previsto e a insatisfao elevada
do cliente.
Para que serve?

Este artigo serve para as empresas que visam melhorar o acompanhamento de seus projetos distribudos utilizando o Scrum como principal metodologia gil no gerenciamento do mesmo.
Em que situao o tema til?

Esse tema til para as empresas que pretendem escalar o projeto atravs do desenvolvimento distribudo e esto em busca de informaes de como o acompanhamento do projeto
pode ser realizado.
Em paralelo ao crescimento dos mtodos geis, o desenvolvimento distribudo de software vem ganhando cada
vez mais adeptos. Dentre as razes pela
opo por esta abordagem, pode ser ressaltado o baixo custo

para manter um espao fsico para acomodar muitas pessoas
em algumas regies e a dificuldade de encontrar pessoas
qualificadas na mesma localidade. Outra vantagem a capacidade das equipes distribudas de trabalharem em paralelo
e em diferentes fusos horrios, acelerando a velocidade de
desenvolvimento [6].
O uso de metodologias geis no desenvolvimento de sistemas com times distribudos pode ser uma boa estratgia para
reduzir custo e ainda mais o tempo de desenvolvimento de
um sistema. O fato de os princpios e valores dos mtodos
geis pregarem maior foco na interao de clientes, feedback
rpido e maior interao entre os membros atravs do contato
face-a-face, um empecilho num ambiente distribudo. Apesar
destas possveis restries, algumas empresas adotaram esta
combinao com sucesso, como a experincia relatada por
Sutherland [13], que descreve o cenrio no qual foi aplicado
Scrum com XP em equipes distribudas.
A adoo do desenvolvimento gil distribudo considerada
um desafio para o gerenciamento gil de projetos, pelo fato
de tornarem a comunicao e a interao entre os membros
mais difceis, podendo causar maus entendimentos das funcionalidades durante o projeto. Por outro lado, metodologias
geis mais especficas para a gesto de projetos, como Scrum,
podem ajudar no gerenciamento ao incentivar a equipe a se
comunicar e acompanhar o progresso do projeto todos os
dias. Atravs das reunies dirias propostas pelo Scrum, os
membros da equipe interagem, o progresso monitorado e os
ajustes que precisam ser realizados durante o projeto podem
ser tomados prontamente, melhorando a comunicao e a
colaborao entre os membros.
O gerenciamento gil de projetos com Scrum deriva de boas
prticas de negcios em empresas como Fuji-Xerox, Honda,
Canon e Toyota. Uma forma de minimizar a distncia fsica
em uma equipe distribuda o apoio ferramental adequado,
que viabilize a execuo de prticas geis de forma distribuda,
sem comprometer a comunicao e colaborao do time.
Motivada por este cenrio, uma ferramenta de cdigo aberto
foi desenvolvida por um aluno do mestrado profissional do
Cesar e evoluda por alunos de mestrado da UFPE, denominada FireScrum. Essa ferramenta visa apoiar muitas das prticas
definidas pelo Scrum, permitindo que o processo seja seguido
e monitorado remotamente. Alm disso, em algumas prticas o
FireScrum prov formas de comunicao oral e textual, interao e colaborao entre os membros de equipes distribudas.
Inserido neste contexto, este artigo apresenta uma forma
de suportar a execuo de prticas de acompanhamento de
projetos geis distribudos, mais especificamente a reunio
diria (ou Daily Meeting) adotada pelo Scrum. Neste sentido,
o objetivo principal deste trabalho definir uma abordagem
para tratar o Daily Meeting distribudo e propor um ambiente
integrado ferramenta FireScrum. Esse ambiente tem como
finalidade apoiar equipes distribudas na realizao da reunio
diria, possibilitando tambm o armazenamento de informaes relevantes dessas reunies. A seo Uma abordagem para
tratar o Daily Meeting distribudo descreve em detalhes como

esse apoio pode ser realizado.
Desenvolvimento de software distribudo

Atualmente, com a globalizao e a crescente demanda por
novos sistemas, as empresas se depararam com a necessidade
de estudar novas formas para alcanar alta produtividade.
Uma opo investigada para alcanar esses objetivos foi o
desenvolvimento distribudo de software (DDS). O DDS consiste no desenvolvimento de software com pessoas distribudas em diferentes localidades. Estes locais podem ser bairros,
cidades ou mesmo pases diferentes. Ele permite que diversas
pessoas trabalhem em lugares diferentes, como uma nica
equipe no intuito de desenvolver software mais rpido do
que o habitual.
Alm disso, alguns motivos so responsveis pela crescente
adoo do DDS, conforme descrito por French [5]. Em seu
estudo, French menciona que a distribuio , muitas vezes,
uma consequncia inevitvel de fatores organizacionais. Os
principais fatores identificados durante o estudo foram os
seguintes:
Os membros no podem ou no querem se mudar para outra
localidade;
Os membros especializados necessrios para o sucesso do
projeto esto em localidades diferentes;
O custo da viagem ou mudana alto;
Reduzir o custo do espao fsico em determinado local.
Alm disso, a demanda por novos sistemas esto crescendo
mais rapidamente do que os recursos profissionais em alguns
locais, e alguns tipos de especialidades so difceis de serem
encontrados.
Alm dos fatores organizacionais j mencionados, o desenvolvimento distribudo traz algumas vantagens competitivas
para a soluo global, tais como reduzir o tempo de entrega
atravs de equipes distribudas que trabalham em paralelo,
e da possibilidade delas desenvolverem em diversos fusos
horrios. A reduo de custos tambm pode ser alcanada
porque contratar profissionais de diferentes pases muitas
vezes mais barato do que os do mesmo local.
No entanto, esta abordagem tambm tem algumas desvantagens. French menciona que, devido natureza distribuda dos
projetos, muitas vezes pode ser difcil ter reunies regulares
face-a-face. Este um grande problema porque essas reunies
ajudam os membros a se conhecerem e a construir um bom
relacionamento entre eles. Alm disso, a relao face-a-face
permite que os membros interajam mais para ajudar um ao
outro em favor do projeto. Outro problema a viagem para
reunies em outras localidades, que caro e cansativo. Assim,
esses problemas so responsveis muitas vezes por um progresso mais lento ou at ao fracasso do projeto [6].
Deste modo, existem alguns desafios enfrentados pelas
equipes distribudas em termos de comunicao e colaborao,
tais como: (1) atraso na resposta e resoluo de problemas; (2)
ausncia de confiana entre os membros da equipe; (3) falta
Engenharia de Software Magazine - Acompanhamento de projetos geis distribudo atravs do Daily Meeting
AGILIDADE
de transparncia sobre o progresso da equipe

e atividades atribudas; (4) falta de informaes
adequadas para os desenvolvedores quando
ocorre alguma mudana, por exemplo, quando
um membro necessita saber quem poderia ajudlo em determinada mudana. No intuito de lidar
com estes desafios, o gerente do projeto precisa de
um esforo maior para lidar com tais problemas,
sendo responsvel por transmitir os progressos e
os problemas que ocorrerem entre as equipes de
diferentes localidades.
Tambm so necessrias duas mudanas para
enfrentar esses problemas. Em primeiro lugar,
uma ferramenta para auxiliar os membros a interagir mais atravs de uma comunicao sncrona e
assncrona distribuda entre os locais. Em segundo
lugar, uma infraestrutura de colaborao para permitir a colaborao sncrona com mais frequncia
entre os membros distribudos. Como resultado,
estas mudanas proporcionariam: (1) uma resposta
mais rpida, diminuindo o tempo de resoluo
sobre as questes que envolvem a comunicao
entre as equipes distribudas; (2) aumento da
produtividade da equipe, o senso de equipe e a
motivao dos membros como um todo [4].
Na seo seguinte ser discutido como esses problemas so abordados pelo desenvolvimento gil.
negcio (Business Value ou BV), ou no retorno sobre o investimento (ROI)

mais elevado. J o ltimo problema foi contornado com a criao do papel
do Scrum Master nas equipas locais, que passaram a ser responsveis
pelos impedimentos de seu backlog e a interao com outras equipes
distribudas atravs do Scrum de Scrums.
Lee menciona que projeto Zorro, que utilizou metodologias geis, teve
um aumento de desempenho e satisfao do projeto de mais de 30%
quando comparado com o projeto Chameleon, que utilizou metodologia
tradicional.
Esta vantagem competitiva alcanada pelo uso de mtodos geis tem
feito muitas empresas comearem a usar metodologias geis juntamente
com o desenvolvimento distribudo, obtendo um ambiente menos burocrtico, com foco principal na comunicao e entrega rpida ao cliente.
Outro caso de sucesso foi descrito por Sutherland [13], que menciona a
experincia adquirida e os problemas surgidos, dando nfase na comunicao como um ponto chave em uma equipe distribuda. De acordo
com Sutherland, a comunicao foi abordada no projeto atravs do Daily
Meeting, compartilhamento de informao entre as equipes e o Sprint
Planning Meeting. Estas reunies foram realizadas utilizando videoconferncia por Skype.
A comunicao um grande problema no gerenciamento do Product
Backlog, na interao entre os membros, e na distribuio e compartilhamento de informaes. Apesar dos problemas, a comunicao e a
Desenvolvimento gil Distribudo

O DDS no restringe seu uso a nenhuma metodologia de desenvolvimento, tendo sido adotado por
vrias empresas nos ltimos anos. As metodologias
tradicionais j foram adotadas por muitos projetos
distribudos e muitos deles falharam devido a
algumas das razes mencionadas na ltima seo.
Lee [9] relata a experincia da aplicao da metodologia tradicional em um dos projetos distribudos,
chamado Zorro. Segundo o relato, o projeto falhou
devido a problemas como a falta de planejamento e
comunicao entre as equipes globais e as equipes
locais, a baixa prioridade de projetos locais e a falta
de experincia, alm de gestores locais responsveis
por vrias funes.
Pelos problemas enfrentados com os mtodos
tradicionais, muitas empresas passaram a adotar
metodologias geis para amenizar esses problemas. Lee descreve que no projeto seguinte, Chameleon, o Yahoo decidiu adotar o Scrum e XP, conseguindo assim eliminar muitos dos problemas.
O primeiro, de planejamento e comunicao, foi
resolvido pela prtica do Sprint Planning Meeting
do Scrum e as reunies entre os Scrum Master de
cada equipe, chamada de Scrum de Scrums. O
segundo problema foi resolvido pela priorizao
das funcionalidades baseado no valor agregado ao
colaborao entre os membros so mais bem tratados pelas

metodologias geis do que pelos mtodos tradicionais. Sutherland [13] menciona que o uso de mtodos tradicionais
neste cenrio distribudo tem mais problemas relacionados
com a comunicao, porque as empresas tendem a fazer
especificaes mais detalhadas, levando um longo tempo
antes de iniciar o projeto. Ele relata tambm dos problemas
com o planejamento do projeto, devido dificuldade que a
equipe teve em seguir o que foi planejado, uma vez que este
era detalhado e mais esttico. Essa falta de flexibilidade faz
com que os projetos apresentem uma alta taxa de falhas ou
atrasos na entrega.
Neste cenrio, Sutherland [14] descreveu que a equipe
distribuda pode ser organizada em trs modelos diferentes,
apresentados a seguir:
Scrums Isolados as equipes so isoladas entre as localidades. Em alguns casos, alguns times no usam Scrum, o
que torna difcil a gesto do projeto;
Scrum de Scrums Distribudos equipes Scrum so isoladas em diferentes localidades e so integradas atravs do
Scrum de Scrums. Scrum de Scrums um encontro entre
os Scrum Masters de cada equipe que ocorre diariamente
(muitas vezes semanalmente) para verificar o progresso e
os problemas entre as equipes distribudas;
Scrums Totalmente Integrados equipes Scrum so
formadas por membros de especialidades distintas, e em
localidades diferentes.
Dentre os modelos, o mais recomendado pela Scrum
Alliance o Scrum de Scrums Distribudos. Este modelo
de trabalho adequado para equipes com diferentes especialidades que adotam Scrum e so isoladas, eliminando a
maioria das dependncias entre as equipes.
No Scrum de Scrums Distribudos cada equipe tem um
Scrum Master, que monitora diariamente o progresso de
seus membros. Alm disso, eles muitas vezes se renem
atravs do Scrum de Scrums, sendo possvel discutir problemas do projeto como um todo e sincronizam as questes
que podem afetar as outras equipes. Assim, esse modelo incentiva uma maior comunicao e colaborao entre equipes
distribudas, fazendo com que trabalhem como uma equipe
nica em prol do projeto, e ajuda a promover uma rpida
resoluo de problemas entre as equipes.
Daily Meeting Distribudo

A adoo do Scrum por equipes distribudas visa facilitar a
comunicao entre os membros devido a certas prticas, tais
como as Scrum Meetings, e especialmente o Daily Meeting.
Estas reunies ajudam as equipes a interagir mais e envolver-se como uma equipe nica para completar as tarefas,
aumentando assim o compromisso de alcanar o objetivo
da Sprint. No entanto, h uma dificuldade de sincronizar as
atividades entre os membros de equipes distribudas, bem
como nos mecanismos de comunicao. Estes problemas
foram encontrados no projeto relatado por Sutherland [14].
10
De acordo com Sutherland, o primeiro grande desafio o

gerenciamento de projetos, particularmente a sincronizao
entre as equipes distribudas. Essa sincronizao aconteceu
pela realizao do Daily Meeting por cada equipe distribuda.
O segundo desafio a comunicao entre as equipes, que foi
tratado pelo Daily Meeting distribudo entre as equipes.
O Daily Meeting distribudo era necessrio para que as
equipes distribudas acompanhassem juntas o progresso do
projeto. Sutherland descreveu como a reunio ocorria diariamente. Devido s diferenas de fuso horrio, escolheu-se um
horrio onde todos os membros estariam presentes. A fim de
evitar problemas relacionados falha na comunicao oral, as
equipes determinaram que cada membro deveria responder s
perguntas por escrito antes da reunio comear. Isso encurta
o tempo necessrio para a teleconferncia e ajuda a superar as
barreiras da lngua, facilitando o entendimento entre as pessoas. Aps responderem as questes, os membros se reuniam
usando teleconferncia (geralmente por Skype) para discutir
as questes.
Alm da reunio diria entre as equipes, as subequipes de
cada localidade tinham um Daily Meeting adicional no incio
do dia. O Scrum de Scrums tambm era realizado uma vez por
semana para coordenar as tarefas entre as subequipes.
Esta experincia relatada por Sutherland possibilitou identificar problemas como as diferenas de fuso horrio, comunicao entre os membros, Daily Meeting locais, Scrum de Scrums
e, tambm, a importncia de responder as perguntas dirias
antes de comear a reunio. A anlise de como esses desafios
foram resolvidos ajudou a propor uma abordagem para melhor
apoiar as equipes distribudas e a verificar que elas precisam
de uma ferramenta para realizar essas reunies virtuais.
Ferramentas para apoio ao Daily Meeting

Nesta seo sero discutidas as ferramentas de apoio s
equipes durante o Daily Meeting distribudo.
Assembla
Assembla uma ferramenta de gerenciamento gil de projetos baseado no Scrum que permite criar Sprints, criar as estrias e associ-las a uma Sprint, assim como criar as tarefas. Ela
tambm permite que os membros acompanhem o progresso
das tarefas atravs do suporte ao Daily Meeting.
Para apoiar o Daily Meeting, a ferramenta tem um espao
no qual o usurio pode preencher as respostas referentes s
trs perguntas da reunio diria e ver as respostas de outros
membros. As respostas so registradas para criar um histrico
com o trabalho realizado pela equipe todos os dias. A fim de
lembrar a equipe para responder pergunta, um e-mail de
alerta enviado em um horrio agendado. A ferramenta tambm fornece um chat para permitir que os desenvolvedores
discutam entre eles sobre os impedimentos.
Desse modo, Assembla fornece comunicao assncrona
baseada na resposta das trs questes e comunicao sncrona atravs do chat; ambas ajudam os membros durante o
Daily Meeting. No entanto, esta soluo no oferece recursos
AGILIDADE
multimdia interessantes, tais como vdeo-conferncia. Outro

recurso importante que a soluo no oferece o Taskboard
para ajudar a equipe a monitorar o status da tarefa, e tambm
no exibe o grfico de Sprint Burndown aos membros, o que
permitiria acompanhar o andamento do projeto ao longo da
Sprint.
ScrumWorks
ScrumWorks um software de gesto gil de projetos que
tem duas licenas, diferenciadas pelo nmero de recursos
oferecidos. A primeira licena o Basic ScrumWorks, que
prev apenas o gerenciamento do projeto, das Sprints e alguns
relatrios. A segunda licena, o ScrumWorks Pro, fornece um
conjunto mais completo de funcionalidades que permite aos
membros gerenciar os usurios, o acesso a diferentes tipos de
relatrio, o acesso ao quadro de horrios (Timesheet), e usar
um Taskboard drag-and-drop.
No entanto, esta ferramenta no fornece um ambiente para
reunio diria. Ele s possui o Taskboard, que permite aos
membros da equipe monitorar o progresso das tarefas, e no
possui recursos de colaborao, tais como vdeo-conferncia,
o que permitiria aos membros interagir em torno do Taskboard, apoiando assim a discusso sobre as trs questes da
reunio diria.
VersionOne
VersionOne uma ferramenta de gesto de projetos que apoia
algumas metodologias de desenvolvimento gil, tais como
Scrum, XP, Kanban, AgileUP e DSDM.
Esta ferramenta permite que a equipe planeje e gerencie as
estrias e os objetivos de vrios projetos, produtos e Sprints. Ela
tambm permite adicionar Sprint, estrias, defeitos, tarefas,
testes e impedimentos, alm de possibilitar que a equipe acompanhe o andamento do projeto usando Storyboard, Taskboard,
Testboard e Burndown charts.
Embora a ferramenta fornea e compartilhe informaes
importantes para a reunio diria, tais como o TaskBoard e o
Burndown, estas informaes no so atualizadas em tempo
real, ou seja, quando um membro atualiza o status de uma tarefa, essa alterao no aparece no Taskboard de outro membro
no mesmo espao de tempo. Isto um empecilho para equipes
distribudas fazerem uma reunio diria sncrona. Portanto,
esta soluo no fornece um ambiente para os membros se
reunirem todos os dias e discutir o andamento do sprint.
TargetProcess
TargetProcess tambm um software integrado de gesto
de projetos que apoia todas as atividades de desenvolvimento
Scrum. Ele permite criar estrias, priorizar o Product Backlog,
e seguir o progresso das tarefas atravs do TaskBoard e do
grfico Sprint Burndown.
Esta soluo web e ajuda a integrar as equipes distribudas
de modo que trabalhem juntas em um nico projeto. O Taskboard apoia a reunio diria atravs da atualizao do status
das tarefas em tempo real pelos seus membros. No entanto,
ele no tem um ambiente para organizar a equipe em uma

reunio e no permite que os membros se comuniquem, a
fim de proporcionar uma melhor interao entre eles usando
o Taskboard.
Desta forma, esta soluo limitada para ser usada durante
a reunio diria, uma vez que no tem os recursos necessrios
para integrar os membros e permitir que eles interajam sobre
as trs perguntas de acompanhamento.
FireScrum
O FireScrum uma ferramenta cdigo livre de gerenciamento gil de projetos focada no Scrum. Foi desenvolvida com o
objetivo de apoiar equipes distribudas, motivada por lacunas
nas propostas semelhantes (ScrumWorks, TargetProcess,
VersionOne, Assembla). A ferramenta foi desenvolvida por
alunos de Engenharia de Software da Universidade Federal
de Pernambuco. A fim de facilitar o uso, a ferramenta foi projetada para que os membros trabalhem de forma semelhante
a um ambiente fsico. O Taskboard foi concebido como um
quadro branco eletrnico, permitindo o uso de post-its para
criar tarefas, e mov-los atravs das colunas do Taskboard,
alterando assim o seu status. Outra preocupao foi a interao
face-a-face defendida pelas metodologias geis, o que exigiu
a utilizao de recursos multimdia, possibilitando maior
interao entre os membros remotos, mas que no entanto s
est disponvel no mdulo Planning Poker.
O FireScrum uma aplicao web, o que significa que
acessvel remotamente atravs de um browser via Internet ou
Intranet, e possui interfaces simples para o uso baseado nos
conceitos de Rich Internet Applications (RIA), provendo maior
usabilidade ao usurio. A ferramenta foi desenvolvida com
uma arquitetura modular de modo facilitar a manuteno e
extenso, permitindo adicionar novas funcionalidades.
Na verso atual do FireScrum, o apoio dado ao Daily Meeting
atravs do Taskboard atualizvel em tempo real. No entanto,
exige que os membros definam um horrio para a reunio e
se encontrem todos os dias em frente ao Taskboard. Durante
a reunio cada membro deve alterar o status das tarefas refletindo as trs perguntas dirias. Entretanto, essa soluo no
permite que os membros interajam, uma vez que o Taskboard
no possui comunicao escrita (por chat) nem oral (por videoconferncia). A ferramenta tambm no permite controlar a
durao da reunio, e no possibilita que os membros vejam
ao mesmo tempo outras informaes necessrias, tais como o
Sprint burndown para acompanhar o andamento do projeto.
Concluses sobre as ferramentas

Com base nos problemas enfrentados por equipes distribudas, conforme discutido nas ltimas sees, e na anlise das
ferramentas atuais que adotam Scrum, tem-se observado a
falta de ferramentas que apiem o Daily Meeting distribudo.
As ferramentas apenas fornecem o Taskboard ou um espao
para os membros de forma assncrona responderem s trs
perguntas. Esta ausncia pode estar relacionada ao fato do
Scrum enfatizar o trabalho da equipe no mesmo espao fsico
11
e no mencionar como essa reunio deve ser tratada num

cenrio distribudo.
A Tabela 1 mostra um conjunto de recursos importantes
identificados a partir dos problemas discutidos nas ltimas
sees, de modo a auxiliar as equipes distribudas nas reunies dirias.
Estas lacunas identificadas na Tabela 1 ajudaram a definir a
abordagem proposta e discutida na prxima seo e tambm
a criar um questionrio para coletar a opinio de pessoas que
vivenciaram projetos distribudos. O questionrio aplicado
possua perguntas sobre quais os problemas enfrentados durante o projeto, e avaliava a importncia dos recursos propostos
na Tabela 1 em uma soluo para amenizar os problemas
durante o Daily Meeting distribudo. O resultado do questionrio pode ser acessado pelo link: https://spreadsheets.google.com/
gform?key=0Asx_k1VExGmFdDJvZUh3UTRTc2lTUmx5UUhX
aEg3TUE&hl#chart. At o momento 38 pessoas responderam,
dentre eles, alunos da UFPE e profissionais do ramo.
Uma abordagem para tratar o Daily Meeting

distribudo
O desenvolvimento dos mdulos do FireScrum foi realizado de
forma distribuda organizada em seis equipes. A experincia da
implementao de um dos mdulos, Planning Poker, foi relatada
durante o Workshop Brasileiro de Mtodos geis [16]. Atravs
deste relato foram levantados vrios problemas enfrentados
durante as reunies dirias. O primeiro deles foi a dificuldade
no agendamento da reunio, que ocorria normalmente por email. Alinhado a isso, existia o problema de os membros no
se lembrarem de comparecer reunio no horrio combinado,
alm tambm da incompatibilidade do horrio entre todos os
membros, de modo que alguns deles no podiam comparecer e
enviavam as respostas das trs perguntas por e-mail, causando
a falta de controle das respostas enviadas.
Outro problema enfrentado durante o desenvolvimento do
Planning Poker foi a falta de integrao entre as ferramentas
de comunicao (por exemplo, Skype) e ferramentas para gerenciamento gil de projetos (por exemplo, FireScrum). Esta
Assembla
combinao permite um melhor acompanhamento da reunio,

visualizando os detalhes do projeto em tempo real por todos
os membros e possibilita que os membros se comuniquem
atravs de chat ou vdeo-conferncia.
Estes problemas discutidos possivelmente ocorreram de forma semelhante em outros projetos distribudos, tais como os
relatados por [13][9][18], uma vez que eles descreveram que o
Skype foi utilizado para a reunio diria e no foi mencionado
nenhuma ferramenta especfica de apoio. Assim, esta abordagem foi proposta visando amenizar os problemas enfrentados
na experincia anterior e levantados no tpico Concluses
sobre as ferramentas.
A abordagem consiste num conjunto de subprticas que
podem ser adotadas pelos membros de equipes distribudas
de modo a tratar os principais pontos discutidos. Desta forma,
inicialmente, a abordagem define a necessidade de o Scrum
Master agendar o horrio da reunio e definir quantos minutos antes de comear o encontro um e-mail ser enviado para
os membros, a fim de lembr-los da reunio. Esse lembrete
deve ser enviado de preferncia 20 minutos antes, para permitir que os membros respondam previamente s trs questes
de acompanhamento. A resposta prvia das perguntas importante por uma srie de razes, dentre elas: o fato de que
alguns membros no podem comparecer reunio; e ajudar
a superar a barreira da lngua durante a comunicao oral
entre os membros de diferentes localidades.
Essa abordagem tambm sugere que os membros compartilhem informaes importantes em tempo real sobre o
projeto, como o Taskboard e Sprint Burndown. O primeiro, o
Taskboard, importante pois permite que os membros atualizem o status de suas atividades, definam as atividades que
eles iro realizar e informem se tiveram algum impedimento.
J o Sprint Burndown auxilia os membros a acompanhar o
andamento do projeto. Alinhado a isso, necessrio fornecer
recursos que permitam que os membros se comuniquem, tais
como udio, vdeo e chat. O udio e o vdeo so importantes
para que os membros conheam o rosto e a voz das pessoas
com as quais esto trabalhando remotamente, ajudando a
ScrumWorks
VersionOne
TargetProcess
FireScrum
Agendamento da reunio
Envio de lembrete aos usurios
Preenchimento das trs perguntas antes de comear a reunio
Controle da durao da reunio

Salvar e recuperar informaes da reunio
Comunicao Sncrona (Ex: chat ou videoconferncia)
Comunicao Assncrona
X
X
Taskboard ou TaskView
Taskboard atualizvel em tempo real
Gerao do Sprint Burndown
X
X
Ambiente integrado a uma ferramenta de gerenciamento gil de projetos

Tabela 1. Recursos para ajudar as equipes distribudas nas reunies
12
AGILIDADE
criar um senso de equipe. E o chat importante para eventuais problemas da

comunicao oral, seja por problemas
tecnolgicos (ex: velocidade da rede),
bem como pelo problema de entendimento entre os membros de diferentes
localidades, como j mencionado.
No intuito de prover maior interao
na equipe, os membros necessitam de
um mecanismo que permita destacar (ou
apontar) para os outros algum detalhe
das informaes compartilhadas, como se
tivessem usando a prpria mo em uma
reunio presencial. Outro fator importante
o controle do tempo, uma vez que o
encontro deve ser breve para evitar que a
reunio perca o foco e algum da equipe
deixe de comparecer nos prximos dias.
Alm disso, para evitar o desperdcio de Figura 1. Ambiente do Daily Meeting
tempo, o Scrum Master deve definir antes de comear a reunio
a ordem que os membros iro falar.
Salvar e recuperar as informaes da reunio, criando assim
Um ltimo ponto definido pela abordagem proposta a imum histrico e permitindo que membros que no compareceportncia de salvar as informaes do encontro, como o chat,
ram reunio possam visualizar o que aconteceu nela;
o udio, o vdeo e as respostas das trs perguntas respondidas
Permitir maior interao entre os membros criando um
pelos membros. Isso permite manter o histrico, possibilitando
mouse para cada um no ambiente. Deste modo possvel que
que os membros que no puderam comparecer reunio poso membro interaja com o ambiente e aponte algum detalhe
sam se manter informados sobre o andamento do projeto.
nas informaes compartilhadas que ele queira que os outros
A abordagem proposta definiu, portanto, um conjunto de subprprestem ateno;
ticas no intuito de auxiliar o Daily Meeting distribudo. Entretanto,
Exibir a lista de tarefas mostrando o responsvel pela tarefa
para atender cada uma delas, necessrio um ambiente integrado
e o status dela.
para auxiliar na realizao destas reunies, como descrito a seguir.
Para atender os requisitos, o ambiente foi separado em trs
Ferramenta
telas. A primeira a de Configuraes, que permite ao Scrum
A fim de apoiar a abordagem proposta, um ambiente para
Master definir a ordem em que os membros iro falar, o tempo
as reunies dirias foi desenvolvido com o objetivo de apoiar
de durao da reunio, e definir os recursos que podero ser
todas as subprticas descritas. Ele foi integrado ao FireScrum
utilizados na reunio (ex: habilitar ou desabilitar o chat, udio/
por ser uma ferramenta de gerenciamento gil de projetos e
vdeo, controle de tempo). A segunda tela a principal, onde
oferecer recursos como Taskboard atualizvel em tempo real
ocorre a reunio (ver Figura 1). E a ltima tela apresenta o
e gerao do Sprint Burndown, evitando assim criar uma nova
histrico das reunies anteriores que foram gravadas.
ferramenta apenas para a reunio diria e ter outra para geA Figura 1 exibe alguns dos recursos disponibilizados como
renciamento de projetos. Os principais requisitos endereados
udio, vdeo e chat, as respostas das trs questes e a lista de
pelo ambiente foram:
tarefas atribudas a cada membro. O ambiente possui tambm
Agendamento da reunio;
uma aba para visualizar o Sprint Burndown, um boto para
Envio de lembrete por e-mail minutos antes da reunio
abrir o Taskboard, e no canto superior direito fica o controle
comear;
do tempo e a vez do membro que est falando.
Permitir que os membros respondam as trs perguntas
O ambiente desenvolvido melhora o apoio s equipes distripreviamente;
budas, que podero usar uma nica ferramenta, o FireScrum,
Integrar o ambiente ferramenta FireScrum;
para gerenciar projetos e realizar o acompanhamento dirio
Permitir a comunicao oral e textual entre os membros;
do mesmo.
Compartilhamento de informaes em tempo real atravs
Apesar de no ter sido ainda validado, o questionrio ajudou
do Taskboard e do Sprint Burndown;
a verificar a aceitao dos requisitos endereados no ambiente.
Controle da durao das reunies;
A maioria destes requisitos obteve uma aceitao acima dos
Controle da durao da vez de cada membro falar;
60%. Dentre os itens com votos mais altos esto os recursos
Controle da ordem dos membros que iro falar durante a
de comunicao e o compartilhamento de informaes atrareunio;
vs do Burndown e Taskboard, os quais atingiram taxas de
13
14
Boehm, Barry.A view of 20th and 21st century software engineering.ICSE 06:Proceedings of the 28th
international conference on Software engineering. 2006.
Cavalcanti, Eric; Maciel, Teresa; Albuquerque, Jones. Ferramenta OpenSource para Apoio ao Uso do
Scrum por Equipes Distribudas. Workshop de Desenvolvimento Distribudo de Software (WDDS).
2009.
Damian, Daniela; Marczak, Sabrina; Dascalu, Madalina; Heiss, Michael; Liche, Adrian.Using a Real-Time
Conferencing Tool in Distributed Collaboration: An Experience Report from Siemens IT Solutions and
Services. ICGSE 09: Proceedings of the 2009 Fourth IEEE International Conference on Global Software
Engineering. 2009.
French, A.; Layzell, P.A Study of Communication and Cooperation in Distributed Software Project
Teams. ICSM 98: Proceedings of the International Conference on Software Maintenance. 1998.
Herbsleb, James D.; Moitra, Deependra. Guest Editors Introduction: Global Software Development.
IEEE Software. 2001.
Highsmith, Jim Agile Project Management - Creating Innovative Products. Pearson Education. 2004.
Karolak, Dale Walter.Global Software Development: Managing Virtual Teams and Environments. IEEE
Computer Society Press. 1999.
Lee, Seiyoung; Yong, Hwan-Seung. Distributed agile: project management in a global environment.
Empirical Software Engineer. 2010.
Dubakov, Michael; Stevens, Peter. TargetProcess. Agile Tools. The Good, the Bad and the Ugly. http://
www.targetprocess.com/download/whitepaper/agiletools.pdf. 2008.
ScrumWorks. ScrumWorks Pro 4. http://www.danube.com/docs/ ScrumWorks_Pro_Datasheet.pdf.
2009.
Singleton. Accelerate with a Daily Scrum. Assembla. http://blog.assembla.com/assemblablog/
tabid/12618/bid/2424/Accelerate-with-a-Daily-Scrum.aspx. 2007.
Sutherland, Jeff; Schoonheim, Guido; Rustenburg, Eelco; Rijk, Maurits. Fully Distributed Scrum: The
Secret Sauce for Hyperproductive Offshored Development Teams. Agile 2008 Conference. 2008.
Sutherland, Jeff; Viktorov, A.; Blount, J.; Puntikov, N. Distributed Scrum: Agile Project Management
with Outsourced Development Teams. Hawaii International Conference on Software Systems, Big
Island, Hawaii. 2007.
Takeuchi, Hirotaka; Nonaka, Ikujiro. The New New Product Development Game. Harvard Business
Review. 1986.
Chalegre,Virgnia C..Santos,Wylliams B.; Souza, Leandro O.; Munoz, Hernan J.; Meira, Silvio R.L.Estudo
de Caso da Utilizao de Scrum no Desenvolvimento Distribudo de Software. Conferncia Brasileira
sobre Mtodos geis de Desenvolvimento de Software. 2010.
Versionone. The State of Agile Development Survey Results. http://www.versionone.com/
pdf/3rdAnnualStateOfAgile_FullDataReport.pdf. 2008.
Williams, Wes; Stout, Mike. Colossal, Scattered, and Chaotic (Planning with a Large Distributed Team.
AGILE Conference. 2006.

Feedback
eu
sobre e
s
Com a crescente adoo do desenvolvimento gil distribudo,

as empresas comearam a enfrentar outros desafios na gesto
de projetos devido a problemas de comunicao e colaborao
entre os membros da equipe. A utilizao de um mtodo gil
como o Scrum ameniza esses problemas, uma vez que as prticas
definidas sugerem maior interao entre os membros, maior envolvimento do cliente, e feedback rpido com entregas peridicas
num curto espao de tempo. Entretanto, como ele enfatiza que
as equipes devem trabalhar no mesmo espao fsico, o Scrum
no define como a metodologia deve ser tratada em um cenrio
distribudo.
Um ponto no abordado quando a equipe distribuda a reunio diria. A realizao desta reunio de forma eficaz permitiria
evitar os principais problemas de gesto, possibilitando que os
membros se comuniquem e interajam diariamente, fornecendo
feedback rpido sobre o andamento das atividades e do surgimento de impedimentos. Como discutido na seo sobre Ferramentas
para apoio ao Daily Meeting, apesar da importncia das reunies
dirias, ele no tratado adequadamente pelas ferramentas atuais
de gerenciamento gil de projetos, pois s fornecem o Taskboard
ou um espao para os membros, de forma assncrona, responderem s perguntas.
Assim, a fim de tratar o Daily Meeting distribudo, a abordagem proposta neste artigo define algumas prticas de modo a
auxiliar as equipes a organizar, gerenciar e realizar tais reunies.
Ela comea enfatizando a importncia das reunies ocorrerem
em um horrio agendado pelo Scrum Master, e a necessidade
do envio de um lembrete para todos os membros da equipe
alertando sobre a reunio. Para o melhor acompanhamento do
projeto imprescindvel o compartilhamento de informaes do
projeto em tempo real entre os membros, tais como o Taskboard
e o Sprint Burndown, e ainda a visualizao das respostas de
cada membro referente s trs perguntas dirias. Entretanto, a
reunio se torna efetiva se disponibilizadas diversas formas de
comunicao sncrona, tanto oralmente (ex: videoconferncia)
quanto por escrito (ex: chat).
De modo a dar suporte s prticas definidas, foi desenvolvido
um ambiente integrado ferramenta de gerenciamento gil de
projetos FireScrum. O FireScrum foi escolhido por ser cdigo
livre, ter uma arquitetura modular e fornecer os recursos necessrios para o ambiente, como o TaskBoard e o Sprint Burndown.
Assim sendo, este artigo descreveu como adaptar para um ambiente distribudo uma das prticas do Scrum, o Daily Meeting.
Alm disso, discutiu como as ferramentas atuais do suporte a
essa prtica, e apresentou um ambiente que fornece uma sala
virtual para que as equipes possam se reunir todos os dias.
Beck, Kent et al. Manifesto for agile software development. Fev. 2001. Disponvel em http://www.
agilemanifesto.org.
D
s
Concluso
Referncias
edio
ta
quase 80% de aceitao. Os que obtiveram votos com menor

aceitao foram: o armazenamento das informaes da reunio e a criao do mouse para cada usurio, que obtiveram
uma aceitao prxima dos 60%. Dessa forma, espera-se que
o ambiente auxilie as equipes distribudas ao prover um local
virtual para se reunirem todos os dias.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Requisitos em SOA Parte 2

Levantamento de Requisitos tcnicos em SOA

Neste artigo veremos os principais aspectos dos requisitos tcnicos de projetos SOA, como classificar
estes requisitos e as caractersticas tecnolgicas
mais relevantes de um servio.
Para que serve?

Auxiliar na conduo da coleta de requisitos tcnicos de Projetos SOA e na identificao dos recursos
tecnolgicos importantes, prevendo-se o lanamento de um programa SOA generalizado para a
empresa.
N
Joo Caldas Jnior
caldasjr@gmail.com
Possui mestrado em Cincias da Computao e Matemtica Computacional pela

Universidade de So Paulo. Atualmente
trabalha como consultor de TI e professor da Fundao Salvador Arena em So
Bernardo do Campo-SP. Possui experincia
em projetos de Engenharia de Software,
Engenharia de Requisitos e Arquitetura
Orientada a Servios na rea bancria.
o primeiro artigo desta srie foi

abordado como identificar os
primeiros servios e determinar seus requisitos de negcio em um
projeto Service-Oriented Architecture
(SOA). Foram comentadas as principais
abordagens para identificar servios,
assim como foram expostas algumas
categorias para requisitos de negcios.
Por fim, discutiu-se um processo simples
para modelar os requisitos de negcio
para os servios identificados.
Neste artigo, sero explorados diferentes tipos de solues tecnolgicas que
precisam ser con hecidas a fim de
Orienta na obteno de um processo base para

a definio da capacidade de planejamento,
gesto e acompanhamento das solues tecnolgicas em um projeto SOA.
capturar os requisitos tcnicos de um

projeto SOA. Sero apresentadas tambm algumas exigncias que devem servir de base para a captura de requisitos
tcnicos, prevendo-se o lanamento de
um programa SOA generalizado para
a empresa. Um programa deste porte
visa: garantir a escala e o controle dos
investimentos dentro de um cenrio de
15
oramentos restritivos, permitir uma maior visibilidade dos

servios compartilhados e um melhor planejamento e reviso
da arquitetura.
Por onde comear?

O foco principal em um projeto SOA deveria ser dado s exigncias do negcio, porm como a maioria das iniciativas SOA
acabam sendo lideradas pelas equipes de TI (e no pelas equipes
de negcio) os requisitos de tecnologia ganham tanta importncia quanto os requisitos de negcio. Dada essa realidade, (e aqui
no se vai discutir se ela correta ou no, pois simplesmente
a realidade) os grupos de TI, desde o incio do projeto, iniciam
discusses de questes como: a adoo do SOAP e WSDL, o
uso de Web Services, Universal Description Discovery and
Integration (UDDI), Enterprise Service Bus (ESBs), e o uso de
ferramentas de governana em SOA (ver definies detalhadas
na Nota do DevMan 1). Na prtica, a equipe de TI escolhe um
servio de negcio a ser usado em uma prova de conceito (POC)
e concentram-se fortemente na tecnologia que ser utilizada
no desenvolvimento deste POC.Neste ponto vale a pena uma
reflexo, preciso cautela na utilizao de algumas das solues
tecnolgicas listadas anteriormente, principalmente no que diz
respeito a trs delas: UDDI, ESB e as Ferramentas de Governana. Partindo da premissa que os projetos esto no incio e que
algumas solues necessitam de maturidade, preciso aprender
antes de tomar decises baseadas em folhetos de fornecedores.
Por exemplo, o UDDI conceitualmente perfeito, no entanto,
a sua implantao em um projeto SOA que provavelmente
iniciar com um pequeno nmero de servios e uma base de
consumidores relativamente limitada, um exagero. No incio,
bem mais produtivo gastar tempo na definio de contratos
WSDL bem estruturados, pois eles daro base s informaes
que sero manipuladas pelos repositrios UDDI.
A mesma linha de argumento vlida para um ESB. Dependendo da complexidade da soluo SOA a ser adotada, um ESB
pode no ser a melhor soluo para o problema. Um ESB deve
ser usado quando existem diversos sistemas que precisam conversar de diversas maneiras e que esto distribudos em locais
diferentes ( o caso tpico de aplicaes em portais web).
O ESB atualmente tornou-se uma poderosa ferramenta de
propaganda das arquiteturas orientadas a servios, atuando
como uma camada de abstrao das interfaces dos servios.
Por meio do ESB possvel integrar os sistemas, mantendo seu
encapsulamento e ainda existem ESBs que fazem mais: podem
at controlar o SLA de um servio. Todas essas caractersticas
tornam a idia de ter um ESB muito atraente, porm ele no
parte obrigatria de uma arquitetura orientada a servios.
Em casos que existem s dois sistemas (ex: Java e .net), bem
razovel considerar a possibilidade de usar algo mais simples,
como o JMS por exemplo.
Finalmente, tem-se uma situao inversa no que diz respeito
s ferramentas de governana. Em projetos SOA, sejam de pequeno ou de grande porte, existe a necessidade de versionar,
monitorar e gerenciar os servios de negcio, e esse papel pode
ser realizado por ferramentas de governana. As ferramentas
16
Engenharia de Software Magazine - Requisitos em SOA Parte 2
Nota do DevMan 1
Padronizando os Padres (Erl [1])
O padro SOAP utilizado pelos Web Services e responsvel por definir o
modelo da troca de mensagens. Para isso utiliza um arquivo XML que define envelopes e os ns intermedirios da comunicao.
O padro WSDL responsvel por identificar o protocolo e o endereo no qual
um servio est publicado, assim como seus parmetros de entrada e sada.
O padro UDDI permite que os servios sejam categorizados, porm sem fornecer uma riqueza de textos para que buscas por um servio especfico sejam
feitas.
O padro ESB permite customizaes no servio de mensagens, isto , ele funciona como um Mediador. A partir dele possvel fazer validaes e roteamento
de mensagens baseado no contedo da mensagem. Um barramento ESB permite um baixo acoplamento entre sistemas visto que um sistema de origem no
precisa conhecer o sistema de destino.
de governana atuais cumprem seu papel perfeitamente

quando aplicadas em pequenos projetos independentes, porm
quanto maior o tamanho do projeto, maior so os problemas
com questes como a gerncia de mudanas, versionamento e
a anlise de impacto com as ferramentas que esto disponveis
hoje. Atualmente estas ferramentas possuem srias limitaes
em termos de interoperabilidade, performance e escalabilidade
em ambientes de sistemas SOA de grande porte [2].
Felizmente, nem todas as decises so difceis, uma boa
notcia que existem tecnologias que j possuem um razovel
nvel de padronizao de mercado, seja para projetos iniciais
(POC) ou projetos j amadurecidos. Tais tecnologias so: os
Web Services, WSDL e SOAP. Os Web Services (baseados em
XML) so o tipo de implementao de servios mais largamente
aceito e bem sucedido. Este tipo de implementao possui como
requisitos fundamentais:
Comunicao via protocolos internet (normalmente HTTP);
Envio e recebimento de dados formatados como documentos
XML.

A ampla aceitao dos Web Services resultou no surgimento
de um conjunto de tecnologias suplementares que se tornaram
um padro de fato. Assim, ao desenvolver um Web Service
deve-se considerar o uso de tecnologias que:
Forneam uma descrio de servio que, no mnimo, consista
de um documento WSDL;
Sejam capazes de transportar documentos XML utilizando
SOAP sobre HTTP.
Os Web Services devem ser definidos numa forma consistente
para que possam ser descobertos e interfaceados com outros
servios e aplicaes. A WSDL uma especificao W3C que
fornece a linguagem mais avanada para a descrio de definies de Web Services.
Apesar de ter sido inicialmente concebido como a tecnologia para transpor a brecha entre plataformas baseadas em
A RQ U I TETUR A ORIENTADA A SERVIOS (SOA)
comunicao RPC, o SOAP se tornou um dos mais conhecidos

formatos de mensagens e protocolo utilizado por Web Services baseados em XML. Por este motivo, o acrnimo SOAP
referido frequentemente como Service-Oriented Architecture
(or Application) Protocol (protocolo de arquitetura orientada
a servios) ao invs de Simple Object Access Protocol que
curiosamente seu nome verdadeiro.
Requisitos Tcnicos para um servio

Esta seo descreve quais so as categorias dos requisitos tcnicos de um servio em um projeto SOA. Em um sentido amplo, as
categorias mais importantes so listadas abaixo, porm o requisito
primordial para uma empresa, quando se trata de tecnologia
SOA, permitir a agilidade nos negcios tambm conhecida
como tolerncia a mudanas. Uma empresa que utilize SOA
com sucesso est sempre evoluindo e permitindo mudanas de
cenrios tecnolgicos.
Segurana. A questo de segurana atualmente a principal
preocupao das empresas na tomada de decises em relao a
implementao de projetos SOA. De acordo com uma pesquisa
global [4], patrocinada pela CA, 43% dos executivos snior de TI
classificam as ameaas segurana como o item mais crtico na
implementao de aplicaes de SOA e de servios baseados na
Web. Quem pode acessar o servio? Quem pode acessar os dados
de dentro de cada servio? E como os dados so garantidos em
uma transmisso entre os servios? So perguntas que devem ser
tecnologicamente respondidas assim que um projeto inicia.
Simplicidade. Como algum que queira utilizar um servio,
pode facilmente utiliz-lo? Esta a pergunta que fica na fronteira entre os requisitos tcnicos e os de negcio. Um servio deve
ser de fcil invocao, apresentar as funcionalidades esperadas,
ter um bom tratamento de erros e, geralmente, ser capaz de se
integrar com outros servios. O ideal que uma empresa menos
madura deva ser capaz de utilizar um servio sem um grande
investimento em tecnologia ou grandes mudanas em seus processos de negcio.
Qualidade. Considere a disponibilidade, escalabilidade, confiabilidade, entre outras caractersticas como fatores de qualidade
de um servio. Quais so as consequncias de SOA em uma
perspectiva de negcios? Um aspecto fundamental em arquiteturas orientadas por servio a gerncia contnua da qualidade
em todo o ciclo de desenvolvimento de processos de negcio e
servios. A qualidade de software est cada vez mais ancorada
no atendimento a processos de negcio de ponta a ponta, que
traduzido no conceito de governana de TI, que a chave para
qualquer projeto SOA de sucesso.
Em alto nvel, a captura destas categorias um excelente ponto
de partida. evidente que cada uma possui um maior detalhamento, planejamento, coordenao e gesto de projetos. No entanto, a orientao para o tipo de informao que se precisa capturar
j ajuda a definir os requisitos tcnicos fundamentais.
Caractersticas tecnolgicas de um servio

Para chegar a um modelo de arquitetura tecnologicamente
desacoplada entre cliente e servio, preciso criar um ambiente
propcio para o compartilhamento e reuso de funcionalidades,

assim como a composio de funcionalidades nas aplicaes.
Abaixo so apresentadas algumas caractersticas tecnolgicas
essenciais a servios integrados a uma arquitetura.
Servios so orientados a mensagens. Os servios so formalmente definidos em termos das mensagens trocadas entre
agentes fornecedores e agentes consumidores. A estrutura
interna e a implementao so propositalmente abstradas.
Logo, existe um limite entre consumidores e fornecedores e
esse limite representa a fronteira entre a interface pblica de
um servio e sua implementao interna, privada. O limite
de um servio publicado por meio do WSDL e pode incluir
declaraes que ditam as expectativas sobre o servio. O cruzamento desse limite pode ser considerado uma tarefa cara
por motivos como:
O local fsico do servio pretendido pode ser um fator
desconhecido;
Os modelos de segurana e de confiana provavelmente
mudaro a cada cruzamento do limite;
O empacotamento e a converso de dados entre as representaes pblica e privada de um servio podem exigir
recursos adicionais; alguns deles podem ser externos ao
prprio servio;
Ainda que os servios sejam criados para durar, as configuraes de servio so criadas para mudar. Esse fato implica
que um servio confivel pode sofrer repentinas quedas de
desempenho em funo de configuraes de rede ou de migrao de local fsico.
Servios so autnomos. Os servios so entidades implantadas independentemente, com verses e gerncias prprias.
Os desenvolvedores no podem fazer suposies em relao
s distncias limites de um servio, visto que essas distncias
tm muito mais probabilidade de mudar do que os limites
propriamente ditos. Por exemplo, os limites do servio devem ser estticos para minimizar o impacto da verso para o
consumidor. Ainda que os limites de um servio sejam bem
estveis, as opes de implantao desse servio em relao
diretiva, ao local fsico ou topologia da rede provavelmente
mudaro.
Os servios so tratados dinamicamente por meio de URIs,
permitindo que seus locais e topologias de implantao mudem
ou evoluam com o tempo, com pouco impacto em relao ao
prprio servio (isso tambm vlido em relao aos canais
de comunicao de um servio). Ainda que essas alteraes
possam ter pouco impacto sobre o servio, elas podem ter um
impacto devastador sobre aplicativos que o utilizem. E se um
servio que estava sendo usando hoje passar para uma rede
na Irlanda amanh? A alterao no tempo de resposta pode
ter impactos esperados ou inesperados sobre os consumidores
do servio. Os designers de servio devem adotar uma viso
pessimista sobre o uso dos servios: os servios falharo e seus
comportamentos associados (nveis de servio) estaro sujeitos
mudana. Nveis apropriados de tratamento de excees e
de lgica de compensao devero ser associados a qualquer
17
invocao de servio. Alm disso, consumidores de servio

podem precisar modificar suas diretrizes para declarar
tempos de resposta mnimos de servios a serem utilizados.
Os consumidores de servio no so os nicos que devem
adotar vises pessimistas do desempenho: os provedores de
servio devem ser da mesma forma, pessimistas ao antecipar
como seus servios sero utilizados. Deve-se esperar que os
consumidores de servio falhem, algumas vezes sem notificar o prprio servio. Os provedores de servio tambm no
podem confiar que os consumidores faro a coisa certa.
Por exemplo, os consumidores podem tentar se comunicar
usando mensagens mal-elaboradas/mal-intencionadas ou
tentar violar outras diretrizes necessrias para uma interao
de servio bem-sucedida.
Feitas essas consideraes, alguns princpios de design simples que ajudam a garantir a compatibilidade com a segunda
caracterstica (Servios so autnomos) so:
Os servios devem ser implantados e ter a verso atualizada, independentemente do sistema em que sejam implantados
e utilizados;
Os contratos devem ser projetados pressupondo-se que,
uma vez publicados, no possam ser modificados. Essa
abordagem fora os desenvolvedores a criarem flexibilidade
em seus de-signs de esquema;
Os servios devem ser tolerantes a falhas, adotando uma
viso pessimista. Da perspectiva do consumidor, deve-se
esperar nveis pouco confiveis de disponibilidade e de desempenho do servio. Da perspectiva do fornecedor, espere
que o servio seja usado de forma errada (deliberadamente
ou no) e que os consumidores do servio falhem, talvez sem
notificar o servio.
Servios compartilham esquema e contrato. Como j foi
dito, a interao com um servio deve seguir diretrizes definidas no contrato deste servio. A maioria dos desenvolvedores
define classes para representar as vrias entidades dentro de
determinados domnios de problemas (por exemplo, Cliente,
Pedido e Produto). As classes combinam comportamento e
dados (mensagens) em uma nica linguagem de programao
ou construo especfica plataforma. Os servios dividem
esse modelo para maximizar a flexibilidade e a interoperabilidade. Os servios que se comunicam usando mensagens
baseadas no esquema XML no reconhecem as linguagens e
as plataformas de programao, garantindo nveis mais amplos de interoperabilidade. O esquema define a estrutura e o
contedo das mensagens, ao passo que o contrato de servio
define o comportamento do prprio servio.
Resumindo, o contrato de um servio consiste nos seguintes
elementos:
Formatos de troca de mensagens definidos com o Esquema
XML;
Padres de troca de mensagens (MEPs) definidos com o
WSDL;
O BPEL pode ser usado como contrato no nvel de processo
comercial para orquestrar vrios servios.
18
Engenharia de Software Magazine - Requisitos em SOA Parte 2
Os consumidores de servio utilizam um contrato de servio para invocar um servio e interagir com ele. Havendo
essa confiana, o contrato de um servio deve permanecer
estvel com o passar do tempo. Os contratos devem ser projetados da forma mais explcita possvel, ao mesmo tempo
tirando proveito da natureza extensvel do esquema XML
e do modelo de processamento SOAP.
O maior desafio da terceira caracterstica sua continuidade. Depois que um contrato de servio publicado,
extremamente difcil modific-lo e ao mesmo tempo
minimizar o impacto sobre antigos consumidores do servio. A linha entre as representaes de dados interna e
externa fundamental para a implantao e a reutilizao
bem-sucedida de determinado servio. Os dados pblicos
(dados passados entre servios) devem se basear em padres
organizacionais ou verticais, garantindo ampla aceitao
entre diferentes servios. Os dados privados (dados dentro
de um servio) so encapsulados em um servio. De alguma
maneira, os servios so como representaes menores de
uma organizao que conduz transaes de e-business.
Assim como uma organizao deve mapear uma Ordem
de compra externo em seu formato interno de OC, um
servio tambm deve mapear uma representao de dados
sob contrato em seu formato interno. As experincias com
encapsulamento de dados OO podem ser reutilizadas para
ilustrar um conceito semelhante: a representao interna
dos dados de um servio s pode ser manipulada por meio
do contrato do servio.
Feitas essas consideraes, vo aqui alguns princpios de
design simples que o ajudam a garantir a compatibilidade
com a terceira caracterstica:
Garantir que o contrato de um servio permanea estvel
para minimizar o impacto sobre os consumidores do servio.
O contrato nesse sentido se refere representao de dados
pblica (dados), ao padro de troca de mensagens (WSDL) e
a recursos e nveis de servio configurveis (diretriz);
Os contratos devem ser o mais explcitos possvel, visando
minimizar a m interpretao. Alm disso, os contratos
devem acomodar a futura verso do servio por meio da
extensibilidade da sintaxe XML e do modelo de processamento SOAP;
Evitar transpor a fronteira entre as representaes de
dados pblica e privada. O formato interno dos dados de
um servio deve ficar oculto para os consumidores e o
esquema de dados pblico deve preferencialmente seguir
um padro organizacional;
Servios de verso quando h alteraes no contrato de
servio so inevitveis. Essa abordagem minimiza a ruptura
de implementaes do antigo consumidor.
Concluso
As demandas de uma arquitetura orientada a servios em
termos de disponibilidade, escalabilidade, desempenho,
confiabilidade e assim por diante so ainda mais importantes quando postas frente s mudanas tecnolgicas na
A RQ U I TETUR A ORIENTADA A SERVIOS (SOA)
Links
[1] Erl,, T.Introduction to Web Services Technologies: SOA, SOAP, WSDL and UDDI
Prentice Hall PTR, Upper Saddle River, NJ, 2007 - www.thomaserl.com
[2] Rodriguez, T. Demsak, T.Lightweight SOAs: Exploring Patterns and Principles of a New
Generation of SOA Solutions - http://msdn.microsoft.com/en-us/architecture/bb426891.aspx
[3] Smartsec SOA - Service Oriented Architecture - http://www.smartsec.com.br/soa.html
[4 ] TI INSIDE, Converge Comunicaes Segurana ponto crtico em SOA e servios web
http://www.tiinside.com.br/News.aspx?ID=102376&C=262

Feedback
eu
edio
ta
D
s
[5] The World Wide Web Consortium (W3C) - http://www.w3.org/
19
sobre e
s
rea de TI. Em SOA existe um aumento significativo do

risco de no acompanhar as necessidades do negcio se a
infraestrutura no atender a demanda e no existir uma
previso ou planejamento para essa demanda. Portanto,
em linhas gerais vital ser cauteloso: planejar com antecedncia, manter o ciclo de comunicao aberto, conhecer as
tendncias em servios do setor, quais os prximos servios
a serem construdos e assim por diante. Em resumo, o
importante seguir um processo, ser pr-ativo em termos
de capacidade de planejamento, gesto e acompanhamento
das solues adotadas.
Do ponto de vista de arquitetura de software, sempre
bom manter os olhos sobre as tecnologias SOA mais atuais, padres e frameworks. Provavelmente, os servios
que seus clientes esto usando agora possuem uma vasta
gama de tecnologias, de modo que voc precisa monitorar
continuamente estas tendncias. Por isso, prudente ter
um Plano de interoperabilidade, ou melhor, tentar prever
os desafios de interoperabilidade em termos de escolhas
de tecnologia.
Engenharia
Automao dos Testes: um lobo na pele de cordeiro?

Conhea os cuidados a serem tomados na implantao da automao dos
testes para evitar o fracasso
O
Daniel Scaldaferri Lages
dlages@gmail.com
Possui MBA em Gerncia de Projetos pela

Fundao Getlio Vargas, ps-graduado
em Gerncia de T.I. pela Universidade FUMEC e Bacharel em Cincia da Computao
pela UFMG. Atualmente Coordenador da
equipe de Quality Assurance da CPM Braxis,
filial BH. Sua experincia profissional inclui
o cargo de Analista de Testes no Synergia
(ncleo de engenharia de software do
Departamento de Cincia da Computao
da UFMG), Gerente da fbrica de software
na Unitech (hoje CPM Braxis) e docncia
no curso de graduao de Sistemas de Informao na PUC-MG. Possui a certificao
ITIL para gerenciamento de servios de T.I.
certificado em testes de software pela ISTQB e em qualidade de software pela IBM.
20
termo lobo em pele de cordeiro utilizado no ttulo desse

artigo origina-se de uma fbula
que fala do lobo que se disfarou com
uma pele coberta de l e assim conseguiu entrar no rebanho de ovelhas,
fazendo-se passar por uma delas tanto
na aparncia como no comportamento
fingido, mas aproveitando essa condio
para devorar as inocentes e desprevenidas vtimas.
Devido ao apelo de se implantar a automao de testes como a salvao em
termos de custo, prazo e produtividade
para os projetos de desenvolvimento de
software, esta iniciativa pode ser comparada com a inocente ovelhinha, pois
aparentemente no apresenta riscos
empresa, apenas benefcios. Mas esta
ovelha pode se revelar um lobo, caso
Engenharia de Software Magazine - Automao dos Testes: um lobo na pele de cordeiro?
Este artigo apresenta uma reflexo sobre os cuidados que devem ser levados em considerao na
aplicao da automao de testes. Muitas vezes
essa atividade vista como a salvao em termos de custo, prazo e produtividade para os projetos. O artigo apresenta situaes que mostram
que, caso a automao no seja bem implementada, s ir prejudicar.
Para que serve?

O artigo poder auxiliar os gerente e profissionais
de testes que desejam automatizar os testes de
software, apresentando os cuidados, as dificuldades e os pontos fracos e fortes dessa atividade. Ir
auxili-los para que pensem racionalmente, e no
utopicamente, sobre essa atividade.

Para empresas e profissionais que possuem interesse em automatizar os testes dos seus softwares de maneira controlada, com conhecimento de
alguns dos principais riscos desta atividade.
o processo de implantao da automao de testes no seja bem planejado e

conduzido, resultando no fracasso do
projeto. Apesar dessa analogia entre a
VALIDAO, VERIFIC AO & TESTE
automao de testes e a fbula do lobo ser um tanto quanto

exagerada, deve servir como alerta para aqueles que desejam
implant-la. O objetivo deste artigo estimular a reflexo dos
gerentes e orient-los em relao aos cuidados que devem
ser levados em considerao na implantao da automao
de testes.
Automao de Testes
Automatizar os testes nada mais do que repassar para
o computador as atividades de testes que normalmente so
realizadas de forma manual. A automao de testes deve ser
iniciada a partir de um processo manual de teste j estabelecido
e maduro. Vrias so as ferramentas disponveis no mercado
para as empresas, entre pagas e gratuitas.
A automao de testes possui alta capacidade para reduzir
esforos. Em contrapartida, possui alta propenso a falhas. A
Tabela 1 apresenta os resultados de sucesso e insucesso da
automao de testes.
Tipos de Ferramentas de Testes

De acordo com a pesquisa da GARTNER sobre o mercado
de ferramentas de testes, so trs as categorias principais de
ferramentas:
Gerenciamento de Testes: Ferramentas que auxiliam no planejamento e gerenciamento dos testes e de seus resultados;
Automao de Testes de Carga e Stress: Ferramentas que simulam
a carga de mltiplos usurios em uma aplicao para entender
e ajustar a performance do sistema;
Automao de Testes Funcionais: Testes de um nico usurio
na aplicao para encontrar falhas funcionais.
Uma outra categorizao, um pouco mais abrangente, pode
ser observada no livro do SPILLNER, livro base para certificao do ISTQB. As categorias so: Controle e Gerenciamento de
Testes, Especificao de Testes, Testes Estticos, Testes Dinmicos e
Testes No Funcionais.
Controle e Gerenciamento de Testes

Dentro desta categoria esto todas as ferramentas que fazem
algum tipo de gesto das atividades de testes. Seja a gesto
das prprias atividades, dos incidentes ou da execuo dos
testes.
Por exemplo, a ferramenta IBM Rational ClearQuest permite
a criao das atividades de testes, assim como de um fluxo de
trabalho (workflow) para cada uma delas, com atributos como
prazos, complexidade etc. Permite tambm alocar os profissionais a essas atividades, alm de permitir o apontamento das
horas trabalhadas nas mesmas.
As ferramentas Mantis, Bugzilla e Trac, por exemplo, tambm se encaixam nessa categoria, pois realizam a gesto dos
incidentes.
Por ltimo, as ferramentas que realizam a gesto da execuo
dos testes. Atravs delas possvel gerir o status atual da execuo
dos testes, identificando quais casos de testes foram executados
ou no, quais apresentaram falhas, quais passaram com sucesso,
SUCESSO
INSUCESSO
Reduo de custos
Tempo desperdiado
Testes melhorados
Dinheiro desperdiado
Resultados precisos
Resultados imprecisos
Diminuio do ciclo de vida do desenvolvimento
Equipe desmoralizada
Produtividade reduzida
Processo pronto para prximos projetos

Oportunidade perdida
Tabela 1. Resultados de sucesso e insucesso da automao de testes
quais esto bloqueados e o motivo. Normalmente essas ferramentas se integram com as ferramentas de gesto de incidentes para
que seja possvel o rastreamento das falhas. Um bom exemplo
a ferramenta Testlink, que pode ser integrada com qualquer uma
das ferramentas de gesto de incidentes citadas.
Especificao de Testes
A especificao dos casos de testes pode ser feita em uma
planilha do Excel, em um documento do Word ou at mesmo
em uma ferramenta Wiki. Entretanto, no so boas opes, pois
no possuem algumas funcionalidades interessantes que esto
presentes nas ferramentas especficas. Essas possuem muitas
vantagens em relao s planilhas e documentos, aumentando
a produtividade e a reutilizao dos casos de testes.
Existem vrias opes, como por exemplo, Testlink, HP Quality
Center e o IBM Rational Test Manager. Os principais benefcios
dessas ferramentas so:
Centralizao dos casos de testes;
Reutilizao dos casos de testes;
Customizao dos formulrios de criao dos casos de
testes;
Facilidade de rastreamento de falhas, casos de testes, casos
de uso e requisitos;
Facilidade na busca de casos de testes;
Integraes com outras ferramentas;
Histrico de alteraes.
Testes Estticos
Os testes estticos so aqueles que, diferentemente dos testes
dinmicos, os objetos testados no so executados, mas sim
analisados. Esta anlise pode ser feita por uma pessoa, como
por exemplo, numa simples reviso informal, ou por diversas
pessoas, em uma inspeo formal ou em um walkthrough.
As ferramentas para testes estticos so teis por encontrarem
defeitos mais cedo, ou seja, nas fases iniciais dentro do processo
de desenvolvimento, evitando a proliferao do defeito para
a fase de construo. Essas ferramentas so utilizadas sobre
especificaes formais, por exemplo, modelos de desenho. Normalmente so customizveis o que permite s organizaes
verificarem seus prprios padres e boas prticas. Um exemplo
o check model da ferramenta CASE IBM Rational Rose.
21
Testes Dinmicos
Sempre que se pensa em ferramentas de testes, o que vem em
mente so as ferramentas de automao da execuo dos testes,
mais especificamente os testes funcionais, de caixa preta, que
so categorizadas como ferramentas de testes dinmicos. Nos
prximos itens esse tipo de teste ser destacado.
Um outro tipo de testes que tambm tem uma forte ligao
com a automao so os testes unitrios (caixa branca). So em
sua maioria automatizados, pois teste de unidade um pedao
de cdigo que chama outro pedao de cdigo para verificar seu
comportamento. Existem diversos frameworks que, atravs das
suas APIs, facilitam a criao e a anlise dos resultados. Os frameworks so especficos para cada linguagem de programao.
Atualmente existem mais de 150 para diferentes linguagens.
Entre eles, o JUnit (www.junit.org), bastante conhecido na comunidade Java. Uma lista deles pode ser encontrada no site:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks.
Testes No Funcionais
Os requisitos no funcionais tambm so suportados por
ferramentas. Os exemplos mais clssicos so as ferramentas
de automao de testes de performance, testes de stress, de
tempo de resposta, de carga e volume. Sem essas ferramentas,
executar estes testes seria praticamente impossvel. Alguns
exemplos so JMeter e Webload. Elas so capazes de:
Simular um grande nmero de requisies e transaes
em paralelo. possvel definir o nmero de solicitaes ao
longo do tempo, assim como o padro de comportamento de
solicitaes;
Medir o tempo de resposta de solicitaes, como consultas e
relatrios. Alm do tempo de reposta, vrios outros parmetros podem ser medidos, como por exemplo, throughput (bytes
por segundo);
Medir a capacidade mxima do sistema, em termos de memria, CPU, swap etc.;
Identificar os gargalos (bottleneck) do sistema.
Este tipo de ferramenta exige grande capacidade analtica do
profissional de testes. Na maioria das vezes ele ir necessitar
da ajuda de vrios outros profissionais, como por exemplo,
especialistas em rede, em banco de dados e arquitetos e programadores. Aps a identificao do gargalo, quem realmente
ir atuar sero os especialistas.
A automao de testes no escopo do restante deste artigo
tratar apenas da execuo automatizada dos testes dinmicos,
mais especificamente, os testes funcionais.
Abordagens de Automao de Testes

Existem vrias abordagens para se automatizar a execuo
dos testes funcionais. Entretanto, na prtica, no so utilizadas
separadamente, mas sim de forma complementar.
Capture and replay (ou playback)
Nesta abordagem, os testes automatizados so baseados na
interface grfica da aplicao. Normalmente a ferramenta de
22
automao fornece um recurso para capturar (capture) as

aes do usurio enquanto o usurio estiver usando a aplicao. Essas aes so traduzidas para comandos na linguagem
de script suportada pela ferramenta de automao, para que
ento possam ser reproduzidas (playback) posteriormente.
Por exemplo, a ferramenta IBM Rational Funcional Tester gera
cdigo em Java. J a ferramenta Selenium, alm de Java, gera
tambm em .Net, entre outras.
A maioria das ferramentas permite ao usurio a utilizao
dessa abordagem. Historicamente, essa uma das caractersticas que tornou a automao de testes mais fcil e conhecida na rea, pois possui forte apelo visual. Toda a ao
do usurio, como por exemplo, cliques, digitaes etc. so
gravadas e reproduzidas. Logicamente, o automatizador
dever incluir pontos de verificao no script gerado.
A principal vantagem dessa abordagem a facilidade
e a rapidez para criao dos scripts de testes. Entretanto,
como desvantagem, possui forte dependncia quanto estabilidade da interface grfica, alm de possuir baixssima
reutilizao. Abaixo, apenas dois exemplos mostram que a
aplicao dessa abordagem puramente, no a soluo:
1. Se for necessrio testar, por exemplo, o cadastro de
100 formulrios, o testador ter que gravar 100 scripts
manualmente;
2. Se o campo Nome do Usurio mudar para Login, todas as referncias ao campo Nome do Usurio presentes
no script tero que ser localizadas e alteradas. E isto pode
ocorrer com vrios outros campos.
Data driven (orientado a dados)
Para resolver o principal problema da abordagem a cima,
surgiu a abordagem orientada a dados. Essa abordagem
nada mais que uma maneira de tornar os dados de entrada do playback variveis, ou seja, torna o script genrico.
Dessa forma, suficiente gravar apenas um script. Para
tornar o script genrico, basta substituir os dados gravados
por variveis. Para executar os 100 cadastros do exemplo,
basta pass-los como parmetro para o script que ser
executado.
Esta abordagem apresenta um grande avano, ganhando
bastante em produtividade e mobilidade em relao aos
dados a serem testados. Sua maior vantagem a reutilizao dos scripts. A j citada IBM Rational Funcional Tester
possui um mecanismo chamado Test Datapool que permite a
execuo orientada a dados. basicamente uma tabela que
armazena os dados variveis de um ou mais scripts. Cada
coluna da tabela mapeada para uma varivel dentro do
script. E a execuo do script ir se repetir enquanto houver
dados na tabela. Note que essa abordagem no substitui a
anterior, mas complementa.
API / Framework driven (orientado a API / Framework)
O seu objetivo a criao de uma infraestrutura que dar
suporte programao dos scripts de testes, aumentando
sua robustez, a facilidade de manuteno e a produtividade
no desenvolvimento. Esta infraestrutura nada mais que

um framework, ou um conjunto de bibliotecas de classes que
desempenham funes comuns a vrias aplicaes, ou dentro
de uma mesma aplicao. Por exemplo, classes que tratam da
leitura de arquivos textos, do acesso a banco de dados, que
so responsveis pelo logging dos scripts e pela gerao dos
resultados dos testes.
Esta abordagem bastante poderosa, e complementa as
demais j apresentadas. Quando o cdigo gerado em uma
linguagem com bons recursos, possvel fazer muitas coisas. Alm de funes de apoio, como a leitura de arquivos,
bibliotecas para tratamentos de cada tipo de componente
grfico podem ser criadas. Por exemplo, para o componente
tabela. possvel imaginar vrios atributos e mtodos
que podero ser necessrios para a realizao de testes. Por
exemplo, nmero de linhas, nmero de colunas, nomes das
colunas, valor de uma determinada clula x,y, somatrios
de valores etc. Tudo isso pode ser implementado. Basta
informar ao mtodo o identificador da tabela. Abaixo, um
exemplo da assinatura de um mtodo que retorna o valor
de uma clula:
String obterValorCelula(String idTabela, int x, int y);
Manipulao de datas, menus de acesso, paginao,

tratamento de javascripts, tudo isso pode estar presente
na biblioteca de testes. Porm, a criao de uma biblioteca
como essa deve ser planejada e, depois de implementada,
bem testada. A documentao da API tambm de fundamental importncia para o sucesso.
Com uma API bem definida para cada componente grfico,
a programao dos testes torna-se mais tranquila. Essa abordagem permite a reusabilidade e facilita o aprendizado dos
analistas de testes, pois no necessitam reinventar a roda.
Aumentam tambm a velocidade de programao dos testes, e
a confiabilidade do script final. Com ela, a utilizao da abordagem capture and replay reduzida bastante, resumindo-se
apenas obteno da identificao dos componentes atravs
do recurso capture.
Keyword driven (orientado a palavras chave)
Nesta abordagem, a ferramenta de automao oferece um
conjunto pr-definido de palavras-chaves para a montagem
dos testes. Cada palavra-chave um comando em alto nvel
(praticamente em linguagem nativa) que representa uma ao
do usurio. Dessa forma, os testes so facilmente entendidos
(e at escritos) pelos usurios finais em virtude do alto nvel
de abstrao.
Essa abordagem separa o trabalho de programao de baixo
nvel da montagem dos scripts de testes. Cada palavra-chave
possui por trs um procedimento implementado. Isso permite
que o script (neste contexto, uma sequncia de palavraschaves), seja de fcil criao e tambm de manuteno.
Tipicamente, as palavras-chaves descrevem aes realizadas
no sistema, como por exemplo, Logar, Acessar, Cadastrar, Remover etc. Normalmente, cada palavra-chave pode
ser seguida por um ou mais parmetros, ou uma lista deles,

por exemplo:
Logar, dlages, senha123
Acessar, Cadastro Cliente
Cadastrar, Diego Souza, 25, Rua Alameda das Accias, 35, BH, MG
Voltar
Pesquisar, Diego Souza
Verificar, Diego Souza
Deslogar
Cuidados
Neste item, que o propsito do artigo, so apresentados 10

cuidados que devem ser levados em considerao na aplicao
da automao de testes. Esses cuidados so baseados em diversos artigos sobre a automao de testes, citados na bibliografia,
alm da experincia do autor.
1. O teste automtico funcional s vale a pena se repetido
vrias vezes. Exceto para casos onde clculos monstruosos
so realizados, ou grandes volumes de carga so carregadas,
pode-se se dar ao luxo de repeti-lo poucas vezes. Fora isso,
no indicado, pois o custo de se automatizar no ser pago.
De acordo com vrios artigos da rea, a automao de testes
pode consumir at 10 vezes mais tempo em etapas como planejar, criar, documentar e executar, em comparao a um teste
executado manualmente. Portanto, no automatize testes que
voc raramente executa. O cenrio ideal para aplic-lo para
sistemas que necessitam de frequentes testes de regresso.
Portanto, antes de pensar em automatizar, deve-se ter certeza
de que a situao ir exigir vrias execues automticas.
2. A automao de testes exige profissionais bastante qualificados, pois automatizar exige programao de mdio para
alto nvel, principalmente se as abordagens API / Framework
driven e/ou Keyword driven forem utilizadas. Este tipo de programao exige ateno a detalhes relacionados disciplina
de testes, que se no forem levados em considerao, podero
inviabilizar os testes e ou mascarar os seus resultados. uma
programao bem diferente da programao que constri um
sistema. Portanto, a experincia dos profissionais um fator
fundamental para a qualidade dos cdigos gerados e afeta
diretamente a preciso na deteco de falhas. Programadores
inexperientes testam seus prprios limites, ou tentam ir alm
de suas reais habilidades, comprometendo o desempenho da
atividade.
3. No indicado automatizar os testes muito cedo dentro
do processo. O sistema a ser testado dever possuir certa
estabilidade. Em sistemas muito instveis, ainda em desenvolvimento, mudanas ocorrem frequentemente sejam por
correes, alteraes de requisitos ou melhorias. A incluso
de um novo campinho e melhorias na interface do usurio
so exemplos comuns. fato que isso ocorre com muita frequncia durante o desenvolvimento. A cada alterao, os scripts
de testes tambm devero ser alterados, sendo assim, sero
duas manutenes em cdigo, dois testes, dois novos pacotes
gerados, ou seja, atividades duplicadas.
A execuo automtica, depois de implementada, realmente
mais barata. Entretanto, mais caro criar e manter os scripts
de teste. Se existir muita manuteno, no vale a pena. Dessa
23
forma, devem-se automatizar apenas os mdulos e funcionalidades j estveis para que sejam retestados sempre que
uma nova verso for gerada ou uma nova funcionalidade for
integrada ao sistema. Como j esto estveis, diminui-se a
frequncia de manuteno. Portanto, assegure-se que a maturidade do sistema j se encontre em um estgio em que h
uma minimizao de manuteno dos scripts de testes.
Alm do cenrio de teste de regresso j citado, ideal para
um projeto com entregas incrementais. Aps uma entrega homologada, os testes dessa parte do sistema so automatizados.
Antes da prxima entrega, executam-se os testes automticos
para verificar se a primeira parte j homologada no sofreu
nenhum impacto colateral. Automatizar o sistema ao mesmo
tempo em que desenvolvido no vivel.
4. A execuo dos testes automticos no substitui a execuo dos testes manuais. Eles se complementam. Talvez essa
seja a maior falha das pessoas leigas a respeito da automao
de testes!
Adotando apenas os testes automticos a qualidade dos testes
cai consideravelmente, pois se perde a criatividade e percepo
humana na execuo manual. Os testes automticos testam apenas aquilo que foi programado para ser testado. Qualquer outra
alterao e variao no software testado no so percebidas por
ele. Normalmente, na execuo manual guiada por um caso de
testes escrito, muitas falhas perifricas ao objetivo principal
do caso de teste so encontradas, devido, principalmente, capacidade analtica e a curiosidade do testador. E isso perdido
se apenas forem executados testes automticos. Alm disso, esse
efeito negativo ampliado se o responsvel pelo script no tiver
experincia em testes, pois como no pensa como um testador,
no ir conseguir traduzir para o seu script as boas ideias.
5. invivel automatizar todos os testes. Isto se deve a dois
fatores principais. O primeiro o custo, que seria muito alto.
No existe projeto que se daria ao luxo de automatizar tudo que
um testador normalmente testa de forma manual. Normalmente
se automatiza o fluxo principal e os mais importantes fluxos
alternativos. Algumas mensagens ao usurio (erros, alertas e
informaes) e regras de negcios (principalmente clculos)
tambm so comumente automatizadas. Justamente o necessrio para um teste de regresso, como dito anteriormente.
O segundo fator devido a restries de tecnologia. Por
exemplo, testar valores apresentados em grficos na forma de
imagens, aplicativos em flash, ou layouts de relatrios em PDF.
Alguns podem at dizer ser possvel, mas no vale a pena.
6. A automao aumenta a probabilidade de falha nos testes,
pois a falha pode estar no prprio script de automao. Dessa
forma deve-se ter rigor ao criar os scripts de testes, para evitar:
Falsos negativos: Os testes automticos acusam falhas no
sistema, mas na verdade no existe falha alguma;
Falsos positivos: Os testes omitem falhas que existem no
sistema.
O primeiro caso menos problemtico, pois como a falha
acusada, torna-se possvel verificar que realmente no uma
falha, e o script pode ser corrigido a tempo. No segundo, a
24
Figura 1. Relao entre esforo de criao e manuteno
falha provavelmente s ser identificada na homologao do

sistema ou aps a entrada em produo.
7. Os testes automticos necessitam de interveno manual
para anlise dos resultados. Assegure que os resultados dos
testes automatizados sejam de fcil interpretao e sempre
sejam avaliados. No registre falhas antes de ter a certeza que
a falha realmente vlida, para evitar que o desenvolvedor
perca o seu tempo descobrindo uma falha nos testes automticos. Resumindo, por mais que os testes sejam realizados
automaticamente, essa atividade exige que profissionais de
testes analisem e controlem sua execuo.
8. O script de testes ir servir como uma documentao do
sistema. Apesar de no ser completo, pois no se automatiza
tudo, pode ser mais preciso que as especificaes textuais,
pois definem claramente o resultado esperado de cada ao,
ou seja, estabelece claramente o critrio de aceitao de cada
funcionalidade.
9. Existe um compromisso entre o esforo de criao dos
scripts de testes versus a manuteno desses scripts. Por
exemplo, caso se aplique a abordagem API / Framework Driven
ou Keyword Driven, que exige maior esforo na criao dos
scripts, o custo da manuteno futura ser menor, uma vez que
o cdigo est bem organizado e estruturado. Caso contrrio, a
aplicao da abordagem Capture and Replay puramente, exige
pequeno esforo de criao, mas alto esforo de manuteno.
A Figura 1 representa essa relao.
10. A automao de testes deve ser vista como um investimento de longo prazo. Suas vantagens no podero ser obtidas
em curto prazo, ou seja, no so imediatas. Ela possui um
custo inicial considervel, devido sua curva de aprendizado
e tambm pela construo da estrutura inicial. Alm disso, h
a necessidade de que os cdigos criados estejam maduros e
previamente testados para serem utilizados. Portanto, apenas
aps isso, todos os seus benefcios reais sero atingidos.
Concluso
A ideia que deve ficar clara na cabea de todos que s vale
a pena automatizar os testes se os mesmos forem executados
vrias vezes. No tem sentido automatizar os testes para
que sejam executados apenas uma, duas ou trs vezes, pois
o custo de automatizar um teste bem maior que realiz-lo
manualmente. Essa diferena depende do produto e da tcnica
utilizada. Dessa forma, o teste automtico s ser pago se
sobre e
s

Referncias
BACH, James; Test Automation Snake Oil - v2.1. Windows Tech Journal, 1996.
BOEHMER Bill; PATTERSON Bea; Software Test Automation Developing an Infrastructure
Designed for Success. Siemens Building Technologies, Inc. 1999.
CAMPOS, Fernando; NETO, N. Signorini; Pitfalls and Strategies in automated Testing, Instituto de
Pesquisas Tecnolgicas do Estado de So Paulo.
DAIGL, Matthias; The Road to Successful Test Automation - 10 Pitfalls Test Managers Should be
Aware of. Imbus AG, Moehrendorf, Germany, 2002.
FEWSTER, Mark; Common Mistakes in Test Automation. Grove Consultants Llandeilo, UK, 2001.
GARTNER, Magic Quadrant for Integrated Software Quality Suites, Gartner RAS Core Research
Note G00169077, Thomas E. Murphy, 31 July 2009.
Feedback
eu
edio
ta
D
s
ele for executado muitas vezes. Alguns estudos dizem que se

os testes automticos forem executados em torno de 10 vezes
j se tornam viveis.
A automao dos testes uma tima ideia para os testes de
regresso. Contudo, para garantir seu investimento pense
primeiro em testar e depois em automatizar. Ou seja, primeiro
tenha um processo de testes maduro. A automao no papel
ideal, mas tem que ser muito bem planejada, seno pode
trazer mais problemas do que solues, saindo mais caro do
que barateando os custos dos testes. Por ltimo, e talvez o
mais importante: testes automticos no eliminam os testes
manuais. Eles so complementares!
HENDRICKSON, Elisabeth; The Differences Between Test Automation Success and Failure, Quality
Tree Consulting, San Diego, CA: 1998.
MARICK, Brian; When Should a Test Be Automated? Testing Foundations, 1998.
KANER, Cem; Improving the Maintainability of Automated Test Suites. Quality Week, 1997.
25
Engenharia
Processo e automao de testes de Software

Trabalhando em ambiente de programao exploratria
Eliane Collins
elianecollins@gmail.com
Mestranda de Engenharia Eltrica pela Universidade Federal do Amazonas (UFAM),

MBA em Gerenciamento de Projetos,
Especialista em TV Digital e Bacharel em
Engenharia de Computao pela Universidade Estadual do Amazonas (UEA), 7 anos
atuando no desenvolvimento de Software,
desses, 4 anos em Teste de Software. Trabalha atualmente no Instituto Nokia de Tecnologia INdT, como Pesquisadora, onde
lidera uma equipe de teste de software e
desenvolve sistemas Web.
Luana Lobo
lulobaum@gmail.com
Atua no ramo de tecnologia e teste de

software, formanda no curso de Processamento de Dados na Universidade Estadual
do Amazonas (UEA). Trabalha atualmente
no Instituto Nokia de Tecnologia INdT, com
automao de teste nas plataformas WEB,
Data Warehouse e Desktop e desenvolvimento de sistemas na plataforma WEB.
26
ste artigo descreve a experincia

prtica de se adotar um processo
de teste utilizando ferramentas
abertas de automao para um ambiente
de programao exploratria, onde no
havia uma especificao detalhada do
sistema e as alteraes de escopo foram
constantes ao longo das entregas de
verses para o cliente. Nesse contexto,
veremos como adequar um ambiente de
desenvolvimento instvel como esse a um
processo de qualidade a fim de garantir
que o produto final seja entregue de acordo com as expectativas do cliente.
Programao Exploratria
A Programao Exploratria um tipo
de Modelo Evolucionrio de desenvolvimento de software o qual tem como base
desenvolver um sistema apresentando
as verses ao usurio, que far comentrios para o aprimoramento e modificaes at que o sistema seja considerado
adequado.
Engenharia de Software Magazine - Processo e automao de testes de Software
Neste artigo veremos a experincia prtica de

executar um processo de teste em um projeto
de software desenvolvido com base na Programao Exploratria, utilizando ferramentas para
automao de testes.
Para que serve?

Mostrar que atravs de ferramentas e tcnicas
adequadas realidade do ambiente do projeto,
possvel obter um nvel de qualidade aceitvel pelo
usurio, minimizando os problemas de documentao e a falta de especificao definida.

Com este artigo veremos que mesmo em situaes
em que h mudanas constantes de requisitos e
falta de documentao do sistema, as atividades
de teste podem ser eficazes desde que haja um
estudo de ferramentas que possam auxiliar na
melhor execuo dos testes e uma boa integrao
e cooperao da equipe de desenvolvimento.
A Figura 1 ilustra o processo do modelo

evolucionrio. Segundo esse processo,
inicialmente temos uma descrio
do sistema em alto nvel, mas no h
ainda um escopo definido. A partir da
descrio inicial desenvolvida a primeira verso do sistema

o mais rpido possvel. Em seguida ela submetida a uma
bateria de avaliaes do usurio. Com estas avaliaes, durante o desenvolvimento so geradas verses intermedirias
do sistema que vo evoluindo durante o processo at alcanar
a funcionalidade desejada.
Este um modelo usado principalmente em sistemas onde
difcil realizar especificao, sistemas de pequeno a mdio
porte, e em pesquisas para desenvolvimento de sistemas de
Inteligncia Artificial, por exemplo. Normalmente esse modelo
implementado por pequenas equipes de desenvolvimento.
As vantagens deste modelo de desenvolvimento so: o fornecimento mais rpido do sistema, o envolvimento do usurio
durante o desenvolvimento do projeto e a facilidade de adaptao a mudanas de requisitos, pois em alguns casos, a entrega
no prazo e a facilidade do uso podem ser consideradas mais
importantes do que detalhes de funcionalidade ou a facilidade
de manuteno em longo prazo [1].
Contexto do Ambiente Testado

O Instituto Nokia de Tecnologia (INdT) uma instituio independente e sem fins lucrativos comprometida com a realizao de
pesquisa e desenvolvimento de solues tecnolgicas atravs do
desenvolvimento de aplicaes, novas tecnologias e conceitos.
As principais reas do INdT so Software Livre e Interfaces de
Usurio, Tecnologias de Produto e Manufatura, Experincias em
Servios e Tecnologias de Rede.
A experincia foi desenvolvida pela rea de Tecnologias de
Produto e Manufatura, a partir de agora referenciada como PMT.
O projeto em questo contava com uma equipe de cinco colaboradores envolvidos no desenvolvimento do sistema. A metodologia
de desenvolvimento adotada foi a Programao Exploratria.
Pela natureza da metodologia de desenvolvimento empregada,
o ambiente de desenvolvimento e, consequentemente, o de teste,
iniciaram com incertezas e instabilidades que poderiam comprometer o sucesso do projeto. Resultados incorretos vindos de
um sistema desenvolvido sem documentao necessria podem
causar graves consequncias, tanto para o cliente quanto para a
empresa responsvel por desenvolver a soluo.
Caso a equipe de testes no consiga preparar adequadamente
os seus casos de teste porque a equipe de desenvolvimento no
documenta adequadamente os casos de uso, com certeza poder fazer com que defeitos no sejam detectados, resultando em
possveis problemas no negcio.
O projeto que serviu de base para este artigo, por questes de
confidencialidade, ser chamado de ProjetoSW. A principal caracterstica funcional deste projeto era que o sistema fosse capaz
de ler vrias planilhas, vindas de clientes (operadoras de telefonia
celular), referentes rea de logstica, gerando a partir delas alguns arquivos no formato .txt, de maneira que fossem carregados
em um outro sistema para as devidas anlises dos dados.
O ProjetoSW foi desenvolvido a partir da Plataforma Java
Swing. Era uma aplicao de pequeno porte, puramente local,
e no havia integrao alguma com qualquer servidor ou outro
aplicativo. A funo dele, inicialmente, era apenas gerar os
Figura 1. Modelo de Desenvolvimento Evolucionrio
arquivos necessrios em formato especificado. Nota-se que o

projeto foi concebido com uma srie de peculiaridades. Alm
destas, o processo de desenvolvimento ainda contava com o
seguinte cenrio:
Apenas dois analistas programadores foram alocados para
o desenvolvimento do sistema, sendo que um deles ainda
acumulava a funo de documentao do sistema;
Com a primeira verso entregue ao usurio, o desenvolvedor
responsvel pela documentao criou um Guia de Usurio.
Este guia era utilizado para ensinar o usurio final a utilizar
o Sistema. Com o passar das entregas este guia no foi sendo
atualizado com os novos requisitos funcionais;
O time de teste era composto apenas por uma analista de
teste para Planejamento e Execuo do Processo de Teste, e
uma testadora para Execuo e Automao;
O conhecimento das funcionalidades e requisitos do cliente
estavam concentrados em uma nica pessoa;
A documentao de requisitos foi gerada a partir de uma reunio feita com o desenvolvedor do sistema, que continha todo
o entendimento do processo do cliente, e a equipe de teste.
Processo de Testes
O processo de testes para o ProjetoSW foi organizado de
modo que as funcionalidades definidas pelo usurio a cada
verso do sistema pudessem ser atendidas, garantindo que
os aprimoramentos feitos no afetariam o funcionamento de
todo o sistema, ou seja, testes de regresso seriam atividades
essenciais. A cada liberao de verso, extra ou oficial, a equipe
de teste se comunicava com a equipe de desenvolvimento para
saber se requisitos anteriores tinham sido modificados e se tinham sido desenvolvidas novas funcionalidades. Isso era feito
pela falta de uma documentao de referncia do sistema.
Em paralelo implementao foi iniciado o planejamento das
atividades de teste onde foram definidos os recursos alocados,
mtricas, estratgia de teste, as ferramentas e os artefatos a serem usados para o projeto. As atividades de teste seriam feitas
por uma analista de teste responsvel pelo processo, anlise e
documentao e uma testadora responsvel por automatizar
os casos de teste. As ferramentas, todas opensource, escolhidas de acordo com a experincia da equipe e a plataforma do
projeto foram:
TestLink: ferramenta para gerenciamento do Plano de Teste.
Com ela possvel criar e gerenciar facilmente os Casos de
Teste e o ciclo de execuo do seu Plano de Teste;
27
Marathon: utilizada para automatizar testes funcionais;

Mantis: ferramenta utilizada para cadastro de defeitos
encontrados. Com ela possvel controlar o ciclo de bugtracking do sistema em desenvolvimento. Faz integrao com o
TestLink.
Automao dos testes funcionais utilizando o Marathon

Como falado anteriormente, o Marathon uma ferramenta Open
Source utilizada para automatizar testes funcionais (aceitao).
Ela testa aplicativos desenvolvidos na Plataforma Java Swing.
Para isso a ferramenta disponibiliza um ambiente integrado para
criao e execuo de scripts de teste. Estes scripts podem ser gravados em Jython ou JRuby. A verso utilizada no ProjetoSW foi a
2.0b4, que conta com vrias e importantes caractersticas, como:
Ambiente de desenvolvimento integrado. Com ele possvel
capturar, depurar e executar os testes automatizados;
Mdulos que podem ser reutilizados e que facilitam a
manuteno;
Propriedades chamadas de Fixtures (scripts em Jython cuja principal funo criar pr e ps-condies de execuo dos testes);
Gerao de relatrios de execuo, disponveis nos formatos
.xml e .html;
Dois recursos fundamentais chamados de Component Resolver
e Custom Component Resolver, utilizados para detectar os componentes da API Swing do Java. Isso inclui botes, campos de edio,
menus, etc., alm de detectar tambm os mtodos e propriedades
de todos os componentes;
Possibilidade de gerar os scripts automticos em JRuby ou
Jython.
Por trabalhar com a abordagem rec-and-play, possvel, a partir
do uso do Marathon, criar testes automatizados por meio da
captura das aes feitas na interface do sistema. Portanto, cliques
do mouse, digitao e outras aes que interajam com os componentes da aplicao so capturados pelo rob do Marathon e
convertidos em scripts Jython. Estes scripts sero posteriormente executados, garantindo a regresso de toda sute de testes
automatizada.
Por Jython ser uma implementao Java da linguagem de script
Python, o cdigo do Marathon pode ser customizado com o
uso de bibliotecas do Java. Essa foi uma das maiores vantagens
observadas ao utilizar esta ferramenta na automao dos testes
funcionais do ProjetoSW.
Um dos recursos do Java utilizados para os testes com o ProjetoSW foram as classes e mtodos da biblioteca AWT. Dentre
elas java.awt.Robot e java.awt.event.KeyEvent. Estas classes eram
utilizadas para validar requisitos que diziam que o usurio final
seria capaz de utilizar a aplicao sem o uso de mouse, apenas
interagindo com o teclado.
Automao dos testes funcionais do ProjetoSW

Para exemplificar o uso do Marathon, veja abaixo todas as
telas de configurao do projeto de teste utilizadas no ProjetoSW. Das vrias abas de configurao existentes, apenas
trs foram utilizadas neste projeto: Project, Main e Class Path.
28
Figura 2. Configuraes bsicas do projeto
Figura 3. Configuraes principais do Sistema a ser testado
A Figura 2 traz as configuraes da aba Project, onde possvel configurar o nome, diretrio, descrio e o tipo de script
do projeto de teste. Para o ProjetoSW, a linguagem de script
escolhida foi Jython.
A Figura 3 mostra a aba Main. nesta tela que as principais
configuraes do projeto a ser testado so informadas ao Marathon. Para o ProjetoSW a nica configurao necessria foi
a localizao da classe principal do projeto.
A Figura 4 mostra a aba Class Path. Nesta aba devem ser
acrescentados as libs e jar necessrios para a execuo da
aplicao. Observe que deve ser gerado um .jar do projeto
(7.0.2CPFRFileGenerator.jar) a ser testado. Este deve ser adicionado no classpath do projeto de teste. no classpath que
o Marathon vai buscar a classe principal informada na aba
Main.
Ao fazer todas as configuraes necessrias, o projeto salvo
e a interface grfica do Marathon exibida (Figura 5). Neste
momento um arquivo chamado defaul.py criado automaticamente para o projeto. Trata-se de uma fixture, um recurso do
Listagem 1. Exemplo simples de navegao utilizando a classe ROBOT da API AWT
Figura 4. Tela de Class Path, adicionando libs
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
#{{{ Marathon Fixture

from default import *
#}}} Marathon Fixture
from java.awt import AWTException
from java.awt import Robot
from java.awt.event import KeyEvent
def test():
java_recorded_version = 1.6.0_10
robot = Robot();
if window(CPFR File Generator):
assert_p(TextField, Text, )
sleep(1)
robot.keyPress(KeyEvent.VK_TAB)
sleep(1)
# Escolher operadora um
for i in range(0, 1):
r obot.keyPress(KeyEvent.VK_DOWN)
r obot.keyRelease(KeyEvent.VK_DOWN)
c lose()
close()
sleep(1)
robot.keyPress(KeyEvent.VK_ENTER)
robot.keyRelease(KeyEvent.VK_ENTER)
sleep(1)
assert_p(ComboBox, Operadora1)
close()
Figura 6. Tela principal

Figura 5. Tela principal do Marathon
Marathon que fornece uma interface para o testador executar

passos, como abrir algum arquivo, limpar a base de dados
ou iniciar a aplicao que ser testada, por exemplo, antes
de iniciar a execuo de algum teste individual. O defaul.py
fornece uma interface para inicializao da aplicao para o
ambiente de teste. As fixtures so utilizadas para garantir que
o mesmo ambiente de configurao exista para a execuo de
cada caso de teste.
Na Listagem 1, h um exemplo simples de navegao pela
interface do aplicativo com o uso da API Java no cdigo do caso
de teste feito no Marathon. Observe as chamadas aos mtodos da
classe Robot da API AWT feitas atravs da linguagem Jython.
Como exemplo da tela principal do ProjetoSW, observe a
Figura 6. O script da Listagem 1 executa a ao de selecionar
um cliente no combobox (linhas 20 a 25), para que as prximas
aes, Import, Mapping, Export, Backup e Generate XLS, possam ser
realizadas. Ao selecionar este cliente, o sistema redirecionado
para a tela de Import, conforme a Figura 7. A linha 30 do script
certifica-se de que o cliente selecionado na tela principal o que
aparece selecionado na tela de Import.
A tela de exemplo que chamamos de Import (Figura 7) possui a
funcionalidade de fazer o upload das planilhas do cliente selecionado, para que as informaes sejam processadas e exportadas
Figura 7. Tela de Import
em formato .txt. Na tabela da tela de Import (Figura 7), a coluna

File indica o caminho do arquivo .xls, e a coluna Type indica a
informao que deve ser extrada da planilha.
Importar planilhas (Tela de Import), fazer processamento em
cima dos dados e do mapeamento escolhido (Tela de Mapping),
e exportar estas informaes em arquivos de texto (Tela de
Export) so as funcionalidades principais do ProjetoSW. Como
falado anteriormente, com a Listagem 1 possvel chegar tela
de Import da aplicao. A Listagem 2 d um exemplo de como
importar os arquivos.
As linhas 15 a 18 so as linhas para escolher o cliente Operadora1. A diferena desta ao que nesta listagem o script
29
simula a ao de escolher o cliente como se o usurio estivesse

usando o mouse. A Listagem 1 simula como se o usurio
estivesse escolhendo o cliente com o teclado, com o uso da
API Java.
As linhas 21 a 26 representam a escolha dos arquivos a serem
importados. A linha 28 coloca o cursor do mouse na coluna
Type da tabela, simulando um evento feito pelo teclado, para
que o mapeamento seja feito. A linha 29 libera o uso da tecla
TAB. Nas linhas 31 a 36 ocorre um tipo de mapeamento, onde o
usurio diz ao aplicativo qual informao deve ser importada
da planilha associada. As linhas 38 a 40 so as responsveis
por clicar no boto Import da tela. Por fim, as linhas 42 a
44 servem para clicar no boto OK da tela de confirmao
exibida pelo aplicativo.
O ciclo da funcionalidade de Import termina com esta listagem. Agora seguindo a especificao do sistema, os dados
importados devem ser mapeados e exportados em arquivos de
texto. A Listagem 3 d um exemplo de como o mapeamento
destas informaes feito. Para ilustrar, a Figura 8 mostra a tela
de mapeamento com alguns dados j importados e algum mapeamento feito. Os dados contidos na coluna Costumer Product
Name so carregados na importao das planilhas. A coluna
Costumer Product Code preenchida pelo usurio do sistema.
o usurio quem faz manualmente o mapeamento dos dados
importados na primeira coluna. Este mapeamento precisa ser
feito para que os arquivos sejam gerados. Se o mapeamento
estiver vazio, os arquivos sero gerados sem contedo.
Como na listagem anterior estvamos na tela de Import, a
Listagem 3 comea o script informando ao Marathon que ele
deve iniciar a execuo pela tela de Mapping (linhas 51 e 52).
As linhas 54 a 60 so as responsveis por fazer o mapeamento. Com estes comandos o Marathon acrescenta as strings no
campo de mapeamento (Figura 8).
Com o mapeamento feito, o ProjetoSW est pronto para
exportar os dados no formato de arquivo de texto. A Figura 9
mostra a tela de exemplo chamada Export. Aqui possvel escolher o local para onde os arquivos sero exportados. A tabela
existente na tela mostra os ltimos arquivos importados para
aquele cliente e o mapeamento feito na tela de Import. Estes
dados so carregados automaticamente aps a importao. O
usurio no precisa informar nada nessa tabela.
A nica ao nesta tela escolher a pasta para onde os
arquivos sero exportados. isso o que faz a Listagem 4. A
linha 71 serve para levar o Marathon tela de Export. A linha
72 simula um clique na opo Select Folder. As linhas 74 a 76
escolhem a pasta desejada, no caso do script, a pasta Desktop.
A linha 78 simula um clique no boto Export. Aps a exportao dos dados, o ciclo bsico de acordo com a especificao
do Sistema est concludo. Todos estes passos foram gerados
automaticamente pelo Marathon a partir da navegao feita
na aplicao pelo testador.
Listagem 2. Importando Planilhas

01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
#{{{ Marathon Fixture

from default import *
#}}} Marathon Fixture
from java.awt import AWTException
from java.awt import Robot
from java.awt.event import KeyEvent
# Test Case ID 711 :: Version: 1
# Import Operadora1
def test():
java_recorded_version = 1.6.0_10
select(ComboBox, Operadora1)
click(bot_folder_normal2)
close()
# Escolhendo os Arquivos com mouse
if window(Open):
select(FileChooser, C:/MarathonTestes/Planilhas/op1/File1.xls;
C:/MarathonTestes/Planilhas/op1/File2.xls;
C:/MarathonTestes/Planilhas/op1/File3.xls;
C:/MarathonTestes/Planilhas/op1/File4.xls)
close()
robot.keyPress(KeyEvent.VK_TAB)
robot.keyRelease(KeyEvent.VK_TAB)
i f window(CPFR File Generator):
c lick(Table, {+ str(i) + , Type})
s leep(1)
close()
close()
if window(Information Message):
c lick(bot_import_normal2) # clicar no boto Import
close()
if window(Information Message): # confirmao de Importao
click(OK)
close()
# {{{
#
Continua na prxima listagem
# }}}
Listagem 3. Mapeando os dados

48.
49.
50.
50.
51.
52.
53.
54
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
# {{{
#
Continuao
# }}}
select(mapping_main2, true)

doubleclick(Table+str(i+1), {+ str(i) +, Customer Product Code})
sleep(1)
select(Table+str(i+1), map, {+ str(i) +, Customer Product Code})
close() # end if
close() # end for
close() # end if
# {{{
#
Continua na prxima listagem
# }}}
Ciclo de execuo dos Ttstes

Segundo o processo de teste em uso no PMT, os artefatos
principais que devem ser gerados pela equipe de teste so:
30
Figura 8. Tela de Mapping
Listagem 4. Exportando os dados

66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
# {{{
#
Continuao
# }}}
i f window(CPFR File Generator):
s elect(export_main2, true)
c lick(bot_folder_normal21)
i f window(Open):
s elect(FileChooser, C:/Users/llobao/Desktop)
c lose()
c lick(bot_export_normal2)
i f window(Message):
c lick(OK)
c lose()
close()
# {{{
#
Fim
# }}}
Figura 10. Exemplo de Caso de Teste
Figura 11. Execuo no TestLink

Figura 9. Tela de Export
Plano de Teste, Especificao de Casos de Teste, Relatrio

de Execuo de Casos de Teste e Relatrio de defeitos. Essas
definies se deram pela variedade de projetos e processos de
desenvolvimento existentes no grupo.
Como estratgia para execuo do Processo de Teste de forma
efetiva, definimos um conjunto de atividades de teste a serem
executadas a cada liberao de verso do sistema:
1. A primeira a fazer especificar no TestLink (Figura 10) os
casos de teste em alto nvel de acordo com os comentrios e as
descries feitas pelos usurios. Se houver alguma mudana
de requisito, os casos de teste no TestLink precisam ser atualizados. Como no existiu documento formal de especificao
de caso de uso, a descrio dos casos de teste foi feita atravs
dos comentrios do usurio;
2. Aps a especificao, os casos de teste das funcionalidades
fechadas eram automatizados pela testadora. Era ento utilizada a ferramenta Marathon para automatizar e gerar scripts
de teste;
3. Aps a especificao e automao dos casos de teste, os
testes de verificao j estavam prontos para serem feitos. A
execuo destes testes era feita no Marathon. Como os relatrios de teste eram feitos com o auxlio do TestLink, a execuo
dos casos de teste precisava ser feita, tambm, no TestLink
(Figura 11). Os defeitos quando encontrados eram registrados
na ferramenta Mantis. Com o Mantis possvel direcionar o
erro ao desenvolvedor e informar a severidade do erro, dentre
outras funcionalidades;
4. Dependendo do nmero de defeitos encontrados, eles eram

priorizados e corrigidos pela equipe de desenvolvimento que
atualizava o estado do defeito no Mantis. Quando as correes
eram validadas, a suite automtica de testes era executada realizando a regresso para garantir que outra parte do sistema
no foi afetada pelas alteraes do cdigo. A probabilidade de
introduo de um erro durante a alterao do software, por
alguma manuteno ou processo iterativo de desenvolvimento,
por exemplo, est entre 50% a 80%. Por isso muitos bugs foram
encontrados nestas etapas de regresso. Isto diminuiu o tempo
de execuo destes testes e o esforo de execuo da testadora.
Porm, como os requisitos funcionais estavam sujeitos a mudanas entre uma release e outra, alguns scripts, no decorrer
do ciclo, tiveram que ser reescritos;
5. Com a verso entregue para teste, o relatrio de defeitos e
melhorias de usabilidade cadastrados no Mantis era entregue
a toda equipe do projeto (Figura 12).
Alm de todas estas prticas feitas para garantir a qualidade
de cada verso, ainda eram feitos Testes Exploratrios. Estes
testes eram executados manualmente no sistema, para assim
obter as impresses quanto usabilidade, performance, e
algum comportamento que o script no alcanaria. Este tipo
de teste foi de extrema importncia, pois com ele foi possvel
encontrar bugs crticos de funcionalidade. Na Figura 13 h
um exemplo de defeito que fazia com que o banco de dados
da aplicao fosse zerado aps a operao de backup. Ento
toda ao de exportao feita, aps a gerao de um backup,
trazia arquivos sem dados.
31
Figura 14. Modelo Evolucionrio com o Processo de Teste

Figura 12. Relatrio de Execuo
Figura 13. Defeito encontrado atravs de Testes Exploratrios
Vale ressaltar que as atividades de teste comearam a ser

feitas a partir da segunda verso do sistema, quando a equipe julgou que o sistema e as funcionalidades implementadas
estavam maduras para receber a primeira carga de testes.
Resultados obtidos
Com a adio do processo de testes, foi observado no decorrer
do projeto ganhos, primeiramente, no sentido de aumentar
a segurana da equipe e do cliente, alm de assegurar que o
que foi desenvolvido estava funcionando corretamente e em
conformidade com o que havia sido solicitado.
Atravs da automao de testes ganhamos tempo na execuo
conseguindo cobrir 100% das funcionalidades solicitadas pelo
cliente e ainda realizar testes exploratrios visando usabilidade da interface. No entanto, vale destacar que no decorrer
do projeto, com as vrias mudanas nos requisitos funcionais,
muitos scripts tiveram que ser reescritos.
Mesmo com a necessria atualizao dos scripts de teste,
a prtica no prejudicou a equipe e nem o teste das novas
verses. Isso ocorreu pelo fato da regresso ser maior para
scripts de funcionalidades j estveis. Com o ganho do tempo
na execuo da regresso destes scripts estveis, foi possvel
utilizar o tempo restante para corrigir e/ou criar scripts para
funcionalidades ainda em fechamento.
32
Atravs da adoo de ferramentas para a especificao

de teste e execuo, houve ganho de tempo tanto para
gerar relatrios quanto para automatizar mais casos de
teste. Com a ferramenta Marathon, que utiliza scripts na
linguagem Jython, foi possvel complementar e otimizar
testes automticos usando APIs Java de leitura de arquivos, para facilitar os testes de comparao de dados, e
de simulao de perifricos, para simular navegao via
teclado na aplicao.
As caractersticas da metodologia empregada no projeto
permitiram que a equipe de testes adequasse um Processo
de Teste ao modelo evolucionrio de Programao Exploratria. O processo de desenvolvimento adaptado est
disponvel na Figura 14, onde pode ser observado que o
Processo de Testes era executado a cada liberao de verso
intermediria. Com isso, o usurio pde ver a qualidade
das verses e sugerir melhorias e novas funcionalidades
para a equipe de desenvolvimento.
Esta prtica possibilitou que a equipe adquirisse conhecimento tanto em ferramentas quanto em processo
de teste, tornando vivel a execuo deste processo nos
projetos posteriores.
Concluso
Neste artigo foi mostrado um processo de teste adequado
a um projeto de software desenvolvido a partir da Programao Exploratria. Isso precisava ser feito para que fosse
possvel atingir um nvel mnimo de qualidade. Um dos
mais importantes ajustes foi a deciso de automatizar as
atividades de teste. Portanto, o planejamento do Processo
de Teste e a Execuo dos seus ciclos foram automatizados,
o que garantiu a otimizao no tempo da equipe de teste
na execuo de todo o processo.
Outra adequao feita foi sobre o conceito de verso
intermediria existente na Programao Exploratria. Atividades do Processo de Teste foram feitas nessas verses,
o que possibilitou o amadurecimento e estabilidade do
sistema. Isso facilitou a identificao de muitos defeitos
atravs da regresso automtica e dos testes exploratrios,
fazendo com que a cada entrega a verso final ficasse mais
estvel.
Com a mudana de requisitos do Projeto de Software,
tambm previsto na Programao Exploratria, houve uma

Feedback
eu
edio
ta
D
s
desenvolvimento. Esse conhecimento trouxe mais segurana

equipe de teste, que se sente apta a rodar seu Processo em Projetos
posteriores na empresa, como vem sendo feito atualmente.
Referncias
Sommerville, I., Engenharia de Software, 6 edio, 2004
Silva, D., Alves, R., Pimentel, R., Uma Anlise Das Recomendaes dos Nveis G e F do MPS.BR para
a Implemnetao do Programa de Qualidade, 2008.
http://www.cci.unama.br/margalho/portaltcc/tcc20081s/pdf/tfg1032008.pdf
TestLink Documentation.TEAMST - Home of TestLink developers Community - http://www.teamst.org/
Madalena, M., Pachecho, R., Uma metodologia para o desenvolvimento de sistemas de descoberta
de conhecimento, Maring, v. 27, n. 1, p. 61-72, Jan./June, 2005
http://periodicos.uem.br/ojs/index.php/ActaSciTechnol/article/viewFile/1500/857
Rios, E., Usando o MPS.BR para amadurecimento das equipes de teste de software - http://
www.iteste.com.br/Portals/0/Avaliando%20o%20n%C3%ADvel%20de%20maturidade%20das%20
equipes%20de%20teste%20de%20software%20usando%20o%20modelo%20MPS%20v%204.pdf
Java Documentation - http://java.sun.com/javase/reference/api.jsp

Jython User Guide http://wiki.python.org/jython/UserGuide
Caetano, C., Automao e Gerenciamento de Testes - Aumentando a Produtividade com as
Principais Solues Open Source e Gratuitas, 2007
Marathon User Guide 2.0b4. Marathon Integrated Testing Environment
http://www.marathontesting.com/Home.html
Rios, E., Anlise de Riscos em Teste de Software - http://www.iteste.com.br/Portals/0/Microsoft%20

Word%20-%20An%C3%A1lise%20de%20Riscos%20em%20Teste%20de%20Software%20
reduzido.pdf
Sousa, F., Modelos de Ciclo de Vida de Desenvolvimento de software - http://www.fabriciosousa.
com/ESI_Modelo_Ciclo_Vida.pdf
Hetzel, W., The Complete Guide to Software Testing, QED Information Sciences, Wellesley, Mass.,
1984.
Mantis BT Documentation - http://www.mantisbt.org/
33
sobre e
s
maior atualizao de scripts de teste. Portanto, mesmo com

a otimizao do tempo gasto em execuo de testes, houve
uma perda de tempo atualizando scripts obsoletos.
Contudo, a experincia em adequar um Processo de Teste
mostrou bons resultados na execuo de todo o Processo de
Software. Isto permitiu que a equipe de testes adquirisse
conhecimento em ferramentas de teste, alm de motivar a
pesquisa de novas ferramentas de automao que atendam
a outras plataformas de desenvolvimento.
Outro ponto importante foi o aprendizado em customizao
de Processo de Teste seguindo uma metodologia especfica de
Engenharia
Qualidade de Software
Desvendando um requisito essencial no processo de desenvolvimento
Lenildo Morais
lenildojmorais@gmail.com
analista de sistemas e analista de testes.

Atualmente est cursando mestrado no
centro de informtica da UFPE em engenharia de software com nfase em testes
e qualidade de software.
34
conceito da qualidade tem hoje

importncia fundamental para
alavancar a competitividade
das empresas. Atualmente, a preocupao com a qualidade deixou de ser um
diferencial competitivo e passou a ser
um pr-requisito bsico para participao no mercado. No setor de software
no diferente. A disseminao do uso
do software em todas as reas, envolvendo monitorao, controle e gesto
de funes crticas, tem aumentado
consideravelmente a importncia da
qualidade de software.
Qualidade hoje em dia no apenas
um diferencial de mercado para a empresa conseguir vender e lucrar mais,
um pr-requisito que a empresa deve
conquistar para conseguir colocar seu
produto no mercado global. Apesar da
ideia de qualidade parecer aparentemente intuitiva, quando analisada com maior
ateno, o conceito se revela um pouco
mais complexo.
Na medida em que cresce a demanda
por sistemas complexos, com grande
Engenharia de Software Magazine - Qualidade de Software
Demonstrar, atravs de uma viso geral, como os

aspectos inerentes qualidade de software podem
contribuir para a competitividade e produtividade.
Voc conhecer os conceitos, caractersticas, pontos
positivos e negativos referentes ao processo de
Para que serve?

Proporcionar aos desenvolvedores e consumidores
de software maior conhecimento sobre a qualidade, uma vez que grande parte dos projetos de desenvolvimento ainda precisa evoluir neste aspecto.

Nos projetos de desenvolvimento de software,
que adotam polticas de qualidade, sobretudo
quando se deseja buscar mercados externos ou
expandir seus clientes internos aumentando a
satisfao dos mesmos.
responsabilidade no contexto das organizaes, a qualidade desponta como

um fator essencial no desenvolvimento
de software, e cada vez mais h uma disposio de investimento nesta rea. Entretanto, uma das primeiras dificuldades
encontradas na definio e implantao
ENGENHARIA DE SOFT WARE
de um programa de qualidade est em compreender o que, de

fato, significa qualidade de software.
Visando apoiar um maior entendimento a respeito do assunto, este artigo apresenta o conceito de qualidade de software,
abordando aspectos como a importncia dos requisitos neste
processo assim como uma viso geral sobre medio e avaliao da qualidade.
Qualidade de Software
Conceituar qualidade de fato uma tarefa complexa, mas
ela pode ser vista como um mtodo gerencial que atravs de
procedimentos disseminados por toda a organizao, busca
garantir um produto final que satisfaa s expectativas do
cliente, dentro daquilo que foi acordado inicialmente.
No contexto de desenvolvimento de software, qualidade pode
ser entendida como um conjunto de caractersticas a serem
satisfeitas, de modo que o produto de software atenda s necessidades de seus usurios. Entretanto, tal nvel de satisfao nem
sempre alcanado de forma espontnea, devendo ser continuamente construdo. Assim, a qualidade do produto depende
fortemente do seu respectivo processo de desenvolvimento.
Devido ao processo de globalizao e consequente aumento
de empresas concorrentes, a qualidade, hoje em dia, crtica
para a sobrevivncia e o sucesso no mercado de software.
Portanto, uma organizao no se destacar neste mercado
a menos que produza software de boa qualidade e que seus
clientes percebam isso nos seus produtos e servios. Neste
contexto, h algumas razes que devem ser consideradas:
Qualidade competitividade: Uma forma do produto se
destacar atravs da qualidade do software e do suporte que
fornecido com ele. Com o amadurecimento do mercado,
os usurios no querem apenas que a empresa fale que tem
qualidade, mas que mostre a todos que a tem atravs de certificao internacional. No ter uma certificao pode acarretar
em desvantagem competitiva;
Qualidade essencial para a sobrevivncia: Clientes esto
buscando por qualidade. Se a empresa no tiver habilidade de
sobreviver em um mercado altamente competitivo, ela est em
dbito com o mercado. A maioria das grandes organizaes
est reduzindo o nmero de fornecedores, e um meio de escolher os fornecedores verificando quais deles tm certificaes
de qualidade;
Qualidade essencial para o mercado internacional: O
mercado de software est cada vez mais se expandindo, se
tornando global. A habilidade das empresas de mostrar qualidade possibilita sua colocao no mercado;
Qualidade custo/benefcio: Um sistema de qualidade
direciona para o aumento da produtividade e permanente
reduo de custos, dando nfase preveno de inconsistncias no desenvolvimento e, consequentemente, de defeitos.
A maior parte das empresas sabe que corrigir defeitos aps
o desenvolvimento do software mais dispendioso do que
identific-los e corrigi-los antes;
Qualidade retm consumidores e aumenta lucros: Pouca qualidade normalmente custa muito mais. A maioria dos clientes no
tolera falta de qualidade, e caso isso ocorra procuram por outros

desenvolvedores. A preocupao com a qualidade aumenta a
satisfao dos clientes e assegura os que j so por mais tempo.
Os consumidores de software necessitam de produtos cada
vez melhores e mais rpidos de serem desenvolvidos para
aumentarem a sua competitividade no mercado. Para que este
objetivo seja cumprido, os fornecedores de software devem
utilizar as melhores prticas da engenharia de software, corrigindo os defeitos assim que forem detectados.
Infelizmente, ainda h empresas fornecedoras de software que
acham que criar sistemas uma arte que no necessita seguir regras, normas ou padres. Isto acontece principalmente por que:
Produtos de software so complexos, at mais do que o hardware onde executam;
Software no tem produo em srie. Seu custo est no projeto
e desenvolvimento;
A engenharia de software ainda no est madura, um
processo em constante evoluo;
No h um acordo entre os profissionais da rea sobre o que
Apesar de tudo isso, preciso entender que o problema no
est no software em si, mas na forma como as pessoas tm
desenvolvido software. de fundamental importncia que as
equipes de desenvolvimento tenham a contnua ateno com a
aplicao dos conceitos de qualidade em seus projetos.
Atualmente, muitas instituies tm se preocupado em criar
normas para permitir o desenvolvimento de softwares de qualidade. A Tabela 1 apresenta uma viso geral com as principais
normas nacionais e internacionais nesta rea.
Qualidade de Software na Viso do Usurio

Os desenvolvedores no devem menosprezar o papel do
cliente no desenvolvimento do software. Cada cliente pode
ter desejos e necessidades diferentes em relao ao mesmo
tipo de produto. A questo como melhor atender aos seus
interesses. Eles esto mais interessados no uso do sistema, na
sua funcionalidade, no desempenho e nos efeitos que o mesmo
pode produzir na sua empresa. O cliente valoriza cada vez
mais que o software seja um parceiro no desenvolvimento de
seu negcio, de forma que suas expectativas sejam atendidas
e sua confiana no produto aumente.
importante considerar que o cliente quem est frente.
Ele tem o direito de participar e opinar durante o processo de
construo do software. Hoje o mercado mais competitivo,
aumentando a oferta de produtos, e o cliente est mais consciente de sua participao.
Neste contexto, a experincia do usurio, alm das qualidades tcnicas do software, um fator determinante para a
construo de sistemas de maior qualidade. Sua participao
pode facilitar a compreenso dos seus desejos quanto ao software que est sendo desenvolvido. Esse aspecto da qualidade
do software chamado usabilidade. Nele o usurio procura
respostas para questes como:
35
As funcionalidades esto disponveis e so executadas

eficientemente?
O software funciona corretamente em imprevistos?
O software seguro, ou seja, evita que pessoas ou sistemas
no autorizados tenham acesso s informaes?
fcil de usar ou requer muito treinamento?
fcil de integrar com outros sistemas existentes?
No h como esquecer que agora o cliente quem est na
direo, tem poder de barganha. J foi o tempo em que o sucesso empresarial se devia aos clientes no terem outra opo.
Hoje o mercado mais competitivo, a globalizao expandiu
o mercado aumentando a oferta de produtos. Essa mudana
de postura na ponta do consumo j exige melhor qualidade de
produtos e processos para atender a esse novo cliente.
Em respeito s caractersticas e necessidades desse novo cliente,
algumas empresas desenvolvedoras de software j introduziram
modificaes no desenvolvimento e teste dos produtos. Muitas
esto colocando equipes para observar os usurios trabalharem
em seu ambiente rotineiro. Outras esto trazendo os usurios
para seus laboratrios de teste, visando melhorar a qualidade do
produto antes de sua disponibilizao para o mercado, uma vez
que a usabilidade fica mais clara quando pessoas sem conhecimentos tcnicos especficos tentam usar o sistema. Esta prtica
tem permitido s empresas diminuir custos, ampliar a equipe de
teste, garantir melhor qualidade e maiores lucros.
Importncia dos Requisitos na Qualidade de Software

Uma das primeiras questes a responder quando o assunto
qualidade como julg-la. Por exemplo: se estamos diante
de produtos distintos, como escolher o melhor? Esse problema
de julgamento acontece com qualquer pessoa cotidianamente,
quando se deseja adquirir itens como roupas, msica, comida
ou filmes. Mas curiosamente, apesar da frequncia com que
avaliamos os objetos nossa volta, muito difcil obter consenso a respeito da qualidade de um produto.
Uma escolha torna-se mais clara quando se estabelecem
critrios que sirvam para julgar um produto. Em algumas
situaes, tais critrios so relativamente simples de identificar
e estabelecer. Por exemplo: em domnios como engenharia
eltrica ou mecnica, as informaes necessrias so obtidas
em funo da finalidade de um determinado produto. Para
dispositivos simples, como um fusvel ou uma engrenagem,
no difcil enumerar algumas caractersticas que provavelmente so relevantes: ponto de fuso, condutncia trmica,
resistncia a cisalhamento ou dimenses fsicas. Passando para
objetos mais complexos, como um transistor, a complexidade
e a quantidade de requisitos tendem a aumentar.
Finalmente, quando se consideram softwares, importante
que a especificao de suas caractersticas seja realizada de
forma consistente. Isso evita mal entendidos e retrabalho pela
equipe de desenvolvimento, e consequente aumento de custo
em fases posteriores do desenvolvimento.
Os requisitos no resolvem, por completo, a questo da definio da qualidade, mas podem ser grandes aliados na sua
36
busca, uma vez que qualidade de software tambm estar

em conformidade com os seus requisitos, podendo ser uma
referncia no seu julgamento.
Projetos grandes, envolvendo muitas funcionalidades e pessoas diferentes (diversos tipos de usurios, denominados stakeholders), provavelmente tm mais chances de conter requisitos
conflitantes. Isso ocorre por falta de consenso em relao a como
certas tarefas devem ser desenvolvidas, ou mesmo para decidir
a prioridade entre elas. Em cenrios desse tipo, pode existir
uma deficincia de dilogo que antecede o projeto do software.
A engenharia de requisitos, uma subrea da Engenharia de
Software, tem por objetivo tratar o processo de definio dos
requisitos de software. Para isso, estabelece a elicitao, anlise
e modelagem daquilo que deve ser atendido pelo software. Este
processo deve observar diferentes pontos de vista, e usar uma
combinao de mtodos, ferramentas e pessoal. O produto
desse processo o chamado documento de requisitos.
Observando o contexto deste documento, o software dever
ser desenvolvido e operado. Ele inclui todas as fontes de informao e todas as pessoas relacionadas ao software. Essas
pessoas so tambm conhecidas como atores. Este universo de
informaes trata do conjunto de objetivos definidos pelos que
demandam o software. Estes objetivos podem ser classificados
como requisitos funcionais e requisitos no funcionais.
Os requisitos funcionais esto diretamente ligados funcionalidade do software, enquanto que os requisitos no funcionais expressam as restries que o software deve atender.
Neste contexto, a questo da qualidade tratada no processo
de levantamento destes requisitos atravs da definio clara
dos critrios de qualidade que o software dever atender.
NORMAS
COMENTRIOS
ISO 9126
Caractersticas da qualidade de produtos de software.
NBR 13596
Verso brasileira da ISO 9126.
ISO 14598
ISO 12119
IEEE P1061
ISO 12207
NBR ISO 9001
NBR ISO 9000-3
NBR ISO 10011
CMMI
SPICE ISO 15504
Guias para a avaliao de produtos de software, baseados na utilizao prtica

da norma ISO 9126.
Caractersticas de qualidade de pacotes de software (software de prateleira,
vendido como um produto embalado).
Standard for Software Quality Metrics Methodology. Norma que trata das
metodologias para padronizao da qualidade de software, incluindo
algumas abordagens de medio.
Software Life Cycle Process. Norma para a qualidade do processo de
desenvolvimento de software.
Sistemas de qualidade Modelo para garantia de qualidade em projeto,
desenvolvimento, instalao e assistncia tcnica (processo).
Gesto de qualidade e garantia de qualidade. Aplicao da norma ISO 9000
para o processo de desenvolvimento de software.
Auditoria de Sistemas de Qualidade (processo).
Capability Maturity Model Integration. Modelo da SEI (Instituto de
Engenharia de Software do Departamento de Defesa dos USA) para avaliao
da qualidade do processo de desenvolvimento de software. No uma norma
ISO, mas muito bem aceita no mercado.
Projeto da ISO/IEC para avaliao do processo de desenvolvimento de software.
Ainda no uma norma oficial ISO, mas o processo est em andamento.
Tabela 1. Principais normas nacionais e internacionais de qualidade
ENGENHARIA DE SOFT WARE
Medindo a Qualidade do Software

O principal problema com que se defronta a Engenharia de
Software a dificuldade de se medir a qualidade do software. A
qualidade de um dispositivo mecnico frequentemente medida
em termos de tempo mdio entre suas falhas, que uma medida
da capacidade de o dispositivo suportar desgaste. O software no
se desgasta, portanto tal mtodo de medio de qualidade no
pode ser aplicado. A norma ISO/IEC 9126 (NBR 13596) fornece
um modelo de propsito geral o qual define seis categorias de
caractersticas de qualidade de software que so, por sua vez,
subdivididas em subcaractersticas, conforme mostra a Tabela 2.
O modelo proposto pela ISO/IEC 9126 (NBR 13596) tem por
objetivo servir de referncia bsica na avaliao do produto de
software. Alm de ter fora de norma internacional, ela cobre os
aspectos mais importantes para qualquer produto de software.
A norma ISO/IEC 12119 tem o objetivo de estabelecer os requisitos de qualidade de software e instrues de como test-lo
com relao s suas especificaes. Ela define que cada pacote
de software tenha uma descrio do produto e sua respectiva
documentao, estabelecendo os seguintes pontos:
1. Descrio do produto compreensvel e completa para ajudar
o usurio ou comprador em potencial na avaliao da adequao do produto sua realidade;
2. Documentao do usurio de fcil compreenso, permitindo
uma viso geral do produto e de todas as suas funes, identificando o conhecimento necessrio para uso da aplicao;
3. Identificao do tipo de interface com o usurio;
4. Instrues detalhadas sobre como instalar o produto, caso

a instalao possa ser conduzida pelo usurio;
5. Possibilidade de verificar se a instalao foi bem sucedida;
6. Especificao de valores-limite para quantidade de registros e dados de entrada, como, por exemplo, preciso de casa
decimal;
7. Operao normal, mesmo quando os dados informados esto
fora dos limites especificados;
8. Consistncia de vocabulrio entre as mensagens e a
documentao;
9. Mensagens de erro com informaes necessrias para solucionar o problema;
10. Diferenciao de tipos de mensagem: confirmao, consulta, advertncia e erro;
11. Clareza e padronizao nos formatos de telas de entrada/
sada e relatrios.
Avaliando a Qualidade do Software

A avaliao da qualidade de software feita com o objetivo
de aprimorar o processo de desenvolvimento e consequentemente
melhorar a qualidade do produto resultante. A norma ISO/
IEC 14598 define um processo de avaliao da qualidade do
software, orientando que o seu uso seja feito em conjunto com
a norma ISO 9126, j que esta define as mtricas de qualidade
de software.
A norma ISO/IEC 14598 inclui modelos para relatrios de avaliao, tcnicas para medio das caractersticas, documentos
CARACTERSITICAS
SUBCARACTERSTICAS
Funcionalidade
Adequao
O conjunto de funes satisfazem as necessidades explcitas e implcitas Acurcia
Interoperabilidade
para a finalidade a que se destina o produto?
Segurana de acesso
Conformidade
Confiabilidade
Maturidade
O desempenho se mantm ao longo do tempo e em condies Tolerncia a falhas
Recuperabilidade
estabelecidas?
Usabilidade
Inteligibilidade
Apreensibilidade
fcil utilizar o software?
Operacionalidade
Eficincia
Comportamento em relao ao tempo
Os recursos e os tempos utilizados so compatveis com o nvel de Comportamento em relao aos recursos
desempenho requerido para o produto?
Manutenibilidade
H facilidade para correes, atualizaes e alteraes?
Portabilidade
possvel utilizar o produto em diversas plataformas com pequeno
esforo de adaptao?
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Adaptabilidade
Capacidade para ser instalado

Capacidade para substituir
Conformidade
SIGNIFICADO
Prope-se a fazer o que apropriado?
Gera resultados corretos ou conforme acordados?
capaz de interagir com os sistemas especificados?
Evita o acesso no autorizado, acidental ou deliberado a programas
e dados?
Est de acordo com normas e convenes previstas em leis e
descries similares?
Com que frequncia apresenta falhas?
Ocorrendo falhas como ele reage?
capaz de recuperar dados aps uma falha?
fcil entender os conceitos utilizados?
fcil aprender a usar?
fcil de operar e controlar a operao?
Qual o tempo de resposta e de processamento?
Quanto recurso utiliza?
fcil encontrar uma falha quando ocorre?
fcil modificar e remover defeitos?
H grandes riscos de bugs quando se faz alteraes?
fcil testar quando se faz alteraes?
fcil adaptar a outros ambientes sem aplicar outras aes ou
meios alm dos fornecidos para esta finalidade no software
considerado?
fcil instalar em outros ambientes?
fcil substituir por outro software?
Est de acordo com padres ou convenes de portabilidade?
Tabela 2. Categorias de caractersticas e subcaractersticas de qualidade de software
37
NORMA
ISO/IEC 14598
PROCESSO
1) Viso Geral A primeira parte da norma ensina a utilizar as outras normas do grupo. Ela apresenta a estrutura de funcionamento da srie de normas para a avaliao da qualidade do
produto de software, assim como apresenta a definio de termos tcnicos utilizados no modelo.
Deve ser usada em conjunto com a ISO/IEC 9126 por todos aqueles que necessitem verificar a qualidade do produto de software.
2) Planejamento e Gerenciamento A segunda parte apresenta como fazer uma avaliao, de forma geral. A norma apresenta requisitos, recomendaes e orientaes para a funo de
suporte ao processo de avaliao do produto de software. O suporte refere-se ao planejamento e a gesto do processo de avaliao e a tecnologia necessria para realizao da avaliao.
3) Guia para Desenvolvedores A terceira parte da norma prope como avaliar sob o ponto de vista de quem desenvolve. Para isso, o desenvolvedor define as condies sob as quais as
medies sero executadas.
Esta norma tem o objetivo de definir, acompanhar e monitorar a qualidade durante o processo de desenvolvimento do software.
4) Guia para Aquisio Avaliar sob o ponto de vista de quem vai adquirir o software. Esta quarta parte da norma divide-se em duas outras partes. A primeira refere-se aquisio de
software de prateleira, e a segunda aquisio de software sob encomenda ou manuteno de softwares existentes.
muito usada na aceitao ou seleo de um produto de software.
5) Guia para Avaliao O guia de avaliao apoia as empresas certificadoras no processo de avaliao sob o ponto de vista de quem certifica. Fornecendo requisitos e recomendaes para
implementao prtica da avaliao do software. Deve ser usada para a definio e acompanhamento de um processo de avaliao.
Tabela 3. Processos presentes na norma ISO/IEC 14598
38
MALDONADO, R. Qualidade de Software: Teoria e Prtica.

GOMES, N. Qualidade de Software Uma Necessidade.

Feedback
eu
sobre e
s
Ainda h empresas que pensam em qualidade apenas como

aquisio de respeito internacional atravs de certificaes e
procedimentos considerados corretos e qualitativos. Atravs
deste artigo, foi possvel ter uma viso geral do processo
de qualidade de software, expondo seus conceitos, importncia, caractersticas e aspectos referentes ao processo de
avaliao.
Referncias
D
s
Concluso
Os desenvolvedores fazem os softwares, mas so os clientes

que iro us-los de fato. Por isso a necessidade de sistematizar
formas de evitar os custos elevados resultantes dos defeitos de
software e dos erros no intencionais dos usurios durante a
fase de levantamento de requisitos. Esta sistematizao s ser
possvel se forem priorizados e atendidos pelo menos quatro
requisitos da qualidade de software: usabilidade, confiabilidade, funcionalidade e manutenibilidade. Sendo estes requisitos
essenciais, exigidos pelos clientes e que devem ser atendidos
pela indstria de software.
Ainda elevado o nmero de empresas que no adotam
tcnicas para melhoria da qualidade de seus produtos, mas
no h como negar que aquelas que desenvolvem software
de qualidade so mais competitivas. A busca contnua pela
qualidade de software um fator decisivo para a sobrevivncia
das empresas em um mercado cada vez mais exigente e globalizado. A abertura de mercados externos para os softwares
brasileiros busca uma nova postura frente qualidade, beneficiando o mercado interno, que acabar demandando softwares
melhores a menor preo.
Neste artigo foi possvel discutir alguns pontos importantes
sobre Qualidade de Software e despertar o interesse para uma
pesquisa mais ampla, observando que a melhoria da qualidade de software tem seu foco no apenas no produto, fazendo
softwares melhores, mas principalmente no cliente, fazendo
softwares mais fceis de usar.
edio
ta
necessrios para avaliao e fases da avaliao. No processo

de avaliao definido por esta norma, a identificao das
necessidades do usurio um passo importante para a qualidade. Tais requisitos so informais por natureza e precisam
ser formalizados. Eles podem ser quantificados e a qualidade
de uso avaliada em mtricas (ISO/IEC 9126). A norma leva em
considerao trs grupos de avaliadores:
Empresas que desenvolvem software e que procuram melhorar a qualidade de seu prprio produto;
Empresas que tm o hbito da aquisio de softwares e buscam a qualidade constante deles;
rgos oficiais que avaliam as empresas desenvolvedoras
de software emitindo documento oficial de certificao de
qualidade.
A Tabela 3 apresenta a norma ISO/IEC 14598 com uma breve
descrio de seus processos.
Durante o processo de avaliao da qualidade de um software
so observadas algumas caractersticas sobre o mesmo. Neste
processo esperado que o software seja:
Repetitvel Resultados idnticos devem ser obtidos ao
avaliar um software vrias vezes, utilizando a mesma especificao da avaliao e o mesmo avaliador;
Reprodutvel Resultados idnticos devem ser obtidos ao
avaliar um mesmo produto repetidas vezes, considerando a
mesma especificao da avaliao e sendo realizada por outro
avaliador;
Objetivo Os resultados da avaliao devem ser baseados
em fatos e evidncias, isto , no devem ser influenciados por
sentimentos ou opinies do avaliador.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Diagramas de Sequncia
Uma Abordagem Prtica
Geraldo Magela Dutra Gonalves

geraldo.magela@ufjf.edu.br
graduado em Engenharia Civil e possui especializao em Anlise e Desenvolvimento

de Sistemas, ambas pela Universidade Federal
de Juiz de Fora (UFJF). tcnico em TI da UFJF
onde trabalha com desenvolvimento de sistemas de informao e informtica desde 1988.
professor do Curso Superior de Tecnologia
em Anlise e Desenvolvimento de Sistemas da
Fundao Educacional Dom Andr Arcoverde
em Valena/RJ.
a ltima dcada, a Orientao

a Objetos firmou-se definitivamente como paradigma padro
de desenvolvimento de sistemas. Entre
as diversas vantagens em relao sua
antecessora, a Anlise Estruturada, a
Orientao a Objetos trouxe uma, considerada fundamental: a adoo de uma
linguagem unificada de modelagem,
acabando com a verdadeira Babel de
metodologias que a precederam. Assim
a UML Unified Modeling Language
Linguagem de Modelagem Unificada,
uma extensa e completa linguagem para
modelagem de diversos aspectos de um
sistema de informao sendo projetado.
A UML disponibiliza um conjunto de
13 diagramas diferentes, cada um deles
capturando uma abstrao do sistema,
e cujo conjunto constitui um excelente
conjunto de artefatos de anlise e projeto.
Nem todos os diagramas, contudo, so
aplicveis e necessrios ao desenvol-
Este artigo apresenta a utilizao dos recursos da

UML, especificamente os diagramas de sequncia.
O desenvolvimento de um modelo de interaes
realmente til, composto de diagramas legveis,
pode ser alcanado pela adoo de uma viso
pragmtica sobre o emprego da linguagem.
Para que serve?

Se bem compreendida e adaptada a cada tipo
diferente de sistema sendo desenvolvido, a abordagem apresentada pode auxiliar na confeco de
documentao de alto nvel de qualidade, mas que
no consuma tempo demais das equipes.

Tanto para equipes de desenvolvimento nas organizaes onde to preterida a atividade de
documentao, quanto no ambiente acadmico,
onde se observam dificuldades por parte dos
alunos em desenvolver, principalmente, os diagramas de sequncia.
vimento de todo e qualquer sistema. Um

conjunto varivel de parmetros e fatores
determina a necessidade de elaborao
de um determinado tipo de diagrama.
39
Todavia, de uma forma quase absoluta, trs dos tipos disponveis de diagramas devem sempre fazer parte da documentao de projeto de um sistema: os Diagramas de Casos de
Uso, juntamente com as respectivas descries detalhadas,
os Diagramas de Classes, e um de dois tipos de diagramas de
interao: os Diagramas de Comunicao ou os Diagramas de
Sequncia. Embora esses dois tipos de diagramas tenham a
mesma semntica, a prtica parece ter consagrado a escolha
dos diagramas de sequncia, por serem mais facilmente interpretados e compreendidos. Entretanto, nos meios acadmico e
profissional detecta-se, ainda hoje, uma grande dificuldade ao
adotar a criao de Diagramas de Sequncia.
Diagramas de Sequncia so muito teis em fornecer suporte real implementao e em constituir rica documentao de
alto nvel. Eles representam os objetos participantes de uma
colaborao enquanto emitem e recebem mensagens no intuito de realizar um caso de uso. As mensagens so apresentadas
em sua ordem temporal, o que facilita a compreenso do fluxo
de controle do caso de uso. A maior dificuldade associada
sua criao parece estar relacionada ao grau de detalhamento
a ser aplicado a esses diagramas. Mas pode-se adotar uma
perspectiva prtica para criao de uma documentao realmente til, e que no se torne uma tarefa ainda mais rdua
do que a prpria codificao do sistema.
Identificando as dificuldades
O problema tem duas perspectivas diferentes. No ambiente
organizacional, de produo, observa-se que o desenvolvimento de diagramas de sequncia muito detalhados tornase uma atividade penosa e contra producente. O tempo
despendido nessa atividade acaba por tornar-se superior
ao da prpria codificao. Ainda aqui, o principal causador
do grande tempo demandado parece ser o detalhamento
exagerado dos diagramas. Faz-los completos e detalhados
trabalhoso e difcil, alm de gerar documentao volumosa
e quase sempre preterida, em favor de um processo mais
gil de desenvolvimento.
O resultado de sua supresso radical dos artefatos do
sistema igualmente danosa, pois permite equipe de
programao, entre diversos outros problemas, resolver de
modo diferente diversas situaes de programao onde a
padronizao traria benefcios inequvocos. Uma concluso incipiente sobre sua utilizao ou no, aponta para a
necessidade de equacionar de forma mais pragmtica seu
uso nos projetos.
No ambiente acadmico, a principal dificuldade encontrada est fundamentada na total falta de unanimidade sobre
criao de diagramas de sequncia descrita na literatura
tcnica, assim como em centenas de exemplos de utilizao
disponveis atravs da Internet. Uma primeira anlise se
refere ao escopo de utilizao dos Diagramas de Sequncia.
Algumas fontes demonstram a utilizao desses diagramas
em um nvel exageradamente macro, aproximando-os dos
antigos Diagramas de Contexto da Anlise Estruturada. Um
exemplo dessa utilizao pode ser visto na Figura 1.
40
Engenharia de Software Magazine - Diagramas de Sequncia
Figura 1. Um diagrama de sequncia excessivamente macro
O diagrama apresentado utiliza de forma incorreta ou inadequada uma srie de elementos da notao de Diagramas de
Sequncia, notadamente a representao do prprio sistema
como um objeto, alm do banco de dados inteiro da mesma
forma. Todavia, esta no a viso mais til e correta dos Diagramas de Sequncia. A verdadeira utilidade de tais diagramas est na representao do fluxo de comunicao entre
objetos de uma comunidade, chamada de colaborao, com
o intuito de realizar um caso de uso. Entretanto, necessrio
que se adote aqui uma perspectiva prtica e gil de maneira
a garantir produtividade no desenvolvimento e ainda assim
gerar documentao til.
Adotando uma estratgia

Adotar uma estratgia significa estabelecer um grau de detalhamento que possibilite rapidez no desenvolvimento de Diagramas de Sequncia teis, que apiem realmente a implementao.
Martin Fowler, em sua obra UML Essencial, afirma: No sou
adepto de projetos de desenvolvimento detalhados; acredito que
muito difcil faz-los bem feitos, e eles retardam o trabalho de
desenvolvimento. O autor usa a UML para fazer esboos do
sistema, o que torna sua utilizao gil e produtiva.
As tcnicas de anlise de sistemas, indiferentemente do paradigma em uso, devem ser entendidas e aplicadas como uma
atividade meio e nunca como um fim em si mesma. Assim,
um grande Diagrama de Sequncia onde constem dezenas de
elementos normativos, e uma longa cadeia de comunicao
entre duas dzias de objetos diferentes pode configurar um
belo mural de arte contempornea, mas dificilmente ter muita
utilidade na construo do sistema.
Uma pitada de Budismo pode ser de utilidade aqui. Um dos
preceitos dessa doutrina ensina que o melhor caminho entre
dois extremos sempre o caminho do meio. Aqui tambm pode
ser uma perspectiva ideal: diagramas em nvel macro no do
suporte algum codificao, enquanto diagramas excessivamente detalhados geralmente so ilegveis. Adotar um meio
termo ponderado entre esses extremos parece ser uma iniciativa
bastante razovel.
PROJETO
Criando diagramas de sequncia teis

Para demonstrar como adotar um grau mediano de detalhamento na criao de Diagramas de Sequncia, define-se um pequeno
contexto com essa finalidade. A Figura 2 mostra um fragmento
de Diagrama de Classes que representa esse contexto.
Para esse contexto, diversos casos de uso devem ser desenvolvidos e a Figura 3 mostra o caso de uso escolhido para este
exemplo.
Um Diagrama de Sequncia uma colaborao que realiza
um caso de uso. Na verdade, um Diagrama de Sequncia realiza um cenrio de um caso de uso. Os Diagramas de Caso de
Uso possuem muito pouca semntica, o que fornece suporte
real para as fases subsequentes do processo de anlise sua
descrio detalhada.
Sobre o grau de detalhamento dos casos de uso para um
sistema real tambm cabem algumas ponderaes. Casos de
uso extremamente detalhados so difceis de ler e demandam
um grande tempo de desenvolvimento. A maioria das instalaes de desenvolvimento de sistemas adotam um ou mais
frameworks de desenvolvimento, o que automatiza uma srie
de procedimentos comuns de programao tornando sua descrio no projeto absolutamente dispensvel. Assim, aqui tambm parece interessante adotar uma descrio medianamente
detalhada, e a que mais se aproxima dessa meta a descrio
apresentada no Quadro 1. Ela representa o fluxo principal
para o caso de uso do exemplo, alm de um pequeno fluxo de
exceo. Tal descrio foi propositalmente mantida simples,
sendo coerente com a idia de adotar um grau mediano e
moderado de detalhamento. De posse desses dois elementos
bsicos, j possvel criar um Diagrama de Sequncia para o
fluxo principal e de exceo deste caso de uso.
A verdadeira valia dos modelos de casos de uso reside nas
descries detalhadas de cada um de seus cenrios, j que os
diagramas so simples e servem apenas para relacionar as
funcionalidades que devero existir no sistema.
Selecionando os objetos participantes

Utilizando o Diagrama de Classes e a descrio do caso de uso
possvel fazer uma lista de objetos de entidade participantes
da colaborao. Esses objetos so chamados persistentes, pois
constituem os elementos principais manipulados pela rea de
negcio representada. Os Diagramas de Sequncia so utilizados diretamente pela equipe de desenvolvimento, o que torna
necessrio incorporar objetos tpicos da soluo do problema,
alm dos objetos de negcio. Esses objetos, utilizados para
compor a soluo do problema representado, so chamados
transientes, pois so criados e destrudos durante uma sesso
do sistema. Para cada caso de uso representado pelo Diagrama
de Sequncia, incorpora-se um objeto transiente de fronteira,
destinado a apresentar uma interface ao mundo exterior (em
termos bem prticos, geralmente um formulrio escrito com
alguma linguagem de programao ou HTML, ou ambas,
destinado a interfacear um ator humano).
Para cada caso de uso representado por um Diagrama de
Sequncia, incorpora-se um objeto transiente de controle, ou
Figura 2. Diagrama de Classes para o contexto de estudo
Figura 3. Diagrama de Caso de Uso CriarMatrcula
controlador. Tais objetos assumem a responsabilidade pela

coordenao do caso de uso, centralizando as aes necessrias
para isso. Se presentes, esses objetos representam a adoo
de um padro de projeto denominado MVC Model, View,
Controller, que constitui uma excelente prtica de projeto e
programao. Ele isola os elementos do sistema em camadas,
tornando mais produtiva a tarefa de manuteno de sistemas
de mdio e grande porte.
Um outro tipo de objeto pode ser incorporado lista de
objetos participantes. um objeto transiente do tipo DAO
Data Access Object. Uma classe DAO, geralmente incorporada
ao sistema na fase de projeto, instancia objetos destinados a
resolver os problemas relacionados persistncia de objetos.
Em ltima anlise, objetos DAO transformam objetos em
registros que possam ser gravados em tabelas de bancos de
dados relacionais e transformam registros desses ltimos em
objetos, que podem ser processados por sistemas de software
orientados a objetos.
A Figura 4 mostra os objetos dispostos lado a lado no Diagrama de Sequncia, assim como o ator primrio, aquele que
dispara o caso de uso em questo. A ordem exata em que os
objetos so apresentados tem influncia apenas no aspecto
final do diagrama, no afetando em nada o desenvolvimento
41
CriarMatcula (CSU001)
Sumrio: O aluno solicita do sistema, sua matrcula em uma determinada disciplina. O sistema verifica se o aluno possui os pr-requisitos necessrios e em caso afirmativo registra a matrcula.
Ator Primrio: Aluno
Pr-condies: O aluno est logado no sistema.
Figura 4. Disposio inicial dos objetos participantes da colaborao
Fluxo Principal
1. O aluno solicita o formulrio (tela) de matrcula.
2. O sistema solicita um cdigo de disciplina.
3. O aluno fornece um cdigo de disciplina.
4. O sistema exibe o nome completo (descrio) da disciplina.
5. O sistema verifica a grade do curso para conhecer os pr-requisitos para aquela disciplina.
6. O sistema verifica o histrico do aluno para determinar se ele
possui os pr-requisitos necessrios.
7. Se sim, o sistema registra a nova matrcula, emite uma mensagem
de aceitao.
8. O sistema oferece alternativa de mais matrculas ou de encerramento.
10. O aluno seleciona encerramento e o caso de uso se encerra.
Fluxo Alternativo: O aluno seleciona mais matrculas e o caso de
uso retorna ao passo 2 (pode acontecer no passo 8).
Fluxo de exceo: O aluno no possui os pr-requisitos (pode
acontecer no passo 6).
1. O sistema reporta essa situao e retorna ao passo 8.
Ps-condies: As matrculas efetuadas tornam-se disponveis aos
coordenadores de curso para avaliao.
Regras de Negcio: Um aluno no pode se matricular em disciplinas
que no tenha cursado seus pr-requisitos.
Quadro 1. Especificao do caso de uso CriarMatrcula
do fluxo de mensagens. Essa ordem de apresentao pode ser

modificada no futuro.
Atores secundrios so aqueles que, embora no disparem o
caso de uso, participam dele de alguma forma, ou so afetados
por seus resultados. Esses tambm podem ser representados,
geralmente, do lado direito do diagrama.
Criando o fluxo de mensagens entre os objetos

Um Diagrama de Sequncia uma conversa entre os objetos
daquela colaborao que levam realizao de uma funcionalidade do sistema. A grande dificuldade determinar como
as mensagens so enviadas e a ordem cronolgica em que so
enviadas.
Essas mensagens e suas respectivas ordens no existem para
que possam ser descobertas. O analista/projetista cria tais
mensagens e determina a sua ordem cronolgica de forma
a alcanar o objetivo definido. Um caso de uso uma representao de uma necessidade ou desejo de seu ator primrio.
Deve-se atender a essa necessidade ou realizar esse desejo, e
42
isso feito por intermdio das mensagens enviadas entre os

objetos.
As mensagens definidas pela UML so de cinco tipos diferentes. Existem mensagens sncronas e mensagens assncronas.
Mensagens so sncronas quando o emissor envia a mensagem e fica aguardando o retorno do receptor para prosseguir
seu processamento. Mensagens so assncronas, quando o
emissor, aps remeter a mensagem, continua a executar o seu
prprio fluxo de controle, o que denota a capacidade de fluxos
de controle paralelos. E, de fato, essa uma capacidade das
linguagens de programao orientadas a objeto: a capacidade
de admitir dois ou mais fluxos de controle simultneos. Java
implementa tal capacidade atravs de threads, rotinas que
podem ser executadas em paralelo.
Mensagens podem ser tambm de criao de objetos (create)
ou de destruio de objetos (destroy). A criao de um objeto
sempre uma responsabilidade do programador, mas sua destruio no. Diferentes linguagens tm diferentes implementaes para essa caracterstica. Java implementa o mecanismo
denominado Garbage Collection que recolhe lixo da memria
automaticamente, ou seja, objetos que no foram referenciados
em um determinado perodo de tempo.
O ltimo tipo normativo de mensagens a mensagem de retorno. Esse tipo de mensagem no tem presena obrigatria no
diagrama. Esse assunto tratado mais adiante neste artigo.
Alm das mensagens definidas pela prpria UML, encontram-se possibilidades de utilizao no normativa e sobre
isso so pertinentes algumas consideraes. Martin Fowler faz
algumas consideraes sobre o uso de notaes normativas e
no normativas, onde defende a utilizao das notaes com
um certo grau de liberdade. O que realmente importa encontrar um subconjunto dos elementos notacionais que atendam
s necessidades especficas de modelagem de um projeto. A
UML deve ser encarada como um template, de onde se extrai
um conjunto de notaes adequadas a um projeto especfico.
Assim, como exemplo, a ferramenta CASE StarUML utiliza
representaes alternativas para mensagens que incluem
uma mensagem propriamente dita (send), aquela que apenas
transporta um parmetro entre emitente e receptor e a mensagem de chamada (call) que inicia a execuo de um mtodo
do receptor. A Figura 5 mostra o disparo do caso de uso pelo
ator primrio, utilizando essa notao alternativa. Nela, a seta
aberta um SEND (msg) enquanto a seta slida um CALL
(chamada).
PROJETO
Figura 5. Usando notaes normativas e no normativas
Representando os retornos
As linhas que aparecem abaixo dos objetos participantes so
de duas naturezas. Uma delas, pontilhada, a linha de vida
do objeto e representa o perodo de tempo em que o objeto
vive. Quando um caso de uso inicia, a presena de diversos
objetos emparelhados com o ator principal significa que tais
objetos foram instanciados e/ou materializados em algum
momento antes do incio do caso de uso e, na ausncia de
uma mensagem explcita de destruio (destroy), os objetos
permanecem em memria aps a finalizao do caso de uso.
bom lembrar aqui que um objeto s existe em tempo de
execuo, uma entidade puramente dinmica. Se um objeto
precisa ser instanciado durante o transcorrer do caso de uso,
uma mensagem especial de criao (create) emitida e o objeto
posiciona-se abaixo daqueles j existentes. Create um mtodo
construtor de uma determinada classe. Outro elemento sobre
a linha de vida uma barra retangular denominada foco de
controle. Ela representa o tempo durante o qual o objeto sobre
ela realiza tarefas solicitadas por outros objetos. Na prtica,
enquanto o objeto est ativo podem existir focos de controle
simultneos. Nos Diagramas de Sequncia, fluxos de controle
simultneos aparecem como barras de foco de controle paralelas e contnuas.
A mesma Figura 5 anterior apresenta esses elementos identificados atravs de notas explicativas, um mecanismo bsico
da UML para melhorar a legibilidade de quaisquer elementos
da linguagem.
Existem duas maneiras de representar retornos nos Diagramas de Sequncia. Uma delas por intermdio da adio
de uma linha pontilhada com direo de retorno, e outra a
interrupo do foco de controle sobre a linha de vida de um
objeto. Na verdade, a cada interrupo do foco de controle,
fica implcito um retorno, motivo pelo qual ele no tem representao obrigatria. A Figura 6 apresenta os retornos sendo
representados das duas maneiras citadas, para exemplificao.
A ferramenta CASE StarUML no faz qualquer distino entre
mensagens sncronas e assncronas.
Figura 6. Representando os retornos das mensagens
Nessa mesma figura aparecem invocaes de mtodos de

acesso (get) que recuperam o valor de atributos em objetos de
classes especficas. Esses mtodos so bsicos e obrigatrios
para cada atributo de uma classe para implementar uma
das caractersticas fundamentais da orientao a objetos: o
encapsulamento. O acesso aos atributos de um objeto tarefa
exclusiva de seus prprios mtodos de acesso, o que encapsula
totalmente o objeto.
Utilizando modularizao de interaes

Uma das novidades introduzidas pela UML 2.0 a utilizao
de quadros e de fragmentos combinados, atravs dos quais se
torna possvel representar alguma lgica presente no fluxo de
controle de um determinado Diagrama de Sequncia. Esse fluxo de controle funciona na prtica como um script geralmente
executado por um objeto de controle ou coordenado por ele.
Dois tipos de elementos grficos foram introduzidos: quadros
e fragmentos combinados. Quadros so usados para definir
Diagramas de Sequncia, de Comunicao ou de Atividades,
que sero posteriormente referenciados em outros diagramas.
Um quadro possui uma aba, no canto superior esquerdo, que
deve conter o tipo de diagrama que ele contm (sd para Diagramas de Sequncia, comm para Diagramas de Comunicao
e activity para Diagramas de Atividades), seguido do nome
dado a esse diagrama. O quadro em si contm um diagrama
de um dos trs tipos possveis. A mesma notao utilizada
para representar a referncia que se faz a um diagrama j definido, dentro de outro, em construo. Um mesmo diagrama
que contenha uma sequncia til pode ser referenciado em
mais de um local de um diagrama, assim como em diagramas
diferentes. Para isso, utiliza-se a palavra ref na aba superior,
com o nome do diagrama referenciado posicionado dentro do
quadro. Observe que, para ser coerente, o trecho referenciado
tem que trabalhar com os objetos sobre cujas linhas de vida
est aplicado.
43
Conforme citado anteriormente, o fluxo de controle associado a uma sequncia como um script de coordenao de
aes destinadas a realizar um caso de uso. Detalhes desse
fluxo de controle podem ser representados nos Diagramas de
Sequncia utilizando-se um elemento grfico denominado
fragmentos combinados. Atravs dele, define-se o fluxo de
controle da interao.
A notao para fragmentos a mesma dos quadros, mas com
operadores diferentes: um retngulo com uma aba superior
esquerda. Dentro da aba, usa-se um operador que reger a
operao descrita dentro do quadro. Embora existam outros
operadores, os mais comumente usados so: alt para estruturas se-ento-seno, opt para estruturas se-ento, e loop para
estruturas de repetio. Dependendo do operador sendo utilizado na aba, o retngulo pode ser dividido em sub-quadros
denominados operandos. Quando existirem operandos, eles
so separados por linhas tracejadas dentro do retngulo principal, e cada um deles deve conter uma expresso denominada
expresso de guarda. Uma expresso de guarda representa
uma condio necessria para que os aes dentro de um
operando sejam executadas.
Finalizando um diagrama de sequncia

A Figura 7 apresenta um Diagrama de Sequncia finalizado,
medianamente detalhado. Ele mostra claramente os objetos
envolvidos na realizao do caso de uso Criar Matrcula, a sequncia das operaes cronologicamente posicionadas, algum
detalhamento da lgica inerente ao fluxo de controle atravs do
quadro de fragmentos combinados alt, os objetos de entidade
e os objetos da aplicao. A necessidade de mais detalhamento
vai sempre estar condicionada complexidade do projeto em
questo, experincia do grupo de desenvolvedores, adoo
ou no de um framework de desenvolvimento e a diversos
outros fatores especficos para cada projeto.
Para o exemplo em questo ainda poderiam ser representados objetos DAO, configurando uma sub-camada da camada
de controle do MVC, destinada a executar as operaes de
compatibilidade entre o sistema e um mecanismo relacional
de persistncia.
Atribuindo corretamente as responsabilidades

Uma das atividades mais crticas de um projeto a determinao das responsabilidades dos objetos participantes de um
caso de uso. Projetar uma s super classe, que detenha todas
as responsabilidades envolvidas to inadequado quanto
projetar dezenas de classes contendo umas poucas responsabilidades. Uma tcnica que pode ser de alguma valia aqui
uma sesso com cartes CRC (Classes, Responsabilidades e
Colaboradores), embora essa atividade possa ser pouco produtiva na prtica. De qualquer forma, uma premissa importante
para atribuir responsabilidades considerar com ateno dois
princpios fundamentais: coeso e acoplamento.
Os conceitos de coeso e acoplamento j estavam presentes no
contexto de desenvolvimento de sistemas usando o paradigma
estruturado. Ali, eles se referiam s relaes entre programas
44
frmMatricula
: Aluno
1 : Iniciar()
ctrMatricula
: Disciplina
: Historico
: Grade
: Matricula
Este quadro de fragmentos

combinados representa uma parte
do fluxo principal e o fluxo
de exceo.
2 : Matricular()
3 : codDisc
4 : getDescDisc()
5 : DescDisc
6 : getPreReq()
7 : getHist()
8 : ret
alt
9 : setMatricula()
[ret=TRUE]
[ret=FALSE]
10 : MSG-OK
11 : MSG-NOTOK
Figura 7. Diagrama de sequncia com detalhamento mediano
ou rotinas. No contexto da Orientao a Objetos eles se referem

aos relacionamentos entre classes, pacotes ou componentes.
Uma classe coesa aquela cujos mtodos tm forte relao
entre si, assim como possui um conjunto de atributos que
constituem claramente um s grupo. Um forte indicador de
baixa coeso a presena, em uma nica classe, de dois ou
mais grupos de atributos que, embora sejam internamente
relacionados, no exibem relao significativa entre os grupos.
Classes pouco coesas so de difcil construo, compreenso
e principalmente manuteno.
Acoplamento representa o grau de dependncia que existe
entre classes distintas. Uma grande quantidade de classes
presente no projeto provoca um alto grau de dependncia entre
elas, o que acarreta problemas durante a fase de produo do
sistema no que tange manuteno. Em sistemas fortemente
acoplados, uma simples mudana no cdigo de uma classe
pode desencadear uma verdadeira reao em cadeia, afetando
uma rede de classes interdependentes.
Como projetar afinal? Vale novamente o caminho do meio.
Ajustar corretamente os graus de coeso e acoplamento
procurar o que em engenharia se chama ponto timo. Um
ponto sobre uma curva que traduz a melhor combinao
possvel entre duas ou mais grandezas. No contexto de desenvolvimento de sistemas, infelizmente no existe um mtodo
nico e totalmente eficaz de encontrar esse equilbrio. Ele
conseguido atravs da experincia prtica adquirida em
diversos projetos.
Resumindo as boas prticas

Embora abundante, a literatura tcnica sobre o assunto
pobre em exemplos prticos. Eduardo Bezerra em sua obra
denominada Princpios de Anlise e Projeto de Sistemas com
UML d um conjunto de dicas para construo de Diagramas
de Sequncia que vale a pena resumir.
A primeira delas diz respeito identificao das classes de
domnio. Essa tarefa pertence ao mbito das atividades da
fase de anlise, mais especificamente tarefa de construo
PROJETO
classes correspondentes no diagrama de classes podem ser

tornadas unidirecionais, o que diminui o acoplamento, simplifica o projeto e, consequentemente, o cdigo.
Concluso
A UML uma riqussima coleo de ferramentas de modelagem de sistemas. Entretanto, para gerar diagramas coesos
e teis, deve-se adotar um grau de detalhamento adequado
ao projeto em questo, como forma de propiciar correo e
agilidade, mantendo o projeto dentro de seu cronograma, sem
sacrificar a sua documentao.
Qualquer ferramenta de modelagem deve ter seu uso customizado ao projeto onde empregada. No se faz necessrio, principalmente nas organizaes, empregar de forma absoluta todas
as suas potencialidades. Usam-se as caractersticas consideradas
teis e produtivas, sem descaracterizar o seu emprego.
A grande maioria dos projetos de sistemas de informao
nas reas administrativa e comercial, pode ser especificada
com seis diagramas UML: um Diagrama de Casos de Uso,
um Diagrama de Classes, um Modelo de Interaes composto
de Diagramas de Sequncia, um Diagrama de Mquina de
Estados, quando aplicvel, um Diagrama de Atividades e um
Diagrama de Implantao.
Nesse contexto, os Diagramas de Sequncia so os mais
numerosos, o que justifica a adoo de uma estratgia de simplificao de seu uso de modo a torn-los utilizveis.
Toda e qualquer combinao de notaes teis so sempre bem
vindas ao projeto em execuo. Usando a linguagem com bom
senso e com critrio, notaes e prticas diferentes podem ser
combinadas e testadas pelas equipes de desenvolvimento visando sempre a produtividade e a qualidade do produto final.
Referncias
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 2.ed. Rio de Janeiro:
Elsevier, 2007. 370p.
BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usurio. 2.ed. Rio de Janeiro:
Campus, 2006. 474p.

Feedback
eu
edio
ta
D
s
FOWLER, Martin. UML essencial: um breve guia para a linguagem padro de modelagem de
objetos. 3.ed., Porto Alegre: Bookman, 2006. 160p.
45
sobre e
s
do diagrama de classes de anlise. Classes de domnio quase

sempre correspondem a entidades que tm uma correspondncia com um elemento presente no domnio.
Definido o conjunto de classes de domnio para um determinado caso de uso, passa-se a investigar um conjunto de classes
de software, ou da aplicao, que sero coadjuvantes na realizao do caso de uso. Isso inclui classes de fronteira, classes de
controle, classes de validao de acesso, dentre outras.
Uma discusso importante, que pode determinar a qualidade
de um projeto, e consequentemente do sistema, decidir quem
cria (instancia) objetos. Quando o padro MVC est sendo
aplicado, essa responsabilidades atribuda a uma classe
controladora, que coordenada a execuo do caso de uso.
Mas em casos extremos, tais responsabilidades acumuladas
podem tornar o projeto da classe controladora muito complexo
e extremamente acoplado. Tambm possvel adotar padres
de projeto para fbricas de objetos, criando classes que tm a
responsabilidade exclusiva de instanciar objetos. Essas consideraes influenciam a criao dos Diagramas de Sequncia
na medida em que definem que classes faro parte da colaborao. Ao adotar classes controladoras bom certificar-se
que elas exeram apenas coordenao. Atribui-se s classes
do domnio cada uma das responsabilidades relacionadas aos
objetos que instanciam.
Finalmente, para que os Diagramas de Sequncia sejam
realmente teis necessrio assegurar que eles permanecem
consistentes dentro do modelo como um todo. Enquanto se
produzem os diagramas do modelo de interaes, necessrio
contrapor tais diagramas com os anteriores Diagramas de Classes e com o Modelo de Casos de Uso. Essas trs dimenses de
um mesmo sistema se influenciam mutuamente, o que significa
que o desdobramento do modelo de interaes pode causar
modificaes nos modelos de classes e no modelo de casos de
uso, assim como o contrrio tambm pode acontecer. Os trs
modelos devero ser finalizados em conjunto e se completam.
Mas essa caracterstica constitui, em si mesma, uma das mais
significativas qualidades de um ciclo de vida de desenvolvimento incremental e iterativo. Assim, uma destacada utilidade
do desenvolvimento do modelo de interaes determinar o
conjunto completo de mtodos que devem ser desenvolvidos
para cada uma das classes, visto que todos eles devero estar
presentes nos Diagramas de Sequncia desenvolvidos. Alm
disso, possvel simplificar as associaes presentes no Diagrama de Classes de anlise pela observao do comportamento
dos objetos nos Diagramas de Sequncia: se entre dois objetos
de classes diferentes, no Diagrama de Sequncia, as mensagens
so enviadas em apenas uma direo, as associaes entre as
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 2

Implementando padres Factory com o uso de tcnicas de refatorao para
padres
Aborda o tema refatorao para padres com
o objetivo de mostrar como o desenvolvedor
pode us-lo para melhorar o cdigo-fonte de
suas aplicaes.
Para que serve?
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Aluno do Curso de Bacharelado em Cincia da Computao da FAGOC - Faculdade

Governador Ozanam Coelho, Microsoft
Student Partners.

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de
Software Magazine.
46
processo de refatorao para

padres envolve uma srie de
conhecimentos que se tornam
indispensveis para que um bom resultado seja obtido. Alm do domnio das
tcnicas de refatorao para padres
e conhecimento sobre os padres de
projeto, o desenvolvedor deve ainda
conhecer outros fatores que esto diretamente ligados a esta tarefa, para que
possua uma melhor compreenso sobre
o processo como um todo, e sobre os
fatores que influenciam diretamente no
seu trabalho de refatorar para padres.
Neste ponto, interessante que o desenvolvedor entenda tambm a importncia
de conhecer as tcnicas de refatorao que
contribuiro para a melhoria do projeto de
cdigo existente (ler Nota do DevMan1).
Engenharia de Software Magazine - Refatorao para Padres Parte 2
Para prover conhecimento ao desenvolvedor

sobre refatorao para padres e demonstrar
atravs de um exemplo prtico a aplicao das
tcnicas de refatorao para padres: Mover
Conhecimento de Criao para Factory e Encapsular Classes com Factory.

O tema se torna fundamental para desenvolvedores que j esto familiarizados com padres
de projeto e j os implementam em seus softwares e que querem saber mais sobre refatorao para padres, conhecendo os benefcios que
sua utilizao traz.
Entender sobre o padro de projeto que a

tcnica de refatorao para padres ataca e
as respectivas tcnicas de refatorao permite ao desenvolvedor ter mais facilidade
para compreender e se beneficiar de seu
uso (ler Nota do DevMan 2).
DESENVOLVIMENTO
Nota do DevMan 1
Refatorao relembrando conceitos importantes
Refatorao (do ingls Refactoring) o processo de modificar um sistema de
software para melhorar a estrutura interna do cdigo sem alterar seu comportamento externo.
O uso desta tcnica aprimora a concepo (design) de um software e evita a deteriorao to comum durante o ciclo de vida de um cdigo. Esta deteriorao
geralmente causada por mudanas com objetivos de curto prazo ou por alteraes
realizadas sem a clara compreenso da concepo do sistema.
Outra consequncia a melhora no entendimento do cdigo, o que facilita a
manuteno e evita a incluso de defeitos. Esta melhora no entendimento vem da
constante alterao do cdigo com objetivo de facilitar a comunicao de motivaes, intenes e objetivos por parte do programador.
Nota do DevMan 2
Substituir Construtores por Mtodos de Criao.
No artigo da edio de numero 28 da revista Engenharia de Software Magazine,
foi apresentada a primeira das 27 tcnicas de refatorao para padres, Substituir
Construtores por Mtodos de Criao. Seguindo uma sequencia, neste artigo ser
apresentada a segunda e a terceira tcnicas de refatorao para padres, Mover
Conhecimento de Criao para Factory e Encapsular Classes com Factory.
Mover Mtodo
As tcnicas de refatorao para padres que sero apresentadas neste artigo, Mover conhecimento de criao para
Factory e Encapsular classes com Factory, possuem, assim
como as demais, uma srie de passos que demonstram como
aplic-las, e um dos passos envolve a aplicao da tcnica de
refatorao Mover Mtodo. Dessa forma, faz-se necessrio
que o desenvolvedor veja um exemplo prtico da aplicao
desta refatorao.
Resumo: Mover mtodo uma refatorao indicada para
momentos em que o desenvolvedor se depara com mtodos
que esto fazendo uso excessivo de informaes vindas de
outras classes. Nesse contexto, esta refatorao permite que o
mtodo seja movido para outra classe, a fim de que ele passe
a pertencer classe que mais prov informaes para que ele
funcione.
Motivao: Classes que possuem diversas funcionalidades
podem acabar carregando informaes alm das que naturalmente deveriam conter. Alguns mtodos existentes nessas
classes acabam fazendo com que ela seja usada mais do que o
normal, e isso a torna mais complexa de ser analisada. Neste
contexto, movem-se os mtodos que no devem fazer parte de
uma classe para outra classe.
Mecnica:
O primeiro passo consiste em analisar a classe que contm
o mtodo que ser movido. Neste caso, busca-se por recursos
da classe que esto sendo usados pelo mtodo. Caso o recurso

esteja sendo usado por outros mtodos, talvez seja importante
mov-los tambm. Neste caso analisam-se as particularidades
de cada aplicao.
Aconselha-se analisar, caso haja uma hierarquia de classes,
o impacto dessa mudana em outras classes do sistema, antes
de mover o mtodo.
Na classe que receber o mtodo a ser movido, deve-se
declarar um mtodo com o mesmo nome do mtodo que se
deseja mover.
Copia-se o cdigo do corpo do mtodo para o mtodo recm
declarado.
Ajustes necessrios devem ser feitos para que o mtodo
funcione na classe onde est agora, cuidando para que ele no
perca nenhuma funcionalidade que possua quando estava
na outra classe.
Executam-se testes para se certificar que tudo correu como
planejado.
Exemplo: Um software comercial possui uma classe Funcionarios onde, aps anlise, chegou-se concluso que no
fazia sentido o mtodo CalcularComissao estar naquela classe,
como mostra a Listagem 1.
O mtodo CalcularComissao, linhas 4 a 14, recebe o valor da
venda que est sendo efetuada e calcula a comisso do funcionrio no ato da venda. Neste contexto, viu-se a importncia de
aplicar a refatorao Mover Mtodo, pois o mtodo em questo
naturalmente deveria pertencer classe Venda.
Como este metodo no est consumindo recursos da classe
Funcionarios, pode-se aplicar a refatorao. Cria-se um mtodo
na classe Venda, com o mesmo nome do mtodo que se deseja
mover, como mostra Listagem 2, linhas 4 a 6.
Listagem 1. Classe Funcionarios com o mtodo CalcularComissao.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
public class Funcionarios

{
// ...
public Decimal CalcularComisao(Decimal valorVenda)
{
Decimal comissao = 0.0M;
if (valorVenda < 500)
{
comissao = (valorVenda / 100) * 3;
}
else if(valorVenda >= 500)
{
}
return comissao;
}
}
Listagem 2. Declarao do novo mtodo na classe Venda.

01.
02.
03.
04.
05.
06.
07.
08.
public class Venda

{
// ...
{
}
// ...
}
47
Agora copia-se o corpo do mtodo CalcularComissao

(Listagem 1, linhas 4 a 14) para o mtodo recem criado, que
ficar como mostra a Listagem 3.
Para que o mtodo na classe Funcionario possa ser removido,
deve-se ajustar o cdigo para que, a partir desse momento, ele
passe a referenciar a classe Venda, e no mais a classe Funcionarios como antes. Feitas as alteraes necessrias, remove-se
o mtodo da classe Funcionarios e executa-se os testes para
se certificar que as mudanas no afetaram o comportamento
do sistema.
Listagem 3. Classe Venda e o mtodo CalcularComissao.

01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Extrair Mtodo
Extrair Mtodo, outra tcnica de refatorao, utilizado no
processo de aplicao da tcnica de refatorao para padres
Encapsular classes com Factory. Por conta disto, precisamos
entend-lo antes de analisar a refatorao para padro Encapsular classes com Factory.
Resumo: A refatorao Extrair Mtodo permite a criao
de novos mtodos com nomes compatveis com a funo do
mtodo.
Motivao: muito comum encontrar em trechos de cdigo
alguns mtodos que esto como mais responsabilidades do
que deveriam ter. Com isso, torna-se complicado entender
qual o real objetivo do mtodo. Extrair mtodo sugere que
um novo mtodo seja extrado deste trecho de cdigo e que
o mesmo passe a possuir parte do cdigo do mtodo que se
est refatorando, permitindo que cada mtodo possua uma
responsabilidade.
Mecnica:
Identifica-se um mtodo que possua mais de uma responsabilidade. Cria-se um novo mtodo com um nome compatvel com a responsabilidade extra do mtodo que se est
analisando.
O cdigo que possui a responsabilidade que se est retirando
do mtodo analisado, agora deve ser copiado para o mtodo
recm criado.
Analisa-se o cdigo movido e verifica-se se h variveis que
esto declaradas no mtodo original. Se sim, o mtodo criado
deve ter parmetros como os das variveis encontradas.
No mtodo novo, deve-se verificar a existncia de declarao
de variveis. Se existir, devem ser modificadas para que sejam
destrudas aps a execuo do mtodo.
No lugar do cdigo que foi extrado do mtodo original, agora
deve haver uma chamada ao novo mtodo. Terminado todo o
processo, deve-se compilar o cdigo e testar a aplicao.
Exemplo: O exemplo de cdigo que ser apresentado pertence a um software financeiro. Em uma determinada classe
foi encontrado um mtodo que recebe como parmetro um
ArrayList de notas e calcula a mdia dessas notas, como mostra
a Listagem 4.
Analisando o mtodo da Listagem 4, percebe-se que ele
possui duas responsabilidades: uma a de calcular a mdia
e a outra a de exibir os resultados. Nota-se que o nome do
mtodo diz que ele calcula a mdia, mas no quer dizer que
48
public class Venda

{
// ...
{
Decimal comissao = 0.0M;
if (valorVenda < 500)
{
}
else if (valorVenda >= 500)
{
}
return comissao;
}
// ...
}
Listagem 4. Mtodo a ser refatorado.

02.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
public void CalcularMedia(ArrayList listaNotas)

{
Int32 quantidadeNotas = listaNotas.Count;
Decimal soma = 0.0M;
Decimal mdia = 0.0M;
for (Int32 i = 0; i < listaNotas.Count; ++i)
{
soma += Convert.ToInt32(listaNotas[i]);
}
mdia = soma / quantidadeNotas;
Console.WriteLine(Quantidade de notas: + quantidadeNotas);
Console.WriteLine(Mdia : + mdia);
Console.Read();
}
ele tenha que exibir os resultados. Este um exemplo de um

mtodo que precisa ser refatorado. Neste caso, cria-se um novo
mtodo, com o nome da funcionalidade que est sobrando e
move-se o cdigo de exibio dos resultados para o mtodo
recm criado, usando os passos descritos na mecnica da
refatorao Extrair Mtodo. O resultado obtido pode ser visto
na Listagem 5.
O cdigo de impresso do resultado foi movido para o mtodo
ExibeResultados, que revela claramente a inteno do cdigo.
Esta refatorao permite que o cdigo fonte se torne menos
complexo, uma vez que pequenos mtodos com funcionalidades especficas so mais fceis de entender e manter, se
comparados a mtodos que carregam vrias responsabilidades.
No exemplo da Listagem 4, s h como perceber que o mtodo
CalculaMedia tambm exibe os resultados se for feita uma
anlise do seu corpo, pois o nome do mtodo no demostra que
ele possui responsabilidades alm de calcular a mdia.
O padro de projeto Factory

Existem vrias definies sobre o que vem a ser uma Factory, o que pode dificultar o processo de entender e aplicar
tal padro. Muitos desenvolvedores usam o termo fazendo
referncia a todo cdigo presente nas aplicaes que so
responsveis pela instanciao de objetos. Outros o utilizam
para fazer referncia aos padres de projeto Factory Method
e/ou Abstract Factory. A definio de Factory descrita em
Refatorao para Padres :
DESENVOLVIMENTO
Uma classe que implementa um ou mais mtodos de criao uma

Factory. Isso verdadeiro se os mtodos de criao so estticos ou no
estticos; se o tipo de retorno dos mtodos de criao uma interface,
classe abstrata ou classe concreta; ou se a classe que implementa um
ou mais mtodos de criao uma Factory.
Assim, o padro Factory Method refere-se a mtodos cujo retorno pode ser um objeto de uma subclasse ou interfaces implementadas em uma hierarquia de classes com polimorfismo. Dada
a definio de Factory descrita em Refatorao para Padres, um
Factory Method no pode ser considerado uma Factory.
Abstract Factory um padro cuja implementao possui
uma classe abstrata presente em uma hierarquia de classes
responsvel pela utilizao em runtime de implementaes
existentes em classes concretas da hierarquia. A Figura 1
mostra um diagrama de classes que ilustra a diferena entre
os padres Factory Method, Abstract Factory e uma Factory,
segundo suas implementaes. As classes da figura apresentam linhas vermelhas que representam os mtodos da classe
responsveis pela instanciao de objetos.
A primeira hierarquia de classes da figura (exemplo de
Factory Method) permite visualizar que o mtodo (linha vermelha da superclasse) implementado pelas subclasses com
polimorfismo. J a classe relativa ao exemplo de Factory, mostra os mtodos responsveis pela instanciao dos objetos da
classe Factory, enquanto a hierarquia de classes do exemplo de
Abstract Factory ilustra as subclasses concretas que substituem
a interface em runtime e seus respectivos mtodos.
At este momento, foram apresentados assuntos importantes
no processo de refatorao para padres utilizando as tcnicas
Mover conhecimento de criao para Factory e Encapsular
Classes com Factory. A partir de agora, sero abordadas as
particularidades de cada uma dessas tcnicas, bem como
exemplos prticos de como aplic-las.
Mover conhecimento de criao para Factory

Resumo: O cdigo e os dados usados no momento de instanciar um objeto podem estar espalhados por diversas classes.
Neste contexto, cria-se uma classe Factory e move-se esse
cdigo e os dados para ela.
Motivao: Esta refatorao para padres permite ao desenvolvedor melhorar o projeto de cdigo de sua aplicao ao identificar classes cujas informaes necessrias para instanciar
e/ou configurar o objeto esto espalhadas por vrios pontos
do cdigo. A isto se d o nome de espalhamento de criao
[2]. Devido a vrios fatores, como por exemplo, manutenes
desordenadas, o projeto de cdigo pode se tornar complexo, e
grande parte das informaes que so usadas para instanciar
um objeto acabam sendo inseridas em outras classes. Com
a implementao de uma Factory, tem-se uma soluo para
esse caso.
Vantagens: Permite a uma classe conter o conhecimento
para instanciar e/ou configurar objetos, evitando que ele fique
espalhado por outras classes. Isto reduz o acoplamento entre o
cdigo que contm a lgica de criao do cdigo cliente.
Figura 1. Diagrama de classes ilustrando a estrutura dos padres Factory

Method, Factory e Abstract Factory
Listagem 5. Mtodo CalcularMedia refatorado.
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
public void CalcularMedia(ArrayList listaNotas)

{
Int32 quantidadeNotas = listaNotas.Count;
Decimal soma = 0.0M;
Decimal mdia = 0.0M;
for (Int32 i = 0; i < listaNotas.Count; ++i)
{
soma += Convert.ToInt32(listaNotas[i]);
}
mdia = soma / quantidadeNotas;
ExibeResultados(quantidadeNotas, mdia);
12.
13.
14.
15.
16.
17.
18.
}
public void ExibeResultados(Int32 quantidadeNotas, Decimal mdia)
{
Console.WriteLine(Quantidade de notas: + quantidadeNotas);
Console.WriteLine(Mdia : + mdia);
Console.Read();
}
Desvantagens: Aumenta a complexidade do cdigo em situaes onde instanciar o objeto diretamente ao invs de usar uma
Factory suficiente.
Mecnica:
1. Dada a definio de instanciador, que uma referncia a classes
que ajudam outras classes no momento de instanciar um objeto,
verifica-se se ele o faz atravs de um mtodo de criao ou um
construtor. Caso no seja um mtodo de criao, deve ser modificado para um. Compila-se a aplicao e executam-se os testes.
2. Cria-se uma classe Factory (classe que ser a responsvel por
carregar as informaes sobre como instanciar seus objetos).
Deve-se cuidar para que o nome da classe Factory seja condizente
com sua responsabilidade.
3. Aplica-se a refatorao Mover Mtodo com intuito de levar o
mtodo de criao para a classe Factory. Caso o mtodo movido
seja esttico, pode-se defini-lo como no-esttico, caso necessrio.
Compila-se a aplicao.
4. Depois da compilao do passo 3, os instanciadores agora
no mais sero capazes de instanciar um objeto, pois o mtodo
ao qual eles fazem referncia no est mais na classe que antes
estava, portanto deve-se ajust-los para que passem a referenciar
a classe Factory.
5. Procura-se por outras classes no sistema, mtodos e informaes que fazem parte do processo de instanciao de um objeto.
Se encontrado, move-se todo esse cdigo para a classe Factory.
Exemplo: Considere a classe Funcionarios. Ela contm
um mtodo instanciador que responsvel por instanciar
um objeto Funcionrio, dependendo do seu tipo. Caso o
49
funcionrio seja horista, instancia-se um objeto funcionrio

com dados de horista. Caso contrrio, instancia-se um objeto
funcionrio com dados de diarista, como pode ser observado
na Listagem 6.
O mtodo CriarFuncionario j um mtodo de criao e no
um construtor, portanto o passo um da mecnica pode ser
descartado neste caso.
O passo 2 sugere a criao de uma classe Factory que carregar consigo o mtodo CriarFuncionario, pois este mtodo
instanciador possui conhecimento de criao de objetos de
funcionrios horistas e diaristas.
A Factory criada deve conter um nome que condiz com sua
responsabilidade. Ser declarada como FabricaFuncionarios.
Em seguida aplica-se a refatorao Mover Mtodo no mtodo
CriarFuncionario, levando-o para a Factory. O resultado pode
ser visto na Listagem 7.
As chamadas ao mtodo movido a partir desse momento no
funcionaro mais. A Listagem 8 mostra como era a chamada
ao mtodo CriarFuncionario antes da refatorao. Depois de
aplicada a refatorao para padres pertencente classe Factory, a Listagem 9 mostra a nova chamada.
Analisando as mudanas na chamada ao mtodo CriarFuncionario, torna-se visvel que a responsabilidade de instanciar
um objeto funcionrio agora pertence a classe Factory, pois a
aplicao desta refatorao para padres permitiu que o conhecimento de criao de objetos Funcionarios fosse movido
para uma Factory.
Listagem 6. Classe Funcionarios

01. public class Funcionarios
02. {
03. // ...
04. Public static Funcionarios CriarFuncionario(UInt32 id, String nome,
String CPF, String tipoFuncionario)
05. {
06.
Funcionarios objFuncionario = new Funcionarios();
07.
objFuncionario.Id = id;
08.
objFuncionario.Nome = nome;
09.
objFuncionario.CPF = CPF;
10.
if (tipoFuncionario.Equals(HORISTA))
11.
{
objFuncionario.Salario = FuncionarioHorista.CalcularSalarioHorista();
12.
}
13.
else
14.
{
objFuncionario.Salario = FuncionarioDiarista.CalcularSalarioDiarista();
15.
}
16.
return objFuncionario;
17. }
18. }
Listagem 7. Classe Factory
01. public class FabricaFuncionarios
02. {
03.
public static Funcionarios CriarFuncionario(UInt32 id, String nome,
String CPF, String tipoFuncionario) {
04.
Funcionarios objFuncionario = new Funcionarios();
05.
objFuncionario.Id = id;
06.
objFuncionario.Nome = nome;
07.
objFuncionario.CPF = CPF;
08.
if (tipoFuncionario.Equals(HORISTA))
09.
{ objFuncionario.Salario = FuncionarioHorista.CalcularSalarioHorista();
10.
}
11. else
12.
{ objFuncionario.Salario = FuncionarioDiarista.CalcularSalarioDiarista();
13.
}
14.
return objFuncionario;
16. }
17. }
Encapsular Classes com Factory

Resumo: Objetos instanciados de classes que esto em um
pacote ou namespace e que implementam uma interface em
comum, podem ter seus construtores definidos como privados
e transferir a responsabilidade de permitir a instanciao de
objetos para uma classe Factory.
Motivao: Indicada para momentos em que o cdigo cliente
instancia objetos de classes que no deveriam ser visveis. Encapsulando classes com Factory pode-se ocultar a esses clientes
a existncia dessas classes e fazer com que eles passem a usar
uma Factory para instanciar esses objetos. Esta ao permite
o ocultamento de informaes, prtica que visa permitir que
determinadas classes possam ser visveis ou no, dependendo
da necessidade do projeto. Outro benefcio o de permitir
que clientes se comuniquem com interfaces ao invs das suas
classes. Esta refatorao indicada quando as classes em questo esto utilizando uma interface pblica comum, alm de
estarem no mesmo pacote ou namespace e herdarem da mesma
superclasse.
Vantagens: Aumenta a clareza do cdigo, ao permitir aos
objetos serem instanciados atravs de mtodos de criao presentes na classe Factory, cujos nomes deixam clara a inteno
do mtodo e o tipo de objeto que ele instancia. Alm disso, permite o ocultamento de informaes e; permite a comunicao
de clientes com interfaces, ao invs de suas classes.
Desvantagens: Faz com que o desenvolvedor tenha que implementar novos mtodos de criao ou atualizar os existentes
50
Listagem 8. Chamada ao mtodo CriarFuncionario antes da refatorao para

padres
Funcionarios objFuncionario = Funcionarios.CriarFuncionario
(010, Joao, 000.000.000-00,HORISTA);
Listagem 9. Chamada ao mtodo CriarFuncionario depois da refatorao para
padres
Funcionarios objFuncionario = FabricaFuncionarios.CriarFuncionario
(010, Joao, 000.000.000-00, HORISTA);
na Factory caso algum novo construtor seja adicionado ou

atualizado nas classes utilizadas pela Factory. Alm disso,
elimina o acesso direto a mtodos de criao de objetos de
subclasses de uma hierarquia.
Mecnica:
1. Dada uma hierarquia de classes, analisa-se o cdigo cliente
em busca de pontos onde h chamada a um construtor de
uma das subclasses da hierarquia. Usa-se a refatorao Extrair
Mtodo na chamada desse construtor. O mtodo extraido deve
ser movido para a superclasse atravs da tcnica de refatorao
Mover Mtodo.
DESENVOLVIMENTO
2. Atualizam-se todas as chamadas ao construtor escolhido no

passo 1 para, a partir de ento, passarem a chamar o mtodo
de criao criado e que agora est na superclasse.
3. Busca-se por outras chamadas a outros construtores das
subclasses, repetindo-se os passos 1 e 2.
4. Sobre o construtor escolhido da subclasse, modifica-se seu
moderador de acesso para privado. A partir desse momento,
s ser possvel instanciar objetos da subclasse a partir de
um mtodo da superclasse, ocultando as informaes da
subclasse ao cdigo cliente.
5. Repetem-se os passos 1 a 4 em todas as subclasses que se
deseja ocultar informao.
Exemplo: A Figura 2 mostra um diagrama de classes, onde
se tem uma hierarquia de classes.
As Listagens 10, 11, e 12 mostram a declarao das classes
representadas na Figura 2.
A partir desse momento ser trabalhada a subclasse
Clientes da hierarquia. O passo 1 consiste em buscar pelo
cdigo da aplicao por chamadas ao mtodo de criao
CriarCliente. Um exemplo de trecho encontrado pode ser
visto na Listagem 13.
A linha 5 da Listagem 13 mostra um ArrayList de clientes
que recebe um novo cliente recm instanciado. Pode-se perceber com isso que o conhecimento para instanciar objetos
da classe Clientes est acessvel a qualquer um que precise
de acesso. Neste contexto, interessante que o privilgio
de instanciar novos Clientes seja restrito a uma Factory,
tornando-se o nico ponto possvel para isto. Ainda no passo 1 desta refatorao para padres, aplica-se a refatorao
Extrair Mtodo na chamada ao mtodo de criao da classe
Clientes, presente na linha 5 da Listagem 13. O resultado
pode ser visto na Listagem 14.
Listagem 10. Classe Pessoa

01.
02.
03.
04.
public abstract class Pessoa

{
// ...
}
Listagem 11. Classe Clientes

01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
public class Clientes : Pessoa

{
// ...
public Clientes CriarCliente(String nome, String CPF, String Cep,
String telefone, Decimal salario)
{
Clientes objCliente = new Clientes();
objCliente.NomePessoa = nome;
objCliente.CPFPessoa = CPF;
objCliente.CepPessoa = Cep;
objCliente.TelefonePessoa = telefone;
objCliente.SalarioPessoa = salario;
objCliente.LimiteCreditoCliente = CalcularLimiteCredito
(Convert.ToUInt32(salario));
return objCliente;
}
//...
}
Listagem 12. Classe Funcionrios.

01.
02.
03.
04.
public class Funcionarios : Pessoa

{
// ...
}
Listagem 13. Cdigo de chamada ao mtodo de criao da classe Clientes.

1. static void Main(string[] args)
2. {
3. ArrayList listaClientes = new ArrayList();
4. // ...
5. listaClientes.Add(Clientes.CriarCliente(nome, CPF, Cep, Telefone, Salario));
6.
7. }
Figura 2. Diagrama de classes de uma hierarquia
51
Listagem 14. Cdigo de chamada ao mtodo de criao da classe Clientes.

02. {
03.
ArrayList listaClientes = new ArrayList();
04.
...
05.
listaClientes.Add(CriarCliente());
06. }
07. private static Clientes CriarCliente()
08. {
09.
return Clientes.CriarCliente(nome, CPF, Cep, Telefone, Salario);
10. }
Listagem 15. Chamada ao mtodo extrado modificada.
02. {
03.
ArrayList listaClientes = new ArrayList();
04.
...
05.
listaClientes.Add(Pessoas.CriarCliente(nome, CPF, Cep, Telefone, Salario));
06. }
Depois de aplicada esta refatorao, a superclasse da hierarquia agora tambm uma classe Factory, que passa a ter a
responsabilidade de ser o nico ponto de acesso que se pode
usar para instanciar objetos de uma das suas subclasses que,
a partir de ento, esto encapsuladas.
Concluso
O padro Factory traz muitos benefcios para quem o utiliza. Muitos desenvolvedores apenas o implementam quando
esto criando cdigo novo e percebem a sua importncia no
projeto.
As refatoraes para padres apresentadas neste artigo,
aliadas s tcnicas de refatorao Mover Mtodo e Extrair
Mtodo, mostram uma nova forma de trabalhar com uma
Factory, que implementando-a a partir da refatorao de
cdigo j em uso.
Referncias Bibliogrficas
KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.

D
s
FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
Feedback
eu
edio
ta
52
GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a objetos,
1ed. Porto Alegre: Bookman, 2000.
sobre e
s
O mtodo extrado (linhas 7 a 10 da Listagem 14) deve ser

movido para a superclasse da hierarquia, usando a refatorao
Mover Mtodo, e deve ter seu moderador de acesso definido
como pblico.
O passo 2 requer que a chamada ao mtodo de criao da
classe Clientes seja modificada para, a partir de ento, referenciar o mtodo movido para a superclasse. O resultado pode
ser visto na Listagem 15.
Para finalizar, modifica-se o moderador de acesso do mtodo de criao da classe Clientes (CriarCliente) para privado.
Repete-se o procedimento em todos os mtodos de criao de
objetos das subclasses, caso queira encapsular mais classes
com o padro Factory.
DESENVOLVIMENTO
53
54

Automação de Testes - Engenharia de Software - Edição 29 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Automação de Testes - Engenharia de Software - Edição 29 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

maduro. Vrias so as ferramentas disponveis no mercado para as empresas, entre pagas

Ano 3 - 29 Edio - 2010

esforo desta atividade no contexto geral de um projeto de software.

teste de software. Sendo assim, se no tivermos conhecimento tcnico adequado sobre

gias de teste, a automao pode trazer grandes benefcios a um projeto de software.

rincia prtica de executar um processo de teste em um projeto de software desenvolvido

O dia em que virei um Ninja

Acompanhamento de projetos geis distribudo atravs do Daily Meeting

Fale com o Editor!

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

Para esta edio, temos um conjunto de 5 vdeo aulas.

Hernan Julho Muoz e Teresa M Medeiros Maciel

20 - Automao dos Testes: um lobo na pele de cordeiro?

26 - Processo e automao de testes de Software

46 - Refatorao para Padres Parte 2

Edio 05 - Engenharia de Software Magazine

Pos trs do bvio

O dia em que virei um

Engenharia de Software - O dia em que virei um Ninja

D seu feedback sobre esta edio!

motivacionais. No duvido que tais eventos possam trazer

Acompanhamento de projetos geis

Hernan Julho Muoz

Mestrando em Engenharia de Software

Teresa M Medeiros Maciel

Mestre em Engenharia de Software e doutoranda pela UFPE. Professora do DEINFO/

o cenrio atual, os sistemas possuem funcionalidades cada vez

Para que serve?

Em que situao o tema til?

Edio 29 - Engenharia de Software Magazine

opo por esta abordagem, pode ser ressaltado o baixo custo

tratar o Daily Meeting distribudo descreve em detalhes como

Desenvolvimento de software distribudo

de transparncia sobre o progresso da equipe

negcio (Business Value ou BV), ou no retorno sobre o investimento (ROI)

Desenvolvimento gil Distribudo

Edio 29 - Engenharia de Software Magazine

colaborao entre os membros so mais bem tratados pelas

Daily Meeting Distribudo

De acordo com Sutherland, o primeiro grande desafio o

Ferramentas para apoio ao Daily Meeting

multimdia interessantes, tais como vdeo-conferncia. Outro

ele no tem um ambiente para organizar a equipe em uma

Concluses sobre as ferramentas

Edio 29 - Engenharia de Software Magazine

e no mencionar como essa reunio deve ser tratada num

Uma abordagem para tratar o Daily Meeting

combinao permite um melhor acompanhamento da reunio,

Preenchimento das trs perguntas antes de comear a reunio

Controle da durao da reunio

Taskboard atualizvel em tempo real

Gerao do Sprint Burndown

Ambiente integrado a uma ferramenta de gerenciamento gil de projetos

criar um senso de equipe. E o chat importante para eventuais problemas da

Edio 29 - Engenharia de Software Magazine

D seu feedback sobre esta edio!

Com a crescente adoo do desenvolvimento gil distribudo,

quase 80% de aceitao. Os que obtiveram votos com menor