Edição36 2011

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.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
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
rocesso de software o conjunto de atividades que constituem o desenvolvimento de

um sistema computacional. Estas atividades so agrupadas em fases, como: definio de
requisitos, anlise, projeto, desenvolvimento, teste e implantao. Em cada fase so defi-
nidas, alm das suas atividades, as funes e responsabilidades de cada membro da equipe, e
como produto resultante, os artefatos. O que diferencia um processo de software do outro a
ordem em que as fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades presentes,
Ano 3 - 36 Edio - 2011
Impresso no Brasil
e os produtos entregues.
Com o crescimento do mercado de software, houve uma tendncia a repetirem-se os passos e
as prticas que deram certo. A etapa seguinte foi a formalizao em modelos de ciclo de vida. Em
outras palavras, os modelos de ciclo de vida so o esqueleto, ou as estruturas pr-definidas nas
Corpo Editorial
quais encaixamos as fases do processo. De acordo com a NBR ISO/IEC 12207:1998, o ciclo de vida
a Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operao
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
e manuteno de um produto de software, abrangendo a vida do sistema, desde a definio de

seus requisitos at o trmino de seu uso.
O modelo de ciclo de vida a primeira escolha a ser feita no processo de software. A partir
desta escolha definir-se- desde a maneira mais adequada de obter as necessidades do cliente,
Capa
Romulo Araujo - romulo@devmedia.com.br
at quando e como o cliente receber sua primeira verso operacional do sistema. No existe
um modelo ideal. O perfil e complexidade do negcio do cliente, o tempo disponvel, o custo, a
Diagramao
Janete Feitosa
equipe, o ambiente operacional so fatores que influenciaro diretamente na escolha do ciclo de
Coordenao Geral
Daniella Costa - daniella@devmedia.com.br
dos casos, v-se a presena de mais de um ciclo de vida no processo. Neste contexto, a Engenha-
Revisor
Gregory Monteiro - gregory@clubedelphi.net
Caroline Velozo - carolinelopes@devmedia.com.br
os Bastidores. Neste artigo sero apresentados alguns dos modelos de ciclo de vida mais comu-
vida de software a ser adotado.

Da mesma forma, tambm difcil uma empresa adotar um nico ciclo de vida. Na maior parte
ria de Software Magazine destaca nesta edio o artigo Ciclos de Vida do Software: Conhecendo
mente encontrados em processos de software: Cascata, Modelo em V, Incremental, Evolutivo,
RAD, Prototipagem, Espiral, Modelo de Ciclo de Vida Associado ao RUP.
Alm desta matria, esta edio traz mais sete artigos:
Jornalista Responsvel
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Gesto do bom humor

Agilidade na Prtica
Apoio
Aprimorando a Escrita de Casos de Uso

Introduo verificao de diagramas de classe Parte 2
Otimizao de Processos de Negcio usando BPM Parte 2
Aspectos importantes da gesto de projetos
Refatorao para Padres Parte 9
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:
Isabelle Macedo e Uellen Goulart 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 bvio
06 Gesto do bom humor
Glnio Cabral
Agilidade
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:
07 - Agilidade na Prtica
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Engenharia
15 - Aprimorando a Escrita de Casos de Uso
Fabrcio Cardim, Iuri Mendes e Rodrigo Oliveira Spnola
21 - Ciclos de Vida do Software

Ana Brbara Lins de Macdo e Rodrigo Oliveira Spnola
Tipo: Processo
Ttulo: Especificao de casos de uso na prtica Partes 26 a 30
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Definir requisitos no uma atividade trivial. Uma das
formas de realizar esta atividade atravs da especificao de casos de
uso. Neste sentido, nesta srie de vdeo aulas apresentaremos um conjunto
de especificaes de casos de uso. Os cenrios sero especificados passo
a passo considerando tpicos como fluxo principal, fluxo alternativo e
regras de negcios.
29 - Introduo verificao de diagramas de classe Parte 2

Waldemar Pires Ferreira Neto
45 - Otimizao de Processos de Negcio usando BPM Parte 2

Ricardo S. Ferreira
Desenvolvimento
51 - Refatorao para Padres Parte 9
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Edio 05 - Engenharia de Software Magazine
Por trs do bvio

Glnio Cabral
gleniocabral@yahoo.com.br
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
Gesto do bom humor
Engenharia de Software - Gesto do bom humor
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
D seu feedback sobre esta edio!
Feedback
eu
sobre e
s
Ser bem humorado no significa destilar gracinhas a torto

e a direito, e muito menos estar em permanente estado de
alegria. O sorriso forado e sem resultados de nada adianta,
por isso at na alegria devemos ser competentes. Ser bem
humorado significa estar aberto ao dilogo, admitindo os
erros e elogiando os acertos. Ser bem humorado promover
a motivao de todos atravs de critrios claros de avaliao,
bem como transparncia nas promoes. Ser bem humorado
fazer com que a comunicao seja clara e objetiva, sem espao
para rudos e boatos. Ser bem humorado fazer com os colaboradores no sintam medo de opinar e de criar, estimulando
assim a iniciativa de cada um. Ser bem humorado entender
que uma postura positiva traz dividendos, e uma postura
negativa traz prejuzos.
No preciso contratar os servios do Chico Ansio para que
uma empresa se torne mais feliz e produtiva. Medidas simples
e baratas podem fazer uma grande diferena nos ndices de
felicidade dos colaboradores. Para que isso acontea, cabe a
cada gestor implementar aes que visem a promoo de ambientes mais criativos e produtivos no seu dia-dia. Ambientes
que prezem pela competncia, seriedade e compromisso com
os resultados. Mas ambientes que tambm respeitem o riso, a
alegria, o respeito mtuo e o prazer de arriscar.
edio
ta
oc j ouviu falar em um artigo de luxo chamado sorriso? Isso mesmo, sorriso... aquele hbito descontrado de
elastecer as bochechas e expor a arcada superior numa
exploso de felicidade. Recentes pesquisas revelaram que as
pessoas de um modo geral esto sorrindo cada vez menos. As
razes para tal fenmeno? Empregos escassos, competitividade
acirrada, engarrafamentos, sobrecarga de trabalho e estresse,
alm de uma srie de fatores que juntos representam o lado
sombrio da chamada vida moderna.
Se o mau humor segue uma trajetria ascendente, ento todos
ns estamos expostos aos seus efeitos. Um deles, por exemplo,
a queda dos ndices de produtividade nas organizaes. Est
mais do que provado que um ambiente de trabalho leve e descontrado estimula a criatividade e viabiliza a existncia de relaes interpessoais mais saudveis. O problema que muitas
vezes o senso de humor visto como um inimigo da seriedade
com que os negcios devem ser geridos. E assim, para alguns
gestores, manter uma carranca corporativa ainda sinnimo
de compromisso e competncia na gesto empresarial.
Uma coisa certa: no precisamos de humoristas nas
empresas, e sim de gestores bem humorados. Humorismo
piadismo, anedota, gozao. Senso de humor uma
postura de leveza e energia diante da vida. No Brasil, ser
um piadista praticamente uma obrigao nacional. No
a toa que programas televisivos como Pnico na TV e CQC
alavancam os ndices de audincia de suas emissoras, tornando seus protagonistas verdadeiros heris nacionais. Mas
quando a conhecida comicidade brasileira se apresenta de
forma preconceituosa e vexatria, a linha tnue que separa o
engraado do inconveniente comea a ser desrespeitada.
E a, o humor perde a graa.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Agilidade na Prtica
Utilizando a ferramenta Sprintometer para apoiar a utilizao de
mtodos geis
De que se trata o artigo?
Este artigo aborda o tema gerncia de projetos utilizando metodologias geis e apresenta a ferramenta
Sprintometer utilizada para apoiar a utilizao de
mtodos geis.
Para que serve?
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Bacharel em Cincia da Computao pela FAGOC - Faculdade Governador Ozanam Coelho,

Microsoft Student Partners.

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.
processo de desenvolvimento de software possui vrias

etapas que a literatura tcnica
vem abordando ao longo dos anos. As
diferentes formas de se desenvolver
software nos dias atuais mostram que
entre as metodologias utilizadas esto
as metodologias tradicionais e as metodologias geis.
Metodologias geis como XP (Extreme
Programing) e Scrum so utilizadas por
diversas empresas de desenvolvimento
com o intuito de tornar seus processos
mais eficientes e geis quanto possvel,
no sentido de continuar dentro do oramento, efetuar as alteraes que as
mudanas nos requisitos exigem, entre
outras coisas, tudo isso dentro dos limites do projeto a ser desenvolvido.
Para mostrar os benefcios que o uso de ferramentas

pode trazer para o desenvolvimento gil de aplicaes.
Para isso, ser apresentado um estudo de caso para
ilustrar a criao de um projeto nesta ferramenta.
Em que situao o tema til?

O tema se torna fundamental para quem utiliza
alguma das metodologias geis, como XP e Scrum,
pois obtero conhecimento sobre como utilizar a
ferramenta Sprintometer para o gerenciamento de
seus projetos.
Para uma empresa aderir a mtodos

geis, na maioria das vezes, leva-se
em conta algumas das caractersticas
dessas metodologias geis, como produtividade, documentao reduzida
(mas no necessariamente eliminada),
utilizao de processos flexveis, entre
outras caractersticas. Independente da
Figura 1. Ferramenta Sprintometer
as aes do Scrum Team. Neste contexto, a ferramenta a ser

apresentada neste artigo permite ao Scrum Master realizar este
trabalho, mas antes de conhec-la, necessrio que alguns
conceitos importantes sobre a ferramenta sejam conhecidos.
A ferramenta Sprintometer
Figura 2. Projeto do tipo Scrum criado
metodologia gil a ser utilizada e da produtividade almejada,

a maioria das empresas busca obter um controle eficiente sobre
os seus processos, sobre a produo da equipe, sobre o processo
de desenvolvimento da soluo e sobre suas informaes.
Com base neste raciocnio, os adeptos de mtodos geis podem contar com uma srie de ferramentas que podem ser utilizadas para apoiar sua utilizao. Neste artigo sero abordados
alguns pontos importantes sobre a utilizao de ferramentas
nas diferentes etapas do processo de desenvolvimento de um
projeto. Tambm ser apresentada a ferramenta Sprintometer
para que o desenvolvedor possa apoiar parte do seu processo
de desenvolvimento de software. Para isso, um estudo de caso
ser utilizado, com o intuito de mostrar na prtica como definir
o escopo de um projeto usando Scrum, apoiado por alguns dos
principais recursos dessa ferramenta.
A utilizao de ferramentas CASE

O processo de desenvolvimento de uma aplicao pode contar
com uma srie de ferramentas conhecidas como ferramentas
CASE (Computer-Aided Software Engineering), que proporcionam
a automatizao das diferentes necessidades do projeto, como
controle do cronograma, controle dos requisitos referentes ao
projeto que se est trabalhando, criao de diferentes tipos de
diagramas de software, teste de software, gesto das mudanas, e at mesmo ambientes de desenvolvimento de software,
dentre outras necessidades.
Em projetos utilizando as metodologias Scrum ou XP, uma
ferramenta interessante seria a que permitisse, a exemplo do
Scrum, que o Scrum Master pudesse manter as informaes que
ele necessita sobre o projeto que se est trabalhando, e com isto
ganhar em produtividade e maior capacidade de monitorar
Engenharia de Software Magazine - Agilidade na Prtica
Sprintometer uma ferramenta livre utilizada para gerir

projetos que utilizam as metodologias geis Scrum ou XP.
Ela permite a definio do projeto como seus sprints, datas de
incio e fim do projeto, criao de cronograma, alocao de
pessoal nas tarefas, clculo de custo do projeto, comunicao
com outros aplicativos da Microsoft (como Excel), entre outras
funcionalidades.
O requisito mnimo para sua utilizao ter conhecimento
de uma das metodologias geis (XP ou Scrum) e gerenciamento de projetos. A abordagem que ser utilizada tem como
foco as pessoas que so responsveis por gerir os projetos da
empresa.
A especificao da ferramenta mostra que ela compatvel
com os sistemas operacionais Windows XP, Windows 2003 e
Windows Vista.
O primeiro passo da utilizao da ferramenta consiste em
fazer o download do arquivo zipado (link para download na
seo links), gratuitamente.
Aps, o arquivo dever ser descompactado. Em seu interior
h um executvel e dois arquivos de exemplo de utilizao da
ferramenta. O aplicativo no necessita ser instalado. A Figura 1
mostra a tela principal da ferramenta.
Inicialmente cria-se um novo projeto, clicando no boto
redondo no canto superior esquerdo da ferramenta, e em
seguida, em Novo. Uma janela aberta, onde so passadas
algumas informaes referentes ao projeto que se deseja criar.
No combobox deve-se escolher o tipo de metodologia gil
que se pretende utilizar. Neste artigo ser utilizado Scrum. A
Figura 2 mostra o projeto criado.
Estudo de caso: Gerenciando o projeto Hotel Master

A partir deste momento ser utilizado um estudo de caso para
ilustrar a aplicabilidade prtica da ferramenta Sprintometer. O
projeto a ser gerenciado utiliza Scrum como metodologia gil,
e leva o nome de Projeto Hotel Master.
O prximo passo inserir um nome para o projeto criado.
Na aba General, no campo name (ver Figura 2) insere-se o nome
do projeto: Projeto Hotel Master. O Agile Project Type, ou seja,
o tipo do projeto gil, j foi definido quando o novo projeto
foi criado. Em Estimation Units (Unidade de estimativa, local
M etodologias geis
onde se define o tipo de estimativa a cerca do projeto) deve-se

escolher como seu projeto ser concebido: se em medida de
horas ideais, onde no melhor caso ser concludo dentro do
planejado, Normal Hours (horas normais), para o caso onde se
considera um cronograma mais flexvel, com uma margem de
sobra, Function Points, para projetos monitorados por pontos
de funo, Days para projetos medidos por dias de trabalho,
entre outros. Para este estudo de caso ser utilizada a medida
Ideal Hours.
Work Types uma funcionalidade importante. nela que se
definem os tipos de trabalho que o projeto necessita. Tais tipos
a serem definidos podem variar de projeto para projeto. Isto
em alguns casos depende da viso do Scrum Master sobre o
projeto e como ele ser dividido para ordenar o Scrum Team.
Os work types que j esto definidos so Coding (codificao)
e Testing (teste), partindo do princpio que todos os projetos
tero etapas de codificar e de testar. Outros tipos podem ser
definidos pelo Scrum Master. Para o projeto Hotel Master sero
criados os work types Analisar e Documentar, clicando em add,
inserindo o nome do work type e deixando o Check Box checado.
Aplique todas as alteraes e salve o projeto em uma pasta
desejada. O resultado pode ser visto na Figura 3.
desenvolvimento do projeto. Aplicando as alteraes, tem-se

um resultado semelhante ao da Figura 5.
Criando tarefas para o sprint

O prximo passo consiste em inserir as tarefas pertencentes
histria Levantando Requisitos. Com o boto direito sobre
ela, em add Task tem-se o identificador da tarefa que est sendo
criada (Task No). No campo Name inserido Conversa com o
administrador da empresa. No campo Description coloca-se
a informao: Nesta conversa so obtidas informaes que
constituiro os requisitos de acordo com as necessidades do
administrador. No campo Initial Estimation (Estimativa Inicial)
atribui-se para a tarefa de conversar com o administrador um
valor. Tal informao deve ser num total de horas, dado que no
incio do projeto foi escolhida a opo Ideal Hours. O valor 3
Criando um sprint para o projeto

Com o boto direito do mouse no projeto (painel do lado
esquerdo da ferramenta) faz-se um clique na opo add Sprint.
Ela permite que um novo sprint seja adicionado no projeto que
est sendo criado.
Em projetos geis com Scrum so definidos sprints de acordo
com o projeto que se est desenvolvendo, dadas as tarefas que
devero ser realizadas. Para este projeto ser criado um sprint
de nome Primeiro Sprint (campo name). Em seguida, deve-se
definir uma data de incio e uma data de fim para o sprint recm
criado. Ser considerado um sprint de 10 dias teis, dado que
a equipe trabalhar apenas de segunda a sexta, com incio no
dia 11 e trmino no dia 22 de abril de 2011.
Ao selecionar a data inicial e data final, os dias so listados.
Dias em vermelho so finais de semana. No caso deste projeto
eles devem ser selecionados e movidos para a lista a direita,
chamada de No Work Dates (dias que no so trabalhados).
Abaixo do campo name, define-se a data do ltimo dia do sprint
(no caso 22 de abril), onde sero reportadas as tarefas que foram
realizadas durante o sprint. Clicando em aplicar salvam-se as
alteraes realizadas. A Figura 4 mostra o resultado.
Com o boto direito no Primeiro Sprint, lado esquerdo da ferramenta, adiciona-se uma histria (opo add Story). Esta opo
permite criar um cenrio dentro do sprint que acabara de ser
criado. No campo ID Story (identificador da histria) insere-se
01. O nome do cenrio Levantando Requisitos (campo name).
No campo Priority (prioridade) pode ser definido a prioridade
que tal cenrio tem sobre os outros, adotando a escala de 0 a 5,
onde 5 a maior prioridade. Para este cenrio, insere-se prioridade nvel 5. Em Description (Descrio do cenrio), utilizado
o seguinte texto: Esta etapa caracterizada pelas entrevistas
com os Stakeholders, onde informaes sero coletadas para o
Figura 3. Projeto Hotel Master
Figura 4. Primeiros passos na criao do sprint
atribudo, o que quer dizer que as 3 primeiras horas do projeto

sero para conversar com o administrador para obteno de
informaes. Na opo Work Type (tipo de trabalho que se refere
tarefa), define-se Analisar. A Figura 6 ilustra as mudanas.
Ainda no cenrio Levantando Requisitos, uma nova tarefa
adicionada. Em Name, tem-se a informao Conversa com
Figura 5. Criando o Primeiro Sprint
Figura 6. Criando a primeira tarefa
Figura 7. Cenrio Levantando Requisitos completo
Figura 8. Hierarquia do sprint at o momento
10
a secretria. Em Description, a informao: Nesta conversa

so obtidas informaes do ponto de vista da secretria, que
operar o sistema do Hotel. Em Initial Estimation definido
2 horas, e em Work Type, Analisar. O resultado do primeiro
cenrio completo (Story) pode ser visto na Figura 7.
medida que as tarefas forem sendo cumpridas, novas outras vo aparecendo, derivadas muitas das vezes das tarefas
anteriores. Na sequncia, adicionado ao Primeiro Sprint o
cenrio de nome Definindo o Projeto, cujo id 02, prioridade
um pouco menor que o cenrio anterior, portanto 4. Na descrio, a informao Os dados levantados no primeiro cenrio
serviro para gerar a documentao do projeto ser inserida.
As alteraes devem ser aplicadas.
No cenrio Definindo o projeto recentemente criado,
adiciona-se uma nova tarefa. Suas informaes so: Definir
diagramas de caso de uso cuja descrio Criar casos de uso
com base nos requisitos levantados, estimativa inicial de 4 horas, e tipo de trabalho Documentar. Outra tarefa adicionada,
cujo nome Definir diagramas de classe, descrio Criar
diagramas de classe com base nos requisitos levantados,
tempo estimado de 4 horas e tipo de trabalho Documentar. A
Figura 8 mostra a hierarquia criada at o momento.
Um novo cenrio adicionado ao Primeiro Sprint (boto
direito no sprint, add Story). Entre as propriedades esto id
03, nome Implementando o sistema, prioridade 3, descrio
Inicia-se a implementao do projeto.
A primeira tarefa a ser criada a de separar os componentes
a serem utilizados, portanto a nova tarefa deve ter no campo
nome o texto Componentes Utilizados, em descrio Tarefa
de separar os componentes que sero utilizados no sistema,
como conexo ao banco de dados entre outros, Estimativa
Inicial 3 horas e tipo de trabalho Coding (Codificar).
A prxima tarefa, ainda em Implementando o projeto, possui
nome Gerar Script do Banco de Dados, descrio Nesta
tarefa gerado o banco de dados com base nas informaes
obtidas no levantamento de requisitos, com estimativa de 8
horas e tipo de trabalho Coding. A Figura 9 permite ter uma
viso geral das tarefas do sprint (lado direito da imagem) e
tambm as informaes da ltima tarefa criada.
As duas prximas tarefas envolvem a implementao e teste
do primeiro caso de uso do sistema. Para esse projeto ser
considerado que, se houvessem mais sprints, os demais casos
de uso seriam implementados neles. Este projeto ter apenas o
Primeiro Sprint, a fim de mostrar como so as funcionalidades
da ferramenta.
Os dados das duas prximas tarefas so nome Implementar
UC1, descrio Implementao do caso de uso numero 1,
estimativa inicial de 46 horas e tipo de trabalho Coding (para
a tarefa de implementar); e nome Testar UC1, descrio Tarefa de testar o caso de uso 1, estimativa de 10 horas e tipo de
trabalho Testing (para a tarefa de testar o caso de uso). A Figura
10 mostra o resultado do Primeiro Sprint com suas tarefas.
Ainda na Figura 10 (aba General quadro Estimate) possvel
visualizar o tempo total atribudo ao projeto, que de 80 horas. No incio da criao do projeto foi definido que o sprint
M etodologias geis
teria 10 dias, com jornada de 8 horas. O cronograma mostra

que as atividades fecharam exatamente o valor. medida
que o cronograma for atrasando, se for o caso, ele dever ser
atualizado. Sendo assim, o Scrum Master consegue ter uma
viso inicial sobre a concluso do sprint, se terminar na data
certa ou no.
do sprint, Conversa com o administrador da empresa, aparecer do lado direito uma tabela, abaixo do groupbox Work Type.
A Figura 13 mostra como devem ser definidas as horas para
a primeira tarefa no cronograma.
Alocando pessoas ao projeto

Outra importante funcionalidade est ligada a atribuio
de tarefas. O primeiro passo adicionar a equipe ao projeto,
e depois aloc-la nas tarefas. Clicando em Primeiro Sprint, na
aba Resources & Budget (Recursos e Oramento) existe um boto
chamado add Resource (adicionar recursos). Adiciona-se ao
Scrum Team um analista (campo name) rotulado como Analista
de Negcio com tipo (Type) Analisar (mostra a funo que ele
exerce) e Hourly Rate (carga horria de trabalho) de 8 horas por
dia (ver Figura 11). Adiciona-se ainda um desenvolvedor de
nome Desenvolvedor Joo, tipo de trabalho Coding, jornada
diria de 8 horas, outro desenvolvedor de nome Desenvolvedor Marcos, tipo Coding, 8 horas de jornada diria e, por
ltimo, um testador, com nome Testador Lucas tipo Testing,
8 horas dirias de trabalho.
Aps inserido o Scrum Team no projeto, resta atribuir as
tarefas existentes no projeto para quem de dever realiz-las.
A Figura 12 ajudar no entendimento.
Clicando sobre a tarefa Conversa com o administrador da
empresa, na aba General, na opo chamada Assigned to (atribudo para) deve ser escolhido Analista de Negcio. Ele ficar
responsvel por executar essa tarefa.
Nas demais tarefas do sprint o mesmo deve ser feito. Para
Conversa com a secretria, atribudo ao Analista de Negcio. As tarefas Definir diagramas de caso de uso e Definir
diagramas de classe tambm so destinadas ao Analista de
negcio, enquanto as tarefas Componentes Utilizados e
Gerar Script do Banco de Dados so atribudas ao Desenvolvedor Joo, e a tarefa Implementar UC1 atribuda ao
Desenvolvedor Marcos. Finalizando, a tarefa Testar UC1
pertence ao Testador Lucas.
Figura 9. Viso geral das tarefas do sprint.
Figura 10. Primeiro Sprint com suas tarefas
Definindo o cronograma do projeto

Continuando com o gerenciamento do projeto Hotel Master,
um prximo passo importante
est relacionado ao cronograma.
indispensvel saber quantas horas
cada tarefa ir gastar dos 10 dias
inicialmente planejados para o
Primeiro Sprint. Para essa tarefa,
necessrio carregar o cronograma
com as devidas informaes. Iniciando o processo, primeiramente
vai-se tabela onde os dados sero
inseridos para cada tarefa. Tais
tabelas podem ser vistas ao clicar
sobre cada tarefa.
Comeando com a primeira tarefa Figura 12. Atribuindo funes
Figura 11. Inserindo um membro da equipe ao projeto
11
Para obter uma tabela igual da Figura 13, algumas informaes devem ser entendidas. Na tabela, as colunas da segunda
em diante indicam os dias que o sprint ir durar, como definido no incio do projeto. Work Day a contagem dos dias que
o sprint ir durar, do primeiro ao dcimo dia, no caso deste
projeto. Done % a porcentagem de trabalho concludo relativo
para aquela tarefa. Isto permite saber se a tarefa foi feita pela
metade ou j est finalizada. Done today/to do so as horas trabalhadas da tarefa em questo, e as horas da estimativa inicial
Figura 13. Criando o cronograma do projeto - Primeira Tarefa
de tempo a ser gasto na tarefa. Como a tarefa Conversar com

o administrador da empresa a primeira tarefa do sprint,
ento ela ocupar as trs primeiras horas do primeiro dia do
sprint (Apr 11). Editando a clula, adiciona-se 0/3, referindo-se
tarefa que ser realizada em 3 horas. O zero representa que
ainda no comeou a realizao da tarefa. O mesmo deve ser
feito com as demais tarefas. A Figura 14 mostra a definio
do cronograma referente segunda tarefa, Conversa com a
secretaria.
Na segunda tarefa so inseridas as 2 horas que a tarefa ir
gastar ainda no primeiro dia do sprint (Apr 11), visto que a
soma das tarefas anteriores no gastou as 8 horas a serem
trabalhadas, isto , a primeira tarefa s gastou as 3 primeiras
horas do primeiro dia do sprint.
A terceira tarefa Definir Diagramas de Caso de Uso, como
mostra a Figura 15, tem estimativa inicial de gastar 4 horas.
Como a soma das tarefas anteriores consome 5 horas do primeiro dia do sprint, ento define-se que sero necessrias as
3 ltimas horas do primeiro dia mais 1 hora do segundo dia,
como pode ser visto na figura.
As Figuras 16 a 20 mostram como foram definidas as horas
no cronograma para as demais tarefas do sprint, respectivamente representando as tarefas Definir Diagramas de Classe,
Componentes Utilizados, Gerar Script do Banco de Dados,
Implementar UC1, Testar UC1.
Uma tabela com a viso geral do cronograma pode ser vista
ao clicar sobre o Primeiro Sprint, na aba Stories, como mostra
a Figura 21.
As clulas em vermelho mostram que 0% das horas das
tarefas foram gastas. Isto verdade, j que nesta etapa est se
definindo o cronograma, no a realizao das tarefas.
Figura 14. Criando o cronograma do projeto - Segunda Tarefa
Figura 15. Criando o cronograma do projeto - Terceira Tarefa
Figura 16. Criando o cronograma do projeto - Quarta Tarefa
12
Figura 17. Criando o cronograma do projeto - Quinta Tarefa
Figura 18. Criando o cronograma do projeto - Sexta Tarefa
M etodologias geis
Definindo o oramento do projeto
mostra que ele trabalhou 0.625 % do segundo dia no projeto,

Aps a definio do cronograma, chegado o momento
que representa 5 horas de jornada. O Desenvolvedor Joo,
de definir o oramento do projeto. Clicando no Primeiro
por sua vez, entrar no projeto assim que o analista terminar
Sprint, na aba direita chamada Resource & Budget possseu trabalho.
vel atribuir custos ao projeto. A Figura 22 mostra a tabela
A segunda clula da linha do Desenvolvedor Joo mostra
depois de definido o oramento.
que ele trabalhou 0.375 % das horas restantes do segundo
Antes de comear a entender os dados inseridos na tabela,
dia no projeto, que na prtica representam 3 horas. Em
alguns pontos devem ser recordados. Quando a equipe foi
alocada no projeto, foi definido um valor de 8 horas para
os alocados, o que significa que eles possuem jornada de 8
horas na empresa (ver Figura 11). Quando o cronograma foi
definido, cada membro do Scrum Team foi designado a uma
tarefa do projeto num dia pr determinado, com uma certa
quantidade de horas especficas. Portanto, no projeto deve
constar o valor que ser gasto com as horas que cada membro
do Scrum Team estiver trabalhando neste projeto.
Como exemplo, considera-se que o Analista de Negcio
ganha R$ 10,00 por hora de trabalho, logo R$: 80,00 por dia
Figura 19. Criando o cronograma do projeto - Stima Tarefa
trabalhado, enquanto os dois desenvolvedores ganham R$
5,00 por hora, logo R$ 40,00 por dia cada um. Por sua vez, o
Testador Lucas ganha R$ 6,00 por hora, somando R$ 48,00
por dia trabalhado. Relembrando que o Analista de negcio est alocado por 13 horas no projeto, o Desenvolvedor
Joo por 11 horas, o Desenvolvedor Marcos por 46 horas e
o Testador Lucas por 10 horas, possvel chegar a um oramento preciso. Ciente dessas informaes parte-se para o
entendimento do oramento definido.
Na Figura 22, tm-se as informaes Date, representando
os dias do Primeiro Sprint, Work Type representando os
Figura 20. Criando o cronograma do projeto - Oitava Tarefa
dias de trabalho, Sum budget que
a soma dos valores que cada dia de
trabalho ir custar para o projeto, o
que significa que a cada clula verde
a soma do dia atual mais a soma
dos anteriores. As clulas em azul
representam os valores em reais da
hora de cada um dos membros do
projeto, como definido anteriormente. Hourly Rate/ Daily Budget referese aos valores em reais referentes
ao tempo dirio de trabalho de cada
membro mediante o custo do seu
perodo de trabalho naquele dia.
Para simplificar o entendimento, Figura 21. Criando o cronograma do projeto - Tabela completa
considera-se os valores das clulas
em tom de cinza com pequenas
bolinhas pretas: a linha do Analista
de negcio quer dizer que ele est
alocado no projeto para trabalhar
no primeiro dia e no segundo dia.
O numero 1 da primeira clula do
Analista de negcio representa que
ele trabalhou no projeto durante
todo o dia, ou seja, 8 horas. A segunda clula do Analista de Negcios Figura 22. Tabela Resource & Budget
13
Sprintometer possui tambm a funcionalidade Exportar para

Excel (menu principal, Excel Workbook). Essa funo permite
que as tabelas geradas pela ferramenta, bem como os grficos,
possam ser exportadas para o Microsoft Excel e sejam manipuladas da forma desejada. Ainda sobre exportar dados, tambm
Download da ferramenta Sprintometer

http://sprintometer.com/
14
Gerenciar projetos de software no uma tarefa simples,

visto que so vrios os pontos que se deve manter controle para
que o projeto no fracasse, principalmente no que diz respeito
ao tempo acordado entre as partes envolvidas no projeto e ao
oramento planejado, evitando assim que o projeto sai mais
caro do que o vendido.
Ter um ponto onde o Scrum Team pode verificar o andamento
do projeto fundamental, visto que se diminuem os riscos,
como o de alocar um membro em outro projeto, quando ele j
est alocado em outro na data pretendida.
Conhecidas as tarefas do projeto, estabelecer o cronograma
e calcular os custos utilizando Sprintometer uma tarefa que
pode ser amenizada, mediante o fato de que as informaes
esto ao alcance dos responsveis por mant-las.

Feedback
eu
sobre e
s
Links
Concluso
D
s
Integrao com o Microsoft Excel
permitido salvar o projeto como arquivo XML, o que torna

vivel a manipulao dos dados por outra ferramenta que
trabalhe com esse formato.
edio
ta
contrapartida, no terceiro dia do sprint ele ficar responsvel

por trabalhar 8 horas no projeto (numero 1 representa jornada
completa, 100% das horas do dia em questo). O Desenvolvedor Marcos entrar no projeto a partir do dia 14 (Apr 14),
alocado por todo o dia, at o dia 21, onde ter que trabalhar
por cerca de 0.75% do dia no projeto, ou seja, 6 horas. O resto
do sprint pertence ao Testador Lucas, que est alocado por
0.25% do dia na data de 21 de abril (2 horas no total) e por
8 horas no dia 22 (representado pelo numero 1). As demais
clulas com um trao (-) representam que os membros da
equipe esto disponveis para outros projetos (tambm pode
ser representado por zero).
Finalizando a entrada desses dados, possvel ter uma soma
referente ao valor total do projeto, no que se refere a custo de
mo de obra. O valor total do Primeiro Sprint, que comea no
dia 11 e termina no dia 22 de abril de R$ 475,00.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Aprimorando a escrita de casos de uso
Fabrcio Cardim
ffcardim@gmail.com
Ps-Graduando em Engenharia de Software

e bacharel em Cincia da Computao pela
Faculdade Ruy Barbosa. Arquiteto e Projetista de Sistemas na Fbrica de Software da
Avansys Tecnologia (www.avansys.com.br)
com mais de quatro anos de experincia em
desenvolvimento de sistemas Web.
Iuri Mendes
Imendes2kx@gmail.com
Ps-Graduando em Engenharia de Software

e bacharel em Cincia da Computao pela
Faculdade Ruy Barbosa. Atua como desenvolvedor na Fbrica de Software da Avansys
Tecnologia (www.avansys.com.br).
Rodrigo Spnola
rodrigo@sqlmagazine.com.br
Doutor e Mestre em Engenharia de Software

pela COPPE/UFRJ.
Diretor de Operaes Kali Software
(www.kalisoftware.com)
Editor Chefe SQL Magazine | WebMobile |
Engenharia de Software Magazine
Professor do Curso de Ps-Graduao em
Engenharia de Software da Faculdade Ruy
Barbosa.
cada fase do ciclo de vida

do software produzimos um
documento contendo uma representao distinta do software a ser
construdo. Cada um desses documentos
representa o software em um determinado nvel de abstrao. A tendncia
diminuirmos o nvel de abstrao atravs da incluso de mais e mais detalhes,
at que, sua ltima representao seja o
cdigo fonte na linguagem escolhida.
Um dos artefatos produzidos no incio
do processo de desenvolvimento de software a sua especificao de requisitos.
Ele base para as demais atividades
de desenvolvimento e sua qualidade
fundamental para o sucesso do projeto.
Uma especificao de requisitos bem elaborada pr-requisito para um software
de qualidade, embora no seja garantia
disso. Desta forma, durante a produo
de requisitos devemos possuir, alm das
atividades essenciais de levantamento e
especificao, atividades relacionadas
garantia da qualidade.
Neste contexto, esse artigo aborda
tpicos relacionados boa prtica da
escrita de casos de uso no processo
Esse artigo aborda tpicos relacionados boa prtica

da escrita de casos de uso no processo de especificao
de requisitos. Nele descrito como os casos de uso devem atender a necessidades especficas de diferentes
partes interessadas.
Para que serve?

Um dos artefatos produzidos no incio do processo de
desenvolvimento de software a sua especificao
de requisitos. Ele base para as demais atividades de
desenvolvimento e sua qualidade fundamental para
o sucesso do projeto.

Na melhoria da forma como trabalhamos com a
especificao de requisitos do software atravs de
casos de uso.
de especificao de requisitos. Nele

descrito como os casos de uso devem
atender a necessidades especficas de
diferentes partes interessadas. Tambm
so apresentados alguns modelos de
casos de uso (vantagens e desvantagens)
e alguns pontos importantes que devem
ser considerados durante o processo de
escrita. Por fim, so detalhados alguns
15
problemas comuns em casos de uso e fatores de melhorias para

se aprimorar a escrita.
Casos de uso
Casos de Uso so documentos importantes para construo
de sistemas. Eles descrevem o comportamento que este sistema
dever ter sob diversas condies. Os casos de uso so documentos geralmente criados na forma de texto e servem como
meio de comunicao entre partes envolvidas no projeto.
Um caso de uso bem escrito fcil de ler. Ele consiste de sentenas
escritas em uma nica forma gramatical um passo de ao simples
na qual um ator alcana um resultado ou transmite informao
para outro ator. Aprender a ler um caso de uso no deve tomar mais
do que uns poucos minutos. (Cockburn, 2001)
A utilizao de casos de uso na especificao de requisitos
deve levar em considerao os interesses das partes envolvidas
(stakeholders). Veremos como a especificao importante na
execuo das atividades dos stakeholders.
Existem diversas situaes onde casos de uso so utilizados e
por esse motivo preciso que sua forma de escrita seja variada.
Essa variao no estilo da escrita dos casos de uso pode tornar
a leitura um tanto confusa. Isso faz com que alguns problemas
acabem surgindo na etapa de especificao de requisitos e veremos alguns fatores que devem ser levados em considerao
para tentar diminuir a ocorrncia desses problemas.
No existe regra para escrever casos de uso, mas existem
alguns modelos que so padres de mercado e so comumente utilizados. Neste artigo vamos comentar sobre dois
desses modelos.
Para isto, este artigo foi divido nas seguintes sees: Especificao de requisitos atravs de Casos de Uso, Stakeholders e seus
interesses, Estilos de escrita de casos de uso, Modelos de casos
de uso, Problemas comuns, Fatores de Melhoria, Concluso.
Figura 1. Interessados na especificao de requisitos
16
Especificao de requisitos atravs de Casos de Uso

Muitas organizaes podem adotar casos de uso com o propsito de capturar e modelar requisitos funcionais conhecidos
de um sistema. Isso pode levar a organizao a produzir casos
de uso de maior qualidade, mais completos e organizados.
Cockburn referencia uma abordagem sugerida por Steve
Adolph, chamada mergulho-e-superfcie.
Crie um modelo amplo e de alto nvel de como acha que o novo
sistema deve trabalhar. Mantenha as coisas simples, j que isto um
novo territrio. Descubra com o qu o cenrio de sucesso principal
deve parecer. Caminhe atravs dele com os antigos especialistas do
domnio.
Ento mergulhe nos detalhes de um caso de uso. Considere as
alternativas. Tire vantagem do fato de que acham isso fcil para
compreender histrias, para descobrir requisitos esquecidos. Leia um
passo num caso de uso e faa a pergunta: Bem, o que acontece se o
cliente quiser uma cpia concreta ao invs de uma cpia digital da
prova?. Isto mais fcil do que tentar montar um completo modelo
mental de como o sistema trabalha.
Finalmente, volte superfcie. O que mudou agora que voc mergulhou nos detalhes? Ajuste o modelo, ento repita o mergulho com
outro caso de uso. (Cockburn, 2001)
Atravs dos casos de uso possvel especificar o comportamento de um sistema e descrever o cenrio de como
a entidade externa interage com ele. Considere entidade
externa tudo aquilo que interage com o sistema e que no
faz parte dele.
Stakeholders e seus interesses

Cada sentena em um caso de uso est l porque descreve
uma ao que protege ou favorece algum interesse de algum
stakeholder. Stakeholders so todas as partes envolvidas no
processo de desenvolvimento do software. Na Figura 1 podemos destacar alguns exemplos de stakeholders que possuem
interesses na especificao de casos de uso para a realizao
de suas atividades.
Abaixo temos o interesse de cada stakeholder no documento
de requisitos:
Cliente: Validar se o que foi especificado atende a sua necessidade de negcio. A aprovao desse documento por parte
do cliente a garantia de que o software ir atender as suas
expectativas, na maioria das vezes.
Analista de Testes: Planejar os testes que sero executados e
criar os casos de testes para cada funcionalidade do sistema.
O analista de testes tambm ajuda na descoberta de algumas
falhas que podem ocorrer durante a especificao.
Arquiteto de software: Identificar as entidades que compem o sistema e como elas devem se relacionar. O arquiteto
responsvel por transformar um conjunto de palavras em
componentes de software atravs de diagramas.
Desenvolvedor: Extrair as funcionalidades do sistema levando em considerao campos, regras de negcio e fluxo de telas.
Para o desenvolvedor, as regras devem estar bem especificadas
para evitar ambigidades. Tambm ajuda na descoberta de
algumas falhas na especificao.
Engenharia de Software Magazine - Aprimorando a escrita de casos de uso
Engen haria de Requisitos
A parte mais difcil escrever uma especificao de casos de

uso que atenda os stakeholders e que seja de fcil leitura e entendimento para todos.
Estilos de escrita de Casos de Uso

No momento da especificao devemos levar em considerao
as diferentes necessidades das partes interessadas no projeto.
Uma especificao para o cliente no pode tratar de detalhes
tcnicos de arquitetura e tecnologia, deve descrever bem as
funcionalidades e as regras do negcio. O cliente um leitor, que
requer uma descrio em alto nvel do sistema, menos tcnica e
de mais fcil leitura.
J o profissional de TI, seja ele um arquiteto, analista de teste, ou
um desenvolvedor, tem interesse em um documento mais tcnico
que descreva em detalhes o que dever ser construdo. Quanto
mais detalhes tcnicos forem abordados, como: componentes,
tecnologias, padro de interface, tipos de dados, mais fcil ser a
leitura e o entendimento da equipe tcnica.
Diante dessa situao podemos classificar casos de uso em
trs estilos:
Foco no Cliente: No possui detalhes tcnicos, linguagem de
alto nvel e de fcil leitura para pessoas que no so da rea de TI.
Esse tipo de caso de uso dificulta o processo de desenvolvimento,
porm, facilita a comunicao com o cliente.
Intermedirio: No entra em detalhes sobre tecnologia e arquitetura, porm j possuem algumas referncias a tabelas de banco
de dados e algumas regras de sistemas. Por ser um mescla dos
outros dois, um bom estilo a ser adotado.
Foco no Desenvolvedor: Possui detalhes de tecnologia e arquitetura o que dificulta a leitura por parte de uma pessoa que no
seja da rea de TI. Em contrapartida aumenta a produtividade
da etapa de desenvolvimento.
O estilo de caso de uso que dever ser adotado para o desenvolvimento do sistema aquele com o qual autores e leitores se sentem
mais confortveis. Para isso, interessante estabelecer padres de
escrita e definir modelos (templates) para especificao de casos
de uso. recomendado que seja adotado mais de um modelo de
caso de uso na organizao. Apenas um template de caso de uso no
suficiente. Devem existir pelo menos dois: um casual para projetos de
pouco formalidade e um inteiramente completo para projetos de maior
formalidade. Qualquer projeto ir adaptar uma das duas formas para
sua situao. (Cockburn, 2001)
Modelos de Casos de Uso

Existem vrios formatos para escrita de casos de uso:
Casos de uso completos, com uma coluna de texto, passos
numerados e sem uso da expresso se.
Casos de uso casuais, com uma breve definio do ator primrio, escopo e nvel, e a descrio do comportamento do sistema
em poucas linhas.
Casos de uso em tabelas de uma ou duas colunas.
Os estilos de escrita e elementos dos casos de uso tambm so
diversos. Mas preciso tomar cuidado para que a legibilidade
dos casos de uso no seja prejudicada. Linhas de tabelas podem

obscurecer a escrita real de casos de uso, enquanto que o excesso
de sentenas torna a escrita difcil de entender. Deve-se levar
em conta que at mesmo o vocabulrio daquele que escreve
diferente daquele que l o documento.
Neste artigo vamos apresentar dois modelos de como escrever
o fluxo de eventos em um caso de uso. As outras informaes
que devem compor um caso de uso foram omitidas, pois so bem
semelhantes em ambos os modelos. Vamos utilizar como exemplo
a funcionalidade de Manter Equipamento de um sistema de
gesto de eventos.
No modelo apresentado na Tabela 1 as iteraes entre atores
e o sistema so descritas em passos enumerados. Esse modelo
torna a leitura do caso de uso mais simples, porm, a depender
a complexidade, acaba deixando o caso de uso desorganizado.
Nas Tabelas 2, 3 e 4 os requisitos so traduzidos para casos de
uso em forma de tabelas. Esse modelo dificulta bastante a leitura,
porm bem organizado.
No existe melhor nem pior, a deciso de qual modelo adotar
deve ser um acordo entre o cliente e a empresa que ir desenvolver
levando em considerao fatores como: experincia da equipe de
desenvolvimento no modelo proposto, experincia dos analistas
de requisitos e o conhecimento do cliente em TI.
Problemas comuns em Casos de Uso

Um padro IEEE (IEEE 830, 1998), que recomenda prticas
para especificao de requisitos de software, define atributos
de qualidade que um documento de requisitos deve possuir.
Foi considerado que a falta de qualquer um destes atributos
constituiria um tipo de defeito. Assim, a seguinte taxonomia
foi definida:
Omisso
Escrever casos de uso uma tarefa cansativa e, por vezes, o
autor tem o descuido, talvez pelo cansao, de omitir informaes importantes no documento. Essas informaes podem
ser: uma mscara para um campo de cadastro; uma regra
de negcio para validar uma informao; uma exceo para
um comportamento indesejado; uma mensagem de erro importante para alertar o usurio de algo errado que ele tenha
realizado. Omisso certamente algo que exigir retrabalho,
e a depender do responsvel pela omisso, ir gerar custos ou
para o contratante ou para o contratado.
Ambiguidade
O vocabulrio de quem escreve quase nunca o mesmo de
quem l, e por esse motivo, normal que, por vezes, diferentes
leitores tenham diferentes interpretaes de um mesmo tpico
no caso de uso. No entanto, no nem um pouco desejvel que
interpretaes erradas ocorram, uma vez que um comportamento falho pode ser implementado no sistema. Tanto leitor
quanto autor podem contribuir para que esse problema ocorra.
O autor deve usar uma linguagem mais clara e descritiva, mas
sem dar muitas voltas. O leitor deve ler todo o caso de uso e
anotar dvidas antes de comear a desenvolver o sistema.
17
1. Fluxos de Eventos:
1.1. Fluxo Bsico
1. Este caso de uso se inicia quando o ator do sistema seleciona no menu a opo Equipamento;
2. O sistema exibe a tela Pesquisar Equipamento;
3. O sistema apresenta os parmetros de filtros; [INF01]
4. O sistema exibe uma listagem com todos os Equipamentos j cadastrados; [INF02] [RN1]
5. O ator escolhe uma das opes disponveis:
5.1. Voltar ao menu principal [A1]
5.2. Alterar Equipamento [A2]
5.3. Incluir Equipamento [A3]
5.4. Pesquisar Equipamento [A4]
6. O caso de uso finalizado.
1.2. Fluxo Alternativo
[A1] Voltar ao menu principal
1. O sistema volta para a tela principal;
[A2] Alterar Equipamento
1. O sistema exibe a tela Equipamento;
2. O sistema disponibiliza os dados para alterao; [INF03]
3. O ator preenche os dados do Equipamento;
4. O ator seleciona a opo Salvar; [A5] [E1] [E2]
5. O sistema registra todos os dados de Equipamento informados; [E2]
6. O sistema apresenta mensagem de finalizao,Alterao realizada com sucesso.;
7. O fluxo alternativo finalizado.
[A3] Incluir Equipamento
1. O sistema exibe a tela Equipamento;
2. O sistema apresenta os parmetros para incluso do novo Equipamento; [INF03]
3. O ator preenche os dados de Equipamento;
4. O ator seleciona a opo Salvar; [A5] [E1] [E2]
5. O sistema grava as informaes preenchidas;
6. O sistema apresenta mensagem de finalizao;Incluso realizada com sucesso;
7. O fluxo alternativo finalizado.
[A4] Pesquisar Equipamento
1. O ator preenche pelo menos uma das informaes; [INF01]
2. O ator seleciona a opo Pesquisar; [E2] [E3]
3. O sistema exibe a lista de Equipamento, a partir dos parmetros informados; [INF02]
[A5] Voltar
1. O ator seleciona a opo Voltar;
2. O sistema desconsidera os dados informados pelo ator;
3. O sistema volta para o fluxo bsico.
1.3. Fluxo de Exceo
[E1] Campos obrigatrios
1. O sistema verifica o preenchimento dos campos obrigatrios;
2. Para campo obrigatrio no preenchido, o sistema exibe a mensagem [nome do campo] obrigatrio!;
3. O sistema retorna ao fluxo que o originou.
[E2] Falha de acesso aos dados
1.O sistema exibe a mensagem de notificao No foi possvel realizar esta operao. Falha de acesso aos dados.;
2. O sistema retorna para o fluxo bsico.
[E3] Pesquisa sem resultados
1. O sistema identifica que nenhuma informao foi localizada para os parmetros informados;
2. O sistema exibe a mensagem;Nenhum dado foi localizado para os parmetros informados;
3. O sistema retorna para o fluxo bsico.
Tabela 1. Modelo de Passos enumerados
18
Inconsistncia
A tarefa de escrever casos de uso, por vezes,
repetitiva, pode levar o autor a repetir requisitos de outros casos de uso. Uma vez que isto
ocorre, este requisito herdado pode vir a
conflitar com os requisitos nativos ao caso
de uso em construo, gerando inconsistncia.
Para o leitor, muitas vezes, no h como saber
qual o correto. Se a falha percebida mais cedo,
o leitor pode anotar como dvida e, uma vez
respondida essa dvida, vir a implementar o
requisito correto. Caso a falha seja descoberta
mais tarde e o requisito errado tenha sido
implementado, haver retrabalho.
Fato Incorreto
Um problema grave que pode ocorrer na escrita do caso de uso adicionar ao documento
um requisito descrevendo um comportamento
do sistema diferente do que foi especificado.
uma falha, geralmente, difcil de ser notada
pelo leitor. O leitor l o requisito, encara como
verdade e o implementa. Muito provavelmente, esse comportamento errado do sistema vai
passar pela equipe de teste, que, geralmente,
cria os casos de teste com base nos casos de
uso, e s ser notado quando homologado
pelo cliente. A depender da falha, o custo para
corrigi-la pode vir a ser muito caro para a contratada, tanto em tempo, quanto em recurso.
Informao Estranha
Encontrar informaes desnecessrias,
que no sero, de forma alguma, teis para
a construo do sistema, no vem a ser um
problema grave. algo que prejudica a legibilidade, e que exige, s vezes, um esforo
maior para ler um caso de uso que poderia
ser mais enxuto e menos cansativo. Este tipo
de informao alm de poder tornar o texto
mais confuso, pode gerar dvidas que tero
que ser esclarecidas e desprender tempo do
processo de construo do sistema.
Fatores de melhoria
Apontar problemas na escrita dos casos
de uso no to complicado. No entanto,
levantar melhorias para solucionar esses
problemas no uma tarefa to simples.
Fatores de melhoria so itens que devem ser
levados em considerao durante a escrita de
casos de uso. Algumas sugestes de pontos
que podemos considerar durante a escrita
de casos de uso com objetivo de aprimorar
sua escrita so:
Engen haria de Requisitos
FB001 Incluir Equipamento

Seq
1
Ao do ator
Resposta do sistema
Seleciona no menu do sistema a funcionalidade Apresenta tela Pesquisar Equipamento.

Equipamento.
O corpo da tela conter a busca padro, possibilitando a consulta por qualquer atributo apresentado na lista de Equipamentos conforme
descrito no item 5.1. da Tabelas de Atributos.
Apresentar a ao Pesquisar.
Essa tela tambm apresenta uma lista contendo os nomes dos Equipamentos, caso exista, cadastrados no sistema. Nessa lista de Equipamento,
em cada registro respeitando as pr-condies de segurana, possibilitar a edio atravs da ao Alterar.
Exibir a ao Incluir, possibilitando a incluso de um novo registro.
Seleciona ao Incluir Equipamento.
Apresenta tela Equipamento Incluir.
O corpo da tela deve conter os campos de acordo com o item 5.2. das Tabelas de Atributos, para preenchimento do usurio.
Exibir as aes: Salvar e Voltar.
Aps preenchimento do dado, o usurio seleciona Grava registro na base.
ao Salvar.
Exibe mensagem Incluso realizada com sucesso, mantm-se na tela Equipamento Incluir exibindo os campos em branco permitindo
nova incluso.
Caso existam divergncias na validao das regras, vide fluxos de exceo [FE001] e [FE002].
Vide fluxo alternativo [FA001] para executar a ao Pesquisar, [FA002] para executar ao Voltar.
Tabela 2. Fluxo Bsico

FA001 Pesquisar Equipamento
Seq
Ao do ator
Resposta do sistema
Preenche a lista de Equipamentos. Sero exibidos os campos definidos no item 5.1. das Tabelas de Atributos.
Os registros retornados sero filtrados de acordo com os dados especificados na busca padro.
Na tela Pesquisar Equipamento, Usurio preenche campo Busca Vide fluxo de exceo: [FE003].
Padro e seleciona ao Pesquisar.
Exibir a ao Alterar.
Vide fluxo alternativo [FA002] para executar ao Voltar e [FA003] para executar a ao Alterar.
FA002 Voltar
Seq
Ao do ator
Resposta do sistema
Na tela Equipamento Incluir/Alterar, Usurio

1
Retorna para tela Pesquisar Equipamento.
seleciona ao Voltar.
FA003 Alterar Equipamento
Seq
Ao do ator
Resposta do sistema
Apresenta tela Equipamento Alterar.

Na tela Pesquisar Equipamento, Usurio seleciona O corpo da tela deve conter os campos especificados no item 5.3. das Tabelas de Atributos e seus contedos cadastrados, habilitando
ao Alterar.
aqueles campos que puderem sofrer alterao de contedo e protegendo o contedo dos demais.
Exibir as aes: Salvar e Voltar.
Grava registro na base. Exibe mensagem Alterao realizada com sucesso, retorna para tela Pesquisar Equipamento exibindo a lista
Aps preenchimento dos dados, o usurio seleciona com todos os registros cadastrados, de acordo com o item 5.1. das Tabelas de Atributos..
ao Salvar.
Para qualquer desvio nas validaes ver fluxos de exceo [FE001] e [FE002].
Vide fluxo alternativo [FA002] para executar ao Voltar.
Tabela 3. Fluxo Alternativo
Navegao
importante que os fluxos de uso sejam bem definidos e
numerados. importante que um fluxo bsico seja explicitado,
enumerando os passos que o usurio leva para executar o requisito principal de um caso de uso. A partir desse fluxo bsico,
necessrio que toda ao do usurio que cause um desvio do
fluxo principal seja mapeada, passo a passo, em fluxos alternativos que devem ser referenciados no exato passo onde pode
haver essa mudana de comportamento do sistema. Claro que
h de se ter bom senso para definir que desvios so relevantes.

No necessrio, por exemplo, que se leve em conta a opo do
usurio fechar o sistema e reiniciar todo o fluxo do incio.
Toda ao que d incio a um fluxo, seja bsico ou alternativo, deve ser destacada. Assim como deve ser destacado
tambm todo o passo em que o sistema finaliza um fluxo e
para que passo, de que fluxo, ele retorna. Com isso, definese o incio e fim de um fluxo, onde esse fim na verdade a
continuidade da navegao em outros fluxos.
19
FE001 Validao de campos obrigatrios.

Seq
Ao do ator
Resposta do sistema
Selecionar ao Salvar.
O sistema verifica se todos os campos obrigatrios foram preenchidos. Se existir campo obrigatrio sem preenchimento o sistema exibe mensagem
[nome do campo] obrigatrio!;
FE002 Falha de acesso aos dados

Seq
Ao do ator
Resposta do sistema
Selecionar ao Salvar.
O sistema exibe a mensagem de notificao No foi possvel realizar esta operao. Falha de acesso aos dados.;
FE003 Pesquisar registro no cadastrado.

Seq
Ao do ator
Resposta do sistema
Pesquisa sem resultados
O sistema identifica que nenhuma informao foi localizada para os parmetros informados;
O sistema exibe a mensagem;Nenhum dado foi localizado para os parmetros informados;
O sistema retorna para o fluxo bsico;
Tabela 4. Fluxo de Exceo
Ritmo de escrita
Administre sua energia. No escreva todos os detalhes num
primeiro momento. Se para comear, voc escrever apenas
20
Concluso
Na construo de um software, a forma como os casos de
uso so escritos pode impactar de forma positiva ou negativa
no processo. interessante evitar cometer os erros e usar os
fatores de melhoria como referncia. No existe uma regra
para um modelo de escrita de casos de uso, mas deve ser algo
confortvel tanto para o cliente como para o desenvolvedor.
Aprimorar a escrita de casos de uso traz grandes benefcios
para o processo de desenvolvimento de um software e aumenta
a probabilidade de gerar produtos de qualidade.
Referncias
Cockburn, Alistair. Escrevendo Casos de Usos Eficazes. Porto Alegre: Bookman, 2001.
Sommerville, Ian. Engenharia de Software So Paulo: Addison-Wesley,
8 Edio, 2007.
Links

D
s
RUP: Artefato: Modelos de Casos de Uso

http://www.wthreex.com/rup/process/artifact/ar_ucmod.htm
Feedback
eu
sobre e
s
Regras de Negcio
As regras devem estar especificadas de forma clara e objetiva
para no permitir dvidas durante o desenvolvimento. Nos
casos onde a regra muito complexa e apenas uma descrio no
suficiente, interessante explicar atravs de exemplos reais.
um esboo, a essncia de cada caso de uso, voc pode dar

ao cliente uma chance de propor correes mais cedo. Voc
eventualmente adicionar detalhes a cada caso de uso, aumentando
a preciso. Se por acaso voc estiver errado (inexato) com suas declaraes originais de objetivos de baixa preciso, ento a energia gasta
com as descries de alta preciso foi desperdiada. melhor ter a lista
de objetivos corretas antes de gastar energia de dzias de meses de
trabalho necessrias para um conjunto de casos de uso completamente
elaborados (Cockburn, 2001).
edio
ta
Campo
essencial que seja explicitado uma srie de informaes. Para
um arquiteto de sistemas, que realiza a modelagem de dados,
importante saber, por exemplo, qual o tipo do campo, tamanho e
obrigatoriedade. A depender das informaes que forem definidas a respeito dos campos, um arquiteto poder especificar que
uma tabela de determinado tipo, possui determinado nmero
de caracteres, not null, ou no.
Para um codificador, a finalidade destas informaes pode ser
um pouco diferente, mas a relevncia a mesma. O codificador
precisar representar as tabelas do banco de dados, atravs de
classes no projeto tcnico, onde devero ser definidos os tipos dos
atributos. Nas classes de negcio devero ser feitas validaes de
obrigatoriedade dos atributos. No entanto, nas telas, na apresentao do sistema para o usurio, que, talvez, as informaes a respeito dos campos sejam mais importantes. Nos formulrios onde
usurios entram com informaes para o sistema que estaro
definidos: quais tipos de caracteres determinado campo aceita,
se so s numricos, ou se letras so aceitas; quantos caracteres
podem ser digitados em determinado campo; qual a mscara,
modelo, de data que dever ser inserido; no caso do usurio estar
editando uma informao j cadastrada, quais campos permitido para edio e quais so bloqueados, somente leitura; quais so
os valores pr-definidos para campos como, estado-civil.
Para que todos esses comportamentos que enriquecem a interface do sistema com o usurio sejam corretamente implementados,
fundamental que todas suas caractersticas sejam bem definidas
nos documentos de caso de uso.
Engenharia
Ciclos de Vida do Software

Conhecendo os Bastidores
Ana Brbara Lins de Macdo

Engenheira Eletrnica com especializao em
Telecomunicaes (UFBA) e formao anterior
em Informtica (UCSal). 8 anos de experincia
profissional na indstria automotiva trabalhando para Ford Motor Company na rea de
engenharia de desenvolvimento de produtos,
mais especificamente, 2 anos na rea de integrao de esforos do times de engenharia e
6 anos trabalhando na rea responsvel pela
rede intraveicular (comunicao digital entre
mdulos eletrnicos e diagnose veicular).
6 anos adicionais de experincia prvia em
Informtica como Analista de Sistemas de
software para aplicaes em internet, finanas, comerciais e vendas. Atualmente est
cursando Ps-Graduao em Engenharia de
Software na Faculdade Ruy Barbosa.
Rodrigo Spnola
rodrigo@sqlmagazine.com.br
Doutor e Mestre em Engenharia de Software

pela COPPE/UFRJ.
Diretor de Operaes Kali Software
(www.kalisoftware.com)
Editor Chefe SQL Magazine | WebMobile |
Engenharia de Software Magazine
Professor do Curso de Ps-Graduao em
Engenharia de Software da Faculdade Ruy
Barbosa.
rocesso de software o conjunto

de atividades que constituem o
desenvolvimento de um sistema
computacional. Estas atividades so
agrupadas em fases, como: definio de
requisitos, anlise, projeto, desenvolvimento, teste e implantao.
Em cada fase so definidas, alm das
suas atividades, as funes e responsabilidades de cada membro da equipe, e
como produto resultante, os artefatos.
O que diferencia um processo de software do outro a ordem em que as fases
vo ocorrer, o tempo e a nfase dados a
cada fase, as atividades presentes, e os
produtos entregues.
Com o crescimento do mercado de
software, houve uma tendncia a repetirem-se os passos e as prticas que deram
certo. A etapa seguinte foi a formalizao em modelos de ciclo de vida.
Em outras palavras, os modelos de ciclo
de vida so o esqueleto, ou as estruturas
pr-definidas nas quais encaixamos as
fases do processo. De acordo com a NBR
Neste contexto, neste artigo apresentaremos alguns

modelos de ciclo de vida, quais sejam: Cascata, Modelo em V, Incremental, Evolutivo, RAD, Prototipagem,
Espiral, Modelo de Ciclo de Vida Associado ao RUP.
Para que serve?

O ciclo de vida a estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento,
operao e manuteno de um produto de software,
abrangendo a vida do sistema, desde a definio de
seus requisitos at o trmino de seu uso.

O modelo de ciclo de vida a primeira escolha a ser
feita no processo de software. A partir desta escolha definir-se- desde a maneira mais adequada
de obter as necessidades do cliente, at quando e
como o cliente receber sua primeira verso operacional do sistema.
ISO/IEC 12207:1998, o ciclo de vida a

Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operao e manuteno de um
produto de software, abrangendo a vida
do sistema, desde a definio de seus
requisitos at o trmino de seu uso.
21
O modelo de ciclo de vida a primeira escolha a ser feita

no processo de software. A partir desta escolha definir-se-
desde a maneira mais adequada de obter as necessidades do
cliente, at quando e como o cliente receber sua primeira
verso operacional do sistema.
No existe um modelo ideal. O perfil e complexidade do
negcio do cliente, o tempo disponvel, o custo, a equipe, o ambiente operacional so fatores que influenciaro diretamente
na escolha do ciclo de vida de software a ser adotado.
Da mesma forma, tambm difcil uma empresa adotar um
nico ciclo de vida. Na maior parte dos casos, v-se a presena
de mais de um ciclo de vida no processo.
Os ciclos de vida se comportam de maneira sequencial (fases
seguem determinada ordem) e/ou incremental (diviso de escopo) e/ou iterativa (retroalimentao de fases) e/ou evolutiva
(software aprimorado).
Neste contexto, neste artigo apresentaremos alguns modelos
de ciclo de vida, quais sejam:
Cascata
Modelo em V
Incremental
Evolutivo
RAD
Prototipagem
Espiral
Modelo de Ciclo de Vida Associado ao RUP
Modelo em Cascata
Formalizado por Royce em 1970, o modelo mais antigo. Suas
atividades fundamentais so:
anlise e definio de requisitos;
projeto;
implementao;
teste;
integrao.
O modelo em cascata tem o grande mrito de ser o primeiro

a impor o planejamento e o gerenciamento ao processo de
software, que antes era casual. O nome cascata foi atribudo
em razo da sequncia das fases, onde cada fase s comea
quando a anterior termina; e da transmisso do resultado da
fase anterior como entrada para a fase atual (o fim de cada fase
resulta em um documento aprovado). Nesse modelo, portanto,
dada muita nfase s fases de anlise e projeto antes de partir
para a programao, a fim de que o objetivo do software esteja bem definido e que sejam evitados retrabalhos, conforme
podemos observar na Figura 1.
Devido sua simplicidade, o modelo em cascata fcil de ser
entendido pelo cliente. um modelo que supe um incio e
fim claro e determinado, assim como uma estimativa precisa
de custo logo no incio, fatores importantes na conquista do
cliente.
O problema se d depois, quando o cliente, aps esperar at
o fim do processo para receber a primeira verso do sistema,
pode no concordar com ela. Apesar de cada fase terminar
com uma documentao aprovada, certamente haver lacunas
devido a requisitos mal descritos pelo cliente, mal entendido
pelo analista ou por mudana de cenrio na organizao que
exija adaptao de requisitos. O modelo em cascata no prev
reviso de fases.
Assim, o risco muito alto, principalmente para sistemas
complexos, de grande porte, afinal o modelo em cascata pressupe uma realidade esttica e bem conhecida, comparado
a uma linha de produo fabril. Mas a rotina do negcio do
cliente no reflete isso. Manipulao de usurios com diferentes habilidades, ambientes operacionais distintos, tecnologia
em crescente evoluo, necessidade de integrao com outros
sistemas (em plataformas antigas ou mais novas), mudanas
organizacionais, at mudanas na legislao do municpio/
estado/pas, pedem um modelo mais flexvel.
Por outro lado, o modelo em cascata adqua-se bem como um
sub-modelo para outros modelos. Por exemplo, no modelo
cascata com realimentao permite-se
que, a cada descoberta da fase posterior,
haja uma correo da fase anterior.
Modelo em V
Figura 1. O modelo em cascata
22
Engenharia de Software Magazine - Ciclos de Vida do Software
Neste modelo, do Ministrio de Defesa

da Alemanha, 1992, o modelo em cascata
colocado em forma de V. Do lado esquerdo do V ficam da anlise de requisitos
at o projeto, a codificao fica no vrtice e
os testes, desenvolvimento, implantao e
manuteno, direita, conforme Figura 2.
A caracterstica principal desse modelo,
que o diferencia do modelo em cascata, a
nfase dada verificao e validao: cada
fase do lado esquerdo gera um plano de
teste a ser executado no lado direito.
Mais tarde, o cdigo fonte ser testado,
do mais baixo nvel ao nvel sistmico
Ges to de Conhecimento
para confirmar os resultados, seguindo os

respectivos planos de teste: o teste de unidade valida o projeto do programa, o teste
de sistema valida o projeto de sistema e o
teste de aceitao do cliente valida a anlise
de requisitos.
Da mesma forma que o modelo em cascata,
o cliente s recebe a primeira verso do software no final do ciclo, mas apresenta menos
risco, devido ao planejamento prvio dos
testes nas fases de anlise e projeto.
Ciclos de Vida Incremental

Neste modelo, de Mills em 1980, os requisitos do cliente so obtidos, e, de acordo com
a funcionalidade, so agrupados em mdulos. Aps este agrupamento, a equipe, junto Figura 2. O modelo em V
ao cliente, define a prioridade em que cada
mdulo ser desenvolvido, escolha baseada
na importncia daquela funcionalidade ao
negcio do cliente.
Cada mdulo passar por todas as fases
cascata de projeto, conforme se observa na
Figura 3, e ser entregue ao cliente um software operacional. Assim, o cliente receber
parte do produto final em menos tempo.
Como o cliente j trabalhar no primeiro
incremento ou mdulo, muito importante
que haja uma especial ateno na integrao
dos incrementos, o que exige muito plane- Figura 3. Ciclo de vida Incremental
jamento, afinal no aceitvel que o cliente
se depare com muitos erros de software a cada incremento,
so to bem conhecidos, ou os requisitos ainda esto sofrendo
tampouco, que a cada incremento ele precise se readaptar a
grandes mudanas. Uma ateno especial deve ser dada ao
mudanas. Desta forma, a anlise feita em cima dos requisitos conseguidos at ento, e a primeira verso entregue ao
agrupamento dos requisitos e qualidade no desenvolvimento
das funes comuns a todo o sistema, que inevitavelmente
cliente. O cliente usa o software no seu ambiente operacional,
e como feedback, esclarece o que no foi bem entendido e d
devero ser entregues no primeiro incremento.
Desta forma, alm de atender as necessidades mais crticas do
mais informaes sobre o que precisa e sobre o que deseja (ou
seja, mais requisitos).
cliente mais cedo, as partes mais importantes sero, tambm, as
A partir deste feedback, nova anlise, projeto e desenvolvipartes mais testadas no ambiente real. Ser mais difcil gastar
mento so realizados, e uma segunda verso do software enrecursos em conceitos errados, ou que um mau entendimento
tregue ao cliente que, novamente, retorna com mais feedbacks.
dos requisitos alcance uma escala difcil de ser ajustada, visto
que durante todo o projeto haver o feedback do cliente (a
Assim, o software vai evoluindo, se tornando mais completo,
at atender todas as necessidades do cliente dentro do escopo
opinio do cliente realimenta o sistema).
Esse ciclo de vida no exige uma equipe muito grande, pois
estabelecido. Tem-se assim a verso final, pelo menos at novos
requisitos aparecerem (ver Figura 4).
a modularizao diminui o escopo de cada incremento, e no
h um paralelismo nas atividades. Haver, por outro lado,
A participao constante do cliente uma grande vantagem
desse modelo, o que diminui o risco de m interpretao de
uma dificuldade em manter a documentao de cada fase
atualizada devido s melhorias no sistema e aos ajustes de
requisitos dos modelos que s oferecem a primeira verso do
software no final do processo. Da mesma forma, o software
requisitos solicitados pelos clientes.
j atende algumas necessidades do cliente muito mais cedo
Modelo Evolutivo
no processo.
No dada muita nfase documentao, pois a gerao
Neste modelo, os requisitos so adquiridos em paralelo
evoluo do sistema. O modelo evolutivo parte do princpio
de verses torna este trabalho muito rduo. Alm disso,
como a anlise de requisitos e desenvolvimento esto sempre
que o cliente no expe todos os requisitos, ou os requisitos no
23
acontecendo, a preocupao em documentar todo o processo

pode fazer com que haja atrasos na entrega.
H uma alta necessidade de gerenciamento nesse tipo de
modelo, pois a falta de documentao adequada, o escopo de
requisitos no determinado, o software crescendo e estando
ao mesmo tempo em produo podem ter conseqncias negativas. Seguem alguns exemplos: o sistema nunca terminar,
pois o cliente sempre pede uma alterao; o sistema no ter
uma estrutura robusta a falhas nem propcia a uma fcil manuteno, pelas constantes alteraes; o cliente mudar de idia
radicalmente entre uma verso e outra ou revelar um requisito
que exija uma verso bem diferente da anterior, fazendo com
que toda a base (de dados ou de programao) precise ser
revista. Os citados problemas podem implicar em um grande
nus financeiro e de tempo.
muito importante que o cliente esteja ciente do que se trata
este ciclo de vida e que sejam esclarecidos os limites de escopo
e de tempo, para que no haja frustraes de expectativas.
Figura 4. Ciclo de vida Evolutivo
RAD Rapid Application Development

Este modelo formalizado por James Martin em 1991, como
uma evoluo da prototipagem rpida, destaca-se pelo
desenvolvimento rpido da aplicao. O ciclo de vida extremamente comprimido, de forma a encontrarem-se exemplos,
na literatura, de durao de 60 e 90 dias. ideal para clientes
buscando lanar solues pioneiras no mercado.
um ciclo de vida incremental, iterativo, onde prefervel que
os requisitos tenham escopo restrito. A diferena principal do
ciclo anterior o forte paralelismo das atividades, requerendo,
assim, mdulos bastante independentes. Aqui os incrementos
so desenvolvidos ao mesmo tempo, por equipes diferentes.
Alm do paralelismo, a conquista do baixo tempo se d graas
compresso da fase de requisitos e da fase de implantao.
Isso significa que, na obteno dos requisitos, costumamse optar por metodologias mais dinmicas e rpidas, como
workshops ao invs de entrevistas. Permite-se tambm um
desenvolvimento inicial no nvel mais alto de abstrao dos
requisitos visto o envolvimento maior do usurio e visibilidade
mais cedo dos prottipos (ver Figura 5).
As fbricas de software que resolvem por adotar este modelo devem ter uma estrutura prvia diferencial de pessoas e
ferramentas, tais como:
Pessoas:
- Profissionais experientes (funcional e gerncia);
- Profissionais de rpida adaptao;
- Equipes de colaborao mtua;
- Maior quantidade de pessoas;
Gerenciamento:
- Empresas pouco burocrticas que encorajem a eliminao
de obstculos;
- Alto controle do tempo;
Uso de Ferramentas:
- CASE;
- Muita diagramao;
- Prvia biblioteca de componentes reutilizveis (APIs, wizards, templates,...);
- Fcil manuteno (ex.: linguagens de programao que
suportem Orientao a Objetos, tratamento de
exceo, ponteiros);
- Adoo de ferramentas maduras, pois no
h tempo de atualizar verses e tratar erros
inesperados;
Os sistemas desenvolvidos no ciclo RAD tendem
a ter uma padronizao de telas muito forte, devido a bibliotecas reutilizveis e templates, porm
tendem a perder em desempenho do sistema e na
anlise de risco (atividades estas que demandam
tempo em qualquer projeto). Assim, prefervel
seu uso para softwares de distribuio pequena.
Prototipagem
Figura 5. Ciclo de vida RAD
24
Prototipagem a construo de um exemplar

do que foi entendido dos requisitos capturados
do cliente. Pode ser considerado um ciclo de vida ou pode ser

usado como ferramenta em outros ciclos de vida.
Um prottipo em engenharia de software pode ser o desenho
de uma tela, um software contendo algumas funcionalidades
do sistema. So considerados operacionais (quando j podem ser utilizados pelo cliente no ambiente real, ou seja, em
produo), ou no operacionais (no esto aptos para serem
utilizados em produo). Os prottipos podem ser descartados,
ou reaproveitados para evolurem at a verso final.
No ciclo de vida de prototipagem, no exigido um conhecimento aprofundado dos requisitos num primeiro momento.
Isso bastante til quando os requisitos no so totalmente
conhecidos, so muitos complexos ou confusos. Desta forma,
se o cliente no sabe expressar o que deseja (o que ocorre
bastante quando no um sistema legado), a melhor maneira
de evitar que se perca tempo e recursos com uma m interpretao a construo de modelos, ou seja, de prottipos do
que o software faria.
Assim, o cliente experimentar, na prtica, como o sistema
ou parte dele funcionar. A partir desse primeiro contato, o
cliente esclarece o que no foi bem interpretado, aprofunda
alguns conceitos e at descobre um pouco mais sobre o que
realmente precisa. A partir deste feedback, novos requisitos
so colhidos e o projeto ganha maior profundidade. Outro
prottipo gerado e apresentado ao cliente, que retorna com
mais feedbacks. Ou seja, o cliente participa ativamente do
incio ao fim do processo (ver Figura 6).
A gerao de prottipos pode ser facilitada por ferramentas
geradoras de telas, de relatrios, poupando esforo de programao e diminuindo o tempo de entrega.
Cada prottipo tem uma finalidade diferente. Um prottipo
pode servir para esclarecer dvidas sobre uma rotina, demonstrar a aparncia das telas, contedo de tabelas, formato
de relatrios. Os prottipos podem tambm ser utilizados
para apresentar opes ao cliente para que ele escolha a que
mais lhe agrade, como opes de navegao, de fluxo de telas,
entre outras.
Por isso, muito importante explicar previamente ao cliente
que prottipos so apenas modelos para melhorar a comunicao. Caso contrrio, pode causar uma frustrao por no
funcionar corretamente, ter funes limitadas, ter resposta
lenta, ou a aparncia ruim. Certamente um prottipo construdo para esclarecer uma rotina provavelmente ter uma
cara feia; para demonstrar a aparncia das telas, no ter
funcionalidade; para apresentar o formato dos relatrios, os
dados no sero coerentes.
O cliente far comparaes entre o sistema final e o que foi
prometido atravs do prottipo e pode ficar insatisfeito. Por
exemplo, geralmente o prottipo no acessa rede ou banco
de dados, pois as informaes so desenhadas com a tela,
fazendo com que tudo fique muito rpido. J no ambiente operacional haver uma degradao de desempenho e o cliente
pode se decepcionar.
Faz parte de um bom gerenciamento no modelo de prototipagem planejar se, quais e que funes dos prottipos no
Figura 6. O modelo e prototipagem (Pressman, adaptado)
operacionais sero reaproveitadas na verso operacional,

para que sua confeco siga as boas prticas de engenharia
de software. Os prottipos no operacionais so construdos
com pouca qualidade em prol da velocidade. Ou seja, no h
preocupao na programao, em refinar o cdigo, em usar
comentrios, em aproveitar eficientemente os recursos de
hardware e software, na manuteno, no reuso de componentes e na integrao com outras funes ou sistemas. Com
certeza ser um problema se a equipe sucumbir presso do
cliente, cada vez mais ansioso para ver a verso final daquele
trabalho, e transformar revelia, prottipos no operacionais
em operacionais.
O gerente tambm deve se preocupar com o escopo do projeto
versus a quantidade de prottipos, para que no se perca muito
tempo nesse processo, tampouco se transforme num processo
de tentativa e erro.
No uma tarefa fcil documentar o modelo de ciclo de vida
baseado na prototipagem devido aos requisitos no serem
totalmente conhecidos no primeiro momento e a consequente
quantidade de mudanas ocorridas.
Modelo Espiral
O modelo proposto por Boehm em 1988 trata de uma abordagem cclica das fases do processo, onde a cada volta ou
iterao temos verses evolucionrias do sistema.
Este um modelo guiado por risco, suporta sistemas complexos e/ou de grande porte, onde falhas no so tolerveis. Para
isso, a cada iterao h uma atividade dedicada anlise de
riscos e apoiada atravs de gerao de prottipos, no necessariamente operacionais (desenhos de tela, por exemplo) para
que haja um envolvimento constante do cliente nas decises.
Cada iterao ou volta dedicada a uma fase do processo
de vida de um software (viabilidade do projeto, definio de
requisitos, desenvolvimento e teste,...). Ao mesmo tempo, cada
volta seccionada em 4 setores, da seguinte forma:
1 Iterao: Viabilidade do projeto:
1.1. Definio de objetivos;
1.2. Avaliao e reduo de riscos;
25
1.3. Desenvolvimento e validao;

1.4. Planejamento da prxima fase;
2 Iterao: Definio de requisitos do sistema:
2.1. Definio dos objetivos;
2.2. Avaliao e reduo de riscos;
2.3. Desenvolvimento e validao;
2.4. Planejamento da prxima fase;
3 Iterao: Projeto do sistema:
3.1. ...
3.2. ...
3.3. ...
3.4. ...
4 Iterao: Desenvolvimento e teste de unidade
4.1. ...
4.2. ...
...
5 Iterao: Implantao
...
Ou, na representao grfica deste modelo conforme Figura 7.
Os quatro setores so explicados da seguinte forma:
1. Na Definio de Objetivos, desempenhos, funcionalidade,
entre outros objetivos, so levantados. Visando alcanar esses
Figura 7. Modelo Espiral
26
objetivos so listadas alternativas e restries, e cria-se um

plano gerencial detalhado.
2. Na Anlise de Riscos, as alternativas, restries e riscos
anteriormente levantados so avaliados. Neste setor (porm
no apenas neste) prottipos so utilizados para ajudar na
anlise de riscos.
3. No Desenvolvimento e Validao um modelo apropriado
para o desenvolvimento do sistema escolhido, de acordo com
o risco analisado no setor anterior (cascata, interativo,...).
4. No Planejamento da Prxima fase ocorre a reviso do
projeto e a deciso de partir para a prxima fase.
Ou seja, cada volta ou iterao do processo vista por quatro
ngulos.
No final da Viabilidade do Projeto teremos como resultado a
Concepo das Operaes; da Definio de Requisitos o produto sero os requisitos; no final do Desenvolvimento e Testes
o projeto criado e os testes habilitados. Pode-se parar por a,
pode-se incluir mais fases, pode a espiral ficar adormecida at
uma nova alterao do sistema se requisitada, e desta forma
estender at o fim de vida do sistema.
Neste modelo, apenas o incio definido. A evoluo e
amadurecimento dos requisitos demandam tempo ajustvel
(assim como custo). Isto torna o sistema difcil de ser vender
ao cliente e exige um alto nvel de gerenciamento em

todo o processo.
Modelo de Ciclo de Vida Associado ao RUP

Derivado da UML e do Processo Unificado de Desenvolvimento de Software, o RUP, Rational Unified
Process, um modelo de processo iterativo e incremental, dividido em fases, orientado a casos de uso.
Possui framework (esqueleto) de processo e manuais
que guiam na utilizao das melhores prticas de especificao de projeto (Vdeo Aula sobre Ciclo de Vida
de Software, parte 3, revista Engenharia de Software
Magazine).
O objetivo do RUP produzir software com qualidade (melhores prticas de engenharia de software) que
satisfaa as necessidades dos clientes dentro de um
prazo e oramento estabelecidos.
Este modelo foi desenvolvido pela Rational Software
Corporation e adquirido pela IBM, que o define da
seguinte maneira: IBM Rational Unified Process,
ou RUP, uma plataforma de processo de desenvolvimento de software configurvel que oferece melhores
Figura 8. Conceitos chaves do RUP
prticas comprovadas e uma arquitetura configurvel.
(ver Figura 8).
O RUP possui quatro fases de negcio. O nome
de cada fase revela o que ser entregue por ela (ver
Figura 9):
Concepo: define o escopo do projeto, ou business
case; onde julgado se o projeto deve ir adiante ou
ser cancelado.
Elaborao: elabora modelo de requisitos, arqui- Figura 9. RUP
tetura do sistema, plano de desenvolvimento para o
Concepo
Elaborao Construo
Transio
software e identificar os riscos.
Construo: constri o software e a documentao
Esforo
~5 %
20 %
65 %
10%
associada.
Programao
10 %
30 %
50 %
10 %
Transio: finaliza produto, define-se plano de entrega e
Tabela 1. Distribuio prevista de esforo e programao para um ciclo
entrega a verso operacional documentada para o cliente.
de desenvolvimento inicial tpico de um projeto de mdio tamanho
A iterao no RUP tem por objetivo minimizar os riscos.

Como pode ser visto na Figura 9, a iterao pode acontecer
dentro de cada fase, gerando incrementos, ou em todo o processo. Por exemplo, dentro da concepo, a iterao pode ocorrer
at que todos os requisitos sejam perfeitamente entendidos.
O plano de iteraes identificar quais e quantas iteraes so
necessrias durante o processo.
Em geral, essas fases demandam esforo e programao diferentes. Para um projeto de mdio porte, de acordo com o fabricante ser seguida a distribuio apresentada na Tabela 1.
O RUP usa templates que descrevem o que esperado no
resultado de cada fase ou cada iterao (IBM, 2004), identificando as competncias e responsabilidades (arquiteto, analista,
testador,...), as atividades e os artefatos.
Para descrever as atividades (codificao de uma classe,
integrao de sistemas,...) o RUP faz o uso de manuais (guidelines), que descrevem tcnicas e heursticas; e de Mentores
de Ferramentas, que explicam o uso da ferramenta para

executar a atividade. Os artefatos de cada fase (documentos,
modelos, cdigos, etc.) so criados, juntamente com templates
e exemplos, para melhor entendimento da equipe e do cliente
(ver Figura 10).
Os templates tambm ajudam no gerenciamento, pois definem
o que precisa ser executado. Servem tambm como guia para que
as boas prticas de especificao de projeto no sejam esquecidas
no processo de desenvolvimento daquele software.
Assim, toda a preocupao dada pelo RUP em disciplinar o
processo atravs de frameworks, guias, templates, faz com que
haja uma melhor alocao de pessoas na equipe, padronizao
do sistema, viso concreta do andamento do projeto.
A escolha do RUP deve ser feita por empresas de software
com prvia experincia, pois a definio de framework, templates, guias, mtodos, entre outros, demandam tempo e exigem
aderncia s boas prticas de processo de software.
27
Modelo
Foco
Requisitos
Cascata
Documento e artefato
Bem conhecido/congelado
Fim do ciclo
Gerenciamento
(1=mais simples)
1
Planejamento de testes
Bem conhecido/congelado
Fim do ciclo
Simples
Incremental
Incrementos operacionais
Maior abstrao / Tratado em mdulos
Prottipos operacionais
Mdio
Evolutivo
Evoluo dos requisitos
Pouco conhecidos
Mdio
RAD
Rapidez
Mdio
Prototipagem
Dvidas nos Requisitos
Escopo restrito / Maior abstrao /

Tratado em mdulos
Abstratos
Mdio
Espiral
Anlise de risco
Complexos
RUP
Frameworks e boas
prticas
Prottipos
no
operacionais
ou no operacionais
ou no operacionais
Complexos
Maior abstrao / evoludos com o

tempo
Maior abstrao / evoludos com o
tempo
1 verso p/ cliente
Sistemas
(tamanho complexidade mximos)
Simples
Tabela 2. Comparao entre os modelos de ciclo de vida
Vale ressaltar que, conforme j mencionado anteriormente, no existe um modelo ideal e na maioria dos softwares
desenvolvidos so utilizados mais de um modelo de ciclo
de vida.
Referncias
Finalizando este artigo sobre os modelos de ciclo de vida

de software, segue uma tabela comparativa das principais
caractersticas que devem ser observadas antes de escolher o
ciclo ou os ciclos de vida a serem adotados (ver Tabela 2).

28
D
s
Feedback
eu
sobre e
s
Consideraes Finais
edio
ta
Figura 10. Os principais artefatos do Rational Unified Process e o fluxo de

informaes existente entre eles
SOMMERVILLE, Ian, Engenharia Software. Addison Wesley. 8 ed

PRESSMAN, Roger, Engenharia Software, McGraw-Hill. 6 ed
Case Maker Inc., What is Rappid Application Development?
PISKE, Otavio. SEIDEL, Fabio, Rapid Application Development
Norma NBR ISO/IEC 12207:1998
SPINOLA, Rodrigo, Boas Prticas de Engenharia de Software, 2011
PFLEGER, Shari, Engenharia de Software Teoria e Prtica, Prentice Hall, 2 Ed
PAULA Filho, Wilson, Engenharia de Software: fundamentos, mtodos e padres, LTC, 3 Ed
Vdeo Aula sobre Ciclo de Vida de Software, Revista digital Engenharia de Software Magazine
Artigo: Ciclo de Vida del Software, http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/
lpcu097%20-%2001.pdf
Artigo: Going Over the Waterfall with the RUP: http://www.ibm.com/developerworks/
rational/library/4626.html
IBM Webpage: Rational Unified Process: http://www-01.ibm.com/software/br/rational/
rup.shtml
RUP Tutorial Tour: http://www.wthreex.com/rup/portugues/index.htm
Engenharia
Introduo verificao de diagramas de

classe Parte 2
Sistemas de Gesto de Contedo Organizacional - Enterprise Content
Manangement (ECM)
Apresentaremos nesta srie de artigos uma tcnica
baseada em templates de testes de design para a
verificao de artefatos de diagramas de classes UML
contra cdigo Java. Nesta segunda parte de nosso
artigo, apresentaremos uma abordagem de apoio
verificao de diagramas de classes da UML.
Para que serve?
D
Waldemar Pires Ferreira Neto
waldemar.neto@gmail.com
Mestre em Informtica na rea de Engenharia de Software

Universidade Federal de Campina Grande UFCG. Bacharel em
Cincia da Computao pela Universidade Federal de Campina
Grande UFCG.
ado o problema da verificao

dos artefatos do diagrama de
classes UML apresentado na
primeira parte deste artigo publicado
na edio 35 da Engenharia de Software
Magazine, a soluo que apresentaremos neste artigo a verificao desses
artefatos atravs da criao de testes de
design baseados em templates de cdigo.
Utilizamos templates, pois identificamos
que os testes de design para a verificao
dos artefatos do diagrama de classes
seguem um padro, e esse padro consegue ser especificado atravs de templates
de teste.
O uso de templates para gerao de
testes utilizado h algum tempo para
a gerao de diversos tipos de testes. Na
Uma das principais contribuies em se aplicar teste de

design diminuir os custos do software. Custos com a
manuteno do software podem chegar at 90% do
custo total do ciclo de vida do software. Dentre esses
custos destacamos o custo com a reviso de cdigo.

Verificao de conformidade com o design especialmente relevante em processos de desenvolvimento
que promovem uma clara distino entre artefatos de
design e de implementao, como por exemplo, o RUP.
E, especialmente, se equipes diferentes desenvolverem
os artefatos de design e os de implementao.
abordagem que apresentaremos, definiremos um template de teste para cada

tipo de artefato no diagrama de classe.
Sendo assim, neste artigo mostraremos a forma como foram adotados os
29
templates de teste. Inicialmente, apresentaremos como adotamos templates para a verificao das classes do diagrama de
classe. Em seguida, apontaremos os demais tipos dos artefatos
do diagrama de classe e suas caractersticas que so cobertas
pelo nosso trabalho. Mostraremos ainda alguns artefatos que
no podem ser verificados, e o porqu desse feito. Depois disso,
ilustraremos a aplicao da abordagem para verificao das
caractersticas referentes a um trecho do diagrama de classe
de um sistema Web. Por fim, discutiremos como essa abordagem alcana todos os artefatos tratados, e como ela pode ser
estendida para tratar outros artefatos.
Template do Teste de Design

A maneira como ns adotamos templates de testes para a
verificao de artefatos dos diagramas de classe pode ser vista
na Figura 1. Nessa figura podemos perceber que existem duas
fases principais: a aplicao dos templates para diagrama de
classe; e a execuo dos testes pela aplicao dos templates.
Inicialmente, definimos um catlogo de templates genricos
capazes de identificar cada tipo de artefato tratado: classe,
operao, atributo, pacote, interface e associao. Esses templates so mtodos genricos formados por trechos estticos
e algumas tags. Os trechos estticos, como o prprio nome
sugere, identificam a parte comum a qualquer teste de uma
instncia de um determinado artefato. As tags, sinalizadas
com < e >, so os trechos variveis desses testes, e devem
ser substitudos pelas especificidades das instncias de cada
artefato no diagrama de classe. Em outras palavras, cada instncia de um artefato no diagrama de classe gera um mtodo
que a testa, substituindo os tags do seu respectivo template
pelas informaes presentes no diagrama de classe.
Nas subsees a seguir, mostraremos os templates de testes de
design para todos os artefatos tratados. Todos esses templates
compartilham algumas propriedades:
nome da entidade: vrias tags dos templates so referentes
ao nome completo das entidades. O nome completo de uma
entidade o seu nome, seguido da hierarquia de nomes das
Figura 1. Processo geral para o uso de templates para a verificao de

diagramas de Classe
Listagem 1. Trecho do Template do Teste de Design para Classe referente a
assinatura do mtodo de teste.
1 public void testClass <dif><NomeDaClasse> ()

2 throws IOException, InexistentEntityException {
3 ...
30
outras entidades onde esta entidade est contida. Todos esses

nomes so separados por .. Por exemplo, a classe Classe1
est contida no pacote pacote2 que por sua vez est contido
no pacote pacote1. Dessa forma, o nome completo da Classe1
deve ser pacote1.pacote2.Classe1;
nome do teste: os mtodos para cada artefato especfico
seguem um padro que identifica o tipo de verificao. Todo
mtodo comea com o test e seguidos do nome do artefato a
ser testado, identificando qual o artefato que est sendo testado.
Logo aps, vem um diferenciador (um contador, por exemplo)
que garante uma assinatura distinta para qualquer mtodo,
identificado pela tag <dif>. Por fim, vem o nome completo da
entidade a ser testada, substituindo o . por _, pois nomes
de mtodos no podem possuir .. Por exemplo, considere a
classe mostrada no item anterior, Class1, o seu nome no mtodo
seria pacote1_pacote2_Classe1;
templates de mensagens explicativas: as verificaes realizadas atravs de uma assertiva (assertTrue, assertFalse, dentre
outras.) possuem uma string template com uma mensagem
que, caso a assertiva falhe, explica o porqu da falha do teste.
Todas as mensagens esto em ingls somente por uma questo de implementao. E ainda, algumas dessas mensagens
possuem a tag <not>, ela significa que de acordo com as informaes do diagrama de classes, essas tags devem ou no
ser substitudas pelo termo not. Por exemplo, se a verificao
for realizada para saber se uma entidade no deve ser abstrata,
ento o tag <not> deve ser substitudo. Caso contrrio, ele no
deve ser substitudo por nada.
Os templates que sero mostrados esto divididos para ressaltar cada caracterstica verificada.
Classe
Inicialmente, ilustraremos a nossa tcnica de criao de
testes de design baseados em templates, mostrando como ela
usada para a verificao do artefato classe. O template para
classe verifica as caractersticas de classe: nome, visibilidade,
superClasse, escopo e interfaces realizadas. O template est
organizado da seguinte forma:
Assinatura do teste. A Listagem 1 exibe o trecho do mtodo
de teste que cria a assinatura do teste de design, identificando
que se trata de um teste de design para a classe a qual o template est sendo aplicado.
Existncia da Classe. A Listagem 2 exibe o mtodo de teste
que substitui o tag <NomeDaClasse> pelo nome completo da
classe. A verificao da existncia da classe testada se d com a
invocao do mtodo getClass da biblioteca DesignWizard. Esse
mtodo retorna uma representao da classe (um ClassNode)
presente no cdigo-fonte que possui o mesmo nome passado
por parmetro. Se no existir nenhuma classe com esse nome
no cdigo, a exceo InexistentEntityException ser lanada,
informando que a classe com o nome indicado no existe.
Classe Abstrata. Se a classe no diagrama de classe for abstrata,
a Listagem 3 substitui a tag <TrueFalse> pelo termo True,
caso contrrio, deve substituir por False. Na mensagem
Engenharia de Software Magazine - Introduo verificao de diagramas de classe Parte 2
Qualidade de Soft ware
explicativa a tag <NomeDaClasse> deve ser substituda pelo

nome completo da classe testada;
Herana de Classe. A Listagem 4 exibe o trecho do mtodo
de teste que verifica se a classe testada deve herdar de outra
classe do diagrama. Caso, no diagrama de classe, a classe
testada no herde diretamente de nenhuma outra, essas linhas devem suprimidas do teste de design a ser criado. fato
que a UML permite herana mltipla entre classes. Contudo,
consideramos que todos os diagramas de classe sero modelados de forma que somente existiro heranas simples. Isso
se deve ao fato de somente consideramos que diagramas de
classe modelam aplicaes em Java, que no permite herana
mltipla. As linhas 3-4 possuem uma string template para a
formao de uma mensagem explicativa seguindo o padro
da mensagem do item anterior;
Visibilidade da Classe. A Listagem 5 exibe o trecho do
mtodo de teste que verifica se a classe no diagrama de classe
possui a mesma visibilidade da classe mapeada no cdigo. A
linha 2 captura todos os modificadores da classe no cdigo
atravs do mtodo getModifiers do DesignWizard. A linha 8
contem uma mensagem explicativa, formada da mesma forma
que as dos itens anteriores. E as linhas 3-5 verificam se, dentre
esses modificadores, est contido o modificador mapeado para
a visibilidade da classe no diagrama;
Realizao de Interfaces. Na Listagem 6, as linhas 2-3 instanciam um array de strings com os nomes completos de todas
as interfaces que essa classe deve realizar, de acordo com o
diagrama de classe. As linhas 4-11 executam um for que varre
esse array de strings. No corpo desse for so realizadas as
aes para a verificao: a linha 5 captura uma representao
da interface no cdigo (caso essa interface no exista, uma exceo ser lanada); as linhas 6-7 capturam todas as interfaces
que a classe testada realiza atravs do mtodo getImplementedInterfaces da biblioteca DesignWizard. Por fim, as linhas
8-10 verificam se a interface capturada pela atual iterao do
for est presente dentre as interfaces realizadas pela classe
extrada do cdigo. Caso no esteja presente, uma mensagem
indicando o erro criada.
Vale ressaltar tambm que o template para testar classe no
verifica algumas caractersticas importantes de classe, tais
como atributos, operaes, associaes, dentre outras. Isso
se deve ao fato de que a verificao dessas caractersticas
bastante complexa. E, sendo assim, decidimos que verificao
dessas caractersticas deveria ser realizada atravs de templates
especficos. Alguns outros fatores que nos motivaram a tomar
essa deciso foram:
1. Cdigo de teste mais limpos: dividindo em cdigos de testes
distintos, os testes criados so menores e mais fceis de serem
entendidos;
2. Identificao de vrios erros simultaneamente: se a verificao de atributos, operaes e associaes fossem realizadas
dentro da verificao de classe, quando ocorresse um erro, o
mtodo de teste iria parar e no identificaria erros em outras
caractersticas que seriam verificadas posteriormente;

verificao da existncia da classe.
1 ...
2 ClassNode aClass = dw.getClass(<NomeDaClasse>);
3 ...
verificao se a classe abstrata.
1 ...
2 assert<TrueFalse>(The class <NomeDaClasse> must <not> be
3 + abstract ,
4 aClass.isAbstract()) ;
5 ...
verificao da hierarquia de classes.
1 ...
2 ClassNode superClass = dw.getClass(<NomeDaSuperClasse> );
3 assertEquals(The class <NomeDaClasse> must extend the class
4 +<NomeDaSuperClasse>, superClass,
5 aClass.getSuperClass());
6 ...
verificao da visibilidade da classe.
1 ...
2 Collection<Modifier> modifs = aClass.getModifiers();
3 assertTrue(The visibility of class <NomeDaClasse> must be
4 + <visibility>,
5 modifs.contains(Modifier.<visibility>));
6 ...
verificao da realizao de interfaces.
01 ...
02 String[] superInterfaces =
03 {<NomeDaInterface1\>, <NomeDaInterface2> , ...};
04 for (String superInterface : superInterfaces) {
05 ClassNode classnodeInterface = dw.getClass(superInterface) ;
06 Set<ClassNode> interfacesExtend =
07 aClass.getImplementedInterfaces();
08 assertTrue(The class <NomeDaClasse> must realize the
09 + interface + superInterface,
10 interfacesExtend.contains(classnodeInterface));
11 }
3. Reuso de teste: caractersticas comuns a vrios artefatos

so verificadas atravs de um mesmo template. Por exemplo,
como uma interface um tipo especial de classe com um esteretipo, ento ela tambm pode possuir operaes. Sendo
assim, para gerar os testes para verificar as operaes tanto
de classe e como de interface pode ser utilizado o mesmo
template de teste.
Operao
O template para os testes de operaes so capazes de criar
testes para verificar todas as operaes do diagrama. Ele no se
restringe somente a operaes de classes, alcana tambm operaes de interfaces, dentre outras. O template para operaes
31
verifica as seguintes caractersticas referentes s operaes:

nome, tipo de retorno, visibilidade e escopo. O template est
organizado da seguinte forma:
que se trata de um teste de design para a operao a qual o
template est sendo aplicado.
Existncia da Operao. A Listagem 8 exibe o trecho do mtodo de teste que recupera do cdigo Java uma representao
da classe com o mesmo nome da classe na qual a operao est
contida (linha 2). Em seguida, extrai dessa representao um
mtodo com a mesma assinatura da operao que est sendo
verificada (linha 3).
Listagem 7. Trecho do Template do Teste de Design para Operaes
referente assinatura do mtodo de teste.
1 public void testMethod<dif><MethodName>()

3 ...
Listagem 8. Trecho do Template do Teste de Design para Operaes referente
a verificao da existncia da operao.
1 ...
2 ClassNode aClass = dw.getClass(\<ClassName>);
3 MethodNode methodClass = aClass.getMethod(<MethodName>);
4 ...
Listagem 9. Trecho do Template do Teste de Design para Operaes referente
a verificao do tipo do retorno.
1 ...
2 assertEquals(The return of the method <MethodName> +
3 from the class <ClassName>must be<TypeName>,
4 <TypeName>, methodClass.getReturnType().getName());
5 ...
referente a verificao se a operao abstrata.
1 ...
2 assert<TrueFalse>(The method <MethodName> from +
3 the class <ClassName> must <not> be abstract,
4 methodClass.isAbstract());
5 ...
referente a verificao se a operao esttica.
1 ...
2 assert<TrueFalse>(The method<MethodName> from the +
3 class <ClassName> must <not> be static,
4 methodClass.isStatic());
5 ...
referente a verificao da visibilidade da operao.
1 ...
2 Collection<Modifier> modifs = methodClass.getModifiers();
3 assertTrue(The visibility of The method<MethodName> from +
4 the class <ClassName> must be +
5 <visibility>, modifs.contains(Modifier.<visibility>));
6}
32
A tag <MethodName> deve ser substituda pela assinatura

no mtodo. No design Wizard, a assinatura de um mtodo
composta pelo nome do mtodo, em seguida, entre parnteses,
os nomes dos tipos dos parmetros do mtodo, separados
por vrgula e na ordem como foram declarados. Dessa forma,
verificando a assinatura do mtodo, alm de verificar se o
nome do mtodo est correto, verifica-se tambm se o tipo
dos parmetros desse mtodo est correto, pois se algum dos
parmetros for declarado na implementao numa ordem
diferente ou com tipos diferentes, o mtodo com a assinatura
esperada no ser encontrado e o teste vai falhar indicando
que o mtodo no existe;
Tipo de Retorno. Dada a existncia da operao, a Listagem 9
exibe o trecho do mtodo de teste que verifica se essa operao
possui o mesmo tipo de retorno declarado no diagrama de
classe. Inicialmente, a tag <TypeName> deve ser substituda
pelo nome completo do tipo de retorno do mtodo no diagrama.
Caso a assertiva falhe, ela possui uma mensagem customizada
explicando a causa da falha do teste. Essa mensagem explicativa customizada substituindo as tags pelos seus valores
correspondentes no diagrama. Caso o mtodo testado seja
um mtodo construtor, essas linhas devem ser suprimidas
do teste a ser criado;
Mtodo Abstrato. A Listagem 10 exibe o trecho do mtodo
de teste que verifica se o mtodo extrado do cdigo deve ou
no ser abstrato, de acordo com a forma como a operao foi
declarada no diagrama. Se a operao no diagrama for abstrata,
na linha 2 deve-se substituir a tag <TrueFalse> por True, caso
contrrio, deve substituir por False.
Escopo do mtodo. A Listagem 11 exibe o trecho do mtodo
de teste que verifica o escopo da operao de acordo com a
forma como a operao foi declarada no diagrama, ou seja,
verifica se o mtodo possui um escopo de classe (mtodo esttico) ou escopo de instncia (mtodo comum). Se a operao
no diagrama possuir um escopo de classe, na linha 8 a tag
<TrueFalse> deve ser substitudo por True, caso contrrio,
deve substituir por False.
Visibilidade. A Listagem 12 exibe o trecho do mtodo de teste
que verifica se a visibilidade do mtodo extrado do cdigo
a mesma do mtodo no diagrama de classes. O padro de
substituio das tags para a criao dessa verificao segue o
mostrado para a visibilidade de classe.
Atributo
Nossos testes de design contemplam ainda os atributos dos
elementos do diagrama de classes. O template para atributo
verifica as caractersticas: nome, tipo de retorno, visibilidade e
escopo. Este template est organizado da seguinte forma:
que se trata de um teste de design para o atributo o qual o
Existncia do Atributo. A Listagem 14 exibe o trecho do mtodo de teste que verifica se existe uma classe com um atributo
com os mesmos nomes das respectivas entidades testadas do
diagrama. Se alguma dessas entidades no existir uma exceo

ser lanada e o teste falhar indicando a sua ausncia;
Escopo. A Listagem 15 exibe o trecho do mtodo de teste
que verifica o escopo do atributo de acordo com a forma
como o atributo foi declarado no diagrama de classe (escopo
de classe ou escopo de instncia). A criao desse teste segue
o mesmo padro do para a criao da verificao de escopo
de operaes;
Visibilidade. A Listagem 16 exibe o trecho do mtodo de
teste que verifica se a visibilidade do atributo extrado do cdigo a mesma do atributo no diagrama. A criao desse teste
segue o mesmo padro do para a criao do testes de design
mostrado anteriormente;
Verificao de Tipo. A Listagem 17 exibe o trecho do mtodo
de teste que verifica se o atributo possui o mesmo tipo do que
foi declarado no diagrama. importante frisar que essa verificao leva em considerao a multiplicidade do atributo. Se a
multiplicidade for 1 ou 0-1, o teste verifica se o tipo do atributo
o mesmo tipo do que est referenciado no diagrama de classe.
Contudo, se a multiplicidade desse atributo for maior que 1, o
teste verifica se o tipo desse atributo uma coleo.
O tipo da coleo a ser verificada definido de acordo com as
caractersticas do atributo: se o atributo for nico (isUnique) e
ordenado (isOrdered) o teste vai verificar se o tipo do atributo
java.util.SortedSet; se o atributo for somente nico, o tipo
verificado java.util.Set; se o atributo for somente ordenado
o tipo verificado java.util.List; por fim, se o atributo no
possuir nenhuma das caractersticas tratadas anteriormente,
o tipo verificado java.util.Collection;
Listagem 13. Trecho do Template do Teste de Design para Atributos

referente assinatura do mtodo de teste.
1 public void testAttribute<dif><NomeDoAtributo>()

3 ...
Listagem 14. Trecho do Template do Teste de Design para Atributos referente
a verificao da existncia do atributo.
1 ...
2 ClassNode aClass = dw.getClass(<NomeDaClasse>);
3 FieldNode attrClass = aClass.getField(<NomeDoAtributo>);
4 ...
a verificao se o atributo esttico.
1 ...
2 assertTrue(The attribute <NomeDoAtributo> of the class
3 + <NomeDaClasse> must <not> be static,
4 attrClass.isStatic());
5 ...
a verificao da visibilidade do atributo.
1 ...
2 Collection<Modifier> modifs = attrClass.getModifiers();
3 assertTrue(The attribute <NomeDoAtributo> of the class+
4 <NomeDaClasse> must be <visibilidade>
5 , modifs.contains(Modifier.<visibilidade>));
6 ...
a verificao do tipo do atributo.
Associao
Associaes so verificadas no cdigo seguindo uma abordagem que considera que todos os membros de uma associao
devem possuir um atributo representando cada memberEnd
navegvel dessa associao. Esses membros devem possuir
ainda mtodos get e set para manipular esses atributos.
Entretanto, nem todas as caractersticas abordadas podem
ser verificadas, pois a anlise esttica do cdigo no fornece
informao suficiente. Por exemplo, o mximo e mnimo de
elementos na associao no podem ser tratados, pois esse tipo
de informao s poderia ser extrada monitorando o nmero
de instncias de uma classe em tempo de execuo.
O template para associao deve ser aplicado para a criao de
testes de design para cada MemberEnd navegvel pertencente
associao. Para cada membro da associao gerado um
teste de design com as seguintes caractersticas:
que se trata de um teste de design para o cada membro da
associao o qual o template est sendo aplicado;
Papel na associao. A Listagem 19 exibe o trecho do mtodo
de teste que verifica se a classe que membro da associao
possui um atributo com o mesmo nome do papel dos outros
membros navegveis da associao. Esse teste ainda verifica
se essa classe possui os mtodos get e set para esse atributo
1 ...
2 assertEquals(The attribute <NomeDoAtributo> of the class
3 + <NomeDaClasse> must return the type +
4 <TipoDoAtributo> , <TipoDoAtributo> ,
5 attrClass.getDeclaredType().getName());
6}
Listagem 18. Trecho do Template do Teste de Design para cada Membro da
Associao referente assinatura do mtodo de teste.
1 public void testAssociation<dif><NomeFonte><NomeAlvo>()

2 throwsInexistentEntityException, IOException {
3 ...
Associao referente a verificao do papel de cada membro.
1 ...
2 ClassNode c1 = dw.getClass(<NomeTipoFonte>);
3 FieldNode f1 = c1.getField(<papel>);
4 MethodNode getAssoc1 = c1.getMethod(get<papel>());
5 MethodNode setAssoc1 = c1.getMethod(set<papel>());
6 ...
(linhas 4 e 5, respectivamente). Nesse teste, a tag <NomeTipoFonte> deve ser substituda pelo nome completo da classe
membro da associao que est sendo testada. A tag <papel>
deve ser substituda pelo nome do papel dos outros member
End navegveis dessa associao;
33
Tipo na Associao. A Listagem 20 exibe o trecho do mtodo

de teste que verifica se o atributo mapeado para a associao
e seus mtodos get e set utilizam o tipo esperado, ou seja,
a tag <NomeTipoAlvo>. Dependendo das caractersticas da
associao, se a multiplicidade for 0-1 ou 1, a tag <NomeTipoAlvo> deve ser substituda pelo nome completo do tipo do
outro memberEnd navegvel da associao. No entanto, se a
Associao referente a verificao do tipo de cada membro.
01
02
03
04
05
06
07
08
09
10
11
12
13
...
assertEquals(the method get<papel> of the class +
<NomeTipoFonte> must return the type +
<NomeTipoAlvo>, <NomeTipoAlvo>,
getAssoc1.getReturnType().getName());
assertEquals(the method set<papel> of the class +
<NomeTipoFonte> must return the type void,
void, setAssoc1.getReturnType().getName());
assertEquals(the attribute <papel> of the class +
<NomeTipoFonte> must return the type +
<NomeTipoAlvo>, <NomeTipoAlvo>,
f1.getDeclaredType().getName());
...

Associao referente a verificao da visibilidade de cada membro.
01 ...
02 Collection<Modifier> modifs = f1.getModifiers();
03 assertTrue(the attribute <papel> of the class +
04 <NomeTipoFonte> must be private
05 , modifs.contains(Modifier.PRIVATE));
06 modifs = getAssoc1.getModifiers();
07 assertTrue(the method get<papel> of the class +
08 <NomeTipoFonte> must be <visibilidade>
10 modifs = setAssoc1.getModifiers();
11 assertTrue(the method set<papel> of the class +
12 <NomeTipoFonte> must be <visibilidade>
14 ...
Associao referente a verificao dos membros de somente leitura.
1 ...
2 Collection<MethodNode> methodsGetAssoc =
3 getAssoc1.getCalledMethods();
4 boolean isReadOnly = false;
5 for(MethodNode method : methodsGetAssoc) {
6 if(method.getName().equals
7 (java.util.Collections.unmodifiable)) {
8 isReadOnly = true;
9 break;
10 }
11 }
12 assertTrue(The method set<papel> must returns a +
13 java.util.Collections.unmodifiable,
14 isReadOnly);
15 }
Listagem 23. Trecho do Template do Teste de Design para Interface referente
1 public void testInterface<dif><NomeDaInterface>()

3 ...
34
multiplicidade for superior a 1, o tipo esperado uma coleo

especializada, logo, a tag <NomeTipoAlvo> deve ser substituda pelo mesmo padro dos tipos das colees explicadas na
seo sobre tipo de atributo.
A substituio das demais tags segue o mesmo padro dos
itens anteriores. As linhas 1-5 e 6-8 so referentes verificao
dos tipos dos mtodos get (tipo de retorno) e set (parmetro
do mtodo), respectivamente. Por fim, as linhas 9-12 so referentes verificao do tipo do atributo o qual a associao
foi mapeada;
Visibilidade. O atributo que representa o memberEnd associado deve ser privado, e a visibilidade para esse memberEnd
deve ser retida nos mtodos get e set de cada membro da
associao. Sendo assim, a Listagem 21 exibe o trecho do mtodo de teste que verifica se o atributo da associao possui a
visibilidade privada (linhas 2-5) e se a visibilidade dos mtodos
get (linhas 7-9) e set (linhas 10-13) esto de acordo com a visibilidade de cada membro navegvel descrito no diagrama;
Somente leitura. Essa caracterstica difcil de ser verificada atravs de anlise esttica, pois s possvel certificar
se um artefato est sendo somente lido ou se est sendo
alterado atravs da monitorao do software em tempo de
execuo.
Porm, podemos verificar essa caracterstica em associaes
com multiplicidade superior a 1 da seguinte forma: o teste
verifica se o mtodo get para o atributo o qual memberEnd foi
mapeado retorna uma coleo atravs do mtodo Collections.
unmodifiable da API para colees de Java. Se a associao no
for somente leitura ou se no tiver uma multiplicidade superior
a 1, essas linhas devem ser suprimidas. A Listagem 22 exibe o
trecho do mtodo de teste que verifica essa caracterstica.
Interface
Outro artefato que nossa soluo tambm testa interface.
O template de Interface verifica as caractersticas: nome e
hierarquia de interfaces. O template est organizado da seguinte forma:
que se trata de um teste de design para a interface a qual o
Existncia da interface. A Listagem 24 exibe o trecho do
mtodo de teste que verifica se existe uma interface na implementao com o mesmo nome da interface especificada
no diagrama de classe. O nome que verificado o nome
completo da interface, ou seja, o nome da interface seguindo a
hierarquia de entidades do projeto. Diferente das verificaes
anteriores, onde a verificao da existncia da entidade se d
quando a entidade extrada do DesignWizard (getClass,
getAttribute, dentre outras.). Para realizar a verificao de
interface necessria uma assertiva a mais, pois uma interface
extrada do cdigo pelo DesignWizard como um ClassNode
comum. A assertiva adicional (linhas 3-4) verifica se o ClassNode extrado realmente representa uma interface, atravs
do mtodo isInterface;
Hierarquia de interfaces. A Listagem 25 exibe o trecho do

mtodo de teste que verifica se uma interface presente no cdigo
estende de outras interfaces, de acordo com a hierarquia de interfaces presente no diagrama de classe. As linhas 1-2 especificam
os nomes completos das interfaces que a interface testada herda
de acordo com o diagrama de classe. As linhas 4-11 iteram sobre
esses nomes verificando se a interface no cdigo tambm herda
das outras interfaces com os mesmos nomes;
Pacote
Por fim, nossa abordagem capaz de criar testes de design
para verificar os pacotes do diagrama de classe. O template
para pacote verifica as caractersticas: nome, hierarquia de
pacote e relacionamentos entre pacote. O template est organizado da seguinte forma:
Nome do teste. A Listagem 26 exibe o trecho do mtodo de
teste que cria a assinatura do teste de design, identificando que
se trata de um teste de design para o pacote o qual o template
est sendo aplicado.
Existncia do pacote. O teste de design gerado verifica se
existe um pacote na implementao com o mesmo nome do
pacote no diagrama de classe. A Listagem 27 exibe o trecho do
mtodo de teste responsvel por verificar essa caracterstica.
Nesse trecho a tag <NomeDoPacote> deve ser substituda pelo
nome completo do pacote, ou seja, o nome do pacote seguindo
a hierarquia de entidades do projeto, da mesma forma como foi
explicado para a verificao do nome de classes. Dessa forma,
esse trecho alm de testar a existncia do pacote ainda verifica
se a hierarquia de pacotes no cdigo condiz com a hierarquia
especificada no diagrama de classe;
Relacionamento entre pacote (Access e Import). A
Listagem 28 exibe o trecho do mtodo de teste responsvel
por verificar se os elementos dos pacotes se relacionam de
acordo com as diretrizes do relacionamento import e access.
As linhas 2-3 especificam quais outros pacotes esse pacote
se relaciona (de acordo com as diretrizes de relacionamento
entre pacotes). A linha 4 cria uma coleo com todas as entidades do pacote testado. As linhas 5-9 criam um coleo com
todas as classes que podem ser extensveis pelas classes do
pacote testado (ou seja, as classe internas ao prprio pacote
e as classes dos pacotes apontados na linha 3). Por fim, as
linhas 10-18 verificam se todos os elementos do pacote testado (internalEntyties) estendem (herana de classe linhas
11-13, realizao de interface - linhas 14-17) dos elementos do
prprio pacote ou dos pacotes acessados.
Exemplo de Aplicao dos Templates

Para exemplificar como a abordagem apresentada neste artigo
pode ser aplicada em um caso real, considere o desenvolvimento
de um sistema Web, onde o designer desse sistema toma uma
deciso estratgica de que o objeto que manipula os dados, DataHandler, deve seguir o padro Singleton, para facilitar a sincronizao do acesso aos dados. De acordo com o padro Singleton,
o objeto deve possuir: (1) seus construtores sendo privados, (2) um
atributo esttico, privado e com o tipo igual ao tipo da prpria

verificao da existncia da Interface.
1 ...
2 ClassNode aClass = dw.getClass(<NomeDaInterface>);
3 assertTrue(The class <NomeDaInterface> must be a interface,
4 aClass.isInterface());
5 ...
verificao da hierarquia da Interface.
01 ...
02 String[] superInterfaces =
03 {<superInterface1>, <superInterface2>, ,...};
04 for(String superInterface : superInterfaces) {
05 ClassNode cnInterface = dw.getClass(superInterface);
06 Set<ClassNode> interfacesExtend =
07 aClass.getImplementedInterfaces();
08 assertTrue(The interface <NomeDaInterface>+
09 must extends from + superInterface,
10 interfacesExtend.contains(cnInterface));
11 }
12 }
Listagem 26. Trecho do Template do Teste de Design para Pacote referente
1 public void testPackage<dif><NomeDoPacote>()

throws java.io.IOException, InexistentEntityException {
2 ...
verificao da existncia do pacote.
1 ...
2 PackageNode thePackage = dw.getPackage(<NomeDoPacote>);
3 ...
verificao dos relacionamentos entre os pacotes.
01 ...
02 String[] importedPackages =
03 {<PackageImp1>, <PackageImp2>, ...};
04 Set<ClassNode> internalEntyties = thePackage.getAllClasses();
05 Set<ClassNode> extentableEntiites = internalEntyties;
06 for(StringaPackage : importedPackages) {
07 extentableEntiites.addAll(dw.getPackage(aPackage)
08 .getAllClasses());
09 }
10 for(ClassNode aEntity : internalEntyties) {
11 assertTrue(aEntity + cannot extends the class +
12 aEntity.getSuperClass(),
13 extentables.contains(aEntity.getSuperClass()));
14 for(ClassNodeaInterface : aEntity.getImplementedInterfaces()) {
15 assertTrue(aEntity + cannot implements the interface
16 + aInterface, extentableEntiites.contains(aInterface));
17 }
18 }
19 }
classe e (3) um mtodo chamado getInstance, que deve retornar

uma instncia nica desse objeto (ou seja, o atributo esttico
privado). Dessa forma, todas as classes que tratarem dados no
sistema vo tratar somente com uma nica instncia. A Figura 2
exibe a classe do diagrama que projeta o acesso aos dados.
35
Aplicando os templates de testes mostrados anteriormente para

verificar a implementao dessa classe sero criados os cdigos:
Listagem 29 (verificao da classe DataHandler), Listagem 30 (verifica0o do atributo self ), Listagem 31 e Listagem 32 (verificao
dos mtodos construtor e getInstance, respectivamente). Considere que a seleo e aplicao dos templates de testes de design deve
ser feito manualmente pela equipe de desenvolvimento.
A Listagem 29 referente verificao da existncia da classe DataHandler (linha 3) da forma como ela foi especificada:
concreta (linhas 4-5) e pblica (linhas 6-8).
Figura 2. Classe de acesso ao banco de dados
A Listagem 30 referente verificao do atributo self da

classe DataHandler. O teste verifica se o tipo desse atributo
o mesmo tipo da classe onde ele est contido (linhas 5-7) e se
ele um atributo esttico (linhas 8 e 9) e privado (linhas de
10-13), conforme especificado na Figura 2.
A Listagem 31 referente verificao do construtor (especificado pelo DesignWizard por <init>) da classe DataHandler
(linha 4). O restante do mtodo de teste verifica as demais
caractersticas do mtodo testado. Em especial, ele verifica se
esse construtor possui a visibilidade privada (linhas 9-11), que
uma caracterstica prpria do design pattern Singleton.
Por fim, a Listagem 32 referente verificao do mtodo
getInstance da classe DataHandler (linhas 3 e 4). O restante do
mtodo de teste verifica as demais caractersticas do mtodo
testado. Em especial, verifica se ele retorna um tipo igual ao
da classe que ele pertence (linhas 5-6), e se ele um mtodo
esttico (linhas 9-10), que so caractersticas prprias do design
pattern Singleton.
Listagem 29. Verificao da classe DataHandler.
Execuo dos Testes Gerados
1 public void testClass1DataHandler() {

2 DesignWizard dw = new DesignWizard(/Project);
3 ClassNode aClass = dw.getClass(DataHandler);
4 assertFalse(The class DataHandler must not be abstract,
5 aClass.isAbstract());
6 Collection<Modifier> modifs = aClass.getModifiers();
7 assertTrue(The visibility of the class DataHandler must be public
8 , modifs.contains(Modifier.PUBLIC));
9}
Nesta seo vamos mostrar como os testes de design funcionam para identificar erros na implementao de um sistema.
Inicialmente, considere a classe mostrada na seo anterior,
DataHandler, e os testes gerados para esta classe. Considere
agora que esta classe foi implementada de uma maneira simplificada, como pode ser vista na Listagem 33. Implementada
assim, essa classe quebra completamente a deciso estratgica
de que o acesso aos dados seja realizado atravs de um Singleton, pelo fato de possuir um construtor pblico.
A Figura 3 mostra os erros no design apontados pelos testes
de design, quando executados sobre a classe DataHandler
mostrada na Listagem 33. Abaixo do label Failure Trace so
mostrados os traces resultantes da execuo de cada um dos
mtodos de teste de design mostrado anteriormente. O primeiro trace referente verificao do mtodo construtor.
Perceba que ele falha, indicando que a visibilidade do mtodo
construtor deve ser privada: The visibility of The method
<init>() from the class DataHandler must be private. E o segundo e terceiro traces so referentes verificao do mtodo
getInstance e do atributo self, respectivamente. Alm disso,
eles falham apontando que o mtodo e o atributo no existem
na implementao do DataHandler.
Listagem 30. Verificao do atributo self.
01
02
03
04
05
06
07
08
09
10
11
12
public void testAttribute1Sel() {

DesignWizard dw = new DesignWizard (/Project);
ClassNode aClass = dw.getClass (DataHandler);
FieldNodeattrClass = aClass.getField(self);
assertEquals(The attribute self from the class DataHandler must be
DataHandler,
DataHandler,attrClass.getDeclaredType().getName());
assertTrue(The attribute seflfrom the class DataHandler must be
static ,
attrClass.isStatic());
Collection <Modifier> modif s = attrClass.getModifiers();
assertTrue(The visibility of the attribute self from the class
DataHandler must be private ,
modif s.contains(Modifier.PRIVATE));
}
Listagem 31. Verificao do atributo construtor.
01
02
03
04
05
06
07
08
09
10
11
12
36
public void testMethod1construc(){

DesignWizard dw = new DesignWizard (/Project) ;
ClassNode aClass = dw.getClass (DataHandler) ;
MethodNode methodClass = aClass.getMethod(<init>()) ;
assertFalse(The method <init>() from the class DataHandler must
not be abstract ,
methodClass.isAbstract());
assertFalse (The method <init>() from the class DataHandler must
not be static ,
methodClass.isStatic());
Collection <Modifier> modif s = methodClass.getModifiers();
assertTrue(The visibility of The method <init>() from the class
DataHandler must be private
, modif s.contains(Modifier.PRIVATE));
}
Consideraes parciais
At este ponto apresentamos uma abordagem para verificao de conformidade entre o design de um sistema especificado atravs de digramas de classes UML e o seu cdigo fonte
implementado em Java. A abordagem consiste basicamente de
templates de testes de design para cada artefato da especificao de diagrama de classes proposto pela OMG.
Os templates de testes de design que foram mostrados podem ser aplicados para verificar caractersticas dos seguintes
artefatos do diagrama de classe de UML: classe, atributo,
operao, associao, interface e pacote. Esses artefatos foram
selecionados, pois se mostram como os mais usuais para a
descrio de modelos usando diagrama

de classes. Alm disso, exemplificamos a
aplicao desses templates para a criao
de testes de design para a verificao de um
trecho de uma aplicao Web para acesso
aos dados da aplicao.
Sobre o escopo das caractersticas verificadas, fato que, segundo a especificao
da OMG, classes possuem outras caractersticas alm das tratadas anteriormente. Figura 3. Resultado dos testes de Design para a classe DataHandler
Contudo, julgamos que essas caractersticas
cobrem as mais usuais para a modelagem
Listagem 32. Verificao do mtodo getInstance.
de diagramas de classe. Outro fato relevante nesse sentido
que vrias caractersticas desses diagramas so muito difceis
01 publicvoid testMethod2getInstance() {
02 DesignWizard dw = new DesignWizard(/Project);
de serem verificadas por anlise esttica do cdigo. Por exem03 ClassNodeaClass = dw.getClass (DataHandler );
plo, o nmero mximo de instncias de uma classe s poderia
04 MethodNode methodClass = aClass.getMethod (getInstance());
ser verificada monitorando o cdigo em tempo de execuo
05 assertEquals(The return of the method getInstance from the class
DataHandler must be +
e verificando se o nmero de instncias de uma classe no
06 DataHandler , DataHandler , methodClass.getReturnType()./]
ultrapassa o nmero de instncias projetadas no diagrama
getShortName());
de classe do sistema.
07 assertFalse(The method getInstance from the class DataHandler
Gerao Automtica de Testes de Design

A abordagem apresentada at o momento para criao de
testes de design a partir de templates de teste possibilita a
verificao de um design expresso atravs do diagrama de
classe sobre a sua implementao em Java. Contudo, para a
adoo em um ambiente real, ele possui alguns problemas
prticos devido aos seguintes fatos:
1. Necessidade do aprendizado de uma nova API. Os testadores tero que conhecer a biblioteca do DesignWizard para
poder aplic-la bem, e especialmente estenderem os testes de
design;
2. Testes muito detalhados. Devido fina granularidade dos
testes de design para cada artefato do diagrama, a criao dos
testes para estes artefatos pode ser muito custosa;
3. Criao manual. A aplicao dos templates sobre cada artefato especfico do diagrama de classe teria que ser realizada
manualmente. Essa ao, alm de sobrecarregar o processo de
desenvolvimento, aumenta o trabalho dos testadores, e fica
bastante propcia a erros humanos na sua criao.
Para solucionar os problemas citados, temos uma ferramenta
chamada UDT (UML Design Tester) que visa gerar automaticamente testes de design capazes de verificar a conformidade
entre a implementao em Java de um sistema e o seu design
expresso atravs de diagramas de classe UML.
A partir de agora faremos uma introduo arquitetura
adotada pela ferramenta de UDT. Em seguida, detalharemos
a implementao de cada mdulo especfico da ferramenta,
destacando os dois principais: o mdulo de gerao de modelos
e o mdulo de gerao da sintaxe concreta.
UML Design Tester (UDT)

UDT uma ferramenta capaz de gerar automaticamente
testes de design para verificar os artefatos do diagrama de
must not be abstract ,

08 methodClass.isAbstract());
09 assertTrue (The method getInstance from the class DataHandler }
must be static ,
10 methodClass.isStatic());
11 Collection <Modifier> modif s = methodClass.getModifiers();
12 assertTrue(The visibility of The method getInstance from the class
DataHandler must be public ,
13 modif s.contains(Modifier.PUBLIC));
14 }
Listagtem 33. Implementao do DataHandler com o design alterado.
1 ...
2 public class DataHandler {
3 public DataHandler() {
4 ...
5 }
6 ...
7}
classes. Esses testes so gerados para todos os templates

mostrados neste artigo. A UDT foi implementada em Java,
a sequncia de atividades que essa ferramenta realiza para
gerar dos testes de design esto ilustradas na Figura 4.
As quatro atividades principais do UDT so realizadas por
quatro mdulos distintos:
Mdulo de Pr-processamento: responsvel por executar
todas as aes necessrias para a configurao do ambiente
de gerao dos testes de design. Por exemplo, verificar a
consistncia dos arquivos;
Mdulo de Gerao de Modelos: executa as aes necessrias para gerao dos modelos dos testes de design para
o diagrama de classe a ser testado, seguindo os templates
de testes de design;
Mdulo de Gerao da Sintaxe Concreta: responsvel por,
baseado nos modelos dos testes de design, gerar o arquivo
com a classe Java final, compilvel e executvel;
37
Mdulo de Ps-processamento: finaliza corretamente a

ferramenta UDT, excluindo todos os artefatos intermedirios
para a gerao do teste de design final.
A abordagem adotada para a gerao automtica dos testes de
design foi o padro MDA. H vrios fatores que nos levaram a
escolher MDA para dar suporte soluo, como:
Alinhamento com os padres da OMG. A OMG props MDA
de forma que fosse capaz de facilitar o processo de desenvolvimento de software, alinhado com seus prprios padres;
Reuso de transformaes. Dado que todas as transformaes so baseadas em meta-modelos, ento domnios que
compartilhem os mesmos meta-modelos podem reusar suas
(uma parte ou completamente) transformaes. Por exemplo,
considere dois projetos que geram modelos de cdigo Java
usando o mesmo meta-modelo. Para gerar a sintaxe concreta
desses modelos um projeto pode reusar as transformaes do
outro e somente implementar as caractersticas que no so
cobertas pelas transformaes do primeiro projeto;
Separao evidente entre representao e lgica. A representao do sistema, as transformaes de cada nvel e a
implementao do sistema, so todos implementados por
artefatos distintos;
Separao de Concerns. Para cada artefato tratado neste
artigo, existe um catlogo especfico de transformaes responsvel por gerar seus testes de design.
Mdulo de Pr-processamento
Nesse mdulo esto todas as aes necessrias para a configurao do ambiente de gerao dos testes de design. As aes
default do sistema so:
1. Verificao dos arquivos de entrada: ela verifica se os parmetros inseridos como entrada para a ferramenta realmente
existem, se o arquivo XMI (padro da OMG para persistir em
arquivo diagramas UML) est bem formado, e se o software
testado corresponde a um JAR;
2. Criao de um diretrio temporrio: ela cria o diretrio
onde todos os arquivos auxiliares, criados durante a gerao
dos testes, sero criados (sand box);
3. Ajuste de meta-modelo: ela converte o meta-modelo do

XMI passado como parmetro para o meta-modelo adotado
pela ferramenta, o proposto pela OMG. Isso se deve ao fato de
que a ferramenta deve ser capaz de tratar XMIs gerados por
diversas ferramentas. Contudo, algumas dessas ferramentas
geram o XMI resultante com um meta-modelo diferente do
padro, sendo assim, necessitando ser alterado. Algumas
ferramentas que persistem adequadamente os arquivos XMI
so, por exemplo, MagicDraw e o OMONDO;
4. Configurao da localizao do projeto testado: ela insere
o caminho do JAR da aplicao testada nos arquivos de configurao. Essa informao importante para posteriormente
ser usada na gerao dos testes de design com esse caminho
especificado.
Outras aes podem ser incorporadas ao sistema. Para tanto, essas novas aes devem estender da interface java.lang.
Runnable da API de Java, e elas devem executar suas tarefas
no corpo do mtodo run. Alm disso, deve-se adicionar as
novas aes lista de aes a serem executadas (preActions)
contida na classe br.edu.gmf.udt.preProcess.Preprocessor.
Mdulo Gerador de Modelos

Esse mdulo responsvel por criar todos os modelos dos
cdigos dos testes de design produzidos pela ferramenta UDT.
Com o intuito de que nossa ferramenta seja capaz de executar
outras transformaes, adotamos a microarquitetura mostrada
na Figura 5. Nesta arquitetura adotamos o design pattern
Abstract Factory que deve prover um conjunto de interfaces capazes de abstrair a forma como diferentes famlias de produto
sejam implementadas. Para a UDT, esse conjunto de interfaces
abstraem a execuo das transformaes que geram os testes
de design. Para tanto, definimos duas interfaces M2M_Seed
e M2M_Machine e uma fbrica (M2M_Factory) responsvel
por selecionar as realizaes dessas interfaces. Os objetos que
implementam a M2M_Machine so responsveis por executar
diretamente do cdigo da ferramenta as transformaes que
geram os modelos de testes. Os objetos que implementam a
M2MSeed possuem duas funes: (1) selecionar sua M2M_Machine correspondente no mtodo
createMachine da M2M_Factory; (2)
passar os parmetros necessrios
para a execuo de sua M2M_Machine correspondente, como por
exemplo, o caminho do modelo de
entrada e sada, etc.
Mdulo de Gerao de Modelos

de Testes de Design
Figura 4. Principais atividades realizadas pela ferramenta UDT
38
Dado que esse mdulo responsvel por gerar os modelos dos testes
de design a partir dos diagramas de
classe UML e que adotamos o framework MDA para a gerao desses
testes, esse mdulo responsvel por
transformar modelos PIM em PSM. O diagrama de classe

considerado como PIM, visto que ele genrico o suficiente
para que possa ser implementado em qualquer linguagem
de programao orientada a objeto. E os modelos de testes
de design so PSM, pois so modelos especficos da linguagem Java.
A Figura 6 mostra a abordagem MDA adotada para
esse mdulo. Nesta figura, encontramos os seguintes
artefatos:
Meta-modelos: como esse mdulo gera modelos de cdigo Java a partir de modelos UML, ento adotamos dois
meta-modelos: i) o origem sendo o da UML 2.0, provido
pelo consrcio OMG; e ii) o destino como sendo o da
linguagem Java - JAS (Java Abstract Syntax), uma representao completa do cdigo Java, adotada pelo Eclipse,
por exemplo;
Modelos: os modelos de entrada so os diagramas de
classe UML contendo o design estrutural do software,
enquanto os de sada so os modelos do cdigo dos testes
de design, criados de acordo com os templates de teste
mostrados no captulo anterior. Ambos os modelos de
entrada e sada devem estar em conformidade com seus
respectivos meta-modelos;
Transformaes: as transformaes foram feitas seguindo a linguagem ATL. Escolhemos essa linguagem, pois ela
possui um framework de criao e execuo amplamente
utilizado, e est alinhada com os atuais padres MDA.
Visto que especificamos em ATL as transformaes que
geram os modelos dos testes de design, ento implementamos ainda a ATL_Seed e ATL_Machine para a execuo
automtica dessas transformaes, de acordo com a arquitetura mostrada na seo anterior (Figura 5).
Transformaes em ATL
Os testes de design so gerados seguindo os templates de
testes de design. Contudo, esses templates s existem conceitualmente no UDT. Na ferramenta as transformaes de
PIM para PSM so a realizao da aplicao dos templates,
ou seja, so essas transformaes que capturam as informaes relevantes do diagrama de classe e geram os modelos
do cdigo de teste para cada artefato.
Para a realizao das transformaes nesse nvel utilizamos
a linguagem ATL. Apesar do padro proposto pela OMG
para esse tipo de transformao ser QVT. Decidimos usar
ATL, pois, diferente de QVT, essa linguagem possui um
framework de criao e execuo amplamente utilizado. E
ainda, assim como QVT, estas transformaes esto completamente alinhadas com os atuais padres da OMG.
As transformaes para a gerao dos testes de design
foram organizadas hierarquicamente para facilitar a compreenso, identificao e extenso dessas transformaes.
Dividimos essa hierarquia de regras em 4 nveis. A Figura 7
mostra a aplicao de cada um desses nveis para gerar uma
linha de cdigo que verifica se uma classe abstrata.
Figura 5. Arquitetura para extenso da ferramenta UDT
Figura 6. Abordagem MDA do Mdulo de Gerao de Modelos de Testes

de Design
1. R1 - Regras de artefato do cdigo. Desenvolvemos uma

match rule ATL1 para cada artefato do diagrama de classe
considerado. Essa match rule responsvel por criar o teste
de design, segundo o template desse artefato. Essa regra cria
o mtodo que testa o artefato (mtodo vazio) e chama as called
rules ATL2 que criam a verificao de cada caracterstica desse
artefato. A Figura 7 mostra que as transformaes referentes
Classe so executadas sobre a Classe C;
2. R2 - Regras de caracterstica de artefato. Essas called rules
criam os trechos do teste de design que testam cada caracterstica especfica de um artefato. Essas regras, por sua vez,
chamam a called rule responsvel por criar cada linha do
template que verificam essa caracterstica. A Figura 7 mostra
a transformao R2 gerando o trecho do testes de design
1 Match Rule - uma forma de transformao provida pela ATL onde os
programadores podem declarar como os elementos dos modelos de entrada
podem ser mapeados nos elementos dos modelos de sada. Trata-se de regras
declarativas.
2 Called rule - um tipo de regra provido pela ATL que podem ser invocadas
sem a necessidade haver mapeamento com algum elemento. Trata-se de
regras imperativas.
39
referente verificao da existncia da Classe C. Apesar da

Figura 7 mostrar que essa transformao gera uma linha, ela
poder gerar vrias outras, dependendo do cdigo necessrio
para gerar o trecho do teste que verifica a caracterstica;
3. R3 - Regra de linha de cdigo. Essas regras criam as entidades
especficas de uma linha de comando. Depois disso chama uma
called rule que recebe essas especificidades e cria a linha de
comando final. Considere como exemplo a declarao simples
de uma varivel. As regras desse nvel vo criar o nome da
varivel e o seu tipo, e em seguida chama uma regra que monta
a linha de cdigo final. A Figura 7 mostra a transformao R3
gerando as entidades especficas para a criao da linha do
testes de design que verificam a existncia da Classe C;
4. R4 - Regra de comando genrico de Java. Essa regra recebe
as especificidades da linha de comando e a cria de acordo com
meta-modelo da linguagem Java. Por exemplo, considere a
declarao simples de uma varivel mostrada no item anterior,
Listagem 34. Transformao ATL para gerao dos modelos de Teste de
Design para classe.
01 module TestClassJava;
02 create OUT : JavaAbstractSyntax from IN : uml2;
03 ...
04 rule CreateClassTest {
05 from class : uml 2 ! Class
06 toblockMethod : JavaAbstractSyntax ! Block (
07 statements <- Sequence {} )
08 do {
09 self.initializingClassTest(blockMethod, class);
10 self.verifyIsAbstract(blockMethod, class);
11 self.verifySuperType(blockMethod, class);
12 self.verifyClassModifiers(blockMethod, class);
13 self.verifyClassInterfaces(blockMethod, class);
14 self.CreateGeneralTestMethod (testClass+
15 self.classesCounter.toString() +
16 _ + class.methodName, blockMethod);
17 }
18 }
19 ...
Figura 7. Hierarquia das regras de transformaes ATL
40
a regra em R4 vai receber como parmetro o nome e tipo da

declarao. Com esses parmetros, ela vai criar uma entidade
de um comando de uma declarao de varivel, e incorpora
essa nova linha aos comandos do devido mtodo. A Figura 7
mostra a transformao R4 gerando a linha final do cdigo e
a acrescentando ao teste que est sendo gerado.
Ilustramos na Listagem 34, a regra de transformao R1 para
a gerao dos testes para Classe. Contudo, especificamos todas
as regras de todos os nveis que geram os testes de design
mostrados anteriormente. A Listagem 34 est organizada da
seguinte forma:
Linha 1: identifica o mdulo dessa transformao ATL,
mostrando que ele trata da verificao de classes;
Linha 2: identifica que o modelo de sada segue o metamodelo da Sintaxe Abstrata de Java. E que o modelo de entrada
deve seguir o meta-modelo de UML2;
Linha 4: mostra o nome da regra responsvel pela criao
dos testes para a verificao das classes do template;
Linha 5: mostra que essa match rule ser executada para
cada classe do diagrama de classe;
Linhas 6 - 7: cria o elemento Block do meta-modelo de JAS.
Esse elemento o bloco do mtodo, onde todos os comandos
gerados (pelas regras R3) devero ser incorporados;
Linhas 8 - 17: a parte imperativa dessa regra, nesse trecho
onde so chamadas as regras do nvel R2;
Linha 9: Essa linha chama uma called rule R2 responsvel
por criar a inicializao do mtodo de teste (linha 3 do template
de testes de design para classe);
Linha 10: Essa linha tambm chama outra called rule R2,
essa responsvel por verificar se a classe abstrata (linhas 4
e 5 do template de testes para classe);
Linha 11: j essa linha chama uma called rule R2 responsvel
por verificar o supertipo da classe. nessa called rule onde
examinado se a classe verificada do diagrama possui algum
supertipo (linhas 6, 7 e 8 do template para Classe). Se a classe
testada no possuir supertipo, nenhuma outra called rule
chamada;
Linha 12: essa linha chama uma called
rule R2 responsvel por verificar a visibilidade da classe (linhas 9, 10 e 11 do
template de classe);
Linha 13: essa linha chama uma called
rule R2 responsvel por verificar as interfaces realizadas pela classe (linhas 12 a 21
do template do teste de classe);
Linhas 14 - 16: diferente das linhas
anteriores, essa linha no chama uma
called rule R2, ao invs disso, ela chama
diretamente uma called rule R4. Ela responsvel por criar um mtodo segundo
o meta-modelo da Sintaxe Abstrata de
Java. Essa called rule recebe dois parmetros: o nome do mtodo e o corpo do
mtodo com as suas linhas (Block). Para
o nome do mtodo passada uma String
formada por: testClass (linha 14), um contador (para servir

como <diff>, linha 15) e o nome completo da classe (linha 16).
Para o corpo do mtodo passado o elemento Block (linha 16)
criado no incio da transformao (linhas 6-7), onde cada linha
criada para o teste de design foi incorporada.
Mdulo de Gerao da Sintaxe Concreta

A fim de tornar os modelos de testes gerados pelo mdulo
da seo anterior compilveis e executveis, construmos um
mdulo para gerao de sintaxe concreta. Implementamos
esse mdulo para modelos que sigam o meta-modelo JAS
adotado.
Na Figura 8 apresentada a abordagem MDA adotada para o
Mdulo Gerador de Sintaxe Concreta. Esse mdulo responsvel pela transformao de PSM (modelos dos testes de design)
para sintaxe concreta (cdigo Java compilvel e executvel).
Nesta figura, descrevemos os seguintes artefatos:
Meta-modelo: dado que esse mdulo gera a sintaxe concreta a
partir de modelos de cdigo Java, somente foi necessrio adotar
um meta-modelo, o JAS, como meta-modelo de origem. Um
meta-modelo destino desnecessrio na gerao de sintaxe
concreta de uma linguagem final;
Modelos: os modelos de entrada so os modelos do cdigo
dos testes de design produzidos pelo mdulo anterior. Os modelos de sada so os cdigos dos testes de design na sintaxe
concreta de Java;
Transformaes: As transformaes de modelo para texto
(M2T) foram definidas usando a linguagem MOFScript. Essa
linguagem mapeia os elementos do modelo do cdigo em
elementos da gramtica de Java, formando sentenas bem
formadas de acordo com essa gramtica.
O processo de gerao da sintaxe concreta se d em trs
etapas: inicialmente, (i) so carregados os modelos de cdigo
Java; em seguida, (ii) os scripts de transformao realizam os
mapeamentos dos elementos dos modelos do cdigo para a
sintaxe concreta da linguagem; e por fim, (iii) o cdigo Java
em sintaxe concreta persistido em arquivo. Esse arquivo
produzido um arquivo de cdigo fonte Java compilvel, uma
vez que ele est de acordo com o meta-modelo de Java.
Transformaes em MOFScript
Diferente das transformaes mostrados anteriormente,
responsveis por gerar os modelos do cdigo de teste, as
transformaes desse mdulo possuem outro objetivo. A partir dos modelos de cdigo, gerar cdigo em sintaxe concreta,
com expresses bem formadas de acordo com a gramtica da
linguagem Java.
A OMG props um padro especfico para tratar as transformaes de Modelos para texto, dentre as linguagens que
seguem esse padro decidimos usar a MOFScript. As vantagens dessa linguagem que nos motivou a sua escolha foram:
i) ela possui um ambiente de criao e execuo para suas
transformaes; ii) ela possui caractersticas de orientao
a objetos, como herana e polimorfismo; iii) o ambiente de
Figura 8. Abordagem MDA do Mdulo de Gerao da Sintaxe Concreta
criao possui algumas vantagens (como highlight de sintaxe,

auto-complemento de cdigo e indicao de erros mais clara)
em relao a outras abordagens como o JET, e o ATL DT; e iv)
o MOFScript est em conformidade com os padres propostos
atualmente pela OMG.
Apesar de MOFScript no ser o padro adotado pela OMG,
ela est em conformidade com o Request for Proposals da OMG
para o padro MOF2Text. A resposta adotada pela OMG para
esse padro est sendo desenvolvida pela ferramenta MDT
do eclipse, contudo ela ainda est em desenvolvimento, e a
verso 1.0 s ficar disponvel em setembro de 2009. Definimos
uma abordagem para a criao das regras de transformaes
em MOFScript. Inicialmente, determinamos que deveramos
agrupar as transformaes referentes a cada tipo concreto da
JAS de acordo com os tipos abstratos que elas realizam. Por
exemplo, agrupamos em um nico arquivo as transformaes
referentes aos tipos concretos que realizam AbstractTypeDeclaration, outro para os que realizam Annotation, e assim por
diante. No meta-modelo de JAS podem ser encontrados todos
os tipos definidos (tanto concretos quanto abstratos).
Seguimos essa abordagem pelos seguintes motivos: (i)facilita
a compreenso, pois as regras que tratam os tipos que realizam
o mesmo tipo abstrato, normalmente, so sema e envolvem
elementos similares; e (ii) simplifica os relacionamentos entre
os agrupamentos, pois um agrupamento somente precisa conhecer os outros os quais seus elementos esto relacionados.
Determinamos ainda que as regras de transformao para
cada agrupamento fossem divididas em dois grupos. As
TextTransformations (TT), responsveis por recuperar as
informaes relacionadas s especificidades do elemento do
meta-modelo tratado pela regra. E as SyntaxTransformations
(ST), responsveis por formatar o texto gerado selecionando
as palavras reservadas da linguagem e escrevendo as informaes na ordem correta. A ttulo de ilustrao, considere
o comando de declarao de uma varivel (VariableDeclarationStatement). Esse elemento no meta-modelo possui trs
relacionamentos:
41
Modificadores: identificam quais as caractersticas da declarao desse atributo. Por exemplo, a visibilidade (public,
private, etc.), se esttico (static), etc.;
Tipo: identifica qual o nome do tipo do atributo que est
sendo declarado;
Fragmentos: identificam as informaes referentes como o
atributo est sendo declarado. Por exemplo, o nome do atributo,
a forma como esse atributo est sendo inicializado, etc.
O elemento comando de declarao de uma varivel (VariableDeclarationStatement), como o prprio nome sugere,
pertence ao agrupamento de Comando (Statement). A Listagem
35 exibe um trecho da transformao TT para Comandos responsvel por recuperar as informaes do modelo referentes
ao comando de declarao de uma varivel. J o cdigo da
Listagem 36 exibe o trecho transformao ST para Comandos
responsvel por formatar comando de declarao de uma
varivel de acordo com a sintaxe da gramtica de Java.
Para escrever a expresso referente declarao de varivel
em sintaxe concreta tem-se que recuperar essas informaes e
escrev-las de acordo com a gramtica da linguagem Java. Na
Listagem 35 podemos observar o cdigo que recupera essas
informaes do modelo.
Listagem 35. Transformao para recuperao das informaes sobre a

declarao de Varivel.
01 import ExpressionTT.m2t
02 import NameTT.m2t
03 import TypeTT.m2t
04 import ASTNodeTT.m2t
05 import VariableDeclarationTT.m2t
06 import StatementTemplates.m2t
07 texttransformation StatementTT (injas : JavaAbstractSyntax) {
08 jas.Statement :: getStatementCode() : String {
09 if(self.oclIsTypeOf(jast.VariableDeclarationStatement))
10 result = self.getVariableDeclarationStatementCode()
11 ...
12 }
13 ...
14 jas.VariableDeclarationStatement
15 :: getVariableDeclarationStatementCode() : String {
16 var modifiers : String= getModifiers(self.modifiers)
17 var type : String = self.type.getTypeCode()
18 var fragments : String =getVariableDeclaration
FragmentsCode(19self.fragments)
20 result = variableDeclarationStatementTemplate(21modifiers, type,
fragments)
22 }
23 }
24 ...
Listagem 36. Transformao para a formatao da declarao de Varivel.
01 texttransformation StatementST(inJAS : JavaAbstractSyntax) {

02 ...
03 module :: variableDeclarationStatementTemplate (
04 modifiers : String,
05 type : String,
06 fragments : String) {
07 result = modifiers + + type + + fragments + ;
08 }
09 ...
42
O cdigo da Listagem 35 est organizado da seguinte

forma:
Linhas 1-5. Importam a transformao para os elementos
dos outros agrupamentos os quais os elementos que realizam
a classe abstrata Statement esto relacionados;
Linha 6. Importa as transformaes que formatam os
comandos;
Linha 7. Especifica o nome da transformao para o agrupamento Statement, StatementTT. Essa linha ainda especifica com
qual meta-modelo essa transformao trabalha, no caso, o meta-modelo da sintaxe abstrata de Java, JavaAbstractSyntax;
Linhas 8-12. Especificam o mtodo getStatementCode que
realiza a gerao do cdigo para este elemento. Visto que na
linha 8 ele est declarado para o elemento Statement do metamodelo, ele ser executado para todo elemento que realize
Statement. Esse mtodo verifica qual o tipo do elemento que
est realizando o Statement e chama o mtodo apropriado. A
linha 9 verifica se o tipo do elemento um VariableDeclarationStatement, e se assim o for, o resultado da transformao
desse Statement ser o retorno do mtodo getVariableDeclarationStatementCode na linha 10;
Linhas 14 - 22. Especificam o mtodo getVariableDeclarationStatementCode e do elemento VariableDeclarationStatement. Esse mtodo responsvel por recuperar do modelo
do cdigo as informaes referentes ao comando de declarao de varivel. Essas informaes so modificador, tipo
e fragmentos, recuperadas nas linhas 16-19. E por fim, esse
mtodo chama a transformao ST que formatar o comando
adequadamente;
O cdigo da Listagem 36 trata da organizao e formatao
do comando de declarao de varivel. Este cdigo est organizado da seguinte forma:
Linha 1. Nomeia a transformao, StatementST. Alm disso,
essa linha ainda especifica com qual meta-modelo essa transformao trabalha, JAS;
Linhas 3 - 9. Especificam o mtodo, variableDeclarationStatementTemplate, que organiza e formata um comando de
declarao de uma varivel. Ele recebe como parmetros as
expresses resultantes dos outros elementos do meta-modelo,
modificadores (linha 5), tipo (linha 6) e a visibilidade (linha
7). E, por fim, na linha 8, esses resultados so organizados de
forma que formem uma expresso bem formada na linguagem
Java.
Foram definidas transformaes seguindo o esquema tratado
anteriormente para Comando de Declarao de Varivel.
Mdulo de Ps-Processamento
Nesse mdulo esto todas as aes necessrias para a finalizao correta da ferramenta. A ao default do sistema
excluir todos os artefatos intermedirios para a gerao do
teste de design final.
Outras aes podem ser incorporadas ao sistema. Para tanto, essas novas aes devem estender da interface java.lang.
Runnable da API de Java, e elas devem executar suas tarefas no

corpo do mtodo run. Alm disso, deve-se adicionar as novas
aes lista de aes a serem executadas (posActions) contida
na classe br.edu.gmf.udt.posProcess.Posprocessor. Definimos
que as aes deve estender a interface java.lang.Runnable para
uniformizar a execuo das aes.
A ferramenta foi projetada de forma que ela necessite o mnimo

de informao possvel para a gerao dos testes de design. Sendo assim, o modo de interao com a ferramenta se d por linha
de comando. O comando de gerao est descrito a seguir:
Concluso
Sendo: (1) arquivoXMI o caminho absoluto para o arquivo

XMI que descreve o diagrama de classes do design a ser testado; (2) diretorioDosTestes o caminho no sistema de arquivos
onde a ferramenta deve salvar os testes de design gerados; (3)
diretorioDoJarTestado o caminho absoluto para o JAR do
software que ser testado pelos testes de design gerado.
D
s

Feedback
eu
edio
ta
Referncias
1.The peer-review process. Learned Publishing, 15:247258, Outubro 2002.
19. Find Bugs. http://findbugs.sourceforge.net/.
2. Altova UModel. http://www.altova.com/products/umodel/.
20. Frdric Jouault e Jean Bzivin. KM3: a DSL for metamodel specification. Em IFIP Int. Conf. on Formal
Methods for Open Object-Based Distributed Systems, LNCS 4037, pginas 171185. Springer, 2006.
3. AMMA Project. Atlas Transformation Language, 2005. http://www.sciences.univnantes.fr/lina/atl/.

4.Anneke Kleppe, Jos Warmer e Wim Bast.MDA Explained:The Model Driven ArchitecturePractice and
Promise. Addison-Wesley, 2003.
5. Api java 2 platform se v1.4.2, interface runnable. http://java.sun.com/j2se/1.4.2/docs/api/java/lang/
Runnable.html.
6. ArgoUML. http://argouml.tigris.org/.
7. Asm bytecode manipulation. http://asm.objectweb.org/.
8. ATL-DT. http://www.eclipse.org/m2m/atl/.
9. B. Hailpern and P. Tarr. Model-driven development: The good, the bad, and the ugly. IBM Systems
Journal, 45(3):451461, 2006.
21. Gail C. Murphy, David Notkin e Kevin Sullivan. Software re exion models: Bridging the gap between
source and high-level models. Em G. Kaiser, editor, Proc. 3rd ACM SIGSOFT Symp. on the Foundations
of Software Engineering, volume 20:4 of ACM SIGSOFT Software Engineering Notes, pginas 1828,
Washington, DC, Outubro 1995.
22. Object Management Group. Meta object facility (MOF) specification. Technical Report ad/97-08-14,
Object Management Group, 1997.
23. Object Management Group. Mof model to text transformation language. Technical Report ad/200404-07, Object Management Group, 2004.
24. JAS-metamodel. http://www.eclipse.org/gmt/am3/zoos/atlanticZoo.
25. Jesse E.Tilly e Eric M. Burke. Ant:The Definitive Guide. OReilly & Associates, Inc., pub-ORA:adr, 2002.
10. Borland Together. http://www.borland.com/br/products/together/.
26. Java Emitter Templates. http://www.eclipse.org/articles/Article-JET/.
11. Clint Morgan, Kris De Volder e Eric Wohlstadter. A static aspect language for checking design rules. Em
Brian M. Barry e Oege de Moor, editors, AOSD, volume 208 of ACM International Conference Proceeding
Series, pginas 6372. ACM, 2007.
27.Jilles van Gurp e Jan Bosch.Design erosion:problems and causes.The Journal of Systems and Software,
61(2):105119, Maro 2002.
12. James J. Horning e Yang Meng Tan David Evans, John V. Guttag. LCLint: A tool for using specifications to
check code. Em Symposium on the Foundations of Software Engineering, Dezembro 1994.
28.Dalton Guerrero e Jorge Figueiredo Joo Brunet.Design tests: An approach to programmatically check
your code against design rules. Em Proc. 31th International Conference on Software Engineering (ICSE
2009), New Ideas and Emerging Results, Maio 2009.
13. David H. Akehurst, Gareth Howells e Klaus D. McDonald-Maier. Implementing associations: UML 2.0 to
java 5. Software and System Modeling, 6(1):335, 2007.
29. John Robert Taylor. An introduction to error analysis: The study of uncertainties in physical
measurements. pginas 128129. University Science Books, 199.
14. David Lorge Parnas. Software aging. Em Bruno Fadini, editor, Proceedings of the 16th International
Conference on Software Engineering, pginas 279290, Sorrento, Italy, Maio 1994.IEEE Computer Society
Press.
30. JUnit. http://www.junit.org.
15. Design Wizard. http://www.designwizard.org.
31. Len Bass, Paul Clements e Rick Kazman. Software Architecture in Practice. Addison Wesley, 1998.
32. MagicDraw UML. http://www.magicdraw.com/.
16. Ecore. http://www.eclipse.org/modeling/emf/?project=emf.
33. Mark Utting e Bruno Legeard. Practical Model-Based Testing: A Tools Approach. Morgan-Kaufmann,
2006.
17. Erich Gamma, Richard Helm, Ralph Johnson e John M.Vlissides. Design Patterns Elements of Reusable
Object-Oriented Software. Addison-Wesley, Massachusetts, 2000.
34. MDT OCL. http://www.eclipse.org/modeling/mdt/?project=ocl.
18. Len Erlikh. Leveraging legacy system dollars for E-business. IT Professional, 2(3):1723, 2000.
35. MOFScript. http://www.eclipse.org/gmt/mofscript/.

36. MySQL. http://www.mysql.com/.
43
sobre e
s
Neste artigo, conhecemos uma abordagem para verificao

de diagramas de classes da UML e mostramos a forma como
implementamos a ferramenta UDT de apoio automatizao
da gerao dos testes de design. A ferramenta foi estruturada
em quatro mdulos: Mdulo de Pr-processamento, responsvel por executar todas as aes necessrias para a configurao do ambiente de gerao dos testes de design; Mdulo
de Gerao de Modelos, responsvel por gerar os modelos
dos testes de design para o diagrama de classe a ser testado;
Mdulo de Gerao da Sintaxe Concreta, responsvel por gerar o arquivo com a classe Java final, compilvel e executvel;
Mdulo de Ps-processamento responsvel por finalizar a
ferramenta UDT.
UDTarquivoXMI diretorioDosTestes diretorioDoJarTestado
Referncias
37. Yann-Gael Gueheneuc e Pierre Leduc Naouel Moha. Automatic generation of detection
algorithms for design defects. Em ASE 06: Proceedings of the 21st IEEE International Conference
on Automated Software Engineering (ASE06), pginas 297300, Washington, DC, USA, 2006. IEEE
Computer Society.
38. Nathaniel Ayewah, William Pugh, J. David Morgenthaler, John Penix e YuQian Zhou. Using
findbugs on production software. Em Richard P. Gabriel, David F. Bacon, Cristina Videira Lopes, e
Guy L. Steele Jr, editors, OOPSLA Companion, pginas 805806. ACM, 2007.
39. Object Management Group. http://www.omg.org/.
48.Stephen Eick, Todd Graves, Alan Karr, J. Marron e Audris Mockus. Does code decay? assessing the
evidence from change management data. IEEE Transactions on Software Engineering, 27(1):112,
2001.
49.Trung T. Dinh-Trong, Nilesh Kawane, Sudipto Ghosh, Robert B. France e Anneliese Amschler
Andrews. A tool-supported approach to testing UML design models. Em ICECCS, pginas 519528.
IEEE Computer Society, 2005.
50.UDT - UML Design Tester. http://www.designwizard.org/index.php/UDT/.
40. Object Management Group, Framingham, Massachusetts. UML 2.0 Superstructure Specification,
Outubro 2004.
51.Victor R. Basili, Gianluigi Caldiera e H. Dieter Rombach. Goal Question Metric Paradigm. Em John
J. Marciniak, editor, Encyclopedia of Software Engineering, volume 1, pginas 528532. John Wiley
& Sons, 1994.
41. Object Management Group. MOF, 2006. http://www.omg.org/cgi-bin/doc?ptc/2005-11-01.
52.Visual Paradigm for UML. http://www.visual-paradigm.com/product/vpuml/.
42. Object Management Group.The OCL 2.0 Specification, 2006. http://www.omg.org/technology/

documents/formal/ocl.htm.
53.Franklin Ramalho e Dalton Serey Waldemar Pires, Jo/ ao Brunet. Uml-based design test
generation. Em SAC 08: Proceedings of the 2008 ACM symposium on Applied computing, pginas
735740, New York, NY, USA, 2008. ACM.
54.William Wesley Peterson. Introduction to Programming Languages. Prentice Hall, Englewood
Cliffs, 1974.
43. OMondo - Eclipse UML. http://www.eclipsedownload.com/.

44. P. A. Stocks e D. A. Carrington. Test templates: a specification-based testing framework. Em
Proceedings of the 15th International Conference on Software Engineering, pginas 405414.
IEEE Computer Society Press, April 1993.
45. Philippe Kruchten, Patricia Lago e Hans van Vliet. Building up and reasoning about architectural
knowledge. Em Christine Hofmeister, Ivica Crnkovic, e Ralf Reussner, editors, QoSA, volume 4214 of
Lecture Notes in Computer Science, pginas 4358. Springer, 2006.
46. Poseidon for UML. http://www.gentleware.com/.
47. Ian Sommerville. Software Engineering. Addison-Wesley, 7th edition, 2004.
44
55.Wolfgang Hesse. RUP - A process model for working with UML. Em Unified Modeling Language:
Systems Analysis, Design and Development Issues, pginas 6174. 2001.
56.Xalan-Java Version 2.7.1. http://xml.apache.org/xalan-j/.
57.XSL Transformations. http://www.w3.org/TR/xslt/.
58.Rmi Douence e Pierre Cointe Yann-Gael Guhneuc, Herv Albin-Amiot. Bridging the gap
between modeling and programming languages.Technical report, Computer Science Department,
cole des Mines de Nantes, 2002.
Engenharia
Otimizao de Processos de Negcio usando

BPM Parte 2
Transformando organizaes Boas em organizaes timas
Ricardo S. Ferreira
rferreira@progress.com
Ricardo Ferreira (@jricardoferreir) trabalha com

TI e na industria de software para computadores
desde 1998, e j construiu e implantou dzias de
projetos e solues para diversas organizaes
do Brasil, em especial para organizaes da indstria das telecomunicaes como operadoras
de telefonia celular e empresas de contedo
digital. Se tornou um especialista em objetos
distribudos, EAI, SOA, EDA, CEP e BPM, com mais
de 7 anos de experincia nestes assuntos. Trabalha com a plataforma Java a mais de 10 anos, e
j implementou e implantou diversos projetos
crticos em servidores de aplicao como JBoss,
WebLogic e Websphere. Trabalha atualmente na
rea de solues e pr-vendas da Progress Software Corporation, ajudando clientes e parceiros
da amrica latina a ganharem maior eficncia
e inteligncia operacional. Antes de atuar na
Progress, foi arquiteto de solues na JBoss, a
diviso de middleware da Red Hat. Possui diversas certificaes de grandes players da indstria
como Sun Microsystems, BEA, IBM e Borland, a
saber: SCEA, SCBCD, SCWCD, SCJP, BEA Certified
SOA Enterprise Architect, IBM Certified SOA
Solution Designer, IBM Certified RUP Solution
Designer e Borland JBuilder Product Certified
Developer. palestrante frequente em diversos
eventos de tecnologia do Brasil e autor de mais
de 180 artigos em seu blog pessoal (http://
architecture-journal.blogspot.com) e revistas
especializadas.
Este artigo dar continuidade srie sobre otimizao de processos de negcio usando BPM, que iniciou
na edio anterior o estudo de uma metodologia para
projetos de BPI (Business Process Improvement). Nesta edio, ser visto quais so as tcnicas e prticas da
fase de anlise, que visa criar o modelo e documentao formal do processo que ser melhorado.
Para que serve?

Como subsdio de qualquer iniciativa de melhoria de
processos de negcio, importante criar um conjunto
adequado de modelos visuais e uma documentao
apropriada para que equipes ou empresas especializadas em projetos de BPI possam conduzir e propor
odos ns sabemos que cinema

acima de tudo arte, e sem sombra
de dvidas, a stima forma de
arte. Mas o que poucos sabem que
cinema tambm uma indstria. considerada uma indstria porque ela precisa de meios de produo, acumulao
de capital e a diviso especializada do
trabalho entre diversos interessados. E
otimizaes e melhorias. Para fazer isso, necessrio

conhecer as tcnicas e prticas necessrias para criar
os insumos que sero o material de trabalho da fase
de redesenho de um processo de negcio.

Este artigo pode ser uma ferramenta muito valiosa para gerentes ou lderes de rea de organizaes que estejam engajadas em otimizar seus
processos de negcio objetivando obter maior
diferencial perante seus clientes, fornecedores e
funcionrios. Ao final da leitura desta srie de artigos, ser possvel que o caro leitor possa conduzir
uma iniciativa de otimizao de processos dentro
de qualquer organizao.
a servio desta indstria que existem os

roteiros, uma das principais atividades
do mundo magnfico do cinema.
Um roteiro nada mais do que um documento chave onde todos os outros profissionais envolvidos com a realizao de
um produto audiovisual (por exemplo,
um filme) basearo o seu trabalho. Ele
determina a histria a ser contada sob
45
algum meio, ele define as mensagens que sero apresentadas

ao pblico, a caracterizao dos personagens na trama e o envolvimento entre eles no decorrer da histria. Tambm define
a sequncia dos acontecimentos da histria, estruturados na
forma de um conjunto de captulos e um eplogo.
Como produes de cinema so produtos audiovisuais caros e
requer um investimento de capital inicial alto, o roteiro torna-se
extremamente importante no projeto inicial de uma produo,
pois atravs dele, possvel ver como diferentes pblicos reagem ideia definida no roteiro, identificar pontos da histria
onde o pblico apresenta maior afinidade ou indignao e se,
por exemplo, ele cumpre a premissa de prender a ateno do
pblico e de se tornar um potencial filme de sucesso. Em suma,
os roteiros ajudam a minimizar o risco de investir capital em
uma produo que pode gerar um grande prejuzo.
Uma organizao possui diversos processos em seu negcio,
e cada um desses processos precisa de um roteiro. Tal roteiro
ou mapeamento deve descrever para cada um dos processos
do negcio, todas as suas etapas, fases, participantes e naturezas de interao. Deve definir claramente qual o objetivo do
processo, quais so as pr-condies para sua realizao, quais
produtos, resultados e indicadores sero gerados e quais mtricas sero usadas em sua medio. Mesmo que um processo
de negcio j tenha um mapeamento, interessante tambm
que este mapeamento seja revisitado e redocumentado para
garantir que todos os detalhes do processo foram expressos
e formalmente capturados. Em especial, importante revisar
os processos de negcio que foram candidatos otimizao, aqueles processos que em algum momento ou situao
apresentaram anomalias como insatisfao dos funcionrios
e clientes, baixa produtividade, dificuldade de reteno de
clientes, alto custo ou mesmo baixa rentabilidade.
Na parte 1 desta srie de artigos, voc aprendeu um pouco
mais sobre o que so processos de negcio, sua importncia
para as organizaes e porque eles precisam ser melhorados.
Aprendeu tambm que projetos de otimizao de processos
(BPI, do ingls Business Process Improvement) so estruturados
em fases e marcos, e aprendeu tambm sobre quais so essas
fases e marcos. Voc aprendeu sobre a fase de planejamento
de um projeto de BPI, onde definido o escopo do projeto,
o time que ir participar e quais sero os processos a serem
otimizados. hora de dedicarmos ateno segunda fase de
um projeto de BPI: a fase de anlise do processo de negcio.
Neste artigo, veremos os detalhes e prticas relacionadas
anlise, mapeamento e documentao de um processo de
negcio que foi elencado como candidato a otimizao na fase
de planejamento de um projeto de BPI.
Documentao e Mapeamento de Processos

A primeira e mais importante atividade da fase de anlise
a documentao e mapeamento do processo que foi elencado para otimizao. Isso significa que voc deve capturar
num nvel bem alto de detalhes, todos os aspectos e nuances
que giram em torno do processo, e documenta-los em um
artefato que seja de fcil entendimento e visualizao, e que
46
possa ser mantido em repositrios da organizao na forma

de ativos.
Voc pode usar diversos tipos de formatos e tecnologias
para capturar o detalhamento mais amplo do processo de
negcio, mas no que tange ao seu fluxo, lgica e padres de
interao, de suma importncia que voc d preferncia
para documentao baseada em diagramas e modelos visuais. Existem diversas vantagens nesta escolha. Primeiro,
modelos visuais so naturalmente mais simples de se entender. O entendimento de coisas complexas se torna muito
mais simples quando aprendido atravs de modelos visuais.
Segundo, modelos visuais so sustentados hoje em dia por
diversos padres da indstria, e no que tange a processos de
negcio, existe hoje uma poderosa notao de modelagem
conhecida como BPMN, sigla de Business Process Modeling
Notation. Usar uma notao padro pode ajud-lo a fazer com
que todos tenham o mesmo entendimento e percepo do
seu processo, pois todos sabero a lngua franca utilizada
para explicao. Alm disso, padres como o BPMN ajudam
que seus processos possam ser documentados e implementados numa ferramenta qualquer como o ARIS Business
Architect da Software AG e possa ser interpretado e aberto
por outra ferramenta, como o Savvion Process Modeler da
Progress Software.
Para entendermos melhor como deve ser feito a documentao e mapeamento de um processo de negcio, temos que
saber exatamente que tipos de perguntas devem ser feitas e
quais respostas devem ser documentadas. So elas:
Quais so as transaes que so envolvidas (demandadas ou
iniciadas) no ciclo de execuo de uma instncia do processo
de negcio? Estas transaes so formadas por pessoas ou
por sistemas?
Qual a durao de cada transao que envolvida no ciclo de
execuo de uma instncia do processo de negcio? As transaes podem ser razo de contenes e gargalos no processo?
Se sim, qual o percentual disso?
Qual a situao em que o processo de negcio solicitado?
Essa situao pode ser monitorada e realizada por um sistema de computador? Quais outros gatilhos podem disparar o
processo de negcio?
Quantas instncias do processo de negcio so esperadas
numa dada hora? E num dado dia? Num dado ms? Saber a
quantidade de instncias em andamento ou j executadas do
processo de negcio ajuda a organizao a obter algum insight
sobre o desempenho do seu negcio?
Este processo de negcio pode estar acontecendo quando
outra instncia do mesmo processo j estiver ocorrendo? Pode
haver paralelismo?
Quem so as pessoas que so envolvidas na execuo de
uma nica instncia do processo de negcio? So pessoas somente de dentro da organizao ou existem pessoas tambm
de fora?
Que espcie de resultados se espera depois da perfeita execuo de uma nica instncia do processo de negcio? Se for
ganho de rendimento, para onde vai esse valor?
Engenharia de Software Magazine - Otimizao de Processos de Negcio usando BPM Parte 2
Melhoria de Processo
Qual a repercusso que gera a falha na execuo de uma

nica instncia do processo de negcio? Impacta diretamente
no negcio da organizao? Pode ferir os objetivos estratgicos
da organizao como maior reteno de clientes, maior rentabilidade ou aumento da satisfao e qualidade?
Cada participante ou etapa do processo de negcio possui
um custo envolvido? Se sim, qual o custo de cada participante e
etapa do processo? possvel calcular o custo total da execuo
de uma nica instncia do processo de negcio?
Quais so os indicadores e mtricas que esto relacionados ao
processo de negcio? As informaes para computao destes
indicadores j existem atualmente no processo ou devero ser
acrescentados?
Todas estas perguntas devem ser respondidas e documentadas apropriadamente na fase de anlise do processo de
negcio. Algumas das respostas sero usadas ainda nesta fase,
outras, iro ser usadas nas fases posteriores, em especial, nas
fases de redesenho, aquisio de recursos e implementao.
Normalmente, estas perguntas devero ser facilmente respondidas se na fase de planejamento do projeto de BPI voc trouxe
para a equipe as pessoas certas. Quando as pessoas certas ou
chaves no fazem parte do time envolvido na iniciativa de BPI,
existe dificuldade em capturar algumas das respostas. Existe
dificuldade principalmente em obter maiores detalhes sobre
algumas das respostas, pois quem est de fora da iniciativa
pode se sentir ameaado ou desconfortvel por voc ou sua
equipe estar mexendo no territrio deles.
No novidade nem mesmo uma vergonha, revisitar a montagem do time do projeto durante a fase de anlise. Gerentes
menos experimentados em projetos de BPI podem ter que fazer
isso nos seus primeiros ou terceiros projetos. Depois de um
tempo, voc comea a ficar mais malicioso sobre quem envolver
num projeto de BPI e passa a acertar em cheio na escolha das
pessoas. Vai comear inclusive, a recomendar capacitaes
e treinamentos para aqueles escolhidos do time que so as
pessoas certas, mas ainda no possuem o conhecimento que
ser necessrio para obter tais respostas.
Depois de documentar as informaes gerais do processo,
hora de comear a documentar o fluxo do processo de negcio.
Esta a hora de criar um ou mais modelos visuais que capturem a essncia do processo, a interao dos participantes e
os resultados que devem ser gerados. Para isso, voc deve se
familiarizar com alguns elementos da notao de modelagem,
em especial da notao BPMN. A Figura 1 sintetiza os principais elementos da notao BPMN que so usados na maioria
dos processos de negcio, at mesmo aqueles mais complexos.
Na notao BPMN, existem claro outros elementos que podem
ser utilizados, mas iremos dedicar o artigo a compreenso
das tcnicas de otimizao de processos e ao mtodo e fases
que foram apresentados no primeiro artigo. Na internet bem
como em livros, voc encontra uma grande quantidade de
informaes que voc pode utilizar para estudar e entender a
notao em maior amplitude. Ela bem simples e no dever
ser difcil de entender.
Figura 1. Lista dos principais elementos da notao BPMN usados em

modelos visuais
Uma boa prtica criar pelo menos duas verses do processo

de negcio. Uma verso dever ser mais simples, e servir
apenas para fornecer uma viso mais macro do processo e de
seu fluxo, ideal para a venda interna da ideia e para visualizao rpida de seus objetivos. A outra verso dever ser mais
elaborada, contendo todos os detalhes relacionados ao fluxo e
lgica do processo, assim como a meno de todas as pessoas
que estaro envolvidas. A verso mais elaborada dever contemplar porventura, a quebra do processo de negcio em outros
processos de negcio menores, na forma de sub-processos.
A utilizao de sub-processos apresenta diversas vantagens,
entre elas, a minimizao da complexidade do modelo. A experincia e a prtica dizem que modelos visuais devem ter entre
sete a dez atividades, mais do que isso torna o modelo menos
expressivo e mais complexo de entender. Para evitar isso,
importante selecionar um conjunto de atividades que juntas
formam a ideia de uma transao e tratar isso como um subprocesso. Neste caso, no lugar do conjunto de atividades ser
criado apenas uma atividade, e esta atividade ir referenciar
um sub-processo. Este sub-processo ir mapear toda a lgica e
fluxo que voc poria dentro do processo principal, e a relao
entre eles ser de composio, ou seja, o processo principal
composto pelo sub-processo, sendo que este sub-processo
ter seu ciclo de vida controlado pelo processo principal. Se
o processo principal deixa de existir ou cancelado por alguma razo, o sub-processo tambm cancelado para manter a
consistncia transacional.
Uma prtica importante durante as sesses de mapeamento
e criao dos modelos visuais tentar no cair na tentao de
j criar o modelo otimizado do processo de negcio. Durante
esta fase de anlise, importante capturar o processo como ele
(tambm conhecido como verso AS-IS), para que sejam feitas
47
as investigaes adequadas na fase de redesenho sobre como

efetivamente melhor-lo. Isso importante por dois motivos.
Primeiro, dependendo da logstica da organizao, pode ser
que este trabalho de anlise seja iniciado por uma pessoa ou
departamento, mas a melhoria em si deva ser feita por outra
pessoa, departamento ou mesmo outra empresa, porventura,
uma empresa especializada em melhoria de processos do tipo
de negcio da organizao. Seja l quem for ter que realizar a
fase de redesenho do processo, vai focar em como melhorar o
processo dado como entrada. Se voc alterou a percepo do
processo atual pondo algumas melhorias que voc acha que
so relevantes, o responsvel pela fase de redesenho no vai
conseguir capturar o real problema que motivou a melhoria
do processo. Caso seja voc e sua equipe os responsveis pelas
duas fases (a saber, a fase de anlise e redesenho) ento essa
observao pode ser ignorada.
Segundo, a fase de redesenho apresenta tcnicas especializadas sobre como identificar os reais problemas de um
processo de negcio dito como problemtico. A captura
de problemas essenciais como baixas rentabilidades, insatisfao de clientes e funcionrios, custos muitos altos ou
lentido, remete o processo de negcio a uma sria estruturada de perguntas e prticas que s surtiro efeito caso o
processo tenha sido mapeado e documentado do jeito que
ele realmente atualmente. As proposies de mudana
e de melhoria tambm levam em considerao a logstica
atual do processo de negcio e isso pode ser comprometido caso voc tome a iniciativa da melhoria na hora errada.
Questes como clculo do custo total do processo, clculo do
seu tempo de durao, captura da real satisfao dos atores
envolvidos nas atividades giram em torno exclusivamente
dos detalhes do processo atual.
Vamos agora exercitar as tcnicas apresentadas num

cenrio fictcio. Suponha que uma empresa do ramo de
telecomunicaes deseja melhorar a experincia que os
seus clientes tm quando solicitam a ativao de uma nova
linha telefnica. Assuma que a razo para a escolha deste
processo de negcio em particular foi a baixa satisfao dos
clientes com este processo, acarretando na abertura de uma
quantidade grande de reclamaes na ouvidoria da empresa
sobre o mau atendimento e demora durante a ativao de
uma nova linha telefnica. Numa viso mais geral deste
processo de negcio, o modelo gerado teria trs grandes
atividades: a solicitao da linha telefnica, a verificao
dos dados do cliente e a ativao da linha telefnica em si. A
Figura 2 mostra uma verso mais simples deste processo de
negcio usando a notao BPMN. Reparem que nesta verso
mais simples, os detalhes relacionados aos atores que participam do processo de negcio so ocultados, assim como
as atividades de realizao, ou seja, as atividades responsveis pela execuo de alguma tarefa ou funcionalidade.
No seu lugar, ficam apenas as atividades que representam
os grandes marcos do processo.
A segunda verso deste processo de negcio dever explorar todos os possveis detalhes, ressaltando principalmente
o fluxo e sequncia das atividades, a natureza das interaes
entre o processo e os atores bem como as condies de entrada e sada das decises e fluxos paralelos. A Figura 3 mostra
um exemplo de como deveria ser a verso mais elaborada
do processo de ativao de linhas telefnicas.
A utilizao do poder da notao BPMN importante nesta
hora porque atravs dos elementos da notao voc pode
expressar mais adequadamente no s a ideia do fluxo, mas
um pouco do sentimento e percepo sobre como o processo
se desenrola. Na Figura 3, por exemplo, voc percebe que cada grupo de atividades est dividido por
cores especiais. Amarelo indica o grupo de atividades desempenhadas pelos clientes. O azul indica
as atividades desempenhadas pelos funcionrios
da rea de vendas e vermelho indica as atividades
Figura 2. Verso mais simples do processo de ativao de linhas telefnicas usando
desempenhadas pela rea de infraestrutura e redes,
BPMN
atividades estas realizadas principalmente pelos
sistemas da engenharia e da TI. Essas cores e raias
representam os swinlanes, elementos da notao
que definem os atores de um processo de negcio.
Sua utilizao pode parecer simples no primeiro momento, mas a utilizao destes recursos pode revelar
uma srie de informaes. Por exemplo, atravs dos
swinlanes, pode-se capturar mais adequadamente
quando um grupo de atores fica em estado de espera,
aguardando que outro grupo de atores finalize suas
atividades. possvel perceber neste caso, quando
um dado grupo de atores experimenta insatisfao,
dado o tempo inadequado que outros atores desempenham as suas tarefas.
Noes de paralelismo tambm revelam informaes
importantes. Ter atividades em paralelo pode
Figura 3. Verso mais detalhada do processo de ativao de linhas telefnicas
48
Melhoria de Processo
parecer uma tcnica para ganhar agilidade, mas tambm

pode ser uma fonte grande de conteno de recursos. Quando falamos recursos, estamos nos referindo a todos os atores
que desempenham tarefas. Um funcionrio de um departamento de anlise de crdito avaliando uma proposta de
ativao de linha telefnica considerado um recurso, assim
como um componente de software responsvel pela insero
dos dados cadastrais de um cliente em um banco de dados.
Colocar atividades como estas em paralelo significa manter
os recursos (pessoas ou sistemas) em conteno, ou seja, eles
no podero participar de outras atividades ou processos
no momento em que estiverem em uso. Paralelismo de atividades tambm pode ser uma boa fonte de insatisfao de
pessoas, em especial de funcionrios. A busca intensa pela
reduo do tempo das atividades pode gerar insatisfao
das pessoas por terem que desempenhar suas tarefas da
forma mais rpida e sinttica possvel, gerando constante
retrabalho e muitas das vezes a exausto do recurso pela
sua intensa utilizao.
Tente, atravs do uso dos elementos da notao, capturar
o maior nmero possvel de detalhes do processo durante
a fase de anlise. Esses detalhes sero utilizados na fase de
redesenho para a proposio de mudanas e melhorias. Lembre-se que, o modelo deve expressar a realidade do processo,
e isso s ser possvel se voc inserir essa realidade dentro
dos modelos. Gosto de pensar nos modelos como mensagens enviadas via uma forma de correspondncia como
cartas ou e-mails. Imagine que voc necessita enviar uma
mensagem a um ente querido que esteja distante. Voc ao
escrever, ir naturalmente expressar na sua escrita, detalhes,
sentimentos, experincias e acontecimentos da forma mais
detalhada possvel, para garantir que a pessoa que ir ler,
ir entender e possivelmente sentir o que voc escreveu.
Modelos funcionam da mesma forma. Voc precisa inserir
no modelo no s detalhes tcnicos como fluxos, decises
e naturezas de interao, mas, assim como em cartas ou
e-mails, sentimentos, experincias e acontecimentos. Estes
sero os insumos mais valiosos usados na fase de redesenho
para proposio da melhoria do processo de negcio.
Captura dos Problemas e Histrico dos Processos

A prtica de melhorar processos de negcio essencialmente
muito simples, mas muitos gerentes experimentam frequentemente dificuldades e frustraes ao conduzirem este tipo
de projeto. Isso acontece porque a prtica popular diz que
depois que voc modela seus processos de negcio, os modelos
sero seus condutores para proposio das melhorias. Neste
caso, desprendem-se horas, dias e meses a fio olhando para
estes modelos e imaginando como seria um fluxo, conjunto
de decises ou naturezas de interao ideal e mais eficiente.
Muitas das vezes, sugerem-se melhorias que na prtica no
surtiro efeito positivo algum no processo, e porventura ir
torn-lo menos eficiente e mais frustrante. Isso acontece porque
a pessoa que fica sendo responsvel por melhorar o processo
de negcio descrito no modelo e em documentos se sente
obrigado a propor uma soluo a ele, mesmo que esta pessoa

tenha que inventar uma.
Os modelos no devem ser usados como condutores para
melhoria dos processos, e sim, as opinies dos stakeholders.
Assim como na Engenharia de Software, os requisitos devem
ser os reais condutores para criao de uma arquitetura de
software adequada. O fio condutor de um projeto de BPI
deve ser o resultado de uma srie de entrevistas com os
stakeholders envolvidos direta ou indiretamente no processo de negcio. A boa prtica diz que voc deve realizar
minuciosas e detalhadas entrevistas com os stakeholders do
processo e capturar deles as suas insatisfaes, experincias
e argumentaes. Na maioria das vezes, o resultado destas
entrevistas ser uma lista de argumentaes e exigncias
sobre o que se espera do processo e o que, da lista do que
se espera, o processo faz e o que ele no faz. Esse deve ser
o real condutor de um projeto de BPI, pois ir garantir que
o grupo de melhorias proposto ir atender de fato quem
experimenta o processo, e, portanto, garantir o sucesso do
projeto.
Capture cada argumentao dos stakeholders, anote-a,
compartilhe-a com o seu time e, se possvel, negocie com
o stakeholder um peso para a sua argumentao. Colocar
pesos em cada argumentao importante por duas razes.
Primeiro, pode ser que a argumentao negativa (reclamao) de um dos stakeholders seja visto por outro stakeholder
como algo positivo. Neste empasse, o grupo dever entrar
num consenso sobre se aquilo uma falha ou virtude do
processo de negcio. Isso no dever ser uma tarefa simples,
e voc precisar conduzir adequadamente estas entrevistas
para que voc oferea a todos um nvel de envolvimento e
satisfao adequado. Segundo, pode ser que estas entrevistas com os stakeholders gerem uma lista muito grande
de melhorias a serem implementadas, principalmente se o
processo em questo for muito problemtico. Neste caso,
ser necessrio na fase de redesenho priorizar e elencar
quais proposies de melhoria sero implementadas, pois
o projeto de BPI poder ter um investimento ou tempo de
concluso muito baixo, e, portanto, o time no poder contemplar todas as proposies de melhoria dentro daquele
projeto. Os pesos ajudaro na escolha de quais melhorias
implementar, e justamente por isso que voc deve negociar
adequadamente estes pesos com os stakeholders, pois eles
devero ter cincia de que nem todas as suas proposies
sero implementadas. Isso ajudar a mant-los dedicados
e motivados durante todo o projeto de BPI, incluindo os
futuros projetos de BPI que porventura participaro.
Concluses
Nesta segunda parte da srie de artigos sobre otimizao de
processos de negcio, vimos quais so as prticas e atividades
para a conduo da fase de anlise de um processo de negcio
elencado na fase de planejamento. Vimos que tipos de detalhes
dos processos devem ser documentados assim como qual a
forma adequada para capturar o fluxo e lgica dos processos
49
Livro Business Process Management: Practical guidelines to successful

implementations ISSBN 9780750686563
50
Blog O BPM que fao hoje... realmente BPM?

http://bit.ly/hwUCXo
Blog Introduo ao Progress Savvion BPM
http://bit.ly/h1qGN7
Progress Savvion BPM
http://web.progress.com/en/savvion/savvion-businessmanager.html
Link para Download do Progress Savvion Modeler
http://bit.ly/fNMsdc

Feedback
eu
sobre e
s
Livro Good to Great: Why some companies make the leap... and others dont ISSBN 9780066620992
Link para o site oficial da notao BPMN

http://www.bpmn.org/
D
s
Referncias
Links
edio
ta
usando modelos visuais. Vimos tambm um pouco da notao

BPMN e como ela ajuda a capturar todos os detalhes de um
processo de negcio.
A partir da documentao e mapeamento feito na fase de
anlise, possvel passar para a fase de redesenho do processo, onde ser feito um trabalho de otimizao de todos os
problemas e deficincias do processo.
O prximo artigo desta srie focar nesta fase de redesenho,
e dar incio jornada de concepo da nova verso do processo de negcio, verso que ir transformar positivamente a
organizao dando-lhe maior eficincia e melhores resultados.
At a prxima!
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 9

Implementao dos padres Observer e Composite atravs de refatoraes
para padres
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode uslo para melhorar o cdigo-fonte de suas aplicaes.
Para que serve?
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Bacharel em Cincia da Computao pela

FAGOC - Faculdade Governador Ozanam
Coelho, Microsoft Student Partners.

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.
o desenvolvimento de uma
aplicao, o desenvolvedor fica
cercado por diversas informaes provenientes do negcio do cliente
e tem a misso de implement-las em
uma soluo que possibilite o cliente
gerir seu negcio. Alm de fornecer uma
soluo que corresponda s expectativas
do cliente, muitas vezes o desenvolvedor
deve faz-las com base em uma srie de
regras que a empresa onde ele trabalha
prope, entre elas, criar estruturas de
cdigo que possam ser reutilizadas,
codificar de forma clara para que outro
desenvolvedor possa entender o negcio
em uma anlise futura, escrever classes
que, caso sofram manuteno posteriormente, no gerem grandes impactos em
outras classes do sistema, entre outras.
Esta ltima, por sua vez, pode levar o
Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs
de exemplos prticos a aplicao das tcnicas de
refatorao para padres Substituir Distino Um/
Muitos por Composite e Substituir Notificaes
Hard-coded por Observer.

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.
desenvolvedor a uma pergunta: como

fazer com que um objeto seja informado
de mudanas ocorridas em outro objeto,
sem criar um grande acoplamento entre
as classes?
Neste sentido existe um padro de
projeto chamado Observer que permite
51
ao desenvolvedor criar uma hierarquia de classes de observadores capazes de avisarem quando mudanas em um
objeto ocorrer, sem que para isso tenham que ser escritas
grandes estruturas de cdigo acopladas ao objeto que se
deseja observar.
Quando j existe grande quantidade de cdigo escrita para
notificar mudanas ocorridas em um objeto, a soluo refatorar para o padro Observer. Neste artigo, uma das refatoraes
para padres apresentadas Substituir Notificaes Hard-coded
por Observer, que fornece uma soluo para refatorar para o
padro de projeto Observer.
A segunda refatorao para padres que este artigo aborda, Substituir Distino Um/Muitos por Composite, mais
uma forma de implementar o padro Composite (ver Nota
do DevMan 1), como as demais formas j apresentadas em
outros artigos desta srie sobre refatorao para padres. Sua
diferena, no entanto, consiste no problema de cdigo que ela
atua. O cenrio a ser estudado consiste em um pilar bsico:
cdigo duplicado.
comum o desenvolvedor em determinados momentos
precisar manipular um nico objeto ou manipular diversos
objetos desta mesma classe. Com isso ele implementa trechos
de cdigo semelhantes para manipular um objeto e outro
para manipular vrios objetos. Esta prtica faz com que muito
cdigo duplicado seja escrito na mesma classe, com intuito de
resolver os dois problemas citados.
Com o padro de projeto Composite, atravs de Substituir Distino Um/Muitos por Composite, o desenvolvedor consegue
criar estruturas capazes de manipular um ou vrios objetos em
um mesmo Composite, eliminando o cdigo duplicado.
As refatoraes para padres descritas neste artigo tm
como pr-requisito um conjunto de tcnicas de refatorao
que incluem Extrair Mtodo, Mover Mtodo, Extrair Interface,
Internalizar Mtodo, Encapsular Coleo e Subir Mtodo na
Hierarquia (ver Nota do DevMan 2).
Nota do DevMan 1
Relembrando conceitos
Uma breve descrio do padro de projeto Composite foi apresentada em artigo
da edio 30 da Engenharia de Software Magazine, e relembrada na edio de
nmero 34.
Nota do DevMan 2
Refatoraes apresentadas em outros artigos
As tcnicas de refatorao Extrair Mtodo, Mover Mtodo, Extrair Interface e Subir Mtodo na Hierarquia j foram apresentadas em outras edies da Engenharia
de Software Magazine, mais precisamente nas edies de nmero 29, 30, 33 e 34.
52
O padro de projeto Observer

Nome do padro de projeto: Observer, pertencente ao conjunto dos padres de projeto classificados como Padres
Comportamentais.
O problema: Em alguns momentos, o desenvolvedor implementa classes cujas instncias assumem determinado
comportamento mediante alguma alterao ou ao em instncias de outras classes. Para que esse recurso funcione, o
desenvolvedor deve implementar um mecanismo que permita
que um objeto seja avisado quando o outro objeto em questo
sofrer tais mudanas. A implementao de um mecanismo
desta natureza pode ser feita com o apoio do padro de projeto
Observer, que permite ao desenvolvedor criar uma estrutura
onde um observador ser responsvel por avisar a um objeto
quando um outro relacionado a ele sofrer alguma mudana
na qual ele deva ser informado.
As consequncias: Com a implementao deste padro de
projeto, o desenvolvedor consegue reduzir o acoplamento entre
classes, e aumentar a reusabilidade das mesmas.
A refatorao internalizar mtodo

Esta refatorao pertencente ao grupo de refatoraes classificadas como Compondo Mtodos.
Nome da refatorao: Internalizar Mtodo.
Resumo: comum encontrar em algumas classes de um
sistema mtodos que, s vezes, so to pequenos e claros.
Aconselha-se a remoo destes mtodos e juntar suas funcionalidades ao mtodo que o invoca.
Motivao: Alguns desenvolvedores tm o habito de criar pequenos mtodos para resolver determinado problema, quando
na verdade um mtodo poderia facilmente conter todas essas
funcionalidades sem carregar responsabilidades alm das que
deveria naturalmente (como visto na refatorao Extrair Mtodo,
mtodos com vrias responsabilidades devem ser divididos,
portanto Extrair Mtodo contrrio a Internalizar Mtodo).
Mecnica:
Analisa-se o mtodo a fim de se certificar que ele no
modificado polimorficamente.
Busca-se por todas as chamadas a este mtodo pelo sistema
e as substitui pelo corpo do mtodo que se deseja Internalizar
(remover).
Remove-se o mtodo.
Executam-se os testes para se certificar de que a aplicao
ainda possui as mesmas funcionalidades que possua antes.
Exemplo: A seguir, tem-se um exemplo retirado de uma
aplicao de cadastro de clientes, como mostra a Listagem 1.
O mtodo AtualizarDadosCliente responsvel por editar
o cliente. Para isso, invoca o mtodo RecuperaCliente, que
apenas recupera o cliente com o id especfico que o mtodo
AtualizarDadosCliente manipular. Neste contexto, pode-se
aplicar a refatorao Internalizar Mtodo para remover o mtodo RecuperaCliente, e adicionar a sua nica funcionalidade
ao corpo do mtodo que o invoca, no caso AtualizarDadosCliente. O resultado pode ser visto na Listagem 2.
Engenharia de Software Magazine - Refatorao para Padres Parte 9
Desen volvimento
A refatorao Encapsular Coleo

Esta refatorao pertencente ao grupo de refatoraes classificadas como Organizando Dados.
Nome da refatorao: Encapsular Coleo.
Resumo: Mtodos que retornam uma coleo de objetos
podem ter seus dados expostos. Criam-se mtodos de gravao e leitura que sero responsveis por manipular a coleo
de objetos, evitando operaes ilegais por parte dos que a
manipulam.
Motivao: Esta refatorao deve ser aplicada para evitar o
uso indevido de dados contidos em colees, como objetos. A
falta de controle sobre as colees de objetos permite que os
dados presentes nelas fiquem expostos sujeitos a alteraes
por quem no tem esse privilgio.
Mecnica:
Busca-se por colees de dados onde h risco de modificaes
descontroladas.
Substitua os pontos no cdigo onde dados so adicionados
coleo por meio de seus mtodos (colees como ArrayLists
e Lists possuem o mtodo add que permite a adio de dados)
por mtodos que faam a adio de dados.
Altere os mtodos que fazem leitura de dados da coleo
para que no permitam que novos dados sejam adicionados
coleo atravs deles.
Execute testes para se certificar que as modificaes no
alteraram as funcionalidades do sistema.
Exemplo: A classe Curso contm vrios mtodos, entre eles
um mtodo que retorna colees de dados e um mtodo que
cadastra novos cursos, como mostra a Listagem 3.
O cdigo presente no mtodo main (Listagem 4) mostra algumas operaes que so realizadas, como recuperar os cursos
cadastrados (invocando o mtodo RecuperaCursos da classe
Curso). Ainda possvel visualizar que algumas operaes
modificam o contedo da lista de cursos, como adicionar um
novo curso lista, remover um curso em uma posio especfica, e ainda limpar essa lista, perdendo todos os dados que
nela esto contidos.
Para evitar que esse tipo de manipulao acontea, esta refatorao prope o uso de mtodos que permitam que essas
operaes sejam efetuadas com segurana. A Listagem 5
mostra os mtodos criados que permitiro que as operaes
realizadas no mtodo main sejam feitas atravs dos mtodos
recm-criados.
Os mtodos criados na classe Curso (Listagem 5) possibilitaro ao desenvolvedor manipular a lista de cursos. O cdigo
do mtodo main foi alterado conforme mostra a Listagem 6. A
partir de agora, a classe Curso conta com mtodos especficos
para manipulao da coleo.
Aps conhecidas as tcnicas de refatorao necessrias para
o entendimento das tcnicas de refatorao para padres que
este artigo aborda, o desenvolvedor poder iniciar o processo
de aprendizagem das tcnicas de refatorao para padres
Substituir Distino Um/Muitos por Composite e Substituir
Notificaes Hard-coded por Observer.
Listagem 1. Mtodos a serem refatorados.
01. private Cliente RecuperaCliente(String ID)

02. {
03. Cliente objCliente = new Cliente();
04. objCliente = objCliente.RecuperaClientePorID(ID);
05. return objCliente;
06. }
07. private Cliente AtualizarDadosCliente(String ID, String nome, String CPF)
08. {
09. Cliente objCliente = RecuperaCliente(id);
10. objCliente.Nome = nome;
11. objCliente.CPF = CPF;
13. }
Listagem 2. Novo mtodo AtualizarDadosCliente.
01. private Cliente AtualizarDadosCliente(String ID, String nome, String CPF)

02. {
03. Cliente objCliente = new Cliente();
04. objCliente = objCliente.RecuperaClientePorID(ID);
05. objCliente.Nome = nome;
06. objCliente.CPF = CPF;
08. }
Listagem 3. Classe Curso
01. public class Curso

02. {
03. ArrayList listaCursos = new ArrayList();
04. ...
05. public ArrayList RecuperaCursos()
06. {
07.
...
08.
return listaCursos;
09. }
10. public Boolean CadastrarCursos(ArrayList listaCursos)
11. {
12. ...
13. return true;
14. }
15. ...
16. }
Listagem 4. Cdigo de manipulao da lista de cursos
01. static void Main(string[] args)

02. {
03. ...
04. Cursos curso = new Curso();
05. ArrayList listaCursos = cursos.RecuperaCursos();
06. listaCursos.Add(Introduo a Economia);
07. listaCursos.RemoveAt(1);
08. ...
09. }
Listagem 5. Mtodos para encapsular a coleo, na classe Curso
01. public class Curso

02. {
03.
04. public void AdicionarCursoNaLista(Curso curso)
05. {
06.
listaCursos.Add(curso);
07. }
08. public void RemoverCursoDaLista(Int32 posicao)
09. {
10.
listaCursos.RemoveAt(posicao);
11. }
12. }
53
Listagem 6. Cdigo no mtodo main modificado
01. static void Main(string[] args)

02. {
03. Curso cursos = new Curso();
04. ArrayList listaCursos = cursos.RecuperaCursos();
05. cursos.AdicionarCursoNaLista(new Curso());
06. cursos.RemoverCursoDaLista(1);
07. }
Listagem 7. Classe Composite
01. public class Composite

02. {
03. private ArrayList listaObjetos;
04. Venda venda = new Venda();
05. public Composite(ArrayList lista)
06. {
07.
this.listaObjetos = lista;
08. }
09. public ArrayList ObterLista()
10. {
11.
return listaObjetos;
12. }
13. public Composite()
14. {
15. }
16.
17. }
Substituir Distino Um/Muitos por Composite

Resumo: Existe cdigo em uma classe responsvel por manipular um objeto e cdigo semelhante para manipular vrios
desses objetos. Cria-se um composite com cdigo nico para
resolver os dois problemas de manipulao de objetos.
Motivao: Distino um/muitos est relacionada ao de
manipular um nico objeto com um trecho de cdigo, e manipular vrios desses objetos usando outro trecho de cdigo.
Ao se criar dois trechos de cdigo para resolver este problema,
cria-se uma distino. Esta ao adiciona muito cdigo duplicado ao sistema. Com esta tcnica de refatorao para o padro
composite, consegue-se remover cdigo duplicado, criando um
nico mecanismo para manipular um ou muitos objetos.
Vantagens: Permite a remoo de cdigo duplicado; Cria um
mecanismo nico para manipular um ou vrios objetos; Facilita
a definio de como manipular vrios objetos ao mesmo tempo
de diversas formas.
Desvantagens: Algumas vezes implica em criar mecanismos
para garantir que os dados passados para o composite so dos
tipos de dados esperado por ele.
Mecnica:
1. Definindo uma classe que ser o composite, cria-se um construtor que recebe uma lista como parmetro. Em seguida, deve
ser criado um mtodo que retorne a lista criada. Modificando o
mtodo que manipula a lista, insere-se uma instncia da classe
composite criada. Posteriormente, os pontos onde h utilizao
da lista de objetos dentro do mtodo que recebe uma lista
devem ser trocados pela lista retornada do composite.
2. Com as refatoraes Extrair Mtodo e Mover Mtodo, devese criar um mtodo com informaes retiradas do mtodo
54
que manipula uma lista, e depois ele deve ser movido para
o composite.
3. O mtodo que recebe uma lista deve se tornar igual ao
mtodo de um objeto. Para isso, algumas mudanas talvez
sejam necessrias.
4. Modifica-se o mtodo que recebe a lista para conter uma
instncia do composite, cujo retorno ser a chamada ao mtodo
movido para o composite. Talvez seja preciso usar a refatorao
Extrair Interface, dependendo do contexto do problema.
5. O mtodo que recebe a lista de objetos agora poder ser
removido, usando a refatorao Internalizar Mtodo.
6. Crie uma forma de limitar a lista contida no composite para
se tornar somente leitura. A refatorao Encapsular Coleo
ajudar neste sentido.
Exemplo: O exemplo a seguir mostra dois mtodos da classe Venda que so responsveis por realizar verificaes. A
diferena entre eles est no fato de que um recebe uma lista
de objetos venda e outro recebe apenas um objeto venda.
Aplicando esta refatorao para padres, cria-se uma classe
composite cujo construtor retornar uma lista de objetos.
Alm disso, essa classe ter a definio de um mtodo
que retornar a lista criada. A Listagem 7 mostra a classe
Composite.
No mtodo que recebe a lista sero aplicadas as refatoraes Extrair Mtodo e Mover mtodo, levando o mtodo
extrado para o composite. A Listagem 8 mostra a classe
Venda e os dois mtodos: o que recebe um objeto e o que
recebe uma lista, e que sero alvos das refatoraes.
O mtodo extrado e movido para o composite se chama
Verificar (Listagem 9). Os mtodos da classe Venda agora
esto como pode ser visto na Listagem 10.
Os mtodos da classe Venda (Listagem 10) executam a
mesma tarefa, portanto o mtodo que recebe uma lista como
parmetro dever ser removido com a refatorao Internalizar Mtodo. O cdigo cliente que invocava o mtodo que
recebe uma lista agora poder ser atualizado para chamar
o mtodo que recebe apenas um objeto, que o tratar da
mesma forma, visto que o objeto passado ser adicionado
a uma lista.
Para finalizar esta refatorao para padres, aplica-se a
refatorao Encapsular Coleo, na lista retornada pela
classe Composite.
Substituir Notificaes Hard-coded por Observer

Resumo: Algumas subclasses possuem apenas a responsabilidade de notificar quando a instncia de uma classe criada. Remove-se esta funcionalidade e torna-se a superclasse
capaz de realizar esta tarefa atravs de um Observer.
Motivao: Hard-coded a definio dada a um trecho de
cdigo criado exclusivamente para uma tarefa, e no utilizvel com outra funo. Notificaes Hard-coded envolvem
notificaes geradas por um trecho de cdigo com a exclusiva misso de comunicar quando acontecer uma mudana
em um objeto de uma classe. Neste contexto, aconselha-se
Desen volvimento
a utilizao desta tcnica de refatorao para padres, que

substituir o cdigo de notificaes por um Observer.
Vantagens: Cria um acoplamento fraco entre a classe responsvel pelas notificaes e seus observadores; Permite
a definio de mais de um observador.
Desvantagens: Torna o projeto de cdigo existente mais
complicado quando as notificaes hard-coded so mais
simples que um observador.
Mecnica: Conceitua-se notificador a classe que envia
informaes e notificaes para outras classes. J as classes
que recebem as notificaes ou informaes enviadas so
chamadas de receptoras.
1. Com a tcnica de refatorao Mover Mtodo e Extrair
mtodo, move-se todo cdigo responsvel por notificar,
deixando na classe notificadora apenas o trecho de cdigo
que chamar o mtodo extrado e movido para a classe
receptora.
2. Com a refatorao Extrair Interface, cria-se uma interface
para a classe receptora.
3. Os mtodos de notificao contidos na classe receptora
devem implementar a interface criada.
4. Os mtodos que esto na classe notificadora devem
ser movidos para a superclasse com a refatorao Subir
Mtodo na Hierarquia.
5. Modifica-se a superclasse para que ela se comunique
com a interface criada, e depois elimina-se o notificador, ou
as caractersticas que tornam a classe uma notificadora.
6. A superclasse deve poder acessar qualquer mtodo da
interface. Para isto, algumas mudanas devem ser feitas.
Exemplo: Considera-se o cdigo da Listagem 11. A classe
uma subclasse da classe NotificadoraVenda. O mtodo
ProdutoFalta envia uma mensagem para uma classe receptora quando uma verificao no estoque feita. A classe
receptora, por sua vez, exibe o status dessa verificao.
O primeiro passo dessa refatorao para padres envolve
a extrao de um mtodo que contenha a lgica de envio
de informaes que, em seguida, deve ser movido para
a classe receptora. A Listagem 12 apresenta como fica
o mtodo ProdutoFalta, e a Listagem 13 mostra a classe
receptora com o mtodo extrado de ProdutoFalta.
Define-se ento uma interface para a classe Receptora,
como mostra a Listagem 14.
O passo 3 envolve fazer com que classe Receptora implemente a interface criada, conforme apresentado na
Listagem 15.
O prximo passo requer que a aplicao da refatorao
Subir Mtodo na Hierarquia, levando o mtodo ProdutoFalta para sua superclasse, como mostra a Listagem 16.
A seguir, atualiza-se o mtodo ProdutoFalta, que agora
est na superclasse, para que se comunique com a interface
da classe Receptora, e no mais diretamente com a classe,
como mostra a Listagem 17.
Resta agora atualizar o cdigo cliente para invocar o
mtodo que agora est na superclasse, e no mais em
Listagem 8. Classe Venda
01 public class Venda

02 {
03 ...
04 public Boolean ValorSuperiorVenda(Venda venda)
05 {
06
Boolean verifica = false;
07
if (venda.Quantidade > 1 && venda.Valor >= 100.0m)
08
{
09
GerarCredito();
10
verifica = true;
11
}
12
return verifica;
13 }
14 public Boolean ValorSuperiorVenda(ArrayList listavenda)
15 {
16
int i = 0;
17
18
while(i <= (listavenda.Count) - 1)
19
{
20
Venda venda = (Venda)listavenda[i];
21
22
{
23
GerarCredito();
24
verifica = true;
25
}
26
i++;
27
}
28
return verifica;
29 }
30 }
Listagem 9. Classe Composite
01. public class Composite

02. {
03. ...
04. public Boolean Verificar(ArrayList listavenda)
05. {
06.
int i = 0;
07.
08.
while (i <= (listavenda.Count) - 1)
09.
{
10.
Venda venda = (Venda)listavenda[i];
11.
12.
{
13.
venda.GerarCredito();
14.
verifica = true;
15.
}
16.
i++;
17.
}
18.
return verifica;
19. }
20. }
Listagem 10. Classe Venda
01. public class Venda

02. {
03. ...
04. public Boolean ValorSuperiorVenda(Venda venda)
05. {
06.
ArrayList lista = new ArrayList();
07.
lista.Add(venda);
08.
Composite compor = new Composite();
09.
return compor.Verificar(lista);
10. }
11. public Boolean ValorSuperiorVenda(ArrayList listavenda)
12. {
13.
Composite composite = new Composite(listavenda);
14.
return composite.Verificar(listavenda);
15. }
16. }
55
Listagem 11. Classe NotificadoraProduto
Listagem 15. Classe Receptora
01. public class NotificadoraProduto: NotificadoraVenda

02. {
03. private Produto produto = new Produto();
04. private Receptora receptora = new Receptora();
05. private readonly String mensagem1 = Produto em falta;
06. private readonly String mensagem2 = Produto disponvel;
07. ...
08. public void ProdutoFalta()
09. {
10.
if (produto.VerificarProdutos())
11.
{
12.
receptora.StatusEstoque(mensagem2);
13.
}
14.
else
15.
{
16.
receptora.StatusEstoque(mensagem1);
17.
}
18. }
19. }
01. public class Receptora: IReceptora

02. {
04. public void StatusEstoque(String mensagem)
05. {
06.
Console.WriteLine(mensagem);
07. }
08. public void VerificarProduto(String mensagem1, String mensagem2)
09. {
10.
11.
{
12.
StatusEstoque(mensagem2);
13.
}
14.
else
15.
{
16.
17.
}
18. }
19. }
Listagem 12. Classe NotificadoraProduto
Listagem 16. Classe NotificadoraVenda
01. public class NotificadoraProduto: NotificadoraVenda

02. {
08. {
09.
receptora.VerificarProduto(mensagem1, mensagem2);
10. }
11. }
01. public class NotificadoraVenda

02. {
03. ...
09. {
10.
11. }
12. ...
13. }
Listagem 13. Classe Receptora
01. public class Receptora

02. {
04. public void StatusEstoque(String mensagem)
05. {
06.
Console.WriteLine(mensagem);
07. }
08. public void VerificarProduto(String mensagem1, String mensagem2)
09. {
10.
11.
{
12.
13.
}
14.
else
15.
{
16.
17.
}
18. }
19. }
Listagem 14. Interface para classe Receptora
01. public interface IReceptora

02. {
03. void VerificarProduto(String mensagem1, String mensagem2);
04. }
56
Listagem 17. Superclasse NotificaVenda
01. public class NotificadoraVenda

02. {
04. IReceptora receptora = new Receptora();
08. {
09.
10. }
11. }
subclasses especficas para cada tipo de notificao. A

subclasse NotificaProduto pode ser removida e novos
mtodos de notificao podem ser definidos na classe
Receptora, e invocados via interface, usando a superclasse
NotificaVenda.
Concluso
Mais uma vez o padro de projeto composite foi apresentado
de uma forma diferente, pois atua em diversos problemas de
cdigo, mostrando que no h uma nica forma e momento
Desen volvimento
Referncias
GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a objetos,
1ed. Porto Alegre: Bookman, 2000.
KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.

Feedback
eu
edio
ta
D
s
FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
57
sobre e
s
de se implementar um padro. Deve-se focar na inteno do

padro e implement-lo de maneira que se adeque ao projeto
em desenvolvimento.
Na srie de artigos apresentados at este momento sobre refatorao para padres possvel visualizar uma das principais
preocupaes das tcnicas de refatorao para padres, que
foram citadas no artigo da edio 28 da Engenharia de Software
Magazine: remover cdigo duplicado e simplificar estruturas
complexas. Esses problemas, se amenizados, podem contribuir
para um menor risco de falhas relacionado manuteno, o
que um dos grandes objetivos de quem desenvolve software.
Neste artigo, o padro de projeto Observer contribuiu para que
os objetivos citados sejam alcanados.
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Aspectos importantes da gesto de projetos

Requer Conhecimento do Problema, Compromisso e Liderana

Apresenta necessidade de reconhecer o problema a
ser tratado, compromisso e liderana como elementos essenciais gesto de projetos.
Para que serve?
Antonio Mendes da Silva Filho

antoniom.silvafilho@gmail.com
Professor e consultor em rea de tecnologia

da informao e comunicao com mais
de 25 anos de experincia profissional,
autor do livros Introduo a Programao
Orientada a Objetos com C++, Arquitetura
de Software, Programando com XML, todos
pela Editora Campus/Elsevier, tem diversos
artigos publicados em eventos nacionais
e internacionais, colunista para Cincia e
Tecnologia pela Revista Espao Acadmico
com mais de 100 artigos publicados, tendo
feitos palestras em eventos nacionais e no
exterior. Foi Professor Visitante da University of Texas at Dallas e da University of
Ottawa. Formado em Engenharia Eltrica
pela Universidade de Pernambuco, com
Mestrado em Engenharia Eltrica pela
Universidade Federal da Paraba (Campina Grande), Mestrado em Engenharia da
Computao pela University of Waterloo
e Doutor em Cincia da Computao pela
Univesidade Federal de Pernambuco.
58
Conscientizar o engenheiro de software e gerentes

de projetos de que no apenas a existncia de um
processo de desenvolvimento e conhecimento tcnico so determinantes para o sucesso de um projeto,
mas que o conhecimento comportamental da equipe

e lder tambm so essenciais.

O artigo identifica diversos aspectos comportamentais essenciais aos membros da equipe
de projeto e, principalmente para o seu lder.
Conhecer e saber lidar com esse conhecimento
comportamental faz a diferena na execuo de
um projeto.
Para ter acesso esse artigo na ntegra acesse o leitor digital:

www.devmedia.com.br/esmag
Engenharia de Software Magazine - Negociao de Contratos
agilidade
59

Edição36 2011

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Edição36 2011

Enviado por

Direitos autorais:

Formatos disponíveis

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

rocesso de software o conjunto de atividades que constituem o desenvolvimento de

Ano 3 - 36 Edio - 2011

e manuteno de um produto de software, abrangendo a vida do sistema, desde a definio de

equipe, o ambiente operacional so fatores que influenciaro diretamente na escolha do ciclo de

vida de software a ser adotado.

Gesto do bom humor

Aprimorando a Escrita de Casos de Uso

Desejamos uma tima leitura!

Fale com o Editor!

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

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

21 - Ciclos de Vida do Software

29 - Introduo verificao de diagramas de classe Parte 2

45 - Otimizao de Processos de Negcio usando BPM Parte 2

Edio 05 - Engenharia de Software Magazine

Por trs do bvio

Gesto do bom humor

Engenharia de Software - Gesto do bom humor

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

D seu feedback sobre esta edio!

Ser bem humorado no significa destilar gracinhas a torto

Para que serve?

Jacimar Fernandes Tavares

Bacharel em Cincia da Computao pela FAGOC - Faculdade Governador Ozanam Coelho,

Marco Antnio Pereira Arajo

Doutor e Mestre em Engenharia de Sistemas

processo de desenvolvimento de software possui vrias

Para mostrar os benefcios que o uso de ferramentas

Em que situao o tema til?

Para uma empresa aderir a mtodos

Edio 36 - Engenharia de Software Magazine

Figura 1. Ferramenta Sprintometer

as aes do Scrum Team. Neste contexto, a ferramenta a ser

Figura 2. Projeto do tipo Scrum criado

metodologia gil a ser utilizada e da produtividade almejada,

A utilizao de ferramentas CASE

Engenharia de Software Magazine - Agilidade na Prtica

Sprintometer uma ferramenta livre utilizada para gerir

Estudo de caso: Gerenciando o projeto Hotel Master

onde se define o tipo de estimativa a cerca do projeto) deve-se

desenvolvimento do projeto. Aplicando as alteraes, tem-se

Criando tarefas para o sprint

Criando um sprint para o projeto

Figura 3. Projeto Hotel Master

Figura 4. Primeiros passos na criao do sprint

Edio 36 - Engenharia de Software Magazine

atribudo, o que quer dizer que as 3 primeiras horas do projeto

Figura 5. Criando o Primeiro Sprint

Figura 6. Criando a primeira tarefa

Figura 7. Cenrio Levantando Requisitos completo

Figura 8. Hierarquia do sprint at o momento

Engenharia de Software Magazine - Agilidade na Prtica

a secretria. Em Description, a informao: Nesta conversa

teria 10 dias, com jornada de 8 horas. O cronograma mostra

Alocando pessoas ao projeto

Figura 9. Viso geral das tarefas do sprint.

Figura 10. Primeiro Sprint com suas tarefas

Definindo o cronograma do projeto