Revista Engenharia de Software 32

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
Ano 3 - 32 Edio - 2011
impresso no brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Capa e diagramao
Romulo Araujo - romulo@devmedia.com.br
Coordenao geral
Daniella Costa - daniella@devmedia.com.br
revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
Jornalista responsvel
Kaline Dolabella - JP24185
na Web
www.devmedia.com.br/esmag
Apoio
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
urante muitos anos, as metodologias tradicionais foram utilizadas

amplamente pela maioria dos projetos e das empresas de desenvolvimento de software, e o modelo cascata era tido como o mais
completo e efetivo. Essa situao se modificou assim que surgiram os primeiros projetos geis, logo aps o manifesto gil em 2001, e o mundo do
desenvolvimento de software se dividiu entre os mais conservadores e os
simpatizantes do Scrum, XP e outras metodologias geis.
No entanto, apesar dos casos de sucesso serem muitos, logo comearam
a aparecer os primeiros estudos de caso que apresentavam problemas
utilizando tais metodologias e, principalmente, o Scrum. O Scrum, mesmo
com inmeras vantagens em vrias perspectivas, deve-se deixar claro, no
a soluo perfeita para todos os problemas da rea de Engenharia de
Software, logo, no a bala de prata dos projetos de desenvolvimento.
Neste contexto, esta edio da Engenharia de Software Magazine desta
o artigo Scrum: No funcionou para voc?. O artigo apresenta algumas
lies aprendidas durante os ltimos anos na rea da qualidade de software e tambm na liderana em equipes de desenvolvimento trabalhando com Scrum. A principal inteno de listar tais lies ajudar outras
equipes que possam vir a ter os mesmos (ou semelhantes) problemas no
decorrer do desenvolvimento de aplicativos e sistemas.
Alm desta matria, esta edio traz mais sete artigos:
Tenho um Chefe difcil: e agora?
Modelagem em uma Viso gil
Entendendo melhor SOA e ESB
Especificao de Casos de Uso
Engenharia de Software: Sobre a Necessidade de Educao Continuada
Refatorao para Padres - Parte 5
Modelagem Temporal, de Implantao, de Artefatos e de Componentes
atravs da UML.
desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine

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 Tenho um Chefe difcil: e agora?
Glnio Cabral
Agilidade
08 - Modelagem em uma Viso gil
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:
Lenildo Morais
13 - Scrum: No funcionou para voc?

Gabriela de Oliveira Patuci
Desenvolvimento
18 - Modelagem Temporal, de Implantao, de Artefatos e de Componentes
atravs da UML
Geraldo Magela Dutra Gonalves
Tipo: Processo
Ttulo: Especificao de casos de uso na prtica Partes 6 a 10
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.
26 - Refatorao para Padres Parte 5

Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Engenharia
33 - Engenharia de Software: Sobre a Necessidade de Educao Continuada
Antonio Mendes da Silva Filho
39 - Especificao de Casos de Uso

40 - Entendendo melhor SOA e ESB

Lenildo Morais
Edio 05 - Engenharia de Software Magazine
Pos 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.
Tenho um Chefe difcil:

e agora?
N
o mercado atual, todos os lderes sabem como motivar suas equipes estabelecendo um timo clima
organizacional, certo? Errado!
Parece estranho, mas ainda h lderes que possuem um
grande talento para promover a desmotivao geral de suas
equipes. Pesquisas apontam que chefes considerados difceis
nunca admitem seus erros, no costumam dar feedbacks, so
ditadores e esto sempre insatisfeitos com o desempenho dos
seus subordinados. Ser que voc, caro leitor, tem sido premiado com um chefe assim? Na dvida, a vo algumas dicas para
que voc saiba lidar melhor com um chefe complicado.
1. Certifique-se de que voc no a nica pessoa a ter
dificuldades de lidar com seu chefe. Lderes que so comprovadamente um problema costumam ser encarados dessa
forma por todos, e no apenas por uma pessoa. Se voc a
nica pessoa a ter problemas com seu chefe, o problema pode
estar em voc.
2. Nunca bata de frente. Estudos comprovam que as relaes
pessoais tm um peso muito grande no mercado brasileiro.
Por isso, nada de bater de frente, pois voc poder ser mal
interpretado. preciso ter o cuidado de conhecer melhor o
chefe para saber a melhor hora de falar, de opinar e de pedir
algo. Em nossa cultura, essas coisas costumam dar muito
resultado. Voc est na sua razo? Ainda assim bater de frente
nunca ser uma boa. V com calma e pelas beiradas.
Engenharia de Software - Tenho um chefe difcil: e agora?
3. Faa sempre o dever de casa e no d brechas para puxes de orelha. A produtividade e a competncia sempre
sero recompensadas e desejadas, mesmo que seu chefe
seja um Hitler. Seu chefe insensvel e nunca reconhece
seus mritos? Ento d o melhor de si e continue fazendo
seu trabalho com responsabilidade e seriedade, porque no
h chefe que resista ao charme de um bom profissional.
Essa postura de excelncia costuma inclusive abrir portas
para outras possibilidades profissionais.
4. No se envolva em fofocas nem fique falando mal de
seu chefe para os colegas de trabalho. Essas coisas costumam chegar aos ouvidos dele, o que pode tornar a situao
ainda mais difcil. A maledicncia corporativa nunca uma
boa postura profissional. Alm do mais, numa possvel
transferncia de departamento ou de funo a fama de
encrenqueiro s ir dificultar as coisas.
5. Sempre que possvel, solicite do seu chefe o feedback
de suas aes. Se tem algo que os chefes complicados no
se sentem vontade para fazer dar um feedback. Isso
acontece porque eles so pssimos no quesito comunicao, e como dar um feedback basicamente comunicarse, a coisa acaba emperrando. Por isso, em alguns casos
preciso arrancar o feedback do chefe. Atravs desse
retorno o colaborador ter informaes importantes para
aprimorar suas aes e ser mais produtivo. O que, diga-se
por trs d o bvio
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:
Feedback
eu
edio
ta
D seu feedback sobre esta edio!
D
s
Por fim, se nada disso adiantar, talvez seja a hora de ter uma
conversa franca com o departamento de recursos humanos e
sinalizar que est disposto a mudar de ares. Mas lembre-se
de duas coisas: primeiro, chefes difceis esto com os dias
contados. No h mais espao para eles num mercado de
trabalho globalizado e dinmico. E segundo, voc pode at
deixar uma empresa por causa de um chefe difcil, mas se for
um bom profissional o mercado de trabalho nunca o deixar.
Siga em frente.
www.devmedia.com.br/esmag/feedback
sobre e
s
de passagem, far com que seu chefe reclame menos do seu

desempenho.
6. No adote uma imagem de vtima e de coitadinho. Os bons
profissionais no agem assim. Se voc se sente perseguido
ou no reconhecido por seu chefe, no ande cabisbaixo pelos
cantos. Seja auto-motivado e tenha sempre a conscincia
do seu valor e potencial. Lembre-se: os bons profissionais
sempre so reconhecidos e desejados. Se no pelo seu chefe,
pelo concorrente ao lado.
7. Desenvolva o hbito de engolir alguns sapinhos. Ao
longo das nossas vidas, sempre estaremos engolindo alguns
anfbios saltitantes. Isso acontece porque nem sempre vamos
poder chutar o balde quando bem entendermos. Afinal,
temos contas para pagar e famlia para sustentar. Sem falar
que mudar de funo ou de emprego no garantia de que
se estar livre para sempre de um chefe difcil. Manter o
controle e esperar a hora certa de tomar certas decises so
posturas que sempre acompanham o profissional maduro e
que sabe o que quer.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Modelagem em uma Viso gil

O que? Quanto? E para que modelar?
De que se trata o artigo?
A
Lenildo Morais
lenildojmorais@gmail.com
analista de sistemas e analista de testes.

Atualmente est cursando mestrado no centro
de informtica da UFPE em engenharia de
software com nfase em testes e qualidade
de software.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Uma viso
geral da UML.
modelagem, do ponto de vista

gil, um mtodo eficiente
que tem como objetivo tornar
mais produtivos os esforos da tarefa
de modelar, to comum nos projetos de
software.
Os valores, princpios e prticas da Modelagem gil podem auxiliar as equipes
na definio de componentes tcnicos
de alto e baixo nvel que faro parte do
desenvolvimento de software. Artefatos
sofisticados elaborados por ferramentas
de alto custo nem sempre so os melhores para ajudar no desenvolvimento do
software. Modelar o software em grupo
e com a participao dos usurios, utilizando rascunhos, vista como uma boa
prtica para se conseguir isto.
Uma das dificuldades mais comuns nas
equipes de desenvolvimento como conseguir efetivamente capturar as necessidades dos usurios. Uma das maneiras
de se alcanar isso passa pelo desenvolvimento iterativo, onde so entregues
software funcionando constantemente
Engenharia de Software Magazine - Modelagem em uma Viso gil
Apresentar, atravs de uma viso geral, os valores,

princpios e prticas da modelagem gil (Agile Modeling), abordando aspectos como: trabalho em
conjunto, participao efetiva do cliente, comunicao, rascunhos como forma de modelagem e a
utilizao da modelagem na obteno da qualidade e de maior produtividade.
Para que serve?

Proporcionar s equipes de desenvolvimento de
software maior conhecimento sobre a modelagem gil, uma vez que grande parte dos projetos
de desenvolvimento ainda precisa evoluir neste
aspecto.
Em que situao o tema til?

Nos projetos de desenvolvimento de software,
sobretudo quando se deseja buscar mercados
externos ou expandir seus clientes internos aumentando a satisfao dos mesmos.
com o objetivo de observar se as necessidades foram atendidas. Ao longo

deste artigo veremos os conceitos e alguns aspectos importantes no tocante
modelagem gil, assim como alguns
benefcios trazidos por esta prtica.
Agilidade
Viso geral da Modelagem gil

O processo atual de desenvolvimento de software ainda
est em um nvel de qualidade muito abaixo do que seria
considerado ideal, isto porque os sistemas so entregues aos
clientes fora do prazo estipulado no projeto e com um custo
maior do que o previsto. Alm disso, esses sistemas frequentemente no alcanam a qualidade desejada pelo cliente e, em
muitos casos, no satisfazem as reais necessidades do mesmo,
levando a altos ndices de manuteno ou passando a ideia
de isso ter de ficar para uma prxima verso.
A modelagem gil vista como um processo de desenvolvimento de software baseado em prticas que visa aumentar a
eficincia das equipes dentro dos projetos. Ao contrrio dos
processos tradicionais, que requer basicamente os mesmos
artefatos para todos os tipos de projetos, a modelagem gil
busca a construo e manuteno eficiente de artefatos,
criando-os apenas quando agregarem valor real ao projeto,
e focando principalmente os esforos no desenvolvimento
do software.
Entretanto, a modelagem gil no uma metodologia de
desenvolvimento gil como eXtreme Programming (XP) ou
Scrum, mas sim uma boa prtica. Ela visa construir e manter
modelos de sistemas de maneira eficaz e eficiente, podendo
ser utilizada dentro de metodologias geis e tradicionais.
J com relao comunicao da equipe, a modelagem gil
pode ser aplicada fazendo com que as pessoas envolvidas
nos projetos colaborem para que a soluo atenda ao negcio.
Neste contexto, no interessante se prender a papis. Uma
equipe de desenvolvimento de software mais eficiente
se todos so capazes de fazer todas as atividades. Esta boa
prtica proporciona um trabalho muito mais colaborativo e
integrado, uma vez que comum nas equipes haver pessoas
com qualidades diferenciadas. possvel que haja uma pessoa
com excelente desenvoltura para conversar com os usurios,
outra pessoa consegue codificar com uma rapidez e qualidade
acima da mdia, e outra pessoa pode ter um conhecimento
abrangente para dar solues a problemas complexos.
comum algumas pessoas, que no so da rea de desenvolvimento de software, acharem que a engenharia de sistemas prxima da engenharia civil ou engenharia mecnica.
Enquanto nas engenharias tradicionais existe uma diviso
entre design e construo, na engenharia de software no
existe esta separao.
Quando um edifcio construdo, o gerenciamento de projeto tradicional faz sentido, pois para esse tipo de produto
(o prdio), necessrio ter uma planta detalhada para poder
iniciar a construo. Nesse projeto quem responsvel pela
atividade de design um arquiteto ou engenheiro que possui
qualificaes intelectuais distintas de quem ir efetuar o
projeto (a construo). O trabalho de construo ser desempenhado pelo pedreiro, que no necessita ter o conhecimento
total da engenharia para fazer o seu trabalho. Essa diviso
acontece por conta das caractersticas totalmente diferentes
entre os dois trabalhadores: um altamente intelectual, o
outro mais braal. Um engenheiro pode ter um custo alto j
o pedreiro tem um custo menor, assim como um engenheiro

pode gerar demandas para o trabalho de at 100 pedreiros.
Dado a natureza do projeto civil, lgico que haja essa diviso
de trabalho entre design e construo. Neste cenrio, no faz
sentido as pessoas do projeto serem engenheiro-pedreiro,
como pode ser na Engenharia de Software.
Durante a construo de um software so consideradas basicamente quatro atividades principais:
1. Compreender o que o usurio quer;
2. Definir como os elementos de software resolvero as necessidades do usurio;
3. Escrever esses elementos de software e integr-los;
4. Testar os elementos e homolog-los com o usurio.
Antes de tudo, deve-se observar que essas atividades ocorrem
muitas vezes dentro de um projeto. Entretanto, considerando
as quatro atividades, a diferena que h com relao engenharia civil que no existem importantes diferenas no nvel
intelectual necessrio para desempenhar essas atividades. A
atividade de levantamento dos requisitos do software no
intelectualmente inferior atividade de codificar estes requisitos. So atividades diferentes, mas no to diferentes como
o trabalho do engenheiro e do pedreiro. O erro que muitas
empresas cometem achar que analistas de sistemas so como
engenheiros civis e programadores so como pedreiros, e isto
no ocorre na prtica.
Aspectos humanos e tcnicos no desenvolvimento de

software
A modelagem gil baseada em uma coleo de prticas,
guiadas por princpios e valores que podem ser aplicados
por profissionais de software no dia a dia. No sendo um
processo prescritivo, no define procedimentos detalhados
de como criar um dado tipo de modelo. Ao invs disso, prov
sugestes de como ser mais efetivo. Em resumo, a modelagem
gil busca o ponto de melhor custo/benefcio entre os artefatos
que devem ser criados para o sistema e o custo de manuteno
e atualizao desses artefatos. Pode-se citar duas motivaes
principais para a criao desta metodologia:
1. O objetivo primrio de um projeto de software o prprio
software, e no um grande conjunto de documentos sobre ele;
2. Um artefato criado primordialmente para permitir a comunicao e a troca de informaes entre a equipe e permitir
a discusso e refinamento do modelo do sistema. Assim, se um
artefato no est passando informaes relevantes ao projeto,
ele no cumpre seu objetivo bsico.
Basicamente, o que se quer com a modelagem do sistema
satisfazer as necessidades dos usurios, garantindo a qualidade
interna (ver Nota 1) do software e respeitando as restries de
custo e prazo do projeto.
Quando se tem que lidar com muita complexidade tcnica,
que geralmente ocorre em sistemas que lidam com milhares de
gigabytes, de usurios, de transaes e de processamento distribudo, um pequeno desvio de disciplina pode levar o sistema ao
caos. Nesse caso, a modelagem voltada para o aspecto tcnico,

em que obrigatrio conhecer a estrutura interna dos componentes, as dependncias, algoritmos complexos, etc.
Todo projeto possui restries de custo e prazo. No se tem
todo tempo e dinheiro do mundo para fazer o software. A misso de um bom modelador administrar as expectativas do
cliente, avaliando com ele quais problemas so prioritrios.
Uma das coisas que as metodologias geis trouxeram tona
a importante participao dos usurios ou clientes para auxiliar
na modelagem do sistema: seja elaborando um mapa mental,
rascunhando uma tela, ou testando um release que acabou de
ser liberado. Os usurios, clientes ou stakeholders possuem um
papel importantssimo para gerar as demandas corretas e avaliar
a qualidade dos trabalhos executados. Isso requer uma comunicao rica entre o cliente e todos os envolvidos no projeto.
Focando nos usurios ou em aspectos mais tcnicos, sempre importante estabelecer o escopo da modelagem gil para
esclarecer o que pode e o que no pode ser atendido por este
processo. A modelagem gil um complemento aos processos
existentes, no uma metodologia completa. Ela no uma
espcie de receita mgica que resolver todos os problemas,
tampouco uma tcnica que garantir melhores resultados. A
ideia por trs da modelagem gil a de utilizar seus esforos
de maneira mais racional e permanecer focado no projeto,
aumentando sua eficincia no desenvolvimento do projeto.
A modelagem gil no visa eliminao da documentao.
Simplesmente diz que a documentao deve ser feita de modo
mais racional, maximizando o investimento do cliente no
processo de desenvolvimento.
A documentao sem dvida uma forma importante de
comunicao nos projetos de software. Entretanto, o pior meio
de comunicao e documentao so artefatos sendo trocados via e-mail. Infelizmente muitos projetos ainda utilizam
somente esse meio pobre de comunicao. Esta a maneira
menos eficiente e mais fria de trocar ideias. J um meio rico
de se comunicar a maneira compartilhada de demonstrar
graficamente as propostas, como rascunho ou um quadro
branco. A prtica bem simples: junta-se as pessoas numa
sala, permitindo que elas colaborem entre si, trocando ideias e
sentimentos com o auxlio de um meio grfico compartilhado.
A eficincia dessa tcnica comprovada em workshops de
requisitos com o cliente ou em discusses arquiteturais dentro
da equipe. O resultado dessas reunies so rascunhos que
podem ser feios na forma, mas so perfeitos para o propsito
de modelagem do sistema.
Rascunhos como forma de modelagem

Sempre que falamos em rascunho, as pessoas ficam com
impresso de coisas mal feitas ou informalidade em excesso.
No entanto, no nosso contexto rascunho um esboo, delineamento, trabalho prvio de redao feito antes de passar
a limpo.
Por alguma razo, profissionais de informtica possuem
um vcio por artefatos digitais. comum ter preferncia
por arquivos que esto em algum lugar do HD. Contudo,
a indstria sobreviveu vrias dcadas sem o computador, e vrias reas de atuao vivem em paz sem o uso
das mquinas. Na rea de desenvolvimento de software
podemos tambm utilizar meios que no so digitais.
Quando falamos em modelagem de um software, uma
das grandes dvidas das equipes de projeto quo longe
devemos nos aprofundar em detalhes. Como ponto de
partida (apoio) podemos nortear nosso raciocnio atravs
de questionamentos como:
1. Qual o nome do projeto?
2. Qual a dvida que tenho?
3. Quem poder modelar isso junto comigo para obter as
respostas?
4. Qual o modelo certo?
Quando nos fazemos estas perguntas significa que estamos com o cliente e querendo saber o que o projeto, ou
seja, na fase de levantamento de requisitos descobrindo
os objetivos, o escopo, as funcionalidades, os riscos. Logicamente quem ajudar a obter essas respostas o cliente.
Estando, portanto, o analista de requisitos e o cliente reunidos, o ponto principal da reunio ter uma compreenso
em alto nvel do sistema, e no todos os detalhes. No
conveniente nessa reunio discutir as mincias. Detalhes
sero adicionados iterativamente e de maneira incremental
durante todo o projeto.
Modelos tambm so formas de decises ou percepes.
Nesse caso, a forma da percepo das funcionalidades e
deciso do escopo inicial do projeto. Um dos valores da
modelagem gil modelar com um propsito e, muitas
vezes, modelar com um propsito significa buscar os critrios de sucesso do projeto. A modelagem busca atender
ao usurio apresentando qualidade e reduzindo custo
ou prazo do projeto. altamente questionvel quando se
modela s para cumprir etapas do processo ou porque
o processo de desenvolvimento exige tal modelo.
Uma das questes relevantes, vistas anteriormente, Qual
o modelo certo?. importante ressaltar que h uma quantidade infinita de maneiras de se modelar. Um esboo feito de
forma conjunta com as partes interessadas um meio muito
eficiente de capturar requisitos e descobrir como atingir o
objetivo de fazer um software com qualidade externa (ver
Nota 2), que atenda s expectativas dos usurios.
Nota 1: Qualidade Interna
Nota 2: Qualidade Externa
Capacidade do software de satisfazer as necessidades implcitas, ou seja, requisitos relacionados

estrutura do software, como por exemplo, a integridade dos dados ou codificao mais
adequada.
Capacidade do software de satisfazer as necessidades explcitas, como por exemplo, o

atendimento s funcionalidades acordadas com o cliente ou o desempenho esperado pelo
software, sempre observando a percepo do usurio.
10
Agilidade
A importncia de se escrever documentos de

requisitos
A vantagem em se fazer com que os clientes e usurios
participem da modelagem do sistema utilizando artefatos e
ferramentas simples, como rascunhos em papel ou no quadro
branco, promover a colaborao e ganhar agilidade na captura de requisitos. Porm, algumas pessoas ou empresas no
reconhecem artefatos em papel como vlidos no processo
de desenvolvimento. Isso leva a uma burocratizao desnecessria na captura de requisitos.
Muitas pessoas levantam requisitos em artefatos informais
para depois transform-los em casos de uso, especificaes
suplementares, prottipos, documentos de regras de negcio
e outros quando voltam para casa. Isto , preenchem esses
templates depois das reunies, formalizando o levantamento.
Como houve uma transformao de artefatos, tpica uma
reviso com o cliente para obter uma aprovao. O problema
que essa aprovao na maioria das vezes no ocorre. Ao ver os
artefatos transformados o cliente lembra-se de mais requisitos
que so mais uma vez capturados em artefatos informais e o
ciclo se repete muitas vezes. Com isso, levam-se semanas para
se aprovar os requisitos e um tempo precioso perdido.
O objetivo de se trabalhar com rascunhos rapidamente
transform-los em software funcionando, de modo que seja entregue ao cliente o software a ser homologado e no documentos a serem aprovados. No se deve perder tempo aprovando
documentos de requisitos depois que foram levantados, pois
eles nunca sero aprovados, e mesmo que sejam aprovados o
cliente poder mudar de ideia quando ver realmente o que ele
quer de fato. Num contexto geral, software funcionando ainda
o melhor artefato para levantamento de requisitos. Dessa
forma, os usurios olham o software e solicitam alteraes
no software e no em documentos. Software a nica coisa
concreta que realmente validamos com os usurios.
Documentos de requisitos tm como objetivo registrar o que
os usurios esperam da aplicao independente da soluo
tcnica. Isso faz com que esses documentos sejam simples e
rpidos de serem elaborados. Mas o mais importante que
esses artefatos sejam elaborados na reunio de levantamento
e no em casa. Deve-se sair da reunio com requisitos levantados e documentados, depois disso, fazer o software para
cumprir o planejamento da iterao.
Modelagem na obteno da qualidade

At ento vimos que a modelagem gil pode melhorar e
documentar decises focadas na qualidade da aplicao,
facilitando a comunicao e disseminando ideias dentro do
time. A modelagem gil possui um princpio chamado Travel
Light. Este princpio diz que manter modelos difcil, e pode
se tornar ainda mais se estes forem complexos e detalhados.
Especialistas na rea afirmam que trs ou quatro modelos
que forneam uma viso geral da anlise, da arquitetura e do
design so suficientes para melhorar a comunicao da equipe.
errado pensar que quanto maior o nmero de documentaes
melhor ser o projeto. A documentao precisa ser enxuta.
Entretanto, a prtica do excesso de documentao ainda

ocorre em muitos projetos. A implantao da modelagem
gil dentro da cultura de desenvolvimento de software uma
experincia tanto interessante quanto traumtica, devido
grande mudana de pensamento trazida pelo mtodo. Para
direcionar os esforos em torno da modelagem gil, existem
alguns princpios que devem ser observados para que o processo adotado seja realmente gil. Dentre esses princpios, os
mais importantes so:
Princpios Fundamentais
Software seu principal objetivo: Produzir softwares que
funcionem;
Racionalizao de artefatos: Racionalizao da documentao, escolhendo aqueles a serem mantidos durante o processo
de desenvolvimento;
Modele com um propsito: Para atender a realidade e para
melhorar a comunicao;
Maximize o investimento do Stakeholder: Valorizar a pessoa chave que representa a empresa.
Princpios Complementares
Contedo mais importante que representao: Desprender-se um pouco de prottipos, apresentando o software
rodando como uma importante forma de validao junto ao
cliente;
Cada um tem algo a aprender com o outro: Na modelagem
gil comum a participao ativa do cliente. Esta interao
mais estreita permite que ambas as partes (produtor e cliente) se entendam melhor, trazendo importantes ganhos ao
projeto;
Adapte o modelo organizao: Cada projeto possui particularidades que precisam ser observadas. Muitas vezes estas
particularidades esto relacionadas com o estilo da empresa
produtora do software e neste caso o modelo deve estar alinhado a ela;
Comunicao transparente e honesta: Com a participao
efetiva do cliente importante prezar pela transparncia das
informaes, que devem estar de comum acordo para ambas
as partes;
Atentar para os instintos da equipe: Ouvir as sugestes e
reclamaes da equipe, pois talvez o problema que ela encontrou possa dificultar no restante da implementao.
A modelagem gil tambm possui dois tipos de prticas: as
prticas centrais e as prticas suplementares. Elas sugerem
pontos que devem ser observados pelas equipes de desenvolvimento de software que ainda no utilizam a modelagem gil,
mas que pretendem introduzi-la em seus projetos.
Prticas Centrais
Trabalho em Equipe: Participao dos vrios perfis da equipe
do projeto durante o desenvolvimento de software, incluindo
o Stakeholder, proporcionando o conhecimento coletivo e evitando que somente uma pessoa domine todo o processo. Uma
forma de disseminar o conhecimento pode ser a divulgao
11
Comprovao atravs do cdigo

Uma das discordncias que muitas equipes tm contra metodologias geis o foco no cdigo. Entretanto, no cdigo que
a alta coeso e baixo acoplamento oferecem benefcios. Um
dos princpios da Modelagem gil : Prove com Cdigo.
Isto , os modelos so somente uma abstrao daquilo que se
est construindo de fato. Mas ser que o modelo est correto?
Ser que ele implementvel? Para saber estas respostas
necessrio provar o modelo com cdigo.
importante ressaltar que a atividade de modelagem visa
obter uma qualidade do cdigo e no do modelo. Uma boa
modelagem tem como objetivo obter um bom cdigo, e no um
bom modelo. A qualidade sempre deve focar no cdigo e nos
importantes conceitos de alta coeso e baixo acoplamento.
Concluso
12
AMBLER, SCOTT. Home Page Agile Modeling

www.agilemodeling.com
COCKBURN, ALISTAIR. Home Page w
ww.alistair.cockburn.us.

Feedback
eu
sobre e
s
Este artigo apresentou que artefatos simples podem ser utilizados para aplicar boas prticas de modelagem. Modelagem
uma atividade em grupo (na maioria das vezes) e tudo que
se faz deve ser focado em melhorar a qualidade do software e
a produtividade da equipe. Modelar simplesmente para ter
o modelo deve ser evitado.
Referncias
D
s
Prticas Suplementares
Produtividade: Utilizar padres e normas de modelagem,
aplicando padres com sabedoria e reutilizando recursos
existentes;
Documentao: Descartar modelos temporrios, formalizando os modelos de contrato;
Propsito: Modelar para entender e para se comunicar;
Boas Ideias: Conhecer bem as ferramentas, refactoring e
Test-First Design.
Entretanto, o mais importante de tudo focar nas atividades

do desenvolvimento e no nos artefatos criados. Durante o
levantamento de requisitos, as atividades de conversar com o
usurio, obter informaes e enriquecer o conhecimento so
mais importantes que os casos de uso, prottipos ou modelos
que surgirem dessa atividade. O importante a criatividade na
soluo do problema, na separao dos conceitos e nas mensagens trocadas entre os envolvidos no projeto do software.
Podemos ver tambm ao longo do artigo que muitas pessoas
confundem a atividade de levantamento de requisitos com
preenchimento dos templates de artefatos de requisitos. E,
pior ainda, muitas vezes esse preenchimento de artefatos
feito simplesmente para cumprir tarefas de um processo de
desenvolvimento pesado, que muitas vezes interferem de
forma negativa na criatividade das pessoas.
O que o cliente quer o software e no os documentos que
abstraem o que se espera do software. Muitos dos artefatos
sugeridos e utilizados na modelagem gil so rascunhos de
casos de uso, rascunhos de prottipos de tela, rascunhos de
diagrama de atividades. Tudo em papel, desenhados junto com
o cliente e com isso automaticamente aprovados por ele. Esses
rascunhos so ento transformados em software funcionando,
seguindo as boas prticas da Engenharia de Software.
edio
ta
dos modelos produzidos colocando-os em painis, parede ou

outro meio;
Simplicidade: Criao de contedo mais leve, descrevendo
modelos simples e utilizando ferramentas menos complexas.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Scrum: No funcionou para voc?

Erros comuns na tentativa de implantar Scrum em times geis

Neste artigo apresentada uma lista onde citouse o resultado de um estudo que lista quais as
principais causas para os problemas mais frequentes em projetos Scrum. Este estudo foi realizado dentro dos ltimos dois anos em projetos
com times geis, inicialmente dentro do papel de
analista de testes e lder de testes, e nos ltimos
meses, tambm no papel de Scrum Master.
D
Gabriela de Oliveira Patuci
opgabi@gmail.com
formada pela UNICAMP em Tecnologia

em Informtica e est cursando mestrado
na rea de Engenharia de Software. Possui
certificao pela Scrum Alliance, tem experincia de trs anos no trabalho com metodologias geis e de cinco anos em Testes
e Qualidade de Software. Hoje atua como
Scrum Master em projetos internacionais
pela Ci&T e j palestrou em eventos como
Agile Brazil 2010.
urante muitos anos, as metodologias tradicionais foram utilizadas amplamente pela maioria
dos projetos e das empresas de desenvolvimento de software, e o modelo cascata
era tido como o mais completo e efetivo.
Essa situao se modificou assim que
surgiram os primeiros projetos geis,
logo aps o manifesto gil em 2001, e o
mundo do desenvolvimento de software
se dividiu entre os mais conservadores e
os simpatizantes do Scrum, XP e outras
metodologias geis.
No entanto, apesar dos casos de sucesso serem muitos, logo comearam a
aparecer os primeiros estudos de caso
que apresentavam problemas utilizando
tais metodologias e, principalmente, o
Para que serve?

O artigo tem a inteno de ser uma referncia
tanto como lies aprendidas de um estudo de
caso, que so consideradas valiosas no ambiente gil, assim como para abrir precedentes para
futuras discusses sobre os pontos levantados
como causas razes e suas solues propostas.
Acredita-se que muitas pessoas no meio gil ou
at mesmo fora dele possam contribuir para a
melhoria deste cenrio vislumbrado no estudo
citado.

O tema til para os profissionais de Engenharia
de Software em geral que planejam iniciar projetos utilizando metodologias geis ou at mesmo para aqueles que j as utilizam mas esto
enfrentando problemas com seus resultados.
13
Scrum. O Scrum, mesmo com inmeras vantagens em vrias

perspectivas, deve-se deixar claro, no a soluo perfeita para
todos os problemas da rea de Engenharia de Software, logo,
no a bala de prata dos projetos de desenvolvimento.
Neste artigo, pretende-se apresentar algumas lies aprendidas durante os ltimos anos na rea da qualidade de software
e tambm na liderana em equipes de desenvolvimento trabalhando com Scrum. A principal inteno de listar tais lies
ajudar outras equipes que possam vir a ter os mesmos (ou
semelhantes) problemas no decorrer do desenvolvimento de
aplicativos e sistemas.
Conceitos da Metodologia
Antes de apresentar os problemas decorrentes do mau uso
da metodologia citada, faz-se necessrio entender os conceitos
bsicos envolvidos no trabalho com projetos geis e a origem
das ideias que definem o SCRUM.
No ano de 2001, logo aps um encontro onde profissionais
e acadmicos da rea de desenvolvimento de software demonstraram seu descontentamento com a maneira com que os
projetos estavam sendo desenvolvidos dentro das empresas,
surgiu o Manifesto gil. Este manifesto foi o ponto de incio
para os principais conceitos das metodologias que viriam a
seguir. Ele foi traduzido para muitas lnguas, inclusive para o
portugus, e citado em vrios artigos da rea de Engenharia
de Software [1].
O Manifesto deu origem a metodologias como XP, Scrum
entre outros e junto com estes conceitos tambm nasceram os
papis envolvidos neste processo. Estes papis so:
Time: Quem realmente desenvolve e produz com qualidade.
Os membros do time devem ser comprometidos com o trabalho
e responsveis por atingir a meta de uma sprint (perodo de
desenvolvimento). Devem ser cada vez mais auto-gerenciveis
e multidisciplinares. Um time normalmente no ultrapassa o
nmero de nove pessoas e atua em um ambiente adequado
afim de facilitar a comunicao efetiva (um dos pontos mais
importantes em times geis);
Product Owner (PO): quem faz a ponte entre o cliente
e o fornecedor. Deve ter uma boa noo do produto e das
necessidades do cliente. Responsvel por manter o product
backlog sempre atualizado e priorizar o trabalho das sprints
que viro. Tambm so atividades do PO definir a viso do
projeto, metas e objetivos das sprints e repassar para o Scrum
Master o objetivo do produto;
Scrum Master (SM): um lder, mas acima de tudo, um

facilitador. O principal objetivo deste papel remover impedimentos, melhorar o dia-a-dia do time, auxiliar o PO na
construo e priorizao do Product Backlog, enfim, garantir
a aplicao do Scrum. Um bom Scrum Master deve ensinar
o cliente a maximizar o ROI (Retorno sobre Investimento) e
facilitar o desenrolar das reunies, to fundamentais neste
processo.
Outro ponto fundamental, alm dos papis, so as reunies
realizadas no decorrer de uma sprint (Figura 1). Os conceitos
que envolvem estas reunies e a sprint so apresentados a
seguir.
Sprint Planning: Define o incio de uma sprint com a realizao de tarefas como: identificao dos itens do Product
Backlog (requisitos) para a construo do Sprint Backlog que
ser atacado durante a sprint, estimativa em pontos dos itens
que sero desenvolvidos, definio da meta da sprint (commitment) e quebra dos itens (estrias) em pequenas tarefas;
Daily Meetings (Stand up Meetings): Reunio, como o
nome j diz, diria e feita geralmente em p. O costume de
faz-la em p foi uma maneira escolhida para garantir que s
os 15 minutos determinados seriam utilizados e que o time
no perderia o foco da reunio. O principal objetivo deste
pequeno encontro responder as perguntas base definidas
pela metodologia: O que eu fiz desde a ltima reunio?,
O que vou fazer at a prxima reunio? e Tenho algo que
esteja me impedindo?;
Retrospective Meeting: Mais uma reunio que tem por base
a resposta a trs perguntas. O time todo responde s perguntas: O que foi bom nesta sprint?; O que no foi bom nesta
sprint?; e O que devemos melhorar para a prxima sprint?.
Para esta ltima pergunta, deve-se escolher entre as respostas
(atravs de votao no time) quais os pontos que sero desenvolvidos e melhorados para a prxima sprint;
Review Meeting: Tem por objetivo apresentar o que foi
construdo durante a sprint pelo time. O time apresenta ao
PO o que foi desenvolvido at o presente ponto e o prprio
PO decide se o que foi apresentado atingiu ou no a meta da
sprint. Podem se fazer necessrios ajustes no backlog ou at
mesmo repriorizao de estrias a partir deste ponto.
Vale ressaltar aps a conceituao das reunies, que a atuao do Scrum Master, durante toda a sprint essencial para
o bom andamento do projeto. A participao do PO em todas
as reunies citadas acima tambm essencial, tanto que este
ponto ser salientado em breve neste mesmo artigo.
A raiz dos problemas (ou seriam as razes?)
Figura 1. Ciclo de Vida de uma Sprint
14
Engenharia de Software Magazine - Scrum: No funcionou para voc?
Depois de alguns anos trabalhando com a metodologia

Scrum, pode-se perceber alguns fatores que se repetem como
os principais viles e so, muitas vezes, responsveis pelo
insucesso de projetos e entregas. Feito um estudo inicial e um
levantamento destes fatores j citados, encontrou-se inclusive,
suas respectivas causas razes.
AgilidAdE
Antes de detalharmos os problemas e suas causas, devemos

ter a conscincia de que, como em toda e qualquer metodologia,
no desenvolver projetos seguindo suas principais caractersticas, vai sim acarretar problemas. Vale ter em mente que, nenhuma metodologia pode obter bons resultados se as equipes
no seguem seus valores e premissas corretamente.
Product Owner no envolvido

Visto qual o papel do Product Owner e sua importncia
para a metodologia proposta, pode-se analisar o quo grave
a falta da presena deste papel durante o decorrer da sprint.
Exemplos claros como blocks (impedimentos) no decorrer do
desenvolvimento podem atrasar e prejudicar muito um projeto.
Ter o PO durante todas as reunies dirias e principalmente
no momento da Planning, onde todas as dvidas (ou pelo
menos sua grande maioria) sobre as regras de negcio so
resolvidas, essencial.
Este problema de no envolvimento do PO com o time ou com
o projeto em discusso normalmente causado pela falta de
profissionais alocados para o papel: um mesmo PO dividido
entre vrios projetos e s vezes, este chega at confundir requisitos, times etc. Este fato, por exemplo, pode ser visto quando
h uma demora para solucionar blocks.
Um dos jeitos mais fceis para identificar quando um block
est afetando o bom andamento do sprint o prprio burndown chart. Pode-se perceber pela Figura 2, o desvio de trabalho
causado por um block entre os dias 23 e 25/11 dentro de um
projeto real. O time vinha trabalhando em uma velocidade
esperada e muito prxima da linha do ideal (segundo a legenda), mas teve um pequeno desvio neste perodo citado na
capacidade de realizar tarefas. Isto se deve ao fato de que este
mesmo time no possua em mos o contedo necessrio para
confeco das pginas acordadas nas estrias. Esta falta de
contedo, aqui sendo considerada o block, foi a principal causa
para tal desvio no meio da sprint e pde ser vista claramente
no grfico durante as reunies dirias.
E a segunda pergunta importante a fazer seria: como tratar
este problema? A melhor maneira de tentar minimizar os
efeitos deste problema dentro de um projeto seria o Scrum
Master trabalhar mais prximo ao Product Owner, no sentido de conseguir as informaes necessrias e desbloquear
o time. O papel do Scrum Master tambm ajudar o PO a
seguir os ritos do Scrum e manter o time sempre livre para
trabalhar sem blocks.
Falta de Requisito (Estrias mal escritas)

Outro problema srio que envolve diretamente o trabalho
do PO so os requisitos (estrias) mal escritos. O requisito,
ao contrrio do que a maioria das pessoas pensa, sim parte
fundamental no Scrum. As estrias servem como base para o
trabalho tanto durante o desenvolvimento, quanto para testes
de software e validao em homologao. Eles so feitos de
maneira mais resumida, mas no podem deixar de conter as
informaes necessrias para o bom entendimento da funcionalidade desejada e devem ser bons o suficiente para servirem
Figura 2. Burndown de projeto com block entre os dias 23 e 25/11
Figura 3. Exemplo de User Story
como base aos casos de testes (isto tambm ser discutido

mais adiante).
Falando de fatores que levam a insucesso, podemos considerar alguns fatores que levam estrias a serem mal escritas.
O primeiro fator uma descrio muito longa. A ideia de
descrever uma estria que os principais pontos possam ser
tratados como uma checklist para futuras discusses durante a planning meeting. Descrever com muita informao
e muitos detalhes pode levar o time a perda da colaborao
e a confiana de que tudo j est escrito (como acontecia em
antigas metodologias). O principal papel da estria levar o
time a estar sempre buscando a comunicao e a colaborao.
Se estes pontos no surgirem, perde-se o foco do Scrum.
O segundo fator confundir critrios de aceitao com casos
de teste. Critrios de aceitao so teis para responder perguntas do tipo Quando sabemos que a estria est pronta? e no
para perguntas do tipo Como testar e como saber se foi feito
da maneira correta?. Estas sim so questes para se pensar no
momento da criao dos casos de testes em si. Critrios devem
ser o suficiente para se saber o que deve ser feito do momento da
planning meeting em diante, mas no podem ser to detalhados
como um documento de Caso de Uso. O uso de ferramentas de
criao de estrias tambm pode ajudar nestes casos, principalmente nos primeiros projetos dos times com menor experincia
ou com Product Owners novos dentro dos times.
15
Seguir o exemplo da Figura 3, ainda a melhor sada para

evitar problemas de estrias mal escritas. O padro da figura
pode ser traduzido como: Eu, como <papel>, quero <funcionalidade>, para que <valor gerado ao cliente>. Este exemplo,
por estudos na rea e experincia pessoal, o modelo mais
utilizado em times geis no mercado at hoje. Abaixo um
exemplo de estria que segue o modelo da Figura 3.
Eu, como Product Owner, quero que a home page tenha
uma busca, para que todo usurio possa acessar o contedo
que deseja rapidamente.
Vrias estrias em desenvolvimento

Uma ideia muito utilizada nos processos geis o one piece
flow. A ttica de atacar todos juntos o mesmo problema, um a
um, um dos motivos da metodologia ser representada por uma
foto de um time de rugby (todo o time atacando junto e ao mesmo tempo exatamente a jogada Scrum). Na Figura 4 podemos
ver como este time se posiciona para resolver a jogada.
Se no estamos atacando as estrias uma por vez, este
pode ser um dos pontos de ateno para o no cumprimento
das metas finais. Tentar realizar todas as estrias de uma vez
um dos maiores problemas e pode ser visto em muitos times
na atualidade.
Pode-se perceber pela Figura 5, um exemplo claro de board do

time em que muitas estrias esto sendo executadas ao mesmo
tempo. Deve-se perguntar: existe mesmo a necessidade de ter
pessoas alocadas em tantas estrias ao mesmo tempo? Realmente no existe nenhuma tarefa que estas pessoas poderiam
estar atacando na primeira estria? Se o time multifuncional,
por que no dividir tarefas de teste com desenvolvedores,
tarefas de webdesign com testers, etc.? Responder todas estas
perguntas pode ser um bom ponto de partida para a soluo
do problema de no entregar estrias totalmente prontas (done)
ao final da sprint e ter vrias estrias iniciadas.
Estimativas Otimistas
Outro problema frequente que pode ser analisado durante
os projetos geis so as estimativas erradas. Quase sempre,
as estimativas so otimistas e os resultados so catastrficos.
Ser que somos mesmo capazes de fazer o trabalho proposto
em to pouco tempo? Esta uma das perguntas que o time
nunca se faz quando est em meio presso do Scrum Master e
principalmente, do Product Owner. claro que o cliente (neste
caso a figura do Product Owner) sempre ter o interesse em
ver o produto final pronto em menos tempo, mas o que temos
que ter em mente que esta pressa por chegar reta final no
faz com que o trabalho fique efetivamente pronto mais rpido,
e o pior, acarreta problemas ainda mais srios como defeitos
em produo e regresso no desenvolvimento do software. O
que deve ser relembrado durante a planning meeting o fato
de quem estima o esforo o time. Scrum Master e Product
Owner devem participar apenas para facilitar a reunio e
solucionar possveis dvidas, respectivamente.
Projeto Scrum vendido com prazo e/ou Escopo

fechados
Figura 4. Time de rugby (representao do SCRUM)
Figura 5. Board com vrias estrias sendo feitas ao mesmo tempo
16
Engenharia de Software Magazine - Scrum: No funcionou para voc?
Trabalhar com um product backlog que aos poucos vai se

transformando em Sprint Backlog e entregar produto com
valor ao cliente: este o formato que buscamos. Fica claro que
sempre que se vende projetos em Scrum, estes deveriam ser
vendidos por nmero de sprints, ou valor por sprint, e nunca
escopo fechado. Scrum no tem escopo fechado, incremental, e como tal, tem o direito de ser mutvel. Prazos e escopos
fechados so uma realidade do passado quando trata-se de
projetos geis e isso tem que ser respeitado para um bom
resultado dos projetos.
Logo, fica a pergunta, como vender projetos Scrum? Existem
vrias maneiras que vem sendo utilizadas, mas uma das mais
simples pode ser vista pela frmula/exemplo a seguir:
Consideremos um time fixo, com velocidade e tamanho de
sprints tambm definidos. O Product Backlog deste projeto
seria algo em torno de 1000 pontos. Se a equipe possui uma
velocidade de 50 pontos e as Sprints duram 2 semanas, como
seria feito o clculo de venda deste projeto? Dividimos o nmero de pontos do backlog (1000) pelo tamanho das sprints
(50) e vamos obter o nmero das semanas (40 semanas). A
este nmero de semanas, somamos uma sprint a cada 5, para
que possveis defeitos possam ser corrigidos e mudanas de
agilidade
Este o incio de uma das vrias propostas que esto sendo

feitas para minimizar os problemas que vem sendo encontrados na disciplina de testes em equipes geis.
Concluso
Este artigo apresentou um estudo sobre quais os principais
problemas encontrados em projetos utilizando a metodologia
Scrum.
Foi apresentada uma lista de problemas frequentes, juntamente com a conceituao bsica do que a metodologia e
como deveria ser tratada, para que todas as equipes tenham a
chance de pensar mais sobre o assunto e tentar melhorar em
futuros projetos.
Algumas ideias j foram apresentadas como possveis solues para a maioria das questes citadas, mas claro que seria
necessrio outro artigo para tratarmos das melhores solues
para cada um dos itens da lista. Assim como o estudo realizado
para verificar os pontos que afetavam a qualidade de entrega
em projetos Scrum, seriam necessrios outros estudos voltados
para todas as possveis solues. Precedentes para trabalhos
futuros j comeam a surgir e podero ser verificados em
artigos futuros.
Referncias
[1] BECK, K.; FOWLER, M. et al (2001).Manifesto for Agile Software Development.
http://www.agilemanifesto.org/.
[2] CRISPIN, L; GREGORY, J. (2009). Agile Testing: A Practical Guide for Testers and Agile Teams.
Addison-Wesley Professional. ISBN 0321534468.
[3] COHN, M. (2004). User Stories Applied for Agile Software Development. Addison-Wesley
Professional. ASIN B000SEFH1A.
[4]PEREIRA, R. (2008). 10 Benefits of One Piece Flow.
http://lssacademy.com/2008/03/27/10-benefits-of-one-piece-flow

Feedback
eu
17
sobre e
s
claro que o desenvolvimento gil chegou nos ltimos anos

com peso muito forte e que est tomando cada vez mais espao
nas salas em empresas no mundo todo. O que devemos nos
perguntar : Estamos TESTANDO de maneira gil?
Bem, se desenvolvemos de maneira incremental, por que
muitos ainda deixam os testes como a ltima atividade da
cadeia? Sem dvida, como resultado das pesquisas realizadas
nos ltimos anos, esta a principal causa de problemas nos
projetos onde o escopo alterado e a falta de qualidade na entrega foram ressaltados pelo cliente. Como justificar muitos
defeitos ao final do projeto? Simples dizer se notarmos que
os testes so deixados para o final da sprint da mesma forma
como j era feita no mtodo cascata.
Mudamos de metodologia, devemos mudar de paradigma.
Casos em que o time todo ajuda a testar e depois o especialista
em testes fica bloqueado at o final da sprint ou at mesmo
que o testador fica com todos os testes e, por falta de tempo,
defeitos acabam no surgindo, so frequentes. importante
ressaltar: temos que mudar o paradigma e comear a fazer testes tambm de maneira incremental. Deixamos este contedo
para um prximo artigo, mas esta questo pode ser utilizada
como o ponto inicial para que todos ns pensemos em como
resolver o problema.
De uma forma geral, pode-se explicar uma possvel soluo
para testes funcionando como uma espcie de gargalo no
trabalho do time, com a criao dos Testes geis ou Testes
Incrementais. O profissional da rea de testes pode e deve
comear a atuar desde o primeiro dia da sprint. Segue abaixo
uma lista com as atividades do dia a dia deste profissional,
fazendo com que todo o time esteja mais engajado na disciplina
de testes e que todo o trabalho seja cumprido de forma mais
eficaz e incremental:
Dia a dia de testes dentro do Scrum:
Dia 0: Antes mesmo da planning meeting, o analista de
testes, aproveitando-se de sua viso geral do produto, poder
revisar os requisitos (estrias), fazendo com que estas fiquem
mais claras e completas. Este trabalho pode ajudar tanto o
PO como o time todo, j que a planning ser muito mais proveitosa tendo um requisito mais completo e revisado por um
membro do time;
Dia 1: Incio do desenvolvimento. Enquanto nada est desenvolvido, criam-se os casos de testes baseados nos critrios de
aceitao das estrias. Este trabalho ser bem reduzido pelo
fato da reviso j ter sido feita anteriormente;
Dia 2 a Dia n: Durante todo o desenvolvimento, os testes
sero realizados em duas etapas: durante toda a sprint no
ambiente dos desenvolvedores (assim muitos dos defeitos
sero antecipados e a comunicao entre desenvolvedores e
D
s
Testes geis ou mtodo cascata?
testadores far com que a qualidade do produto fique ainda

mais elevada) e logo aps a finalizao do desenvolvimento, no
ambiente separado para testes (o teste funcional que as equipes
j fazem), onde todos os defeitos so realmente reportados, s
vezes at atravs de uma ferramenta;
Dia Final: Os testes se concentram em Testes de Regresso,
para que se possa confirmar a qualidade verificada anteriormente no produto e em Retestes, para assegurar que todos os
defeitos reportados foram corrigidos.
edio
ta
escopo possam ser mais bem tratadas. Neste caso, ficaramos

com 24 sprints. O clculo final seria o nmero final de sprints
(24) vezes o nmero de horas de todo o time.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Modelagem Temporal, de Implantao, de

Artefatos e de Componentes atravs da UML
Abordagem Prtica Parte 4
Esse artigo apresenta os Diagramas de Temporizao, que integram o grupo de diagramas da UML
destinados a modelar comportamento. Apresenta
tambm os Diagramas de Artefatos, Diagramas de
Componentes e Diagramas de Implantao, destinados documentao nas atividades de projeto de
desenvolvimento de sistemas.
Para que serve?
Geraldo Magela Dutra Gonalves

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

Sistemas, ambas pela Universidade Federal de
Juiz de Fora. tcnico em TI da Universidade
Federal de Juiz de Fora onde trabalha com
desenvolvimento de sistemas de informao e
informtica desde 1988. professor do Curso
Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Dom Andr
Arcoverde em Valena/RJ.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Conhecendo o diagrama de componentes.
18
A mesma viso dos artigos anteriores se aplica aqui.

Apresentar a notao de forma clara e objetiva, procurando destacar principalmente os elementos mais
teis nas situaes reais de modelagem. Procura-se
uma maneira prtica de aplicao dos recursos, sem
grandes nus para os cronogramas de projeto. Docu-
literatura tcnica, hoje vasta

e diferenciada, costuma ser
unnime em classificar os diagramas da UML (Unified Modeling
Language) em dois grandes grupos: Diagramas Estruturais e Diagramas Comportamentais. No h nada de errado
com essa classificao, mas existe uma
outra, com mais sub-nveis, que traduz
de forma mais completa a natureza de
cada diagrama, assim como tipifica mais
mentao desenvolvida de modo draft, no incio do

projeto, pode ser detalhada ao longo dele, paralelamente s atividades de implementao e testes.

Sistemas com estados tempo-dependentes de
forma contnua podem valer-se dos Diagramas de
Temporizao para especificao das transies
permitas e das restries de tempo associadas a essas transies. J sistemas com topologia no trivial
e/ou extensa, necessitam modelagem atravs dos
Diagramas de Implantao. Sistemas desenvolvidos
com orientao a componentes so cada vez mais
comuns e enfatizam a desejada capacidade de reuso, onde Diagramas de Componentes sero teis em
sistemas de porte mdio a grande.
acuradamente as abstraes capturadas

por cada um deles. Ento, classifica os
treze diagramas da UML em quatro
categorias:
Modelagem Estrutural: Diagramas de
Casos de Uso, Diagramas de Classes, Diagramas de Objetos, Diagramas de Pacotes
e Diagramas de Estrutura Composta.
Modelagem de Interaes: Diagramas de
Sequncia, Diagramas de Comunicao e
Diagramas de Viso Geral da Interao.
Engenharia de Software Magazine - Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML
proJEto
Modelagem Comportamental: Diagramas de Transio

de Estados, Diagramas de Atividades e Diagramas de
Temporizao.
Modelagem da Implantao: Diagramas de Artefatos, pouco
discutidos na literatura tcnica mas teis em sistemas de topologia no trivial, Diagramas de Componentes e Diagramas
de Implantao.
Nos dois ltimos artigos dessa srie foram abordados os
Diagramas de Transio de Estados e os Diagramas de Atividades. O Diagrama de Temporizao completa o grupo
de Modelagem Comportamental. Para encerrar essa srie de
artigos, so apresentados tambm os trs diagramas de modelagem da implantao, fase final da execuo de um projeto
de desenvolvimento de sistemas de informao.
Restries Temporais Discretas e Restries Temporais

Contnuas
Sistemas com estados ou processos tempo-dependentes podem ser classificados em duas categorias bem distintas. Num
primeiro grupo, situam-se os sistemas onde os intervalos de
tempo (time units) associados s transies entre estados so
percebidos de forma discreta. Isto significa que os intervalos
de tempo tm duraes uniformes e pr-fixadas, no admitindo
variaes. Como exemplo, no fluxo de controle de uma mquina
de lavar moderna, o tempo em que ela estar operando no estado lavando sempre igual, ou seja, tem um valor fixo finito e
pr-fixado, no admitindo variaes entre diferentes sesses de
execuo. Em termos objetivos, a mquina estar operando em
estado lavando por 5 minutos, por exemplo. Tais restries de
tempo, presentes nos cada vez mais comuns sistemas embarcados, podem ser modeladas pela rica sintaxe dos Diagramas de
Transio de Estados e pelos Diagramas de Atividades, como
foi demonstrado nos dois artigos anteriores.
Um segundo grupo, rene sistemas onde as transies entre
estados de um objeto ou de um grupo de objetos se daro
dentro de um intervalo de tempo no fixo, embora finito. Em
termos prticos, o sistema espera por um evento externo ou
interno que inicie uma transio dentro de um intervalo de
tempo que possui um mximo. O evento dever ocorrer entre
0 e 5 segundos, por exemplo. Se o intervalo de tempo se esgotar sem que o evento esperado ocorra, o sistema provocar
um evento interno que inicia uma transio alternativa. Para
modelar essa segunda categoria de sistemas, a UML disponibiliza o Diagrama de Temporizao.
representam estados e transies de um objeto ao longo de

um perodo de tempo.
Construindo um Diagrama de Temporizao

O perodo de tempo representado nos Diagramas de Temporizao chamado de linha de vida (lifeline) e pode ser divido em
perodos menores chamados unidades de tempo (time units).
Os estados e transies so representados dentro de um quadro com rtulo td (timing diagram). Um mesmo quadro pode
representar uma nica linha de vida (de um objeto) ou vrias
linhas de vida (de uma colaborao) incluindo interferncia de
uma linha de vida de um objeto sobre a linha de vida de outro.
Essa interferncia se d atravs da emisso de mensagens de
tempo. Isto ser tratado frente, neste artigo.
Diagramas de Temporizao podem ser apresentados em
duas notaes diferentes. Uma delas, mais simples, denominada linha de vida de valor, e uma mais completa, denominada
linha de vida de estado. Para exemplificar a construo de um
Diagrama de Temporizao, a Figura 1 apresenta um quadro
de temporizao (timing frame) para um equipamento de
caixa eletrnico utilizando a notao linha de vida de estados.
Nela aparecem 3 linhas de vida (lifelines), cada uma delas
representando a linha de vida de objetos controladores dos
componentes do equipamento.
Cada linha de vida deve exibir os estados pelos quais o
objeto em questo transita, para que o grfico de tempo seja
apresentado como uma evoluo entre eles. Um leitor de cartes magnticos e um mecanismo de contagem e entrega de
cdulas, so equipamentos fsicos controlados por objetos do
software de auto-atendimento bancrio. Tais objetos vo emitir
sinais que sero recebidos e processados pelos equipamentos,
ativando ou desativando suas funes. Para executar uma
sesso de uso, o software de controle do caixa eletrnico vai
instanciar objetos de classes controladoras e ativar um fluxo de
controle condizente com a escolha do usurio a partir de um
menu de opes. Para realizar um saque, por exemplo, o controlador transita, em linhas gerais, entre os seguintes estados:
disponvel lendoCarto esperandoSenha processando
contandoCdulas disponvel. Alm disso, o leitor de cartes e
o mecanismo de contagem de cdulas estaro sempre em uma
de duas condies possveis: disponvel/operando.
Para representar a evoluo da linha de vida ao longo do
tempo, deve ser introduzida uma escala de tempo que divide
Diagramas de Temporizao
Diagramas de Estados representam os estados possveis
de apenas um objeto e as transies permitidas entre eles.
Diagramas de Atividades so um caso especial de Diagramas
de Estados onde os estados so aes/atividades e podem
representar a participao de diversos objetos. Diagramas de
Temporizao so, tambm, uma variao de diagramas de
estados e de transies entre eles, mas onde tais transies
esto associadas a restries de tempo. Em ltima anlise,
Figura 1. Timing Frame para um caixa eletrnico
19
um determinado perodo em unidades de tempo (time units).

A Figura 2 apresenta essa escala, bem como os estados pelos
quais transitam os trs elementos do equipamento.
O grfico de tempo ento montado horizontalmente
sobre as linhas de vida, com as transies posicionadas nas
unidades de tempo. A linha de vida principal, do software
controlador do equipamento (realizando um caso de uso),
vai estar, a princpio, sincronizada com as linhas de vida das
unidades auxiliares apenas pela superposio coincidente
dos momentos em que acontecem, mas essa representao
pode ser melhorada com a introduo de mensagens de
tempo, como ser demonstrado.
A Figura 3 apresenta os grficos representativos da evoluo pelos estados dos trs componentes do caixa. As operaes do leitor de cartes e do mecanismo de contagem de
cdulas esto sincronizadas com suas referncias feitas na
linha de vida do software controlador do caixa eletrnico.
Para enriquecer a representao de sincronia e dependncia entre as trs linhas de vida, pode-se lanar mo
do recurso de incluir mensagens de tempo, como referido
anteriormente. Uma mensagem de tempo deixa uma linha
de vida e chega a outra no mesmo diagrama, enfatizando
a dependncia entre elas. Para fixar em que momentos isso
acontece, cada unidade de tempo deve ser quantificada
e nomeada. Os lapsos de tempo em que as unidades de
tempo representam no so necessariamente iguais, isto
, cada estado permanece ativo por tempos diferentes. A
Figura 4 apresenta mensagens de tempo emitidas da linha
de vida do controlador principal para os controladores dos
equipamentos auxiliares. Apenas os marcos importantes
Figura 2. Estados/Condies para cada linha de vida
20
do tempo foram nomeados, ou seja, apenas aqueles em que

se do as transies de estados.
Finalizando o Diagrama de Temporizao

Um ltimo elemento nessa forma de representao de Diagramas de Temporizao so as restries de tempo. Conforme
referido anteriormente, essa representao dos Diagramas de
Temporizao denominada linha de vida de estados. Ela apresenta, claramente, estados e transies entre eles, assim como
as restries temporais aplicadas s transies. A Figura 5
apresenta um diagrama de temporizao completo, com as
restries de temporizao aplicadas.
Comparando Representaes
Uma segunda maneira de representar Diagramas de Temporizao denominada linha de vida de valor. Mais adequada
quando se est lidando com uma grande quantidade de estados e transies, ela mais compacta e concisa, embora exiba
menos informaes do que o formato anterior. A Figura 6
mostra o formato de linha de vida de valor para o caixa eletrnico apresentado. Nela, cada estado representado por
um hexgono e as transies por cruzamentos das linhas de
suas arestas. A escala de tempo pode ser apresentada como
no formato anterior ou pode ser omitida, enquanto restries
de tempo e durao aparecem entre chaves.
Diagramas da Fase de Implantao

Num processo de desenvolvimento de sistemas incremental
e iterativo (do qual o Rational Unified Process RUP uma
instncia), quatro grandes fases de desenvolvimento so atravessadas por pelo menos 6 atividades diferentes: elicitao
Figura 3. Grficos de temporizao das trs linhas de vida sincronizadas
proJEto
Figura 4. Mensagens de tempo emitidas entre linhas de vida
de requisitos, anlise de requisitos, projeto, implementao,

testes e implantao. Nesse tipo de processo de desenvolvimento aliam-se as melhores qualidades de duas aproximaes
diferentes para o desenvolvimento de sistemas de software robustos. A primeira delas a adoo das ferramentas e tcnicas
de modelagem, que fornecem documentao de alto nvel e de
suporte efetivo implementao. A segunda busca a melhor
qualidade dos processos geis, rapidez no desenvolvimento
sem sacrifcio da qualidade.
O processo incremental alia o desenvolvimento de modelos
estveis e robustos da anlise orientada a objetos rapidez
de desenvolvimento conseguida com a execuo de diversas
iteraes durante a fase de construo, produzindo a cada
ciclo concludo, um incremento que passa a integrar a parte
do sistema que j est em operao. Assim, por exemplo, duas
semanas aps o incio da fase de construo (uma durao
aproximada de uma iterao), j possvel implantar uma
parte do sistema e torn-la operacional.
Para apoiar e documentar essa atividade dos ciclos de desenvolvimento, a UML disponibiliza trs tipos diferentes de diagramas: Diagramas de Artefatos, Diagramas de Componentes e
os Diagramas de Implantao propriamente ditos. Embora no
sejam citados e explorados na literatura tcnica e nem faam
parte das listas oficiais de diagramas da UML, Diagramas de
Artefatos so claramente referidos por Booch, Rumbaugh e Jacobson em sua obra UML Guia do Usurio, e podem ser muito
teis para documentao e localizao de artefatos em sistemas
de mdio a grandes portes, como ser demonstrado.
Figura 5. Restries de tempo associadas s transies
Figura 6. Formato de linha de vida de valor para o caixa eletrnico
Artefatos e Diagramas de Artefatos

Enquanto modela as diversas vises de um sistema, o desenvolvedor constri modelos lgicos, compostos de elementos
igualmente lgicos. Assim a natureza de classes, interfaces,
suas associaes, casos de uso e outros diversos componentes
da linguagem de modelagem. Em determinado momento do
processo, estes elementos lgicos tero de ser manifestados
por componentes fsicos, reais, que os implementem e permitam
suas operaes. Tais elementos fsicos so chamados artefatos.
Artefatos so elementos fsicos, suportados por uma plataforma de implementao. Um artefato pode ser entendido como
um pacote fsico contendo elementos lgicos tais como classes,
interfaces e colaboraes. A Figura 7 mostra a notao UML
2 para um artefato.
A ideia de artefato est fortemente ligada definio de
arquivos reais, embora seja mais abrangente do que isso. Mas
de uma forma prtica, pode-se considerar que artefatos so
21
simplesmente arquivos individuais que suportam os elementos lgicos e seus relacionamentos. Assim, existem artefatos
resultantes do trabalho de desenvolvimento, ou seja, o produto
do desenvolvimento. So eles, arquivos fonte e arquivos de dados a partir dos quais sero gerados artefatos de implantao.
Estes, por sua vez, incluem os arquivos executveis, arquivos
de configurao, arquivos de inicializao e bibliotecas, entre
outros. Esse segundo conjunto configura um sistema executvel completo, que suporta totalmente as especificaes lgicas
contidas no primeiro conjunto. Um terceiro e ltimo conjunto
de artefatos inclui aqueles que s tm existncia em tempo
de execuo de um sistema. Podem denominar-se transientes
ou efmeros.
Tais tipos de artefatos podem ser reconhecidos pela colocao
de esteretipos tais como: <<executable>>, um arquivo com
cdigo executvel, <<library>>, uma biblioteca convencional
ou dinmica, <<file>>, um arquivo contento cdigo fonte, ou
<<document>>, um arquivo em formato texto ou outro formato
que contenha uma tabela, um script, entre outros. Na representao de artefatos, o desenvolvedor tem liberdade para criar
e usar esteretipos especficos para identificar artefatos incomuns ou muito particulares de um determinado sistema.
Figura 7. Um artefato
A combinao desses tipos de artefatos permite modelar

trs aspectos importantes de implantao de sistemas: a modelagem de executveis e bibliotecas, a modelagem de tabelas,
arquivos e documentos, e a modelagem de cdigo fonte.
Diagramas de Artefatos admitem dois tipos de relacionamento entre artefatos: uma dependncia, quando um artefato
utiliza servios oferecidos por outros, ou uma manifestao,
quando um artefato uma manifestao fsica de um elemento
lgico qualquer.
Diagramas de Artefatos de Cdigo Fonte

O cdigo fonte que implementa as funcionalidades de um
sistema geralmente desenvolvido em uma srie de artefatos
que so ento relacionados. Tais relacionamentos podem
originar-se primariamente das especificaes lgicas dos relacionamentos entre trechos de cdigo, mas tambm podem
refletir dependncias de compilao, ou seja, diretivas obrigatrias para obteno do cdigo executvel. Em outras palavras,
a simples ausncia de uma biblioteca de classes pode tornar
impossvel a compilao de um mdulo, de um componente
ou de todo um sub-sistema.
A modelagem criteriosa dos artefatos produto do desenvolvimento oferece uma viso privilegiada dessas dependncias.
A Figura 8 um exemplo desse tipo de modelagem aplicado
ao caixa eletrnico.
A Figura 8 representa as dependncias entre artefatos. Para
gerar o artefato software.class, que um arquivo executvel
(interpretvel no caso do Java). O diagrama mostra tambm
claramente que, para executar, software.class faz uso de uma
biblioteca dinmica, biblioteca.dll, assim como depende de
uma conexo a um sistema gerenciador de banco de dados,
do qual usa dados de uma tabela denominada nomes.tbl.
Para sistemas complexos de software, esta representao pode
assumir importncia crtica.
Diagramas de Artefatos de Cdigo Executvel

Esse diagrama pode ser particularmente til em sistemas
com diversos mdulos executveis que utilizam bibliotecas
dinmicas. Os elementos que tm relao direta so representados, assim como seus relacionamentos, que neste caso so
todos de dependncia, ou seja, um artefato utilizando servios
oferecidos por outros. A Figura 9 apresenta um exemplo de
modelagem onde tambm esto modeladas as dependncias
existentes em relao a um arquivo de inicializao assim como
de um arquivo de ajuda on-line.
Diagramas de Artefatos de Arquivos Auxiliares
Figura 8. Diagrama de Artefatos
22
Nem todos os artefatos que integram o conjunto de artefatos

do sistema so arquivos fonte, executveis ou bibliotecas. Uma
tabela integrante de um banco de dados relacional, por exemplo,
tambm um artefato. A rigor, um sistema gerenciador de banco
de dados um componente formado de dezenas de artefatos.
Numa outra situao, um arquivo HTML pode ser usado como
fonte para implementao de ajuda on-line para um sistema de
acesso via WEB. claro que modelar todo um banco de dados
proJEto
utilizando Diagramas de Artefatos uma tarefa desnecessria,

j que existe toda uma notao apropriada para essa finalidade,
mas para destacar a interao entre um elemento executvel e
uma das tabelas de um SGBD, os Diagramas de Artefatos so
de valia e ajuda inestimvel. A Figura 10 apresenta um exemplo
desse tipo de modelagem.
Existem diversas consideraes importantes sobre o emprego
de Diagramas de Artefatos, especificamente falando, assim
como sobre os inter-relacionamentos entre estes e os Diagramas
de Componentes e de Implantao tratados frente.
Em primeiro lugar, os trs tipos de Diagramas de Artefatos
no so estanques, isto , eles podem ser mesclados de forma
livre, mostrando relacionamentos entre artefatos fonte, executveis e auxiliares e representando dependncias, manifestaes e implantaes de forma livre. Isso gera uma riqueza
de representao que torna tais diagramas muito teis em
gerao de documentao de apoio manuteno. Diagramas
de Artefatos construdos assim podem exibir tags com valores
atribudos que expressam uma srie til de atributos associados aos artefatos, tais como verses, modificaes, atualizaes
e outros elementos.
Uma segunda considerao importantssima sobre a possibilidade, e s vezes necessidade, de interseo entre os trs
diagramas de implantao. Artefatos podem estar contidos
dentro de componentes de software (tratados adiante), e estes
podem estar contidos dentro de pacotes, dentro de outros componentes ou mesmo dentro de outros artefatos. Componentes de
software, assim como artefatos isolados, podem estar alocados
a ns de processamento (elementos dos diagramas de implantao apresentados frente). Elementos lgicos da linguagem de
modelagem podem ser manifestados pelos artefatos j citados,
enquanto artefatos podem ser implantados em ns especficos
de processamento. Quando se desenvolvem diagramas que associam artefatos, componentes, pacotes e ns de processamento
(tratados adiante), os relacionamentos entre artefatos e os demais
elementos, alm da dependncia, podem ser de outros dois tipos:
implantao (deployment) ou manifestao (manifestation).
Uma implantao indica um n fsico onde um artefato ser
localizado. Um relacionamento de manifestao representa uma
instanciao fsica de um artefato qualquer.
Componentes e Diagramas de Componentes

No cerne da ideia de componentes est a reutilizao. Em linhas
gerais, o desenvolvimento de software baseado em componentes
inspira-se na mesma atividade desenvolvida com sucesso pela
engenharia de hardware e eletrnica em geral, que j projeta com
sucesso, baseada em componentes, com mais de meio sculo de
vantagem em relao ao desenvolvimento de software. A idia
no nova e nem engatinha. J existem padres de indstria
reais e em desenvolvimento. Como elemento fundamental para
construo de tais sistemas situa-se o componente.
Um componente de software um elemento que integra um
determinado sistema sem ser exclusivo deste. Em outras palavras, um mesmo componente pode estar presente em mais
de um sistema de naturezas diferentes e pode ser tambm
substitudo a qualquer momento sem prejuzo para o sistema.

A atuao de um componente dentro de um determinado sistema se d atravs de interfaces fornecidas pelo componente ou
requeridas pelo mesmo, atravs das quais so fornecidos servios daquele componente ou requeridos servios fornecidos por
outros componentes. Interfaces se conectam ao componente
atravs de portas, definidas em sua estrutura encapsulada. Um
componente , assim, totalmente encapsulado, s disponibilizando suas funcionalidades atravs de portas especficas que
comportam interfaces.
Componentes no so elementos atmicos; eles possuem
uma estrutura interna. Sua composio pode ser de classes
internas ou de outros componentes, assim como de pacotes.
Os elementos da estrutura interna de um componente devem,
naturalmente, exibir associaes. A forma mais corriqueira de
representar estas associaes atravs de dependncias, mas o
caminho mais utilizado para isso a utilizao das interfaces.
A Figura 11 apresenta a representao de um componente na
notao da UML 2. Est representada, alm do componente,
uma interface requerida, atravs da qual esse componente
poder se conectar ao sistema. O contexto o mesmo usado
anteriormente. O componente mostrado utilizando um esteretipo que pode ser omitido, j que o smbolo exclusivo
para componentes.
23
Desenvolvendo um Diagrama de Componentes

Para desenvolver um diagrama de componentes, a primeira
atividade determinar que componentes compem o sistema. Para o contexto do caixa eletrnico, trs componentes
podem ser listados: o conjunto de classes que implementam
as funcionalidades do equipamento, o conjunto de classes
que controlam o leitor de cartes e o conjunto de classes que
controlam o mecanismo de contagem e liberao de cdulas,
embora componentes nem sempre sejam apenas conjuntos
de classes. Os equipamentos sero acessados por interfaces
requeridas, que sero realizadas pelos controladores (mtodos
de classes controladoras) das funcionalidades (casos de uso)
do equipamento.
O componente principal, o software controlador do equipamento, exibe uma estrutura interna que pode ser representada
no diagrama. Essa estrutura interna inclui classes de fronteira
e controladoras para cada funcionalidade, alm de acesso a
mecanismo de persistncia de objetos. Em ltima anlise,
esse importante componente contm o sistema de controle
propriamente dito.
As interfaces requeridas pelos equipamentos perifricos so
todas fornecidas pelo componente principal, atravs de portas dedicadas que preservam o encapsulamento de todos os
componentes. A Figura 12 apresenta um Diagrama de Componentes que modela a arquitetura baseada em componentes do
sistema. O diagrama foi desenvolvido dentro de um frame com
rtulo cmp (componente). A estrutura interna do componente
Figura 11. Um componente com interface requerida
Figura 12. Diagrama de Componentes para o caixa eletrnico
24
principal no foi completamente mostrada, pois isso tornaria

o diagrama visualmente confuso.
Diagramas de Implantao
Sistemas simples, destinados execuo em estaes standalone, tm todos os seus artefatos residentes nessa nica estao.
Mas estes sistemas praticamente no existem mais. Sistemas
modernos de processamento de informaes so baseados
em acesso via web e residem em ambientes de processamento
distribudo, com seus artefatos residindo em diferentes pontos
de uma rede de processamento. Estes pontos so denominados ns de processamento e sua localizao geogrfica j
no necessita fronteiras. Uma rede pode estar, e na realidade
frequentemente est, localizada em diversas locaes, s vezes
em pases diferentes.
Em casos menos extremos, sistemas de mdio a grande
portes podem conter-se em um nico site, mas ainda assim
espalhando-se por diversos servidores diferentes. Para documentar a rede de ns de processamento, assim como determinar a localizao real (fsica) dos diversos artefatos que compe
o sistema, a UML disponibiliza o Diagrama de Implantao
que, entre outras finalidades, representa as localizaes fsicas (ns) e seu contedo (artefatos), exibindo ainda uma srie
de atributos atravs de tags. Um n de processamento uma
localizao fsica que possui alguma quantidade de memria
e freqentemente capacidade de processamento. A notao da
UML para representar um n aparece na Figura 13.
Embora um n possa ser representado com apenas o nome,
ele admite o uso de adornos, como tags com valores atribudos
e compartimentos especiais contendo listas de nomes de artefatos residentes naquele n. Na representao da topologia de
um ambiente de processamento surgiro ns com capacidade
de processamento e ns que simplesmente so dispositivos
de armazenamento. Para distinguir entre esses tipos de ns
pode-se utilizar os esteretipos <<device>> para dispositivos,
e <<executionEnvironment>> para processadores.
As conexes entre ns so normalmente representaes de
ligaes fsicas entre os componentes de uma rede, j que os ns
representam exatamente estes componentes. Para obter um diagrama legvel e til no convm representar todos os artefatos
e sim aqueles considerados fundamentais para compreenso
do funcionamento do sistema. Assim, em vez de representar
todas as tabelas de um banco de dados, pode-se represent-lo
como um pacote ou como um conjunto de componentes. Para
documentar de maneira clara e til, o desenvolvedor pode
lanar mo de todos os elementos dos diagramas de artefatos,
de componentes, de pacotes e de implantao, combinando-os
vontade, para gerar documentao rica e til.
A Figura 14 representa a topologia para o sistema do caixa
eletrnico, as conexes (inclusive as remotas) entre os diversos
ns, e as residncias dos principais artefatos do sistema. SiteBanco representa uma localizao fsica que executa programas
de acesso s bases de dados. O n CaixaEletrnico conecta-se
remotamente ao SiteBanco e estabelece uma colaborao que
desempenhar a funcionalidade requisitada.
proJEto
Dois programas executando no site, exibem um relacionamento com este chamado implantao (deploy). Isto significa
que o n SiteBanco quem implanta os artefatos indicados.
Os programas que rodam nos servidores de aplicao no site
do banco exibem uma dependncia em relao a um pacote
que representa todos os artefatos integrantes de um sistema
gerenciador de banco de dados (SGBD). O n CaixaEletrnico
conecta-se com dois ns auxiliares que esto rotulados como
dispositivos perifricos ou devices. Como os trs ns esto
geograficamente localizados num espao nico, essa conexo
feita por cabos multivias. Estes ns no possuem capacidade
de processamento e eventualmente nem mesmo memria. So
dispositivos auxiliares controlados por drivers. Um ou mais
componentes RotinaAcesso podem ser instanciados durante
uma sesso de execuo do software. Isto est evidenciado atravs de um relacionamento de agregao entre o componente
e o n. Finalmente, o artefato principal, software.class, exibe
um relacionamento com o n CaixaEletrnico denominado
manifestao. Isso significa que o artefato se manifesta atravs
do elemento fsico representado pelo n.
Figura 13. Representao de um n de processamento
Concluso
Figura 14. Diagrama de Implantao
menos complexos) sistemas embarcados, ou seja, programas

controladores de dispositivos e aparelhos eletrnicos especficos. Alguns sistemas comerciais e/ou administrativos
podem apresentar processos tempo-dependentes, mas estas
dependncias podem ser modeladas nos diagramas de estado
e atividades.
Referncias Bibliogrficas
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2007. 370p.
BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usurio. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2006. 474p.
FOWLER, Martin. UML essencial: um breve guia para a linguagem padro de modelagem de
objetos. 3.ed., Porto Alegre: Bookman, 2006. 160p.

Feedback
eu
edio
ta
D
s
BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML
2.2.ed. Rio de Janeiro: Campus-Elsevier, 2006. 496p.
25
sobre e
s
Os diagramas UML mais representativos e largamente

empregados so, sem dvida, os diagramas de classes, de
sequncia, de estados e de atividades. Embora todos os outros
sejam de igual valia para a equipe de desenvolvimento, um
projeto pode sobreviver sem eles, o que acaba por desestimular seu desenvolvimento. Isso um antigo problema vestindo
roupa nova. Dispensar tempo com documentao que pode
ser considerada secundria sempre foi uma atividade preterida e/ou abandonada. Para mudar essa realidade, que uma
questo de cultura dos desenvolvedores, a UML disponibiliza
todo um conjunto de modelos com notaes apropriadas para
modelagem dos mais variados aspectos inerentes ao desenvolvimento de sistemas.
Diagramas empregados na fase de implantao de sistemas compreendem Diagramas de Artefatos, Diagramas de
Componentes e Diagramas de Implantao. Embora pouco
empregados, so de grande importncia para modelagem de
sistemas de mdia a alta complexidade e que executam em
ambientes de processamento distribudos. Seu emprego passa
a ser quase obrigatrio quando tais ambientes so extensos e
complexos.
Diagramas de Artefatos de cdigo fonte e executvel passam
a ser uma espcie de ndice para localizao de artefatos em
uma extensa rede de ns de processamento. Recursos como
quantidade de memria e capacidade de processamento podem
ser alocados e controlados mediante seu emprego e atualizao
constante. J os Diagramas de Componentes so uma obrigatoriedade para instalaes que desenvolvem com essa filosofia. A
representao dos componentes e seus relacionamentos torna
mais amena a difcil tarefa de manuteno.
Por fim, diagramas de temporizao encontram seu melhor
emprego em especificaes de sistemas de controle de ambientes, geralmente de tempo real e em pequenos (mas no
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 5

Implementando o padro Strategy com Substituir lgica condicional por
Strategy
U
Jacimar Fernandes Tavares
jacimar.tavares@studentpartners.com.br
Aluno do Curso de Bacharelado em Cincia da Computao da FAGOC - Faculdade

Governador Ozanam Coelho, Microsoft
Student Partners.

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

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora, da Faculdade Metodista
Granbery e da Universidade Severino Sombra, professor do Curso de Tecnologia em
Anlise e Desenvolvimento de Sistemas da
Fundao Educacional D. Andr Arcoverde.
Analista de Sistemas da Prefeitura de Juiz
de Fora, Editor da Engenharia de Software
Magazine.
26
ma prtica comum a vrios desenvolvedores, principalmente

os que no possuem conhecimento sobre padres de projeto, a de
criar extensos mtodos com complexa
lgica de seleo, com o objetivo de fornecer todos os caminhos para determinados comportamentos em um s lugar.
Tal prtica funcional e pode ser realizada em tempo hbil, mas outras questes
devem ser levadas em considerao.
Mtodos com extensa lgica de seleo
possuem complexidade ciclomtica elevada, o que pode vir a ser um problema
quando se pensa em manutenes futuras.
A refatorao para o padro Strategy fornece um mecanismo mais sofisticado que um
mtodo com extensa lgica condicional, se
bem aplicada. Contudo, refatorar para o
padro Strategy no uma tarefa simples,
visto que h vrios conceitos e prticas
envolvidas neste processo.
A partir deste momento sero apresentados conceitos e prticas que esto diretamente ligados ao processo de refatorar
para o padro Strategy com a utilizao
da tcnica de refatorao para padres
Engenharia de Software Magazine - Refatorao para Padres Parte 5
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode us-lo para
melhorar o cdigo-fonte de suas aplicaes.
Para que serve?

Para prover conhecimento ao desenvolvedor sobre
refatorao para padres e demonstrar atravs de
um exemplo prtico a aplicao das tcnicas de refatorao para padres Substituir Lgica condicional por
Strategy.

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.
Substituir Lgica condicional por Strategy, uma viso geral do que o padro
de projeto Strategy, bem como as tcnicas de refatorao Mover Mtodo (ver
Nota do DevMan1), Introduzir Objeto
Parmetro, Substituir Condicional por
Polimorfismo e Substituir Enumerao
por Subclasse. Ao final ser abordada
a tcnica de refatorao para padres
dESEnvolviM Ento
Substituir Lgica condicional por Strategy, onde um exemplo

prtico de sua utilizao ser apresentado.
O padro de projeto Strategy
Nome do padro de projeto: Strategy. Pertencente ao conjunto dos padres de projeto classificados como Padres
Comportamentais.
O problema: Em alguns momentos possvel encontrar aplicaes com muito cdigo escrito para determinar como ser a
tomada de aes mediante algumas solicitaes dos clientes da
aplicao. O padro de projeto Strategy pode atuar neste sentido,
uma vez que sua implementao possibilita a definio de uma
estrutura de classes responsveis por implementar diferentes
algoritmos que sero utilizados para definir novas estratgias
para um conjunto de objetos de uma classe, por exemplo.
As consequncias: Com isso, consegue-se utilizar diferentes
algoritmos de estratgia em tempo de execuo, alm de permitir a definio de algumas variaes desses algoritmos na
estrutura de classes que compem a estratgia.
A refatorao Introduzir Objeto Parmetro
Esta refatorao pertencente ao grupo de refatoraes classificadas como Tornando as Chamadas de Mtodos Mais Simples.
Nome da refatorao: Introduzir Objeto Parmetro.
Resumo: Algumas classes possuem vrios mtodos que recebem vrios parmetros em comum. Neste contexto, cria-se
um objeto que possua os atributos mais usados pelos mtodos
e modifique-os para receberem um objeto, no lugar dos vrios
dados que recebiam como parmetros.
Motivao: Introduzindo objetos no lugar de vrios dados
como parmetro, pode-se reduzir, e muito, o cdigo duplicado, alm de juntar os dados em um s lugar. Pode-se ainda
reduzir significativamente o nmero de parmetros passados
ao mtodo.
Mecnica:
Cria-se a classe que ter atributos que substituiro os parmetros passados aos mtodos.
Declare nela os atributos que deseja substituir pelos
parmetros.
Modifique os mtodos para receberem como parmetro um
objeto da classe criada, apagando os antigos parmetros.
Execute os testes.
Exemplo: O exemplo a seguir vem de um sistema comercial
do qual so extradas vrias informaes, onde vrios mtodos
so invocados para obt-las. A Listagem 1 mostra o cdigo da
classe Departamento.
Ao analisar o cdigo da Listagem 1 percebe-se que h vrios
pontos com cdigo omitido. Isso necessrio para que o foco
fique somente na declarao dos mtodos e no no corpo do
mtodo, que para esta refatorao no importante.
Os mtodos declarados possuem algo em comum: a lista de
parmetros idntica entre eles. Primeiramente cria-se a classe
que ter atributos equivalentes aos parmetros utilizados pelos
mtodos, conforme a Listagem 2.
Nota do DevMan 1
Refatorao Mover Mtodo
A tcnica de refatorao Mover Mtodo foi apresentada no artigo da edio 29 da
Engenharia de Software Magazine.
listagem 1 Classe Departamento.
01. public class Funcionarios

02. {
03. ...
04. public Decimal RecuperaTotalSalarios(String nome, DateTime inicio,
DateTime final)
05. {
06.
...
07.
return total;
08. }
09. public Boolean DeletarRegistroSalarial(String nome, DateTime
inicio, DateTime final)
10. {
11.
...
12.
return statusAcao;
13. }
14. public Decimal RecuperaValorTotalComissao(String nome,
DateTime inicio, DateTime final)
15. {
16. ...
17. return comissao;
18. }
19. ...
20. }
listagem 2 Classe Dados.
01. public class Dados

02. {
03. private String nome;
04. private DateTime dataInicio;
05. private DateTime dataFinal;
06. public String Nome
07. {
08.
get { return nome; }
09.
set { nome = value; }
10. }
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
{
}
{
}
public DateTime DataInicio

get { return dataInicio; }
set { dataInicio = value; }
public DateTime DataFinal
get { return dataFinal; }
set { dataFinal = value; }
public Dados(String nome, DateTime dataInicial, DateTime
dataFinal)
22. {
23.
this.Nome = nome;
24.
this.DataInicio = dataInicial;
25.
this.DataFinal = dataFinal;
26. }
27. }
27
Listagem 3 Classe Funcionarios refatorada.
01. public class Funcionarios

02. {
03. public Funcionarios()
04. {
05. }
06. public Decimal RecuperaTotalSalarios(Dados dadosNecessarios)
07. {
08. Decimal total = 0;
09. return total;
10. }
11. public Boolean DeletarRegistroSalarial(Dados dadosNecessarios)
12. {
13. Boolean statusAcao = true;
14. return statusAcao;
15. }
16. public Decimal RecuperaValorTotalComissao(Dados dadosNecessarios)
17. {
18. Decimal comissao = 0.0m;
19. return comissao;
20. }
21. }
Listagem 4 Classe Pessoa.
01. public class Pessoa

02. {
03. private Funcionario funcionario;
04. private String RecuperaTipoFuncionario()
05. {
06. return funcionario.RecuperaTipoFuncionario();
07. }
08. public Decimal RecuperaValorSalario()
09. {
10. switch (RecuperaTipoFuncionario())
11. {
12.
case Mensalista:
13.
return funcionario.RecuperaSalario();
14.
case Diarista:
15.
16.
default:
17.
return 0;
18. }
19. }
20. }
Listagem 5 Superclasse da hierarquia: classe Funcionario.
01. public abstract class Funcionario

02. {
03. public abstract String RecuperaTipoFuncionario();
04. public abstract Decimal RecuperaSalario();
05. }
Listagem 6 Subclasse da hierarquia: classe Mensalista.
01. public class Mensalista: Funcionario

02. {
03. ...
04. public override String RecuperaTipoFuncionario()
05. {
06. return Mensalista;
07. }
08. public override decimal RecuperaSalario()
09. {
10.
return salario;
11. }
12. }
28
O mtodo construtor da classe Dados, Listagem 2, fica responsvel por instanciar o objeto Dados. Os mtodos da classe
Funcionarios, Listagem 1, depois de ter seus parmetros substitudos por um objeto ficam como mostra a Listagem 3.
Aparentemente o resultado da troca de parametros por um
objeto pode no paracer to satisfatrio mas, se aplicado em
classes que possuem vrios mtodos com uma grande lista
de parametros em comum, pode reduzir consideravelmente
o cdigo duplicado.
A refatorao Substit uir comando Condicional por
Polimorfismo.
Esta refatorao pertencente ao grupo de refatoraes classificadas como Simplificando Expresses Condicionais.
Nome da refatorao: Substituir Comando Condicional por
Polimorfismo.
Resumo: Substitui comandos condicionais que selecionam
aes a serem executadas por mtodos polimrficos.
Motivao: Usada para remover expresses condicionais
para um determinado objetivo que se repetem em vrios trechos de cdigo. Com isso, simplifica-se o projeto de cdigo e
removem-se duplicaes.
Mecnica:
Verifique o mtodo que contenha uma sentena switch ou else
ifs. Aplica-se a refatorao Extrair Mtodo para que a expresso
condicional fique sozinha no mtodo, caso necessrio.
Usa-se Mover Mtodo para levar o mtodo que contem a
sentena switch para a superclasse.
Cria-se um mtodo em cada uma das subclasses e cola-se
nele o trecho de cdigo da lgica condicional que se refere
subclasse em questo. Caso a subclasse j possua um mtodo
que possa ser usado para substituir o trecho da lgica condicional, desconsidera-se este passo.
Deleta-se o cdigo da lgica condicional que acabou de
copiar .
Executa-se todos os passos at remover toda lgica
condicional.
Exemplo: A Listagem 4 apresenta a classe Pessoa, que contem
uma sentena switch.
Nota-se que o mtodo RecuperaValorSalario no possue
nada alm da sentena switch, o que descarta a necessidade
de aplicao da refatorao Extrair Mtodo.
O segundo passo portanto requer que o mtodo RecuperaValorSalario seja movido para a superclasse da hierarquia. As
Listagens 5, 6 e 7 mostram a hierarquia referida.
Depois da aplicao do segundo passo da refatorao, a classe
Funcionrio ficar como na Listagem 8.
Nota-se que o mtodo RecuperaValorSalario agora tem um
objeto funcionrio como parmetro. Isso necessrio para que
o mtodo continue funcionando aps ter sido movido para a
classe Funcionario.
O prximo passo consiste em criar mtodos nas subclasses
que tenham as mesmas funes que a logica condicional. O
que quer dizer, por exemplo, que a classe Mensalista deve ter
um mtodo que retorne o salario de um funcionario mensalista
Desenvolvimento
para substituir o case mensalista da sentena switch . Analisando as classes Mensalista e Diarista, perecebe-se que tal mtodo
j existe. Agora, portanto, resta modificar o mtodo RecuperaValorSalario da classe Funcionario para eliminar a lgica
condicional. A Listagem 9 mostra o resultado da mudana.
A refatorao Substituir Enumerao por Subclasses
Esta refatorao pertencente ao grupo de refatoraes classificadas como Organizando Dados.
Nome da r efatorao: Subst it u i r Enu merao por
Subclasses.
Resumo: Substituio de enumeraes por subclasses, pois
enumeraes alteram o comportamento de uma classe.
Motivao: Usa-se esta refatorao para dividir uma classe
que possui caractersticas de uma classe que carrega mais
informao do que normalmente deveria carregar. Substituindo as enumeraes por subclasses, consegue-se clarificar
a inteno do cdigo.
Mecnica:
Analisa-se a enumerao e cria-se uma classe para cada valor
contido na enumerao, tornando-as subclasses da classe que
contm a enumerao.
Deletam-se os campos da enumerao e movem-se as caractersticas que so especficas das subclasses para elas.
Execute os testes.
Exemplo: A classe Pessoa possui uma enumerao chamada
TipoPessoa, onde Alunos representado por 0, e Professores
por 1. A classe Pessoa possui ainda mtodos que realizam
operaes para alunos e para professores, o que caracteriza
que a classe Pessoa possui comportamentos que poderiam
ser divididos por outras classes, conforme ser feito nesta
refatorao. A Listagem 10 mostra a classe Pessoa.
Aplicando essa refatorao, parte do cdigo da classe Pessoa
poder ser dividido em duas classes: Alunos e Professores. Assim ser possvel clarificar o cdigo da classe Pessoa, ao mov-lo
para as subclasses. As Listagens 11 e 12 mostram as subclasses
criadas a partir da anlise dos campos da enumerao.
A classe Pessoa agora a superclasse das subclasses Alunos
e Professores. Agora para clarificar e reduzir a complexidade
da classe Pessoa, move-se todo conhecimento especfico para
as respectivas subclasses que, neste caso, implica em mover o
mtodo AlterarSenhaAluno para a classe Alunos e RecuperarNomeProfessor para Professores, conforme Listagens 13 e 14.
Para finalizar, basta apagar a enumerao da classe Pessoa e
ajustar as chamadas enumerao para as novas mudanas.
A partir desse momento, todo cdigo que antes era destinado classe Pessoa, agora dever ser analisado e escrito
na subclasse que melhor se encaixar nos objetivos da nova
funcionalidade.
At este ponto foram apresentados os conceitos e prticas que
o desenvolvedor precisa para iniciar o processo de aprendizado
sobre a refatorao para o padro Strategy. A partir deste momento ser apresentada a tcnica de refatorao para padres
Substituir Lgica condicional por Strategy.
Listagem 7 Subclasse da hierarquia: classe Diarista.
01. public class Diarista: Funcionario

02. {
03. ...
04. public override String RecuperaTipoFuncionario()
05. {
06. return Diarista;
07. }
08. public override decimal RecuperaSalario()
09. {
10. return salario;
11. }
12. }
Listagem 8 Classe Funcionrio.

02. {
04. public Decimal RecuperaValorSalario(Funcionario funcionario)
05. {
06. switch (RecuperaTipoFuncionario())
07. {
08.
case Mensalista:
09.
10.
case Diarista:
11.
12.
default:
13.
return 0;
14. }
15. }
16. }
Listagem 9 Classe Funcionario.

02. {
04. public abstract Decimal RecuperaSalario();
05.
06.
07.
08.
09. }
public Decimal RecuperaValorSalario(Funcionario funcionario)

{
}
Listagem 10 Classe Pessoa com a enumerao TipoPessoa.
01. public class Pessoa

02. {
03.
04.
05.
06.
07.
08.
09.
10.
11.
public enum TipoPessoa

{
Alunos = 0,
Professores = 1
}
public void AlterarSenhaAluno(String novaSenha)
{
...
}
12. public void RecuperaNomeProfessor(Int32 id)

13. {
14. ...
15. }
16. }
29
Listagem 11 Subclasse Alunos.
01. public class Alunos : Pessoa

02. {
03. }
Listagem 12 Subclasse Professores.
01. public class Professores : Pessoa

02. {
03. }
Listagem 13 Classe Alunos.
01. public class Alunos : Pessoa

02. {
03. public void AlterarSenhaAluno(String novaSenha)
04. {
05. ...
06. }
07. }
Listagem 14 Classe Professores.
01. public class Professores : Pessoa

02. {
03. public void RecuperaNomeProfessor(Int32 id)
04. {
05. ...
06. }
07. }
Listagem 15. Classe Emprestimos.
01. public class Emprestimos

02. {
03. public Decimal emprestimoMinimo = 50.00m;
04. public Decimal salarioMinimo = 510.0m;
05. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)
06. {
07. if (renda <= (salarioMinimo / 2))
08. {
09.
return emprestimoMinimo;
10. }
11. else if(renda <= salarioMinimo)
12. {
13.
return ((renda * 10)/ 100) + taxa;
14. }
15. else if(renda <= (salarioMinimo * 2))
16. {
17.
return ((renda * 20) / 100) + 2* taxa;
18. }
19. else
20. {
21.
return ((renda * 50) / 100) - (taxa * 5);
22. }
23. }
24. }
A refatorao para padres Substituir Lgica condicional

por Strategy
Resumo: Alguns mtodos possuem complexa lgica condicional para escolher e executar determinados clculos. Para
lidar com isto, define-se uma hierarquia de classes Strategy
onde cada subclasse ficar responsvel por executar um tipo
de clculo da lgica condicional.
30
Motivao: Mtodos com lgica condicional de grande

complexidade podem dificultar a tarefa de entendimento do
mtodo e assim dificultar a anlise de qual trecho da lgica
condicional ser executada e qual ao ser efetuada. Esta tcnica de refatorao para padres fornece um mecanismo onde a
lgica condicional poder ser eliminada. Isto se torna possvel
graas implementao do padro Strategy que fornecer um
mecanismo baseado em polimorfismo e que possibilitar que
as subclasses da estratgia criada possuam cada uma delas
uma das aes que a lgica condicional removida possua.
Vantagens: Permite a remoo de lgica condicional, simplificando o projeto de cdigo existente; torna algoritmos mais
claros de se entender; permite que um algoritmo seja trocado
por outro em tempo de execuo.
Desvantagens: Complica um projeto de cdigo existente
quando outro mecanismo mais simples poderia resolver o
problema, neste caso, um mecanismo baseado em herana;
dificulta a visualizao de como dados so passados entre
os objetos.
Mecnica: Busca-se por um mtodo que possua lgica condicional a ser removida.
1. Cria-se uma classe Strategy. Seu nome deve ser compatvel
com a funo do mtodo escolhido e terminado com a palavra
Strategy.
2. Utiliza-se a refatorao Mover Mtodo levando o mtodo
escolhido para a classe criada no passo 1. Deve-se deixar uma
cpia do mtodo no seu local de origem e modific-la para que
delegue ao mtodo movido para a classe criada no passo 1.
Caso o mtodo escolhido faa referncia a outros mtodos da
classe onde est escrito, devem-se mov-los tambm para classe
criada no passo 1. A refatorao Introduzir Objeto Parmetro
permite a reduo de parmetros a serem passados para as
estratgias definidas. Caso necessrio, ela deve ser utilizada.
3. Modifique o cdigo cliente para se adequar s novas
mudanas.
4. Utiliza-se a refatorao Substituir Condicional por Polimorfismo no mtodo presente na classe criada no passo 1. Talvez
seja necessria a aplicao da refatorao Substituir Enumerao por Subclasses. Para se certificar se o uso desta refatorao
se aplica, considera-se o contexto em que ela deve ser aplicada.
Compila-se a aplicao e executam-se testes.
Exemplo: A Listagem 15 mostra a classe Emprestimos, onde
possvel perceber que o mtodo CalcularEmprestimo possui
grande quantidade de lgica condicional para calcular o emprstimo com base na taxa de juros e na renda do cliente.
Aplicando a refatorao para padres em questo, tem-se a classe CalcularEmprestimoStrategy, como mostra a Listagem 16.
Prosseguindo, tem-se a criao de um mtodo em CalcularEmprestimoStrategy que receber a lgica condicional
presente no mtodo CalcularEmprestimo (Listagem 15). A
Listagem 17 mostra o resultado.
Move-se o corpo do mtodo CalcularEmprestimo (Listagem 15)
para o corpo do mtodo Calcular (Listagem 17). Deve-se tambm
mover todo o cdigo presente na classe CalcularEmprestimo
Desenvolvimento
(Listagem 15) que o cdigo movido esteja utilizando. O resultado

pode ser visto na Listagem 18.
Modifica-se o mtodo CalcularEmprestimo da classe Emprstimos (Listagem 15), para que ele delegue classe CalcularEmprestimoStrategy. A Listagem 19 mostra o resultado.
Utilizando herana e polimorfismo, analisa-se o mtodo Calcular
na classe CalcularEmprestimoStrategy (Listagem 18). Para cada
tipo de clculo que ele produz, no caso 4 (um pra cada condicional,
cria-se uma subclasse para a classe CalcularEmprestimoStrategy.
Tais subclasses devem conter um mtodo Chamado Calcular,
e o seu corpo deve conter um dos tipos especficos de calculo
da lgica condicional em questo. Depois, deve-se modificar a

classe CalcularEmprestimoStrategy para abstrata e modifica-se
seu mtodo Calcular para abstrato, permitindo que os mtodos
recm criados nas subclasses o implementem. As Listagens 20,
21, 22, 23 e 24 mostram o resultado destas mudanas.
A refatorao para padres Substituir Lgica Condicional por
Strategy est finalizada. Cumpriu-se o objetivo, que era a implementao do padro Strategy. O benefcio citado na descrio da
refatorao era o de simplificar o projeto de cdigo existente.
Isto se torna visvel se analisado o mtodo CalcularEmprestimo
(Listagem 15). A lgica condicional que escolhia qual tipo de
Listagem 16. Classe CalcularEmprestimoStrategy.
Listagem 20. Subclasse MeioSalarioMinimoStrategy.
1. p
ublic class CalcularEmprestimoStrategy
2. {
1.
2.
3.
4.
5.
6.
7.
3. }
Listagem 17. Classe CalcularEmprestimoStrategy
1. public class CalcularEmprestimoStrategy

2. {
3. public Decimal Calcular(Decimal renda, Decimal taxa)
4. {
5. return 0.0m;
6. }
7. }
Listagem 18. Classe CalcularEmprestimoStrategy
1.
2.
3.
4.
public class CalcularEmprestimoStrategy

{
public Decimal emprestimoMinimo = 50.00m;
public Decimal salarioMinimo = 510.0m;
5. public Decimal Calcular(Decimal renda, Decimal taxa)

6. {
7. if (renda <= (salarioMinimo / 2))
8. {
9.
return emprestimoMinimo;
10. }
11. else if (renda <= salarioMinimo)
12. {
13.
return ((renda * 10) / 100) + taxa;
14. }
15. else if (renda <= (salarioMinimo * 2))
16. {
17.
return ((renda * 20) / 100) + 2 * taxa;
18. }
19. else
20. {
21.
22. }
23. }
24. }
Listagem 19. Classe Emprestimos
1. p
ublic class Emprestimos
2. {
3. private CalcularEmprestimoStrategy calcularEmprestimo;
4. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)
5. {
6. return calcularEmprestimo.Calcular(renda, taxa);
7. }
8. }
public class MeioSalarioMinimoStrategy: CalcularEmprestimoStrategy

{
public override Decimal Calcular(Decimal renda, Decimal taxa)
{
}
}
Listagem 21. Subclasse SalarioMinimoStrategy.
1.
2.
3.
4.
5.
6.
7.
public class SalarioMinimoStrategy: CalcularEmprestimoStrategy

{
{
}
}
Listagem 22. Subclasse DoisSalariosMinimosStrategy.
1.
2.
3.
4.
5.
6.
7.
public class DoisSalariosMinimosStrategy: CalcularEmprestimoStrategy

{
{
return ((renda * 20) / 100) + 2 * taxa;
}
}
Listagem 23. Subclasse RendaAltaStrategy.
1.
2.
3.
4.
5.
6.
7.
public class RendaAltaStrategy: CalcularEmprestimoStrategy

{
{
}
}
Listagem 24. Superclasse CalcularEmprestimoStrategy.
1.
2.
3.
4.
public abstract class CalcularEmprestimoStrategy

{
public Decimal emprestimoMinimo = 50.00m;
public Decimal salarioMinimo = 510.0m;
5. public abstract Decimal Calcular(Decimal renda, Decimal taxa);

6. }
31
clculo executar foi diluda no padro Strategy, onde cada subclasse de CalcularEmprestimoStrategy fica responsvel pela
implementao de um mtodo, que por sua vez fica responsvel
por um tipo de clculo, e o mtodo CalcularEmprestimo (Listagem 15) ficou como mostra a Listagem 19.
1. GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a

objetos, 1ed. Porto Alegre: Bookman, 2000.
Concluso
3. FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.

Feedback
eu
edio
ta
D
s
2. KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.
sobre e
s
Um dos grandes benefcios dos padres de projeto est relacionado ao fato de permitir a criao de solues flexveis
e reutilizveis. A aplicao do padro Strategy neste artigo
mostrou que o mecanismo criado aumentou a flexibilidade do
cdigo a partir do momento que tornou mais simples a insero
de novas estratgias para novos tipos de clculos, e ao mesmo
tempo tornou o cdigo reutilizvel, permitindo s estratgias
definidas serem reutilizadas em outros projetos.
Referncias Bibliogrficas
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Engenharia de Software
Sobre a Necessidade de Educao Continuada

Apresenta a engenharia de software, destacando
sua importncia no cenrio atual de crescimento
econmico mundial e apontando a necessidade de
educao continuada de engenheiros de software.
Antonio Mendes da Silva Filho

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

da informao e comunicao com mais
de 20 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 mais de
30 artigos publicados em eventos nacionais
e internacionais, colunista para Cincia e Tecnologia pela Revista Espao Acadmico com
mais de 60 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.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Problemas
e suas causas no desenvolvimento de software.
Para que serve?
o longo das ltimas dcadas

o software deixou de ser uma
parte nfima e de custo desprezvel dos sistemas para se tornar parte
determinante e dispendiosa. Hoje em
dia, tudo o que voc toca tem software, seja no uso domstico quanto nas
organizaes. Voc encontra software
nos caixas das farmcias, no mercado da
esquina, naquelas pequenas mquinas
que permitem milhes de transaes
com carto de crdito e nos avies que
levam a pessoas pelos quatro cantos do
mundo.
Incrvel e intangvel o software. Isso
mesmo, software um produto intangvel, o qual difcil descrever bem como
avaliar. Por outro lado, comparativamente
ao hardware facilmente modificado,
tornando as manutenes sejam elas de
Conscientizar o engenheiro de software da necessidade de criar uma cultura de engenharia

de software que prioriza documentao adequada de software para apoiar rastreabilidade,
manutenibilidade e reuso de artefatos de software. Recomenda engenharia reversa e arquitetura de software como componentes para sua
formao.

O artigo identifica diversos fatos e tendncias do
segmento de TI, discute cenrio atual e apresenta recomendaes para os profissionais de engenharia de software que visam atender a demanda de desenvolvimento de sistemas de software
que satisfaam restries de custo, tempo (de
desenvolvimento) e qualidade.
carter corretivo ou evolutivo tambm

mais fceis. Mas, isso apenas verdade se o software tiver seu projeto bem
33
documentado. Documentao de um projeto essencial para

permitir a manuteno e evoluo de um sistema de software.
Para tanto, torna-se imprescindvel ter ou, se ainda no tiver, criar
uma cultura (de engenharia de software) para adotar boas prticas
da engenharia de software que compreendem os pilares do desenvolvimento de software de modo a atender s suas premissas
bsicas: custo, tempo de desenvolvimento e qualidade.
Engenharia de Software
De acordo com o documento IEEE Std 610.12-1990 que apresenta o IEEE Standard Glossary of Software Engineering Terminology (http://standards.ieee.org/findstds/standard/610.12-1990.
html), Engenharia de software definida como The application
of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of
engineering to software.
Sabe-se que software no uma entidade fsica e, portanto, no
sofre qualquer tipo de desgaste (fsico) como geralmente acontece com o hardware. Entretanto, apesar de no sofrer desgaste
fsico como o hardware, software est sujeito a modificaes
que ocorrem durante o ciclo de vida. Essas modificaes podem
acontecer devido insero de defeitos decorrentes do desenvolvimento os quais so geralmente corrigidos antes da entrega
do produto. Mas, observe que novos defeitos ainda podem ser (e
geralmente so) inseridos devido s modificaes que o software
sofre devido a sua evoluo. Por exemplo, toda vez que uma nova
funcionalidade desejada ou solicitada pelo cliente, torna-se
necessrio adicionar e/ou modificar as instrues j existentes
no software. Como resultado dessas mudanas, novos defeitos
podem ser introduzidos e, portanto, pode tambm causar a
deteriorao na qualidade do software.
Fases genricas no desenvolvimento de software

Dentro do contexto discutido acima, importante observar
que a manuteno uma das fases que certamente o software
ir lidar. Outras duas fases so definio e desenvolvimento,
como ilustrado na Figura 1.
Cabe destacar que o desenvolvimento de qualquer produto
(como, por exemplo, software) ou artefato, requer do engenheiro de software saber quais os passos necessrios para
alcanar o objetivo de ter o produto pronto (desenvolvido).
Isso compreende as fases de definio, desenvolvimento e
manuteno, mostradas na Figura 1.
A fase de definio engloba a identificao de informaes que
deveriam ser processadas, funes e desempenho desejados,
tipo de interface a ser utilizada, tarefas que o sistema deveria
prover suporte, perfil de usurios do sistema, dentre outras.
Figura 1. Fases genricas no desenvolvimento de software
34
Engenharia de Software Magazine - Engenharia de Software
A fase de desenvolvimento concentra-se no projeto de estruturas de dados e arquitetura de software do sistema (isto
, como ele est organizado), converso do projeto para uma
linguagem de programao especfica (ou seja, implementao), realizao de testes e avaliao.
Finalmente, a manuteno considera modificaes e/ou
correes necessrias no sistema a fim de que este atenda aos
requisitos do sistema. Perceba que o processo de desenvolvimento de um sistema de software tem duas grandes atividades
de interesse que envolve o desenvolvimento da poro de
software que implementa as funcionalidades do sistema, e
a atividade que a antecede e norteia o desenvolvimento, que
o projeto de software. Esta ltima atividade resultado do
levantamento e anlise de requisitos que prov informaes
para decises de projeto.
Necessidade da Engenharia de Software

No contexto atual, qual o nvel de necessidade da engenharia
de software?
A resposta : crtico. E, mais ainda, h consequente demanda
por profissionais da rea qualificados.
A adoo das prticas de engenharia de software essencial
para assegurar a confiabilidade dos produtos e servios de
software. As prticas compreendem instituir uma cultura de
engenharia de software, onde a equipe de projeto de sistemas
de software esteja comprometida com a documentao de todos os artefatos de um projeto de modo a prover suporte a:
1. Rastreabilidade
2. Manutenibilidade
3. Reuso
A fase inicial do desenvolvimento de software na qual
ocorre a definio do sistema considera o entendimento
dos requisitos desejados alm de claramente estabelecer a
origem do requisito. Essa informao ser fundamental para
a rastreabilidade.
Observe que rastreabilidade est relacionada aos relacionamentos entre os requisitos, as fontes dos requisitos, bem
como o projeto de sistema. A rastreabilidade das fontes dos
requisitos visa identificar e relacionar os requisitos s partes
interessadas (ou stakeholders) daqueles requisitos. Alm disso,
h o relacionamento en tre os requisitos (isto , a dependncia
existente entre eles) e a ligao de requisitos aos componentes
do sistema em desenvolvimento.
E, quanto a manutenibilidade?
Neste momento, importante distinguir entre manuteno
que compreende um conjunto de atividades planejadas a fim
de realizar mudanas, enquanto que a evoluo se refere quilo
que de fato acontece com o software. E, nesse sentido, cabe
destacar que medida que o software tem se tornado quase
ubquo nos sistemas, ele tem tambm crescido em tamanho
(isto , na quantidade de linhas de cdigo) e complexidade.
Perceba que esse crescimento dos sistemas de software requer
mecanismos apropriados para documentao, rastreamento,
e manuteno.
EngEnHAriA dE SoF t WArE
Por outro lado, o reuso de software pode ser entendido como

um processo de implementar e atualizar sistemas de software
fazendo uso de software existente. Vale lembrar que software
compreende componentes, objetos, requisitos, modelos de
projeto, arquitetura, documentao do cdigo, cenrios de
testes, metas de projeto, manuais. Vale ressaltar que reuso de
software pode se dar num sistema de software, num conjunto
de sistemas similares ou ainda em sistemas completamente
diferentes. Note que reuso de software no desenvolver um
sistema de software desde seu incio, mas desenvolver um
sistema de software a partir dos componentes de software j
existentes. Cabe destacar que a meta de reuso de software
utilizar tanto quanto possvel o software resultante de esforos
de desenvolvimentos anteriores, visando reduzir os custos,
tempo e riscos associados com novos desenvolvimentos.
Cultura de Engenharia de Software

Instituir uma cultura de Engenharia de Software significa
adotar suas prticas e obter da equipe de projeto um comprometimento de documentar adequadamente todos os artefatos de um projeto. Talvez voc possa estar imaginando que
dedicar esforo em documentar todos os artefatos produzidos
seja um esforo ftil e desnecessrio. E, concordo com voc
se estiver considerando desenvolver um pequeno sistema de
software para uma pequena farmcia ou mesmo para o mercadinho da esquina. Tal tarefa pode ser comparada ao esforo
de voc construir uma casinha de madeira para seu cachorro
de estimao. Voc, sozinho, pode dar conta do recado.
No entanto, se voc tiver a necessidade de informatizar
um sistema de uma biblioteca de uma instituio que possui
cerca de 10.000 usurios (onde h renovao de quase 2.000
usurios por ano) e tem mais de 50.000 ttulos entre livros,
revistas e outros itens (com aquisio regular de novos ttulos), ento voc ter a necessidade de trabalhar em equipe a
fim de desenvolver esse software. Aqui, torna-se prudente
documentar o projeto. Aqui, documentao no um luxo,
mas sim uma necessidade, pois tal sistema com certeza ter
modificaes.
Agora, pode-se considerar uma situao ainda mais extrema
de documentao de projeto. Voc tem noo de quantas linhas
de cdigo h num Boeing 777?
Um Boeing 777 tem mais de 4 milhes de linhas de cdigo
(isto , software) rodando em cerca de 1.300 processadores.
Agora, voc imagina desenvolver tudo isso sem qualquer
planejamento ou documentao de projeto?
Desenvolver um sistema como de uma biblioteca ou similar
requer atividades de modelagem para apoiar o projeto, um
processo de desenvolvimento com atividades bem definidas,
alm de ferramentas que automatizem atividades do processo. E, isso ser ainda mais essencial no desenvolvimento de
sistemas de grande porte como, por exemplo, software utilizado em avies, sistemas de comrcio eletrnico e sistemas de
administradoras de carto de crdito.
Perceba que desenvolvimento de software tem sido e ainda permanece uma atividade difcil, pois ela requer que o
Figura 2. Influncias sobre o software
engenheiro de software considere os elementos influenciadores

sobre o software, destacados na Figura 2.
Esse conjunto de foras ilustradas na Figura 2 influenciam o
software. Todavia, trs dentre elas tm impacto determinante
sobre o software que compreendem custo, prazo e qualidade
(caracterizada pela confiabilidade que constitui atributo essencial da qualidade).
Afinal, qual o problema com o software?
Falibilidade de software (ou possibilidade de existncia de
falhas) e a consequente falta de confiabilidade, alm do fato
de que software quase sempre modificado, resultando num
produto quase sem garantia. Observe que a nica certeza que
se tem a de que o software ser modificado e, portanto, a
documentao do projeto essencial para permitir a rastreabilidade e, mais importante, a manutenibilidade.
Para lidar com essa demanda, a engenharia de software
prov um conjunto de procedimentos, formalismos e tcnicas
que visa a construo de sistemas de software que atendam os
requisitos funcionais e no funcionais. Note que a proposta
da engenharia de software compreende estabelecer e utilizar
princpios de engenharia a fim de obter software de baixo
custo que seja confivel e opere de maneira efi ciente nas
mquinas onde for empregado.
Como h uma certeza de que o software sofrer modificaes,
ento os artefatos do projeto sero constantemente alterados
durante o desenvolvimento de software. Nesse sentido, o
desenvolvimento de vrias verses do sistema requer que a
equipe estabelea mecanismos para controlar a evoluo do
software pois, do contrrio, a rastreabilidade do que foi alterado pode ser comprometida.
Reuso de Software
Reuso considerado como uma espcie de palpite para o
futuro do software. Perceba que o aumento da produtividade
decorrente de uma adoo de cultura de reuso de artefatos de
software pode implicar num conjunto de benefcios listados
abaixo:
Melhor qualidade;
Maior produtividade;
Melhor uso de recursos;
35
Atendimento a demanda de negcios;

Menos tempo para entrega do produto;
Auxlio a questes complexas de sistemas (o reuso de forma
sistemtica implica numa recuperao de investimento de
qualquer tecnologia).
Da mesma forma que se podem identificar as vantagens destacadas acima, as empresas podem se deparar com limitaes
como, por exemplo:
Exige investimento inicial;
Um tanto de aposta no futuro;
Pode induzir a erros se no for adequadamente conduzido;
Pode resultar em custos maiores se no for devidamente
realizado;
Deve ser empregado de maneira cautelosa em sistemas que
requerem confiabilidade operacional.
A certeza que existe de que software quase sempre modificado requer do engenheiro de software o cuidado de documentar adequadamente o projeto para futura manuteno, futura
necessidade de rastrear parte dos requisitos do projeto (para
adio ou alterao de funcionalidades), alm de futuro reuso,
implicando em possvel reduo de custo de desenvolvimento
e aumento de produtividade.
Sobre a necessidade de educao continuada

Nesse cenrio de elevada demanda por software, quais os
componentes de qualificao profissional fundamentais para
um engenheiro de software? Perceba que o cenrio atual e de
dcadas vindouras requer educao continuada.
Tecnologia da informao e, mais especicamente, software
tem sido e continuar a ser um produto demandado no mercado global. Apesar da volatilidade vericada em segmentos
do mercado, os cenrios indicam crescimento de demanda por
software e seus prossionais. De acordo com pesquisa da realizada pela Forrester Research, Inc. informa que gastos a nvel
mundial no ano de 2009 foram de US$ 1,469 bilhes no setor
de TI, sendo US$ 362 bilhes referentes a software, havendo
previso que nos anos de 2010 e 2011 os gastos com software
sero de aproximadamente US$ 400 e 440 bilhes, como mostrado na Figura 3. Desse total, quase metade do mercado de
software pertinente aos EUA, enquanto que cerca de 10% do
total pertinente Amrica Latina.
Figura 3. Gastos em TI a nvel mundial. (Fonte: Global IT Market Report,

Forrester Research, Inc., 2010)
36
Dentro do contexto destacado acima, o profissional de engenharia de software deve considerar participar de programas
de educao continuada de modo a atender a demanda por
produtos inovadores, maiores e mais complexos. Nesse sentido,
um aspecto de suma importncia no projeto de sistemas de software de grande porte sua organizao a qual representada
como um modelo arquitetural que consiste de componentes
computacionais e de conectores que permitem a interao
entre esses componentes. Esta percepo corresponde viso
arquitetural de software num projeto de sistema.
importante tambm considerar que uma questo antecedente a importncia que a rea de arquitetura de software tem
no contexto atual diz respeito natureza do software, bem
como seu crescimento em termos de tamanho e complexidade.
Vale lembrar que os problemas de desenvolvimento de sistemas
de software de larga escala foram inicialmente reconhecidos
durante a dcada de 60. Em razo disto, na dcada de 70,
houve grande ateno dos desenvolvedores e pesquisadores
para o projeto de software. Uma das idias da poca era que
a atividade de projeto era separada da implementao, bem
como exigia notaes e tcnicas especficas.
J na dcada de 80, a pesquisa em engenharia de software
deixou o foco em projeto de software e esteve mais concentrada na integrao de projetos, bem como no processo de
projeto e gerenciamento de software. Como resultado desse
foco de pesquisa, houve o surgimento de vrias tcnicas de
modelagem e projeto de software, sendo essas incorporadas
s linguagens de programao. Alm disso, houve pesquisa
e avanos nos mtodos de anlise, fazendo uso de tcnicas de
descrio formais, o que permitiu lidar melhor com problemas
de inconsistncia e ambiguidades.
No incio da dcada de 90, houve um trabalho de catalogao
de padres de projeto do grupo conhecido como Gang of Four.
Tais padres so considerados como experincia de projeto que
pode ser reutilizada. Ainda na dcada de 90, porm em sua
segunda metade, a tecnologia baseada em componentes tem
ganhado proeminncia. Isto pode ser justificado, em parte, devido aceitao das abordagens orientadas a objetos. importante observar que a abordagem orientada a objetos tem sido
difundida com a tecnologia de componentes de software.
Adicionalmente, o desenvolvimento de tcnicas de abstrao
tem sido uma das principais fontes de avano em termos de
desenvolvimento e programao de sistemas de software e
a dcada de 90, notoriamente, marcada pelo surgimento de
uma nova disciplina arquitetura de software, que aponta
um conjunto de aspectos discutidos a seguir.
Foco da Disciplina - A disciplina de arquitetura de software
tem seu interesse concentrado na organizao do software
em sistemas de grande porte, diferentemente, do principal
foco de interesse em cincia da computao que recai sobre
as estruturas de dados e projetos de algoritmos. Dessa forma,
arquitetura de software requer notaes, tcnicas e ferramentas
especficas. Num projeto arquitetural de software, os esforos
concentram-se na organizao do sistema, distribuio dos
EngEnHAriA dE SoF t WArE
componentes, protocolos de comunicao, mecanismos de

sincronizao e acesso a dados, dentre outros.
Tipo de Representao - Uma descrio de arquitetura de
software faz uso de notaes baseadas em grafos, onde se tem
um conjunto de componentes e conectores interligando esses
componentes. Os componentes compreendem unidades de
computao que realizam tarefas tais como clientes, servidores, banco de dados e objetos. Os conectores atuam como
mecanismos de interligao dando suporte interao entre
os componentes. Exemplo disto so as chamadas de procedimentos, pipes e protocolos de acesso.
Estilo Arquitetural - Um estilo arquitetural descreve os
tipos de componentes e conectores pertinentes a uma famlia
arquitetural bem como caractersticas topolgicas e semnticas
de seus elementos.
Projeto a nvel Arquitetural - O projeto arquitetural tem seu
foco nos compromissos assumidos durante o projeto, onde o
projetista ou arquiteto de software busca casar as propriedades
de uma arquitetural a um conjunto de funcionalidades e atributos de qualidade desejados no sistema a ser desenvolvido.
Esta abordagem difere dos mtodos de projeto de software
que definem um conjunto de passos que orientam o projetista
desde a anlise de requisitos at a implementao.
importante observar que o projeto a nvel arquitetural
vem para complementar os mtodos de projeto, uma vez
que no projeto arquitetural feita a seleo de um estilo
arquitetural (ou combinao de estilos) de modo a satisfazer
um conjunto de funcionalidades e atributos de qualidade.
No difcil identificar as contribuies que a disciplina
de arquitetura de software tem proporcionado ao processo
de desenvolvimento de software. O projeto arquitetural
tem papel relevante, principalmente, no desenvolvimento
de sistemas de grande porte, pois uma escolha inadequada
de uma arquitetura em detrimento de outra pode acarretar
em resultados insatisfatrios em termos de desempenho,
confiabilidade, interoperabilidade e outros requisitos no
funcionais que so diretamente relacionados arquitetura de
software do sistema. Perceba que a arquitetura de software
de um sistema atua com um elo entre os requisitos e a implementao. Esta viso ilustrada na Figura 4.
Fornece ainda uma descrio abstrata do sistema, expondo
um conjunto de propriedades e ocultando outras. A arquitetura de software permite que engenheiros ou arquitetos de
software possam avaliar se um sistema pode ou no satisfazer
um conjunto de requisitos. Um conjunto de contribuies ao
processo de desenvolvimento de software, observadas ao
longo da dcada de 90, so destacadas abaixo.
Compreensibilidade - A arquitetura de software consiste
de uma descrio de projeto em nvel elevado de abstrao,
o que simplifica a apresentao e entendimento de sistemas
de grande porte. Adicionalmente, um modelo arquitetural
ajuda a expor as restries existentes no projeto.
Natureza Evolutiva - A natureza evolutiva dos sistemas
de software requer que haja separao de interesses entre os
requisitos
arquitetura de software
Implementao
Figura 4. Arquitetura como elo entre requisitos e implementao
componentes de um sistema de modo a minimizar o custo e

esforo de atualizao e manuteno em um sistema. Assim,
uma descrio arquitetural pode separar a funcionalidade de
um componente de outros levando em conta as formas nas
quais esses componentes interagem uns com os outros. Isto
permite que modificaes nos componentes ou no mecanismo
de conexo possam acontecer, possibilitando a adio de novas
caractersticas e/ou funcionalidades com custos de modificao devidamente estimados.
Reuso - As descries arquiteturais oferecem suporte ao
reuso em mltiplos nveis. Podem-se ter arquiteturas reutilizveis que fornecem a organizao e o modelo de coordenao usado em diversos sistemas. Tambm, tem-se o reuso de
componentes que possibilita a reutilizao de componentes
em vrios sistemas. Alm disso, pode-se ainda considerar os
trabalhos existentes sobre arquiteturas de domnio especfico,
que oferece suporte ao reuso.
Anlise - Uma descrio da arquitetura fornece mais subsdios
anlise, possibilitando-se checar a consistncia e conformidade
com estilo arquitetural. Alm disso, verificado se requisitos
no funcionais so suportados pela arquitetura sob anlise.
Gerenciamento - Considerar a obteno da arquitetura
de software de um sistema como marco num processo de
desenvolvimento constitui em assegurar as possibilidades
de expanso do sistema e custos envolvidos, bem como que
os requisitos de capacidade operacional do sistema sero
atendidos. Caso contrrio, se este marco no existe, pode-se
deparar com a situao na qual a arquitetura no acomoda
futuras expanses no sistema e/ou a capacidade operacional
do sistema fica aqum do desejado.
Um aspecto de suma importncia a ser considerado a natureza evolutiva do processo de desenvolvimento de software,
bem como as novas possveis aplicaes onde software pode
ser usado. Esta caracterstica evolutiva do software tambm
precisa ser considerada a nvel arquitetural. Nesse sentido,
duas provveis demandas incluem: (i) a crescente necessidade
de integrao de subsistemas e componentes de software e (ii)
o uso de sistemas baseado em rede.
Vale ressaltar que a necessidade de disponibilizar novos
produtos, novos servios e atualizar os existentes em funo
da demanda e presso do mercado tem influenciado a forma
na qual os sistemas de software so desenvolvidos.
37
38
Software and higher education

http://portal.acm.org/citation.cfm?id=1107458.1107486
Creating a Software Engineering Culture
http://www.processimpact.com/articles/culture.pdf
Software Engineering Body of Knowledge
http://www.computer.org/portal/web/swebok
The Nature of Software: Whats So Special About Software Engineering?
http://www.ibm.com/developerworks/rational/library/4700.html
Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering
http://sites.computer.org/ccse/
Measuring and Sustaining the New Economy, Software, Growth, and the Future of
the U.S Economy: Report of a Symposium (2006)
http://www.nap.edu/catalog.php?record_id=11587

Feedback
eu
sobre e
s
Engenharia de software uma rea fascinante, mas considero que devida ateno no tem sido dada formao dos
profissionais, objetivando conscientiz-los da importncia da
documentao do projeto. Sem uma documentao adequada
de projeto, a rastreabilidade dos artefatos, a manutenibilidade
e reuso de software fica comprometida.
Observo que a maioria dos cursos de engenharia de software,
tanto a nvel de graduao quanto ps-graduao, dedicam
nenhuma ou uma nfima parcela do tempo para a disciplina de
engenharia reversa de software, a qual considero como essencial na formao do profissional de engenharia de software.
Finalizando, este autor recomenda que a disciplina de engenharia reversa de software deva fazer parte da grade dos
cursos de Engenharia de Software, Computao e correlatos.
Por que? Observe que muitas empresas possuem sistemas
(legados ou no) que requer manuteno e, para tanto, voc
engenheiro de software necessita da documentao de projeto.
Referncias
D
s
Concluso
Do contrrio, voc ser obrigado a fazer engenharia reversa

a fim de atender a necessidade de evoluo do software. Por
outro lado, os conceitos e tcnicas de engenharia reversa (que
sero apresentados em artigo futuro) ajudam a conscientizar
o profissional da importncia de se ter um projeto de software
adequadamente documentado.
edio
ta
Colocar um novo sistema no mercado com um, dois ou trs

meses de antecedncia em relao aos concorrentes pode significar o sucesso de um produto e/ou a sobrevivncia de uma
empresa. Em funo deste cenrio, tem havido a tendncia
de adquirir partes do sistema que j tenham sido desenvolvidas por outros. Isto implica na possibilidade de concluir o
desenvolvimento mais cedo de um produto, colocando-o no
mercado. Isto, contudo, implica na necessidade de efetuar a
integrao do sistema. Resultado disto tem sido o interesse
por parte de empresas em buscar profissionais qualificados
para realizar este trabalho de integrao de subsistemas, onde
ele desenvolve cdigo de integrao, fazendo a colagem dos
subsistemas e/ou componentes.
Engenharia
Especificao de Casos de Uso

Aprenda atravs de alguns exemplos reais

Este artigo apresenta inicialmente algumas definies
associadas engenharia de requisitos e especificao
de requisitos atravs de casos de uso. Em seguida, so
apresentados alguns exemplos reais de especificao
de requisitos utilizando casos de uso. Alm disso, este
artigo tambm apresenta algumas definies importantes sobre o diagrama de casos de uso e exemplificar seu uso atravs de um exemplo prtico.

rodrigo@sqlmagazine.com.br
Para que serve?
Editor Chefe Engenharia de Software Magazine

Diretor de Operaes - Kali Software (www.
kalisoftware.com)
Doutor e Mestre em Engenharia de Software
pela COPPE/UFRJ. Autor de diversos artigos
cientficos sobre Engenharia de Software publicados em revistas e conferncias renomadas, dentro e fora do pas. Experincia de participao em mais de 20 projetos de consultoria
para diferentes empresas tendo atuado com
gerncia de projetos, requisitos e testes de
software. Implementador certificado do MPS.
BR, tendo tambm experincia atuando junto
a empresas certificadas CMMI.
O objetivo do artigo explicitar de forma prtica

como a especificao dos requisitos do software
engenharia de requisitos um
termo usado para descrever
as atividades relacionadas
produo (levantamento, registro, validao e verificao) e gerncia (controle
de mudanas, gerncia de configurao,
rastreabilidade, gerncia de qualidade
dos requisitos) de requisitos. A Figura 1
representa essa definio.
atravs de casos de uso podem ser efetuadas em um

nvel de detalhe tal que informaes importantes
para outras etapas do desenvolvimento como planejamento de testes, projeto e desenvolvimento no
sejam omitidas.

O assunto abordado til no dia a dia do analista
de requisitos na realizao de suas atividades.
Mas o que podemos entender por requisitos? Existem diferentes definies

encontradas na literatura tcnica:
Um requisito uma caracterstica do
sistema ou a descrio de algo que o
sistema capaz de realizar para atingir
os seus objetivos;
As descries das funes e restries
so os requisitos do sistema.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Trabalhando com requisitos e casos de uso com a UML
Para ter acesso esse artigo na ntegra acesse o leitor digital:
39
Engenharia
Entendendo melhor SOA e ESB

Importantes conceitos para demandas de negcio

Apresentar, atravs de uma viso geral, os conceitos,
diferenas e algumas caractersticas de SOA (Service
Oriented Architecture) e ESB (Enterprise Service Bus)
e como estes podem ser teis nas empresas que os
adotam.
Para que serve?

Proporcionar s empresas um maior planejamento
para implementao de seus sistemas distribudos,
A
Lenildo Morais
lenildojmorais@gmail.com
analista de sistemas e analista de testes.

Atualmente est cursando mestrado no centro de informtica da UFPE em engenharia de
software com nfase em testes e qualidade de
software.
s empresas esto percebendo

cada vez mais a necessidade
de ter e manter suas infraestruturas de TI prontas para acompanhar
as mudanas do mercado. Este fator
implica diretamente no crescimento
e na competitividade diante de seus
concorrentes, independentemente do
segmento de atuao da mesma. Neste
contexto, o SOA uma abordagem
arquitetural corporativa que permite
possibilitando uma maior integrao entre seus modelos de negcio.

Quando se pretende otimizar os recursos disponveis nas empresas, atravs do reuso de componentes e integrao de servios, sobretudo quando
se deseja buscar uma aproximao das reas de
negcio e de TI, aumentando a viso e o poder de
deciso por parte de seus gestores.
a criao de servios de negcio interoperveis que podem facilmente ser

reutilizados e compartilhados entre
as diversas aplicaes utilizadas nas
empresas.
O Service-Oriented Architecture (SOA),
ou Arquitetura Orientada a Servios,
um estilo de arquitetura utilizado no
desenvolvimento de softwares onde
uma aplicao definida como um
conjunto de servios.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Projeto de
Arquitetura de Software
Para ter acesso esse artigo na ntegra acesse o leitor digital:
40
Engenharia de Software Magazine - Entendendo melhor SOA e ESB
arquitetu r a
41
42
Engenharia de Software Magazine - Entendendo melhor SOA e ESB

Revista Engenharia de Software 32

Enviado por

Dados do documento

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

Revista Engenharia de Software 32

Enviado por

Direitos autorais:

Formatos disponíveis

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Ano 3 - 32 Edio - 2011

Fale com o Editor!

urante muitos anos, as metodologias tradicionais foram utilizadas

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

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

13 - Scrum: No funcionou para voc?

26 - Refatorao para Padres Parte 5

39 - Especificao de Casos de Uso

40 - Entendendo melhor SOA e ESB

Edio 05 - Engenharia de Software Magazine

Pos trs do bvio

Tenho um Chefe difcil:

Engenharia de Software - Tenho um chefe difcil: e agora?

por trs d o bvio

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

D seu feedback sobre esta edio!

Edio 32 - Engenharia de Software Magazine

de passagem, far com que seu chefe reclame menos do seu

Modelagem em uma Viso gil

De que se trata o artigo?

analista de sistemas e analista de testes.

modelagem, do ponto de vista

Engenharia de Software Magazine - Modelagem em uma Viso gil

Apresentar, atravs de uma viso geral, os valores,

Para que serve?

Em que situao o tema til?

com o objetivo de observar se as necessidades foram atendidas. Ao longo

Viso geral da Modelagem gil

o pedreiro tem um custo menor, assim como um engenheiro

Aspectos humanos e tcnicos no desenvolvimento de

Edio 32 - Engenharia de Software Magazine

caos. Nesse caso, a modelagem voltada para o aspecto tcnico,

Rascunhos como forma de modelagem

Nota 1: Qualidade Interna

Nota 2: Qualidade Externa

Capacidade do software de satisfazer as necessidades implcitas, ou seja, requisitos relacionados

Capacidade do software de satisfazer as necessidades explcitas, como por exemplo, o

Engenharia de Software Magazine - Modelagem em uma Viso gil

A importncia de se escrever documentos de

Modelagem na obteno da qualidade

Entretanto, a prtica do excesso de documentao ainda

Edio 32 - Engenharia de Software Magazine

Comprovao atravs do cdigo

Engenharia de Software Magazine - Modelagem em uma Viso gil

AMBLER, SCOTT. Home Page Agile Modeling

D seu feedback sobre esta edio!

Entretanto, o mais importante de tudo focar nas atividades

dos modelos produzidos colocando-os em painis, parede ou

Scrum: No funcionou para voc?

De que se trata o artigo?

formada pela UNICAMP em Tecnologia

Para que serve?

Em que situao o tema til?

Edio 32 - Engenharia de Software Magazine

Scrum. O Scrum, mesmo com inmeras vantagens em vrias

Scrum Master (SM): um lder, mas acima de tudo, um

A raiz dos problemas (ou seriam as razes?)

Figura 1. Ciclo de Vida de uma Sprint

Engenharia de Software Magazine - Scrum: No funcionou para voc?