Modéstia à parte, sua

melhor opção para

se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para Engenharia de Software:
Desenvolvimento .NET
profissionais de desenvolvimento
GRADUAÇÃO
e programação.
Engenharia de Computação
São programas voltados para a Análise e Desenv. de Sistemas
formação de profissionais de elite,
F ORMAÇÕES
com aulas 100% práticas, corpo
Desenvolvedor Java
docente atuante no mercado,
Desenv. Java: Sist. Distribuídos
acesso à mais atualizada biblioteca
Gestor de TI
de TI do Rio, laboratórios equipados
Desenvolvedor Web .NET 2008
com tecnologia de ponta, salas de
MCITP Server Administrator
estudo e exames.
SQL Server 2008

r/esti
Acesse nosso site e conheça todos os nossos programas: [Link]/esti

TURMAS
NO RIO DE
JANEIRO
[Link] - cursos@[Link] - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO

 EDITORIAL

D
urante muitos anos, as metodologias tradicionais foram utilizadas
amplamente pela maioria dos projetos e das empresas de desen-
volvimento de software, e o modelo cascata era tido como o mais
completo e efetivo. Essa situação se modificou assim que surgiram os pri-
meiros projetos ágeis, logo após o manifesto ágil em 2001, e o mundo do
desenvolvimento de software se dividiu entre os mais conservadores e os
Ano 3 - 32ª Edição - 2011 Impresso no Brasil
simpatizantes do Scrum, XP e outras metodologias ágeis.
No entanto, apesar dos casos de sucesso serem muitos, logo começaram
Corpo Editorial a aparecer os primeiros estudos de caso que apresentavam problemas
utilizando tais metodologias e, principalmente, o Scrum. O Scrum, mesmo
Colaboradores com inúmeras vantagens em várias perspectivas, deve-se deixar claro, não
Rodrigo Oliveira Spínola
Marco Antônio Pereira Araújo é a solução perfeita para todos os problemas da área de Engenharia de
Eduardo Oliveira Spínola Software, logo, não é a “bala de prata” dos projetos de desenvolvimento.
Neste contexto, esta edição da Engenharia de Software Magazine desta
Capa e Diagramação
Romulo Araujo - romulo@[Link] o artigo “Scrum: Não funcionou para você?”. O artigo apresenta algumas
lições aprendidas durante os últimos anos na área da qualidade de sof-
Coordenação Geral
tware e também na liderança em equipes de desenvolvimento trabalhan-
Daniella Costa - daniella@[Link]
do com Scrum. A principal intenção de listar tais lições é ajudar outras
Revisor e Supervisor equipes que possam vir a ter os mesmos (ou semelhantes) problemas no
Thiago Vincenzo - [Link]@[Link]
decorrer do desenvolvimento de aplicativos e sistemas.
Jornalista Responsável Além desta matéria, esta edição traz mais sete artigos:
Kaline Dolabella - JP24185 • Tenho um Chefe difícil: e agora?
Na Web • Modelagem em uma Visão Ágil
[Link]/esmag • Entendendo melhor SOA e ESB
Apoio • Especificação de Casos de Uso
• Engenharia de Software: Sobre a Necessidade de Educação Continuada
• Refatoração para Padrões - Parte 5
• Modelagem Temporal, de Implantação, de Artefatos e de Componentes
através da UML.

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se você tiver algum problema no recebimento do seu exemplar ou precisar de Rodrigo Oliveira Spínola
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de [Link]@[Link]
bancas de jornal, entre outros, entre em contato com: Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação
Isabelle Macedo e Uellen Goulart – Atendimento ao Leitor
[Link]/mancad
(UNIFACS, 2001). Colaborador da Kali Software ([Link]), tendo minis-
(21) 2220-5338 trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e
Kaline Dolabella Desenvolvimento Orientado a Objetos. Consultor para implementação do [Link]. Atua
Gerente de Marketing e Atendimento
kalined@[Link]
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
(21) 2220-5338 UFRJ. É Colaborador da Engenharia de Software Magazine.

Publicidade
Marco Antônio Pereira Araújo
Para informações sobre veiculação de anúncio na revista ou no site entre em
maraujo@[Link]
contato com:
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
Cristiany Queiroz
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
publicidade@[Link] Computacionais e Bacharel em Matemática com Habilitação em Informática pela
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
Fale com o Editor! do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
vontade para entrar em contato com os editores e dar a sua sugestão! Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, Colaborador da Engenharia de Software Magazine.
entre em contato com os editores, informando o título e mini-resumo do tema que você
gostaria de publicar:
Eduardo Oliveira Spínola
eduspinola@[Link]
Rodrigo Oliveira Spínola - Colaborador
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
[Link]@[Link]
gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS)
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
 ÍNDICE

Caro Leitor, Por trás do óbvio

06 – Tenho um Chefe difícil: e agora?

Agilidade
Glênio Cabral

08 - Modelagem em uma Visão Ágil

Para esta edição, temos um conjunto de 5 vídeo aulas. Lenildo Morais

Estas vídeo aulas estão disponíveis para download no Portal 13 - Scrum: Não funcionou para você?
Gabriela de Oliveira Patuci
da Engenharia de Software Magazine e certamente trarão
Desenvolvimento
uma significativa contribuição para seu aprendizado. A lista
18 - Modelagem Temporal, de Implantação, de Artefatos e de Componentes
de aulas publicadas pode ser vista abaixo:
através da UML
Geraldo Magela Dutra Gonçalves

26 - Refatoração para Padrões – Parte 5

Tipo: Processo
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
Título: Especificação de casos de uso na prática – Partes 6 a 10
Autor: Rodrigo Oliveira Spínola Engenharia
Mini-Resumo: Definir requisitos não é uma atividade trivial. Uma das 33 - Engenharia de Software: Sobre a Necessidade de Educação Continuada
formas de realizar esta atividade é através da especificação de casos de Antonio Mendes da Silva Filho
uso. Neste sentido, nesta série de vídeo aulas apresentaremos um conjunto
de especificações de casos de uso. Os cenários serão especificados passo 39 - Especificação de Casos de Uso
a passo considerando tópicos como fluxo principal, fluxo alternativo e Rodrigo Oliveira Spínola
regras de negócios.
40 - Entendendo melhor SOA e ESB
Lenildo Morais
Edição 05 - Engenharia de Software Magazine 5
Pos trás do Óbvio

Glênio Cabral
gleniocabral@[Link]
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-
co. Idealizador do site de educação infantil [Link].

Tenho um Chefe difícil:

e agora?
N
o mercado atual, todos os líderes sabem como mo- 3. Faça sempre o dever de casa e não dê brechas para pu-
tivar suas equipes estabelecendo um ótimo clima xões de orelha. A produtividade e a competência sempre
organizacional, certo? Errado! serão recompensadas e desejadas, mesmo que seu chefe
Parece estranho, mas ainda há líderes que possuem um seja um Hitler. Seu chefe é insensível e nunca reconhece
grande talento para promover a desmotivação geral de suas seus méritos? Então dê o melhor de si e continue fazendo
equipes. Pesquisas apontam que chefes considerados difíceis seu trabalho com responsabilidade e seriedade, porque não
nunca admitem seus erros, não costumam dar feedbacks, são há chefe que resista ao charme de um bom profissional.
ditadores e estão sempre insatisfeitos com o desempenho dos Essa postura de excelência costuma inclusive abrir portas
seus subordinados. Será que você, caro leitor, tem sido premia- para outras possibilidades profissionais.
do com um chefe assim? Na dúvida, aí vão algumas dicas para 4. Não se envolva em fofocas nem fique falando mal de
que você saiba lidar melhor com um chefe complicado. seu chefe para os colegas de trabalho. Essas coisas costu-
1. Certifique-se de que você não é a única pessoa a ter mam chegar aos ouvidos dele, o que pode tornar a situação
dificuldades de lidar com seu chefe. Líderes que são com- ainda mais difícil. A maledicência corporativa nunca é uma
provadamente um problema costumam ser encarados dessa boa postura profissional. Além do mais, numa possível
forma por todos, e não apenas por uma pessoa. Se você é a transferência de departamento ou de função a fama de
única pessoa a ter problemas com seu chefe, o problema pode encrenqueiro só irá dificultar as coisas.
estar em você. 5. Sempre que possível, solicite do seu chefe o feedback
2. Nunca bata de frente. Estudos comprovam que as relações de suas ações. Se tem algo que os chefes complicados não
pessoais têm um peso muito grande no mercado brasileiro. se sentem à vontade para fazer é dar um feedback. Isso
Por isso, nada de bater de frente, pois você poderá ser mal acontece porque eles são péssimos no quesito comunica-
interpretado. É preciso ter o cuidado de conhecer melhor o ção, e como dar um feedback é basicamente comunicar-
chefe para saber a melhor hora de falar, de opinar e de pedir se, a coisa acaba emperrando. Por isso, em alguns casos
algo. Em nossa cultura, essas coisas costumam dar muito é preciso “arrancar” o feedback do chefe. Através desse
resultado. Você está na sua razão? Ainda assim bater de frente retorno o colaborador terá informações importantes para
nunca será uma boa. Vá com calma e pelas beiradas. aprimorar suas ações e ser mais produtivo. O que, diga-se

6 Engenharia de Software - Tenho um chefe difícil: e agora?

 POR TRÁS D O ÓBVIO

de passagem, fará com que seu chefe reclame menos do seu Por fim, se nada disso adiantar, talvez seja a hora de ter uma
desempenho. conversa franca com o departamento de recursos humanos e
6. Não adote uma imagem de vítima e de coitadinho. Os bons sinalizar que está disposto a mudar de ares. Mas lembre-se
profissionais não agem assim. Se você se sente perseguido de duas coisas: primeiro, chefes difíceis estão com os dias
ou não reconhecido por seu chefe, não ande cabisbaixo pelos contados. Não há mais espaço para eles num mercado de
cantos. Seja auto-motivado e tenha sempre a consciência trabalho globalizado e dinâmico. E segundo, você pode até
do seu valor e potencial. Lembre-se: os bons profissionais deixar uma empresa por causa de um chefe difícil, mas se for
sempre são reconhecidos e desejados. Se não pelo seu chefe, um bom profissional o mercado de trabalho nunca o deixará.
pelo concorrente ao lado. Siga em frente.
7. Desenvolva o hábito de engolir alguns sapinhos. Ao
longo das nossas vidas, sempre estaremos engolindo alguns
anfíbios saltitantes. Isso acontece porque nem sempre vamos
poder chutar o balde quando bem entendermos. Afinal, Feedback
Dê seu feedback sobre esta edição! eu
temos contas para pagar e família para sustentar. Sem falar

s
Dê
que mudar de função ou de emprego não é garantia de que A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
se estará livre para sempre de um chefe difícil. Manter o Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
controle e esperar a hora certa de tomar certas decisões são Dê seu voto sobre este artigo, através do link:
posturas que sempre acompanham o profissional maduro e [Link]/esmag/feedback
que sabe o que quer.

Edição 32 - Engenharia de Software Magazine 7

Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Modelagem em uma Visão Ágil

O que? Quanto? E para que modelar?

De que se trata o artigo?

Apresentar, através de uma visão geral, os valores,
princípios e práticas da modelagem ágil (Agile Mo-
deling), abordando aspectos como: trabalho em

A
modelagem, do ponto de vista conjunto, participação efetiva do cliente, comuni-
ágil, é um método eficiente cação, rascunhos como forma de modelagem e a
que tem como objetivo tornar utilização da modelagem na obtenção da qualida-
mais produtivos os esforços da tarefa de e de maior produtividade.
de modelar, tão comum nos projetos de
software. Para que serve?
Os valores, princípios e práticas da Mo- Proporcionar às equipes de desenvolvimento de
delagem Ágil podem auxiliar as equipes software maior conhecimento sobre a modela-
na definição de componentes técnicos gem ágil, uma vez que grande parte dos projetos
de alto e baixo nível que farão parte do de desenvolvimento ainda precisa evoluir neste
desenvolvimento de software. Artefatos aspecto.
sofisticados elaborados por ferramentas
Lenildo Morais de alto custo nem sempre são os melho- Em que situação o tema é útil?
lenildojmorais@[Link] res para ajudar no desenvolvimento do Nos projetos de desenvolvimento de software,
É analista de sistemas e analista de testes. software. Modelar o software em grupo sobretudo quando se deseja buscar mercados
Atualmente está cursando mestrado no centro e com a participação dos usuários, utili- externos ou expandir seus clientes internos au-
de informática da UFPE em engenharia de
zando rascunhos, é vista como uma boa mentando a satisfação dos mesmos.
software com ênfase em testes e qualidade
de software. prática para se conseguir isto.
Uma das dificuldades mais comuns nas
equipes de desenvolvimento é como con- com o objetivo de observar se as ne-
Conteúdo Multimídia! seguir efetivamente capturar as necessi- cessidades foram atendidas. Ao longo
dades dos usuários. Uma das maneiras deste artigo veremos os conceitos e al-
Neste artigo você encontra o vídeo: “Uma visão
geral da UML”. de se alcançar isso passa pelo desenvol- guns aspectos importantes no tocante
vimento iterativo, onde são entregues à modelagem ágil, assim como alguns
[Link]/esmag software funcionando constantemente benefícios trazidos por esta prática.

8 Engenharia de Software Magazine - Modelagem em uma Visão Ágil

 AGILIDADE

Visão geral da Modelagem Ágil o pedreiro tem um custo menor, assim como um engenheiro
O processo atual de desenvolvimento de software ainda pode gerar demandas para o trabalho de até 100 pedreiros.
está em um nível de qualidade muito abaixo do que seria Dado a natureza do projeto civil, é lógico que haja essa divisão
considerado ideal, isto porque os sistemas são entregues aos de trabalho entre design e construção. Neste cenário, não faz
clientes fora do prazo estipulado no projeto e com um custo sentido as pessoas do projeto serem “engenheiro-pedreiro”,
maior do que o previsto. Além disso, esses sistemas frequen- como pode ser na Engenharia de Software.
temente não alcançam a qualidade desejada pelo cliente e, em Durante a construção de um software são consideradas ba-
muitos casos, não satisfazem as reais necessidades do mesmo, sicamente quatro atividades principais:
levando a altos índices de manutenção ou passando a ideia 1. Compreender o que o usuário quer;
de “isso terá de ficar para uma próxima versão”. 2. Definir como os elementos de software resolverão as neces-
A modelagem ágil é vista como um processo de desenvolvi- sidades do usuário;
mento de software baseado em práticas que visa aumentar a 3. Escrever esses elementos de software e integrá-los;
eficiência das equipes dentro dos projetos. Ao contrário dos 4. Testar os elementos e homologá-los com o usuário.
processos tradicionais, que requer basicamente os mesmos
artefatos para todos os tipos de projetos, a modelagem ágil Antes de tudo, deve-se observar que essas atividades ocorrem
busca a construção e manutenção eficiente de artefatos, muitas vezes dentro de um projeto. Entretanto, considerando
criando-os apenas quando agregarem valor real ao projeto, as quatro atividades, a diferença que há com relação à enge-
e focando principalmente os esforços no desenvolvimento nharia civil é que não existem importantes diferenças no nível
do software. intelectual necessário para desempenhar essas atividades. A
Entretanto, a modelagem ágil não é uma metodologia de atividade de levantamento dos requisitos do software não é
desenvolvimento ágil como eXtreme Programming (XP) ou intelectualmente inferior à atividade de codificar estes requi-
Scrum, mas sim uma boa prática. Ela visa construir e manter sitos. São atividades diferentes, mas não tão diferentes como
modelos de sistemas de maneira eficaz e eficiente, podendo o trabalho do engenheiro e do pedreiro. O erro que muitas
ser utilizada dentro de metodologias ágeis e tradicionais. empresas cometem é achar que analistas de sistemas são como
Já com relação à comunicação da equipe, a modelagem ágil engenheiros civis e programadores são como pedreiros, e isto
pode ser aplicada fazendo com que as pessoas envolvidas não ocorre na prática.
nos projetos colaborem para que a solução atenda ao negócio.
Neste contexto, não é interessante se prender a papéis. Uma Aspectos humanos e técnicos no desenvolvimento de
equipe de desenvolvimento de software é mais eficiente software
se todos são capazes de fazer todas as atividades. Esta boa A modelagem ágil é baseada em uma coleção de práticas,
prática proporciona um trabalho muito mais colaborativo e guiadas por princípios e valores que podem ser aplicados
integrado, uma vez que é comum nas equipes haver pessoas por profissionais de software no dia a dia. Não sendo um
com qualidades diferenciadas. É possível que haja uma pessoa processo prescritivo, não define procedimentos detalhados
com excelente desenvoltura para conversar com os usuários, de como criar um dado tipo de modelo. Ao invés disso, provê
outra pessoa consegue codificar com uma rapidez e qualidade sugestões de como ser mais efetivo. Em resumo, a modelagem
acima da média, e outra pessoa pode ter um conhecimento ágil busca o ponto de melhor custo/benefício entre os artefatos
abrangente para dar soluções a problemas complexos. que devem ser criados para o sistema e o custo de manutenção
É comum algumas pessoas, que não são da área de desen- e atualização desses artefatos. Pode-se citar duas motivações
volvimento de software, acharem que a engenharia de siste- principais para a criação desta metodologia:
mas é próxima da engenharia civil ou engenharia mecânica. 1. O objetivo primário de um projeto de software é o próprio
Enquanto nas engenharias tradicionais existe uma divisão software, e não um grande conjunto de documentos sobre ele;
entre design e construção, na engenharia de software não 2. Um artefato é criado primordialmente para permitir a co-
existe esta separação. municação e a troca de informações entre a equipe e permitir
Quando um edifício é construído, o gerenciamento de pro- a discussão e refinamento do modelo do sistema. Assim, se um
jeto tradicional faz sentido, pois para esse tipo de produto artefato não está passando informações relevantes ao projeto,
(o prédio), é necessário ter uma planta detalhada para poder ele não cumpre seu objetivo básico.
iniciar a construção. Nesse projeto quem é responsável pela
atividade de design é um arquiteto ou engenheiro que possui Basicamente, o que se quer com a modelagem do sistema é
qualificações intelectuais distintas de quem irá efetuar o satisfazer as necessidades dos usuários, garantindo a qualidade
projeto (a construção). O trabalho de construção será desem- interna (ver Nota 1) do software e respeitando as restrições de
penhado pelo pedreiro, que não necessita ter o conhecimento custo e prazo do projeto.
total da engenharia para fazer o seu trabalho. Essa divisão Quando se tem que lidar com muita complexidade técnica,
acontece por conta das características totalmente diferentes que geralmente ocorre em sistemas que lidam com milhares de
entre os dois trabalhadores: um é altamente intelectual, o gigabytes, de usuários, de transações e de processamento distri-
outro é mais braçal. Um engenheiro pode ter um custo alto já buído, um pequeno desvio de disciplina pode levar o sistema ao

Edição 32 - Engenharia de Software Magazine 9

caos. Nesse caso, a modelagem é voltada para o aspecto técnico, No entanto, no nosso contexto rascunho é um esboço, deli-
em que é obrigatório conhecer a estrutura interna dos compo- neamento, trabalho prévio de redação feito antes de passar
nentes, as dependências, algoritmos complexos, etc. a limpo.
Todo projeto possui restrições de custo e prazo. Não se tem Por alguma razão, profissionais de informática possuem
todo tempo e dinheiro do mundo para fazer o software. A mis- um vício por artefatos digitais. É comum ter preferência
são de um bom “modelador” é administrar as expectativas do por arquivos que estão em algum lugar do HD. Contudo,
cliente, avaliando com ele quais problemas são prioritários. a indústria sobreviveu várias décadas sem o computa-
Uma das coisas que as metodologias ágeis trouxeram à tona é dor, e várias áreas de atuação vivem em paz sem o uso
a importante participação dos usuários ou clientes para auxiliar das máquinas. Na área de desenvolvimento de software
na modelagem do sistema: seja elaborando um mapa mental, podemos também utilizar meios que não são digitais.
rascunhando uma tela, ou testando um release que acabou de Quando falamos em modelagem de um software, uma
ser liberado. Os usuários, clientes ou stakeholders possuem um das grandes dúvidas das equipes de projeto é quão longe
papel importantíssimo para gerar as demandas corretas e avaliar devemos nos aprofundar em detalhes. Como ponto de
a qualidade dos trabalhos executados. Isso requer uma comuni- partida (apoio) podemos nortear nosso raciocínio através
cação rica entre o cliente e todos os envolvidos no projeto. de questionamentos como:
Focando nos usuários ou em aspectos mais técnicos, é sem- 1. Qual é o nome do projeto?
pre importante estabelecer o escopo da modelagem ágil para 2. Qual é a dúvida que tenho?
esclarecer o que pode e o que não pode ser atendido por este 3. Quem poderá modelar isso junto comigo para obter as
processo. A modelagem ágil é um complemento aos processos respostas?
existentes, não é uma metodologia completa. Ela não é uma 4. Qual é o modelo certo?
espécie de receita mágica que resolverá todos os problemas,
tampouco uma técnica que garantirá melhores resultados. A Quando nos fazemos estas perguntas significa que esta-
ideia por trás da modelagem ágil é a de utilizar seus esforços mos com o cliente e querendo saber o que é o projeto, ou
de maneira mais racional e permanecer focado no projeto, seja, na fase de levantamento de requisitos descobrindo
aumentando sua eficiência no desenvolvimento do projeto. os objetivos, o escopo, as funcionalidades, os riscos. Logi-
A modelagem ágil não visa à eliminação da documentação. camente quem ajudará a obter essas respostas é o cliente.
Simplesmente diz que a documentação deve ser feita de modo Estando, portanto, o analista de requisitos e o cliente reu-
mais racional, maximizando o investimento do cliente no nidos, o ponto principal da reunião é ter uma compreensão
processo de desenvolvimento. em alto nível do sistema, e não todos os detalhes. Não é
A documentação sem dúvida é uma forma importante de conveniente nessa reunião discutir as minúcias. Detalhes
comunicação nos projetos de software. Entretanto, o pior meio serão adicionados iterativamente e de maneira incremental
de comunicação e documentação são artefatos sendo troca- durante todo o projeto.
dos via e-mail. Infelizmente muitos projetos ainda utilizam Modelos também são formas de decisões ou percepções.
somente esse meio pobre de comunicação. Esta é a maneira Nesse caso, a forma da percepção das funcionalidades e
menos eficiente e mais fria de trocar ideias. Já um meio rico decisão do escopo inicial do projeto. Um dos valores da
de se comunicar é a maneira compartilhada de demonstrar modelagem ágil é “modelar com um propósito” e, muitas
graficamente as propostas, como rascunho ou um quadro vezes, modelar com um propósito significa buscar os cri-
branco. A prática é bem simples: junta-se as pessoas numa térios de sucesso do projeto. A modelagem busca atender
sala, permitindo que elas colaborem entre si, trocando ideias e ao usuário apresentando qualidade e reduzindo custo
sentimentos com o auxílio de um meio gráfico compartilhado. ou prazo do projeto. É altamente questionável quando se
A eficiência dessa técnica é comprovada em workshops de modela só para cumprir “etapas” do processo ou porque
requisitos com o cliente ou em discussões arquiteturais dentro o processo de desenvolvimento exige tal modelo.
da equipe. O resultado dessas reuniões são rascunhos que Uma das questões relevantes, vistas anteriormente, é “Qual
podem ser feios na forma, mas são perfeitos para o propósito é o modelo certo?”. É importante ressaltar que há uma quan-
de modelagem do sistema. tidade infinita de maneiras de se modelar. Um esboço feito de
forma conjunta com as partes interessadas é um meio muito
Rascunhos como forma de modelagem eficiente de capturar requisitos e descobrir como atingir o
Sempre que falamos em rascunho, as pessoas ficam com objetivo de fazer um software com qualidade externa (ver
impressão de coisas mal feitas ou informalidade em excesso. Nota 2), que atenda às expectativas dos usuários.

Nota 1: Qualidade Interna Nota 2: Qualidade Externa

Capacidade do software de satisfazer as necessidades implícitas, ou seja, requisitos relacionados Capacidade do software de satisfazer as necessidades explícitas, como por exemplo, o
à estrutura do software, como por exemplo, a integridade dos dados ou codificação mais atendimento às funcionalidades acordadas com o cliente ou o desempenho esperado pelo
adequada. software, sempre observando a percepção do usuário.

10 Engenharia de Software Magazine - Modelagem em uma Visão Ágil

 AGILIDADE

A importância de se escrever documentos de Entretanto, a prática do excesso de documentação ainda

requisitos ocorre em muitos projetos. A implantação da modelagem
A vantagem em se fazer com que os clientes e usuários ágil dentro da cultura de desenvolvimento de software é uma
participem da modelagem do sistema utilizando artefatos e experiência tanto interessante quanto traumática, devido à
ferramentas simples, como rascunhos em papel ou no quadro grande mudança de pensamento trazida pelo método. Para
branco, é promover a colaboração e ganhar agilidade na cap- direcionar os esforços em torno da modelagem ágil, existem
tura de requisitos. Porém, algumas pessoas ou empresas não alguns princípios que devem ser observados para que o pro-
reconhecem artefatos em papel como “válidos” no processo cesso adotado seja realmente ágil. Dentre esses princípios, os
de desenvolvimento. Isso leva a uma burocratização desne- mais importantes são:
cessária na captura de requisitos. Princípios Fundamentais
Muitas pessoas levantam requisitos em artefatos informais • Software é seu principal objetivo: Produzir softwares que
para depois transformá-los em casos de uso, especificações funcionem;
suplementares, protótipos, documentos de regras de negócio • Racionalização de artefatos: Racionalização da documenta-
e outros quando “voltam para casa”. Isto é, preenchem esses ção, escolhendo aqueles a serem mantidos durante o processo
templates depois das reuniões, formalizando o levantamento. de desenvolvimento;
Como houve uma transformação de artefatos, é típica uma • Modele com um propósito: Para atender a realidade e para
revisão com o cliente para obter uma aprovação. O problema é melhorar a comunicação;
que essa aprovação na maioria das vezes não ocorre. Ao ver os • Maximize o investimento do Stakeholder: Valorizar a pes-
artefatos transformados o cliente lembra-se de mais requisitos soa chave que representa a empresa.
que são mais uma vez capturados em artefatos informais e o
ciclo se repete muitas vezes. Com isso, levam-se semanas para Princípios Complementares
se aprovar os requisitos e um tempo precioso é perdido. • Conteúdo é mais importante que representação: Despren-
O objetivo de se trabalhar com rascunhos é rapidamente der-se um pouco de protótipos, apresentando o software
transformá-los em software funcionando, de modo que seja en- rodando como uma importante forma de validação junto ao
tregue ao cliente o software a ser homologado e não documen- cliente;
tos a serem aprovados. Não se deve perder tempo aprovando • Cada um tem algo a aprender com o outro: Na modelagem
documentos de requisitos depois que foram levantados, pois ágil é comum a participação ativa do cliente. Esta interação
eles nunca serão aprovados, e mesmo que sejam aprovados o mais estreita permite que ambas as partes (produtor e clien-
cliente poderá mudar de ideia quando ver realmente o que ele te) se entendam melhor, trazendo importantes ganhos ao
quer de fato. Num contexto geral, software funcionando ainda projeto;
é o melhor artefato para levantamento de requisitos. Dessa • Adapte o modelo à organização: Cada projeto possui parti-
forma, os usuários olham o software e solicitam alterações cularidades que precisam ser observadas. Muitas vezes estas
no software e não em documentos. Software é a única coisa particularidades estão relacionadas com o estilo da empresa
concreta que realmente validamos com os usuários. produtora do software e neste caso o modelo deve estar ali-
Documentos de requisitos têm como objetivo registrar o que nhado a ela;
os usuários esperam da aplicação independente da solução • Comunicação transparente e honesta: Com a participação
técnica. Isso faz com que esses documentos sejam simples e efetiva do cliente é importante prezar pela transparência das
rápidos de serem elaborados. Mas o mais importante é que informações, que devem estar de comum acordo para ambas
esses artefatos sejam elaborados na reunião de levantamento as partes;
e não “em casa”. Deve-se sair da reunião com requisitos levan- • Atentar para os instintos da equipe: Ouvir as sugestões e
tados e documentados, depois disso, é fazer o software para reclamações da equipe, pois talvez o problema que ela encon-
cumprir o planejamento da iteração. trou possa dificultar no restante da implementação.

Modelagem na obtenção da qualidade A modelagem ágil também possui dois tipos de práticas: as
Até então vimos que a modelagem ágil pode melhorar e práticas centrais e as práticas suplementares. Elas sugerem
documentar decisões focadas na qualidade da aplicação, pontos que devem ser observados pelas equipes de desenvol-
facilitando a comunicação e disseminando ideias dentro do vimento de software que ainda não utilizam a modelagem ágil,
time. A modelagem ágil possui um princípio chamado Travel mas que pretendem introduzi-la em seus projetos.
Light. Este princípio diz que manter modelos é difícil, e pode
se tornar ainda mais se estes forem complexos e detalhados. Práticas Centrais
Especialistas na área afirmam que três ou quatro modelos • Trabalho em Equipe: Participação dos vários perfis da equipe
que forneçam uma visão geral da análise, da arquitetura e do do projeto durante o desenvolvimento de software, incluindo
design são suficientes para melhorar a comunicação da equipe. o Stakeholder, proporcionando o conhecimento coletivo e evi-
É errado pensar que quanto maior o número de documentações tando que somente uma pessoa domine todo o processo. Uma
melhor será o projeto. A documentação precisa ser enxuta. forma de disseminar o conhecimento pode ser a divulgação

Edição 32 - Engenharia de Software Magazine 11

dos modelos produzidos colocando-os em painéis, parede ou Entretanto, o mais importante de tudo é focar nas atividades
outro meio; do desenvolvimento e não nos artefatos criados. Durante o
• Simplicidade: Criação de conteúdo mais leve, descrevendo levantamento de requisitos, as atividades de conversar com o
modelos simples e utilizando ferramentas menos complexas. usuário, obter informações e enriquecer o conhecimento são
mais importantes que os casos de uso, protótipos ou modelos
Práticas Suplementares que surgirem dessa atividade. O importante é a criatividade na
• Produtividade: Utilizar padrões e normas de modelagem, solução do problema, na separação dos conceitos e nas mensa-
aplicando padrões com sabedoria e reutilizando recursos gens trocadas entre os envolvidos no projeto do software.
existentes; Podemos ver também ao longo do artigo que muitas pessoas
• Documentação: Descartar modelos temporários, formali- confundem a atividade de levantamento de requisitos com
zando os modelos de contrato; preenchimento dos templates de artefatos de requisitos. E,
• Propósito: Modelar para entender e para se comunicar; pior ainda, muitas vezes esse preenchimento de artefatos é
• Boas Ideias: Conhecer bem as ferramentas, refactoring e feito simplesmente para cumprir tarefas de um processo de
Test-First Design. desenvolvimento pesado, que muitas vezes interferem de
forma negativa na criatividade das pessoas.
Comprovação através do código O que o cliente quer é o software e não os documentos que
Uma das discordâncias que muitas equipes têm contra meto- abstraem o que se espera do software. Muitos dos artefatos
dologias ágeis é o foco no código. Entretanto, é no código que sugeridos e utilizados na modelagem ágil são rascunhos de
a alta coesão e baixo acoplamento oferecem benefícios. Um casos de uso, rascunhos de protótipos de tela, rascunhos de
dos princípios da Modelagem Ágil é: “Prove com Código”. diagrama de atividades. Tudo em papel, desenhados junto com
Isto é, os modelos são somente uma abstração daquilo que se o cliente e com isso automaticamente aprovados por ele. Esses
está construindo de fato. Mas será que o modelo está correto? rascunhos são então transformados em software funcionando,
Será que ele é implementável? Para saber estas respostas é seguindo as boas práticas da Engenharia de Software.
necessário “provar o modelo com código”.
Referências
É importante ressaltar que a atividade de modelagem visa
obter uma qualidade do código e não do modelo. Uma boa AMBLER, SCOTT. Home Page Agile Modeling
modelagem tem como objetivo obter um bom código, e não um [Link]
bom modelo. A qualidade sempre deve focar no código e nos
COCKBURN, ALISTAIR. Home Page w
importantes conceitos de alta coesão e baixo acoplamento. [Link].

Conclusão Feedback
Dê seu feedback sobre esta edição! eu
Este artigo apresentou que artefatos simples podem ser uti-

s
Dê
lizados para aplicar boas práticas de modelagem. Modelagem A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
é uma atividade em grupo (na maioria das vezes) e tudo que Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
se faz deve ser focado em melhorar a qualidade do software e
edição
Dê seu voto sobre este artigo, através do link:
a produtividade da equipe. Modelar simplesmente para “ter
[Link]/esmag/feedback
o modelo” deve ser evitado.

12 Engenharia de Software Magazine - Modelagem em uma Visão Ágil

Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Scrum: Não funcionou para você?

Erros comuns na tentativa de implantar Scrum em times ágeis

De que se trata o artigo?

Neste artigo é apresentada uma lista onde citou-
se o resultado de um estudo que lista quais as
principais causas para os problemas mais fre-
quentes em projetos Scrum. Este estudo foi rea-
lizado dentro dos últimos dois anos em projetos
com times ágeis, inicialmente dentro do papel de
analista de testes e líder de testes, e nos últimos
meses, também no papel de Scrum Master.

Para que serve?

D
urante muitos anos, as metodo- O artigo tem a intenção de ser uma referência
logias tradicionais foram utili- tanto como lições aprendidas de um estudo de
zadas amplamente pela maioria caso, que são consideradas valiosas no ambien-
dos projetos e das empresas de desenvol- te ágil, assim como para abrir precedentes para
vimento de software, e o modelo cascata futuras discussões sobre os pontos levantados
era tido como o mais completo e efetivo. como causas raízes e suas soluções propostas.
Essa situação se modificou assim que Acredita-se que muitas pessoas no meio ágil ou
surgiram os primeiros projetos ágeis, até mesmo fora dele possam contribuir para a
Gabriela de Oliveira Patuci logo após o manifesto ágil em 2001, e o melhoria deste cenário vislumbrado no estudo
opgabi@[Link] mundo do desenvolvimento de software citado.
É formada pela UNICAMP em Tecnologia se dividiu entre os mais conservadores e
em Informática e está cursando mestrado
na área de Engenharia de Software. Possui
os simpatizantes do Scrum, XP e outras Em que situação o tema é útil?
certificação pela Scrum Alliance, tem expe- metodologias ágeis. O tema é útil para os profissionais de Engenharia
riência de três anos no trabalho com me- No entanto, apesar dos casos de su- de Software em geral que planejam iniciar pro-
todologias ágeis e de cinco anos em Testes cesso serem muitos, logo começaram a jetos utilizando metodologias ágeis ou até mes-
e Qualidade de Software. Hoje atua como aparecer os primeiros estudos de caso mo para aqueles que já as utilizam mas estão
Scrum Master em projetos internacionais
pela Ci&T e já palestrou em eventos como
que apresentavam problemas utilizando enfrentando problemas com seus resultados.
Agile Brazil 2010. tais metodologias e, principalmente, o

Edição 32 - Engenharia de Software Magazine 13

Scrum. O Scrum, mesmo com inúmeras vantagens em várias • Scrum Master (SM): É um líder, mas acima de tudo, é um
perspectivas, deve-se deixar claro, não é a solução perfeita para facilitador. O principal objetivo deste papel é remover im-
todos os problemas da área de Engenharia de Software, logo, pedimentos, melhorar o dia-a-dia do time, auxiliar o PO na
não é a “bala de prata” dos projetos de desenvolvimento. construção e priorização do Product Backlog, enfim, garantir
Neste artigo, pretende-se apresentar algumas lições aprendi- a aplicação do Scrum. Um bom Scrum Master deve ensinar
das durante os últimos anos na área da qualidade de software o cliente a maximizar o ROI (Retorno sobre Investimento) e
e também na liderança em equipes de desenvolvimento traba- facilitar o desenrolar das reuniões, tão fundamentais neste
lhando com Scrum. A principal intenção de listar tais lições processo.
é ajudar outras equipes que possam vir a ter os mesmos (ou
semelhantes) problemas no decorrer do desenvolvimento de Outro ponto fundamental, além dos papéis, são as reuniões
aplicativos e sistemas. realizadas no decorrer de uma sprint (Figura 1). Os conceitos
que envolvem estas reuniões e a sprint são apresentados a
Conceitos da Metodologia seguir.
Antes de apresentar os problemas decorrentes do mau uso • Sprint Planning: Define o início de uma sprint com a re-
da metodologia citada, faz-se necessário entender os conceitos alização de tarefas como: identificação dos itens do Product
básicos envolvidos no trabalho com projetos ágeis e a origem Backlog (requisitos) para a construção do Sprint Backlog que
das ideias que definem o SCRUM. será atacado durante a sprint, estimativa em pontos dos itens
No ano de 2001, logo após um encontro onde profissionais que serão desenvolvidos, definição da meta da sprint (commit-
e acadêmicos da área de desenvolvimento de software de- ment) e quebra dos itens (estórias) em pequenas tarefas;
monstraram seu descontentamento com a maneira com que os • Daily Meetings (Stand up Meetings): Reunião, como o
projetos estavam sendo desenvolvidos dentro das empresas, nome já diz, diária e feita geralmente em pé. O costume de
surgiu o Manifesto Ágil. Este manifesto foi o ponto de início fazê-la em pé foi uma maneira escolhida para garantir que só
para os principais conceitos das metodologias que viriam a os 15 minutos determinados seriam utilizados e que o time
seguir. Ele foi traduzido para muitas línguas, inclusive para o não perderia o foco da reunião. O principal objetivo deste
português, e é citado em vários artigos da área de Engenharia pequeno encontro é responder as perguntas base definidas
de Software [1]. pela metodologia: “O que eu fiz desde a última reunião?”,
O Manifesto deu origem a metodologias como XP, Scrum “O que vou fazer até a próxima reunião?” e “Tenho algo que
entre outros e junto com estes conceitos também nasceram os esteja me impedindo?”;
papéis envolvidos neste processo. Estes papéis são: • Retrospective Meeting: Mais uma reunião que tem por base
• Time: Quem realmente desenvolve e produz com qualidade. a resposta a três perguntas. O time todo responde às pergun-
Os membros do time devem ser comprometidos com o trabalho tas: “O que foi bom nesta sprint?”; “O que não foi bom nesta
e responsáveis por atingir a meta de uma sprint (período de sprint?”; e “O que devemos melhorar para a próxima sprint?”.
desenvolvimento). Devem ser cada vez mais auto-gerenciáveis Para esta última pergunta, deve-se escolher entre as respostas
e multidisciplinares. Um time normalmente não ultrapassa o (através de votação no time) quais os pontos que serão desen-
número de nove pessoas e atua em um ambiente adequado volvidos e melhorados para a próxima sprint;
afim de facilitar a comunicação efetiva (um dos pontos mais • Review Meeting: Tem por objetivo apresentar o que foi
importantes em times ágeis); construído durante a sprint pelo time. O time apresenta ao
• Product Owner (PO): É quem faz a ponte entre o cliente PO o que foi desenvolvido até o presente ponto e o próprio
e o fornecedor. Deve ter uma boa noção do produto e das PO decide se o que foi apresentado atingiu ou não a meta da
necessidades do cliente. Responsável por manter o product sprint. Podem se fazer necessários ajustes no backlog ou até
backlog sempre atualizado e priorizar o trabalho das sprints mesmo repriorização de estórias a partir deste ponto.
que virão. Também são atividades do PO definir a visão do
projeto, metas e objetivos das sprints e repassar para o Scrum Vale ressaltar após a conceituação das reuniões, que a atu-
Master o objetivo do produto; ação do Scrum Master, durante toda a sprint é essencial para
o bom andamento do projeto. A participação do PO em todas
as reuniões citadas acima também é essencial, tanto que este
ponto será salientado em breve neste mesmo artigo.

A raiz dos problemas (ou seriam as raízes?)

Depois de alguns anos trabalhando com a metodologia
Scrum, pode-se perceber alguns fatores que se repetem como
os principais vilões e são, muitas vezes, responsáveis pelo
insucesso de projetos e entregas. Feito um estudo inicial e um
levantamento destes fatores já citados, encontrou-se inclusive,
Figura 1. Ciclo de Vida de uma Sprint suas respectivas causas raízes.

14 Engenharia de Software Magazine - Scrum: Não funcionou para você?

 AGILIDADE

Antes de detalharmos os problemas e suas causas, devemos

ter a consciência de que, como em toda e qualquer metodologia,
não desenvolver projetos seguindo suas principais caracterís-
ticas, vai sim acarretar problemas. Vale ter em mente que, ne-
nhuma metodologia pode obter bons resultados se as equipes
não seguem seus valores e premissas corretamente.

Product Owner não envolvido

Visto qual o papel do Product Owner e sua importância
para a metodologia proposta, pode-se analisar o quão grave
é a falta da presença 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 reuniões diárias e principalmente
no momento da Planning, onde todas as dúvidas (ou pelo
menos sua grande maioria) sobre as regras de negócio são
resolvidas, é essencial. Figura 2. Burndown de projeto com block entre os dias 23 e 25/11
Este problema de não envolvimento do PO com o time ou com
o projeto em discussão é normalmente causado pela falta de
profissionais alocados para o papel: um mesmo PO é dividido
entre vários projetos e às vezes, este chega até confundir requi-
sitos, times etc. Este fato, por exemplo, pode ser visto quando
há uma demora para solucionar blocks.
Um dos jeitos mais fáceis para identificar quando um block
está afetando o bom andamento do sprint é o próprio burndo-
wn 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 próxima da linha do ideal (segundo a le- Figura 3. Exemplo de User Story
genda), mas teve um pequeno desvio neste período citado na
capacidade de realizar tarefas. Isto se deve ao fato de que este como base aos casos de testes (isto também será discutido
mesmo time não possuía em mãos o conteúdo necessário para mais adiante).
confecção das páginas acordadas nas estórias. Esta falta de Falando de fatores que levam a insucesso, podemos consi-
conteúdo, aqui sendo considerada o block, foi a principal causa derar alguns fatores que levam estórias a serem mal escritas.
para tal desvio no meio da sprint e pôde ser vista claramente O primeiro fator é uma descrição muito longa. A ideia de
no gráfico durante as reuniões diárias. descrever uma estória é que os principais pontos possam ser
E a segunda pergunta importante a fazer seria: como tratar tratados como uma “checklist” para futuras discussões du-
este problema? A melhor maneira de tentar minimizar os rante a planning meeting. Descrever com muita informação
efeitos deste problema dentro de um projeto seria o Scrum e muitos detalhes pode levar o time a perda da colaboração
Master trabalhar mais próximo ao Product Owner, no senti- e a confiança de que tudo já está escrito (como acontecia em
do de conseguir as informações necessárias e “desbloquear” antigas metodologias). O principal papel da estória é levar o
o time. O papel do Scrum Master também é ajudar o PO a time a estar sempre buscando a comunicação e a colaboração.
seguir os ritos do Scrum e manter o time sempre livre para Se estes pontos não surgirem, perde-se o foco do Scrum.
trabalhar sem blocks. O segundo fator é confundir critérios de aceitação com casos
de teste. Critérios de aceitação são úteis para responder pergun-
Falta de Requisito (Estórias mal escritas) tas do tipo “Quando sabemos que a estória está pronta?” e não
Outro problema sério que envolve diretamente o trabalho para perguntas do tipo “Como testar e como saber se foi feito
do PO são os requisitos (estórias) mal escritos. O requisito, da maneira correta?”. Estas sim são questões para se pensar no
ao contrário do que a maioria das pessoas pensa, é sim parte momento da criação dos casos de testes em si. Critérios devem
fundamental no Scrum. As estórias servem como base para o ser o suficiente para se saber o que deve ser feito do momento da
trabalho tanto durante o desenvolvimento, quanto para testes planning meeting em diante, mas não podem ser tão detalhados
de software e validação em homologação. Eles são feitos de como um documento de Caso de Uso. O uso de ferramentas de
maneira mais resumida, mas não podem deixar de conter as criação de estórias também pode ajudar nestes casos, principal-
informações necessárias para o bom entendimento da funcio- mente nos primeiros projetos dos times com menor experiência
nalidade desejada e devem ser bons o suficiente para servirem ou com Product Owners novos dentro dos times.

Edição 32 - Engenharia de Software Magazine 15

 Seguir o exemplo da Figura 3, ainda é a melhor saída para Pode-se perceber pela Figura 5, um exemplo claro de board do
evitar problemas de estórias mal escritas. O padrão da figura time em que muitas estórias estão sendo executadas ao mesmo
pode ser traduzido como: “Eu, como <papel>, quero <funcio- tempo. Deve-se perguntar: existe mesmo a necessidade de ter
nalidade>, para que <valor gerado ao cliente>”. Este exemplo, pessoas alocadas em tantas estórias ao mesmo tempo? Real-
por estudos na área e experiência pessoal, é o modelo mais mente não existe nenhuma tarefa que estas pessoas poderiam
utilizado em times ágeis no mercado até hoje. Abaixo um estar atacando na primeira estória? Se o time é multifuncional,
exemplo de estória que segue o modelo da Figura 3. por que não dividir tarefas de teste com desenvolvedores,
“Eu, como Product Owner, quero que a home page tenha tarefas de webdesign com testers, etc.? Responder todas estas
uma busca, para que todo usuário possa acessar o conteúdo perguntas pode ser um bom ponto de partida para a solução
que deseja rapidamente.“ do problema de não entregar estórias totalmente prontas (done)
ao final da sprint e ter várias estórias iniciadas.
Várias estórias em desenvolvimento
Uma ideia muito utilizada nos processos ágeis é o “one piece Estimativas Otimistas
flow”. A tática de atacar todos juntos o mesmo problema, um a Outro problema frequente que pode ser analisado durante
um, é um dos motivos da metodologia ser representada por uma os projetos ágeis são as estimativas erradas. Quase sempre,
foto de um time de rugby (todo o time atacando junto e ao mes- as estimativas são otimistas e os resultados são catastróficos.
mo tempo é exatamente a jogada Scrum). Na Figura 4 podemos Será que somos mesmo capazes de fazer o trabalho proposto
ver como este time se posiciona para resolver a jogada. em tão pouco tempo? Esta é uma das perguntas que o time
Se não estamos “atacando” as estórias uma por vez, este nunca se faz quando está em meio à pressão do Scrum Master e
pode ser um dos pontos de atenção para o não cumprimento principalmente, do Product Owner. É claro que o cliente (neste
das metas finais. Tentar realizar todas as estórias de uma vez caso a figura do Product Owner) sempre terá o interesse em
é um dos maiores problemas e pode ser visto em muitos times ver o produto final pronto em menos tempo, mas o que temos
na atualidade. que ter em mente é que esta pressa por chegar à reta final não
faz com que o trabalho fique efetivamente pronto mais rápido,
e o pior, acarreta problemas ainda mais sérios como defeitos
em produção e regressão no desenvolvimento do software. O
que deve ser relembrado durante a planning meeting é o fato
de quem estima o esforço é o time. Scrum Master e Product
Owner devem participar apenas para facilitar a reunião e
solucionar possíveis dúvidas, respectivamente.

Projeto Scrum vendido com prazo e/ou Escopo

fechados
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 número de sprints, ou valor por sprint, e nunca
escopo fechado. Scrum não tem escopo fechado, é incremen-
Figura 4. Time de rugby (representação do SCRUM) tal, e como tal, tem o direito de ser mutável. Prazos e escopos
fechados são 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
várias maneiras que vem sendo utilizadas, mas uma das mais
simples pode ser vista pela fórmula/exemplo a seguir:
Consideremos um time fixo, com velocidade e tamanho de
sprints também 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 cálculo de venda deste projeto? Dividimos o nú-
mero de pontos do backlog (1000) pelo tamanho das sprints
(50) e vamos obter o número das semanas (40 semanas). A
este número de semanas, somamos uma sprint a cada 5, para
Figura 5. Board com várias estórias sendo feitas ao mesmo tempo que possíveis defeitos possam ser corrigidos e mudanças de

16 Engenharia de Software Magazine - Scrum: Não funcionou para você?

 AGILIDADE

escopo possam ser mais bem tratadas. Neste caso, ficaríamos testadores fará com que a qualidade do produto fique ainda
com 24 sprints. O cálculo final seria o número final de sprints mais elevada) e logo após a finalização do desenvolvimento, no
(24) vezes o número de horas de todo o time. ambiente separado para testes (o teste funcional que as equipes
já fazem), onde todos os defeitos são realmente reportados, às
Testes ágeis ou método cascata? vezes até através de uma ferramenta;
É claro que o desenvolvimento ágil chegou nos últimos anos • Dia Final: Os testes se concentram em Testes de Regressão,
com peso muito forte e que está tomando cada vez mais espaço para que se possa confirmar a qualidade verificada anterior-
nas salas em empresas no mundo todo. O que devemos nos mente no produto e em Retestes, para assegurar que todos os
perguntar é: Estamos TESTANDO de maneira ágil? defeitos reportados foram corrigidos.
Bem, se desenvolvemos de maneira incremental, por que
muitos ainda deixam os testes como a última atividade da Este é o início de uma das várias propostas que estão sendo
cadeia? Sem dúvida, como resultado das pesquisas realizadas feitas para minimizar os problemas que vem sendo encontra-
nos últimos anos, esta é a principal causa de problemas nos dos na disciplina de testes em equipes ágeis.
projetos onde o escopo alterado e a falta de qualidade na en-
trega foram ressaltados pelo cliente. Como justificar muitos Conclusão
defeitos ao final do projeto? Simples dizer se notarmos que Este artigo apresentou um estudo sobre quais os principais
os testes são deixados para o final da sprint da mesma forma problemas encontrados em projetos utilizando a metodologia
como já era feita no método cascata. Scrum.
Mudamos de metodologia, devemos mudar de paradigma. Foi apresentada uma lista de problemas frequentes, junta-
Casos em que o time todo ajuda a testar e depois o especialista mente com a conceituação básica do que é a metodologia e
em testes fica bloqueado até o final da sprint ou até mesmo como deveria ser tratada, para que todas as equipes tenham a
que o testador fica com todos os testes e, por falta de tempo, chance de pensar mais sobre o assunto e tentar melhorar em
defeitos acabam não surgindo, são frequentes. É importante futuros projetos.
ressaltar: temos que mudar o paradigma e começar a fazer tes- Algumas ideias já foram apresentadas como possíveis solu-
tes também de maneira incremental. Deixamos este conteúdo ções para a maioria das questões citadas, mas claro que seria
para um próximo artigo, mas esta questão pode ser utilizada necessário outro artigo para tratarmos das melhores soluções
como o ponto inicial para que todos nós pensemos em como para cada um dos itens da lista. Assim como o estudo realizado
resolver o problema. para verificar os pontos que afetavam a qualidade de entrega
De uma forma geral, pode-se explicar uma possível solução em projetos Scrum, seriam necessários outros estudos voltados
para testes funcionando como uma espécie de gargalo no para todas as possíveis soluções. Precedentes para trabalhos
trabalho do time, com a criação dos Testes Ágeis ou Testes futuros já começam a surgir e poderão ser verificados em
Incrementais. O profissional da área de testes pode e deve artigos futuros.
começar 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 Referências
de testes e que todo o trabalho seja cumprido de forma mais
[1] BECK, K.; FOWLER, M. et al (2001). Manifesto for Agile Software Development.
eficaz e incremental:
[Link]
Dia a dia de testes dentro do Scrum:
• Dia 0: Antes mesmo da planning meeting, o analista de [2] CRISPIN, L; GREGORY, J. (2009). Agile Testing: A Practical Guide for Testers and Agile Teams.
testes, aproveitando-se de sua visão geral do produto, poderá Addison-Wesley Professional. ISBN 0321534468.
revisar os requisitos (estórias), fazendo com que estas fiquem
[3] COHN, M. (2004). User Stories Applied for Agile Software Development. Addison-Wesley
mais claras e completas. Este trabalho pode ajudar tanto o
Professional. ASIN B000SEFH1A.
PO como o time todo, já que a planning será muito mais pro-
veitosa tendo um requisito mais completo e revisado por um [4]PEREIRA, R. (2008). 10 Benefits of One Piece Flow.
membro do time; [Link]
• Dia 1: Início do desenvolvimento. Enquanto nada está desen-
volvido, criam-se os casos de testes baseados nos critérios de Feedback
Dê seu feedback sobre esta edição! eu
aceitação das estórias. Este trabalho será bem reduzido pelo
s
Dê

fato da revisão já ter sido feita anteriormente; A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

• Dia 2 a Dia n: Durante todo o desenvolvimento, os testes Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
edição
serão realizados em duas etapas: durante toda a sprint no Dê seu voto sobre este artigo, através do link:
ambiente dos desenvolvedores (assim muitos dos defeitos [Link]/esmag/feedback
serão antecipados e a comunicação entre desenvolvedores e

Edição 32 - Engenharia de Software Magazine 17

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software

Modelagem Temporal, de Implantação, de

Artefatos e de Componentes através da UML
Abordagem Prática – Parte 4
De que se trata o artigo? mentação desenvolvida de modo draft, no início do
Esse artigo apresenta os Diagramas de Temporiza- projeto, pode ser detalhada ao longo dele, paralela-
ção, que integram o grupo de diagramas da UML mente às atividades de implementação e testes.
destinados a modelar comportamento. Apresenta
também os Diagramas de Artefatos, Diagramas de Em que situação o tema é útil?
Componentes e Diagramas de Implantação, desti- Sistemas com estados tempo-dependentes de
nados à documentação nas atividades de projeto de forma contínua podem valer-se dos Diagramas de
desenvolvimento de sistemas. Temporização para especificação das transições
permitas e das restrições de tempo associadas a es-
Para que serve? sas transições. Já sistemas com topologia não trivial
A mesma visão dos artigos anteriores se aplica aqui. e/ou extensa, necessitam modelagem através dos
Apresentar a notação de forma clara e objetiva, pro- Diagramas de Implantação. Sistemas desenvolvidos
curando destacar principalmente os elementos mais com orientação a componentes são cada vez mais
Geraldo Magela Dutra Gonçalves comuns e enfatizam a desejada capacidade de reu-
[Link]@[Link]
úteis nas situações reais de modelagem. Procura-se
É graduado em Engenharia Civil e possui es- uma maneira prática de aplicação dos recursos, sem so, onde Diagramas de Componentes serão úteis em
pecialização em Análise e Desenvolvimento de grandes ônus para os cronogramas de projeto. Docu- sistemas de porte médio a grande.
Sistemas, ambas pela Universidade Federal de
Juiz de Fora. É técnico em TI da Universidade

A
Federal de Juiz de Fora onde trabalha com
literatura técnica, hoje vasta acuradamente as abstrações capturadas
desenvolvimento de sistemas de informação e
informática desde 1988. É professor do Curso e diferenciada, costuma ser por cada um deles. Então, classifica os
Superior de Tecnologia em Análise e Desenvol- unânime em classificar os dia- treze diagramas da UML em quatro
vimento de Sistemas da Fundação Dom André gramas da UML (Unified Modeling categorias:
Arcoverde em Valença/RJ. Language) em dois grandes grupos: Dia- • Modelagem Estrutural: Diagramas de
gramas Estruturais e Diagramas Com- Casos de Uso, Diagramas de Classes, Dia-
Conteúdo Multimídia! portamentais. Não há nada de errado gramas de Objetos, Diagramas de Pacotes
com essa classificação, mas existe uma e Diagramas de Estrutura Composta.
Neste artigo você encontra o vídeo: “Conhecen-
do o diagrama de componentes”. outra, com mais sub-níveis, que traduz • Modelagem de Interações: Diagramas de
de forma mais completa a natureza de Sequência, Diagramas de Comunicação e
[Link]/esmag cada diagrama, assim como tipifica mais Diagramas de Visão Geral da Interação.

18 Engenharia de Software Magazine - Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UML
 PROJETO

• Modelagem Comportamental: Diagramas de Transição representam estados e transições de um objeto ao longo de

de Estados, Diagramas de Atividades e Diagramas de um período de tempo.
Temporização.
• Modelagem da Implantação: Diagramas de Artefatos, pouco Construindo um Diagrama de Temporização
discutidos na literatura técnica mas úteis em sistemas de to- O período de tempo representado nos Diagramas de Tempori-
pologia não trivial, Diagramas de Componentes e Diagramas zação é chamado de linha de vida (lifeline) e pode ser divido em
de Implantação. períodos menores chamados unidades de tempo (time units).
Os estados e transições são representados dentro de um qua-
Nos dois últimos artigos dessa série foram abordados os dro com rótulo td (timing diagram). Um mesmo quadro pode
Diagramas de Transição de Estados e os Diagramas de Ati- representar uma única linha de vida (de um objeto) ou várias
vidades. O Diagrama de Temporização completa o grupo linhas de vida (de uma colaboração) incluindo interferência de
de Modelagem Comportamental. Para encerrar essa série de uma linha de vida de um objeto sobre a linha de vida de outro.
artigos, são apresentados também os três diagramas de mo- Essa interferência se dá através da emissão de mensagens de
delagem da implantação, fase final da execução de um projeto tempo. Isto será tratado à frente, neste artigo.
de desenvolvimento de sistemas de informação. Diagramas de Temporização podem ser apresentados em
duas notações diferentes. Uma delas, mais simples, é denomi-
Restrições Temporais Discretas e Restrições Temporais nada linha de vida de valor, e uma mais completa, denominada
Contínuas linha de vida de estado. Para exemplificar a construção de um
Sistemas com estados ou processos tempo-dependentes po- Diagrama de Temporização, a Figura 1 apresenta um quadro
dem ser classificados em duas categorias bem distintas. Num de temporização (timing frame) para um equipamento de
primeiro grupo, situam-se os sistemas onde os intervalos de caixa eletrônico utilizando a notação linha de vida de estados.
tempo (time units) associados às transições entre estados são Nela aparecem 3 linhas de vida (lifelines), cada uma delas
percebidos de forma discreta. Isto significa que os intervalos representando a linha de vida de objetos controladores dos
de tempo têm durações uniformes e pré-fixadas, não admitindo componentes do equipamento.
variações. Como exemplo, no fluxo de controle de uma máquina Cada linha de vida deve exibir os estados pelos quais o
de lavar moderna, o tempo em que ela estará operando no esta- objeto em questão transita, para que o gráfico de tempo seja
do ‘lavando’ é sempre igual, ou seja, tem um valor fixo finito e apresentado como uma evolução entre eles. Um leitor de car-
pré-fixado, não admitindo variações entre diferentes sessões de tões magnéticos e um mecanismo de contagem e entrega de
execução. Em termos objetivos, a máquina estará operando em cédulas, são equipamentos físicos controlados por objetos do
estado ‘lavando’ por 5 minutos, por exemplo. Tais restrições de software de auto-atendimento bancário. Tais objetos vão emitir
tempo, presentes nos cada vez mais comuns sistemas embarca- sinais que serão recebidos e processados pelos equipamentos,
dos, podem ser modeladas pela rica sintaxe dos Diagramas de ativando ou desativando suas funções. Para executar uma
Transição de Estados e pelos Diagramas de Atividades, como sessão de uso, o software de controle do caixa eletrônico vai
foi demonstrado nos dois artigos anteriores. instanciar objetos de classes controladoras e ativar um fluxo de
Um segundo grupo, reúne sistemas onde as transições entre controle condizente com a escolha do usuário a partir de um
estados de um objeto ou de um grupo de objetos se darão menu de opções. Para realizar um saque, por exemplo, o con-
dentro de um intervalo de tempo não fixo, embora finito. Em trolador transita, em linhas gerais, entre os seguintes estados:
termos práticos, o sistema espera por um evento externo ou disponível – lendoCartão – esperandoSenha – processando –
interno que inicie uma transição dentro de um intervalo de contandoCédulas – disponível. Além disso, o leitor de cartões e
tempo que possui um máximo. O evento deverá ocorrer entre o mecanismo de contagem de cédulas estarão sempre em uma
0 e 5 segundos, por exemplo. Se o intervalo de tempo se es- de duas condições possíveis: disponível/operando.
gotar sem que o evento esperado ocorra, o sistema provocará Para representar a evolução da linha de vida ao longo do
um evento interno que inicia uma transição alternativa. Para tempo, deve ser introduzida uma escala de tempo que divide
modelar essa segunda categoria de sistemas, a UML disponi-
biliza o Diagrama de Temporização.

Diagramas de Temporização
Diagramas de Estados representam os estados possíveis
de apenas um objeto e as transições permitidas entre eles.
Diagramas de Atividades são um caso especial de Diagramas
de Estados onde os estados são ações/atividades e podem
representar a participação de diversos objetos. Diagramas de
Temporização são, também, uma variação de diagramas de
estados e de transições entre eles, mas onde tais transições
estão associadas a restrições de tempo. Em última análise, Figura 1. Timing Frame para um caixa eletrônico

Edição 32 - Engenharia de Software Magazine 19

um determinado período em unidades de tempo (time units). do tempo foram nomeados, ou seja, apenas aqueles em que
A Figura 2 apresenta essa escala, bem como os estados pelos se dão as transições de estados.
quais transitam os três elementos do equipamento.
O gráfico de tempo é então montado horizontalmente Finalizando o Diagrama de Temporização
sobre as linhas de vida, com as transições posicionadas nas Um último elemento nessa forma de representação de Dia-
unidades de tempo. A linha de vida principal, do software gramas de Temporização são as restrições de tempo. Conforme
controlador do equipamento (realizando um caso de uso), referido anteriormente, essa representação dos Diagramas de
vai estar, a princípio, sincronizada com as linhas de vida das Temporização é denominada linha de vida de estados. Ela apre-
unidades auxiliares apenas pela superposição coincidente senta, claramente, estados e transições entre eles, assim como
dos momentos em que acontecem, mas essa representação as restrições temporais aplicadas às transições. A Figura 5
pode ser melhorada com a introdução de mensagens de apresenta um diagrama de temporização completo, com as
tempo, como será demonstrado. restrições de temporização aplicadas.
A Figura 3 apresenta os gráficos representativos da evo-
lução pelos estados dos três componentes do caixa. As ope- Comparando Representações
rações do leitor de cartões e do mecanismo de contagem de Uma segunda maneira de representar Diagramas de Tempo-
cédulas estão sincronizadas com suas referências feitas na rização é denominada linha de vida de valor. Mais adequada
linha de vida do software controlador do caixa eletrônico. quando se está lidando com uma grande quantidade de esta-
Para enriquecer a representação de sincronia e depen- dos e transições, ela é mais compacta e concisa, embora exiba
dência entre as três linhas de vida, pode-se lançar mão menos informações do que o formato anterior. A Figura 6
do recurso de incluir mensagens de tempo, como referido mostra o formato de linha de vida de valor para o caixa ele-
anteriormente. Uma mensagem de tempo deixa uma linha trônico apresentado. Nela, cada estado é representado por
de vida e chega a outra no mesmo diagrama, enfatizando um hexágono e as transições por cruzamentos das linhas de
a dependência entre elas. Para fixar em que momentos isso suas arestas. A escala de tempo pode ser apresentada como
acontece, cada unidade de tempo deve ser quantificada no formato anterior ou pode ser omitida, enquanto restrições
e nomeada. Os lapsos de tempo em que as unidades de de tempo e duração aparecem entre chaves.
tempo representam não são necessariamente iguais, isto
é, cada estado permanece ativo por tempos diferentes. A Diagramas da Fase de Implantação
Figura 4 apresenta mensagens de tempo emitidas da linha Num processo de desenvolvimento de sistemas incremental
de vida do controlador principal para os controladores dos e iterativo (do qual o Rational Unified Process – RUP é uma
equipamentos auxiliares. Apenas os marcos importantes instância), quatro grandes fases de desenvolvimento são atra-
vessadas por pelo menos 6 atividades diferentes: elicitação

Figura 2. Estados/Condições para cada linha de vida Figura 3. Gráficos de temporização das três linhas de vida sincronizadas

20 Engenharia de Software Magazine - Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UML
 PROJETO

Figura 4. Mensagens de tempo emitidas entre linhas de vida Figura 5. Restrições de tempo associadas às transições

de requisitos, análise de requisitos, projeto, implementação,

testes e implantação. Nesse tipo de processo de desenvolvi-
mento aliam-se as melhores qualidades de duas aproximações
diferentes para o desenvolvimento de sistemas de software ro-
bustos. A primeira delas é a adoção das ferramentas e técnicas
de modelagem, que fornecem documentação de alto nível e de
suporte efetivo à implementação. A segunda busca a melhor
qualidade dos processos ágeis, rapidez no desenvolvimento
sem sacrifício da qualidade.
O processo incremental alia o desenvolvimento de modelos
Figura 6. Formato de linha de vida de valor para o caixa eletrônico
estáveis e robustos da análise orientada a objetos à rapidez
de desenvolvimento conseguida com a execução de diversas Artefatos e Diagramas de Artefatos
iterações durante a fase de construção, produzindo a cada Enquanto modela as diversas visões de um sistema, o desen-
ciclo concluído, um incremento que passa a integrar a parte volvedor constrói modelos lógicos, compostos de elementos
do sistema que já está em operação. Assim, por exemplo, duas igualmente lógicos. Assim é a natureza de classes, interfaces,
semanas após o início da fase de construção (uma duração suas associações, casos de uso e outros diversos componentes
aproximada de uma iteração), já é possível implantar uma da linguagem de modelagem. Em determinado momento do
parte do sistema e torná-la operacional. processo, estes elementos lógicos terão de ser ‘manifestados’
Para apoiar e documentar essa atividade dos ciclos de desen- por componentes físicos, reais, que os implementem e permitam
volvimento, a UML disponibiliza três tipos diferentes de dia- suas operações. Tais elementos físicos são chamados artefatos.
gramas: Diagramas de Artefatos, Diagramas de Componentes e Artefatos são elementos físicos, suportados por uma platafor-
os Diagramas de Implantação propriamente ditos. Embora não ma de implementação. Um artefato pode ser entendido como
sejam citados e explorados na literatura técnica e nem façam um pacote físico contendo elementos lógicos tais como classes,
parte das listas oficiais de diagramas da UML, Diagramas de interfaces e colaborações. A Figura 7 mostra a notação UML
Artefatos são claramente referidos por Booch, Rumbaugh e Ja- 2 para um artefato.
cobson em sua obra UML – Guia do Usuário, e podem ser muito A ideia de artefato está fortemente ligada à definição de
úteis para documentação e localização de artefatos em sistemas arquivos reais, embora seja mais abrangente do que isso. Mas
de médio a grandes portes, como será demonstrado. de uma forma prática, pode-se considerar que artefatos são

Edição 32 - Engenharia de Software Magazine 21

simplesmente arquivos individuais que suportam os elemen- A combinação desses tipos de artefatos permite modelar
tos lógicos e seus relacionamentos. Assim, existem artefatos três aspectos importantes de implantação de sistemas: a mo-
resultantes do trabalho de desenvolvimento, ou seja, o produto delagem de executáveis e bibliotecas, a modelagem de tabelas,
do desenvolvimento. São eles, arquivos fonte e arquivos de da- arquivos e documentos, e a modelagem de código fonte.
dos a partir dos quais serão gerados artefatos de implantação. Diagramas de Artefatos admitem dois tipos de relaciona-
Estes, por sua vez, incluem os arquivos executáveis, arquivos mento entre artefatos: uma dependência, quando um artefato
de configuração, arquivos de inicialização e bibliotecas, entre utiliza serviços oferecidos por outros, ou uma manifestação,
outros. Esse segundo conjunto configura um sistema executá- quando um artefato é uma manifestação física de um elemento
vel completo, que suporta totalmente as especificações lógicas lógico qualquer.
contidas no primeiro conjunto. Um terceiro e último conjunto
de artefatos inclui aqueles que só têm existência em tempo Diagramas de Artefatos de Código Fonte
de execução de um sistema. Podem denominar-se transientes O código fonte que implementa as funcionalidades de um
ou efêmeros. sistema é geralmente desenvolvido em uma série de artefatos
Tais tipos de artefatos podem ser reconhecidos pela colocação que são então relacionados. Tais relacionamentos podem
de estereótipos tais como: <<executable>>, um arquivo com originar-se primariamente das especificações lógicas dos re-
código executável, <<library>>, uma biblioteca convencional lacionamentos entre trechos de código, mas também podem
ou dinâmica, <<file>>, um arquivo contento código fonte, ou refletir dependências de compilação, ou seja, diretivas obriga-
<<document>>, um arquivo em formato texto ou outro formato tórias para obtenção do código executável. Em outras palavras,
que contenha uma tabela, um script, entre outros. Na represen- a simples ausência de uma biblioteca de classes pode tornar
tação de artefatos, o desenvolvedor tem liberdade para criar impossível a compilação de um módulo, de um componente
e usar estereótipos específicos para identificar artefatos inco- ou de todo um sub-sistema.
muns ou muito particulares de um determinado sistema. A modelagem criteriosa dos artefatos produto do desenvol-
vimento oferece uma visão privilegiada dessas dependências.
A Figura 8 é um exemplo desse tipo de modelagem aplicado
ao caixa eletrônico.
A Figura 8 representa as dependências entre artefatos. Para
gerar o artefato [Link], que é um arquivo executável
(interpretável no caso do Java). O diagrama mostra também
claramente que, para executar, [Link] faz uso de uma
biblioteca dinâmica, [Link], assim como depende de
uma conexão a um sistema gerenciador de banco de dados,
do qual usa dados de uma tabela denominada [Link].
Figura 7. Um artefato Para sistemas complexos de software, esta representação pode
assumir importância crítica.

Diagramas de Artefatos de Código Executável

Esse diagrama pode ser particularmente útil em sistemas
com diversos módulos executáveis que utilizam bibliotecas
dinâmicas. Os elementos que têm relação direta são represen-
tados, assim como seus relacionamentos, que neste caso são
todos de dependência, ou seja, um artefato utilizando serviços
oferecidos por outros. A Figura 9 apresenta um exemplo de
modelagem onde também estão modeladas as dependências
existentes em relação a um arquivo de inicialização assim como
de um arquivo de ajuda on-line.

Diagramas de Artefatos de Arquivos Auxiliares

Nem todos os artefatos que integram o conjunto de artefatos
do sistema são arquivos fonte, executáveis ou bibliotecas. Uma
tabela integrante de um banco de dados relacional, por exemplo,
é também um artefato. A rigor, um sistema gerenciador de banco
de dados é um componente formado de dezenas de artefatos.
Numa outra situação, um arquivo HTML pode ser usado como
fonte para implementação de ajuda on-line para um sistema de
Figura 8. Diagrama de Artefatos acesso via WEB. É claro que modelar todo um banco de dados

22 Engenharia de Software Magazine - Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UML
 PROJETO

utilizando Diagramas de Artefatos é uma tarefa desnecessária,

já que existe toda uma notação apropriada para essa finalidade,
mas para destacar a interação entre um elemento executável e
uma das tabelas de um SGBD, os Diagramas de Artefatos são
de valia e ajuda inestimável. A Figura 10 apresenta um exemplo
desse tipo de modelagem.
Existem diversas considerações 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 Implantação tratados à frente.
Em primeiro lugar, os três tipos de Diagramas de Artefatos
não são estanques, isto é, eles podem ser mesclados de forma
livre, mostrando relacionamentos entre artefatos fonte, exe-
Figura 9. Diagrama de Artefatos
cutáveis e auxiliares e representando dependências, manifes-
tações e implantações de forma livre. Isso gera uma riqueza
de representação que torna tais diagramas muito úteis em
geração de documentação de apoio à manutenção. Diagramas
de Artefatos construídos assim podem exibir tags com valores
atribuídos que expressam uma série útil de atributos associa-
dos aos artefatos, tais como versões, modificações, atualizações
e outros elementos.
Uma segunda consideração importantíssima é sobre a pos-
sibilidade, e às vezes necessidade, de interseção entre os três
diagramas de implantação. Artefatos podem estar contidos
dentro de componentes de software (tratados adiante), e estes
podem estar contidos dentro de pacotes, dentro de outros com-
ponentes ou mesmo dentro de outros artefatos. Componentes de
software, assim como artefatos isolados, podem estar alocados
a nós de processamento (elementos dos diagramas de implanta-
ção apresentados à frente). Elementos lógicos da linguagem de Figura 10. Diagrama de Artefatos
modelagem podem ser “manifestados” pelos artefatos já citados,
enquanto artefatos podem ser “implantados” em nós específicos substituído a qualquer momento sem prejuízo para o sistema.
de processamento. Quando se desenvolvem diagramas que as- A atuação de um componente dentro de um determinado siste-
sociam artefatos, componentes, pacotes e nós de processamento ma se dá através de interfaces fornecidas pelo componente ou
(tratados adiante), os relacionamentos entre artefatos e os demais requeridas pelo mesmo, através das quais são fornecidos servi-
elementos, além da dependência, podem ser de outros dois tipos: ços daquele componente ou requeridos serviços fornecidos por
implantação (deployment) ou manifestação (manifestation). outros componentes. Interfaces se conectam ao componente
Uma implantação indica um nó físico onde um artefato será através de portas, definidas em sua estrutura encapsulada. Um
localizado. Um relacionamento de manifestação representa uma componente é, assim, totalmente encapsulado, só disponibili-
instanciação física de um artefato qualquer. zando suas funcionalidades através de portas específicas que
comportam interfaces.
Componentes e Diagramas de Componentes Componentes não são elementos atômicos; eles possuem
No cerne da ideia de componentes está a reutilização. Em linhas uma estrutura interna. Sua composição pode ser de classes
gerais, o desenvolvimento de software baseado em componentes internas ou de outros componentes, assim como de pacotes.
inspira-se na mesma atividade desenvolvida com sucesso pela Os elementos da estrutura interna de um componente devem,
engenharia de hardware e eletrônica em geral, que já projeta com naturalmente, exibir associações. A forma mais corriqueira de
sucesso, baseada em componentes, com mais de meio século de representar estas associações é através de dependências, mas o
vantagem em relação ao desenvolvimento de software. A idéia caminho mais utilizado para isso é a utilização das interfaces.
não é nova e nem engatinha. Já existem padrões de indústria A Figura 11 apresenta a representação de um componente na
reais e em desenvolvimento. Como elemento fundamental para notação da UML 2. Está representada, além do componente,
construção de tais sistemas situa-se o componente. uma interface requerida, através da qual esse componente
Um componente de software é um elemento que integra um poderá se conectar ao sistema. O contexto é o mesmo usado
determinado sistema sem ser exclusivo deste. Em outras pa- anteriormente. O componente é mostrado utilizando um es-
lavras, um mesmo componente pode estar presente em mais tereótipo que pode ser omitido, já que o símbolo é exclusivo
de um sistema de naturezas diferentes e pode ser também para componentes.

Edição 32 - Engenharia de Software Magazine 23

Desenvolvendo um Diagrama de Componentes principal não foi completamente mostrada, pois isso tornaria
Para desenvolver um diagrama de componentes, a primeira o diagrama visualmente confuso.
atividade é determinar que componentes compõem o siste-
ma. Para o contexto do caixa eletrônico, três componentes Diagramas de Implantação
podem ser listados: o conjunto de classes que implementam Sistemas simples, destinados à execução em estações ‘standa-
as funcionalidades do equipamento, o conjunto de classes lone’, têm todos os seus artefatos residentes nessa única estação.
que controlam o leitor de cartões e o conjunto de classes que Mas estes sistemas praticamente não existem mais. Sistemas
controlam o mecanismo de contagem e liberação de cédulas, modernos de processamento de informações são baseados
embora componentes nem sempre sejam apenas conjuntos em acesso via web e residem em ambientes de processamento
de classes. Os equipamentos serão acessados por interfaces distribuído, com seus artefatos residindo em diferentes pontos
requeridas, que serão realizadas pelos controladores (métodos de uma rede de processamento. Estes pontos são denomi-
de classes controladoras) das funcionalidades (casos de uso) nados nós de processamento e sua localização geográfica já
do equipamento. não necessita fronteiras. Uma rede pode estar, e na realidade
O componente principal, o software controlador do equipa- frequentemente está, localizada em diversas locações, às vezes
mento, exibe uma estrutura interna que pode ser representada em países diferentes.
no diagrama. Essa estrutura interna inclui classes de fronteira Em casos menos extremos, sistemas de médio a grande
e controladoras para cada funcionalidade, além de acesso a portes podem conter-se em um único site, mas ainda assim
mecanismo de persistência de objetos. Em última análise, espalhando-se por diversos servidores diferentes. Para docu-
esse importante componente contém o sistema de controle mentar a rede de nós de processamento, assim como determi-
propriamente dito. nar a localização real (física) dos diversos artefatos que compõe
As interfaces requeridas pelos equipamentos periféricos são o sistema, a UML disponibiliza o Diagrama de Implantação
todas fornecidas pelo componente principal, através de por- que, entre outras finalidades, representa as localizações físi-
tas dedicadas que preservam o encapsulamento de todos os cas (nós) e seu conteúdo (artefatos), exibindo ainda uma série
componentes. A Figura 12 apresenta um Diagrama de Compo- de atributos através de tags. Um nó de processamento é uma
nentes que modela a arquitetura baseada em componentes do localização física que possui alguma quantidade de memória
sistema. O diagrama foi desenvolvido dentro de um frame com e freqüentemente capacidade de processamento. A notação da
rótulo cmp (componente). A estrutura interna do componente 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 atribuídos
e compartimentos especiais contendo listas de nomes de arte-
fatos residentes naquele nó. Na representação da topologia de
um ambiente de processamento surgirão nós com capacidade
de processamento e nós que simplesmente são dispositivos
de armazenamento. Para distinguir entre esses tipos de nós
pode-se utilizar os estereótipos <<device>> para dispositivos,
e <<executionEnvironment>> para processadores.
As conexões entre nós são normalmente representações de
ligações físicas entre os componentes de uma rede, já que os nós
representam exatamente estes componentes. Para obter um dia-
grama legível e útil não convém representar todos os artefatos
Figura 11. Um componente com interface requerida e sim aqueles considerados fundamentais para compreensão
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
lançar mão de todos os elementos dos diagramas de artefatos,
de componentes, de pacotes e de implantação, combinando-os
à vontade, para gerar documentação rica e útil.
A Figura 14 representa a topologia para o sistema do caixa
eletrônico, as conexões (inclusive as remotas) entre os diversos
nós, e as residências dos principais artefatos do sistema. Site-
Banco representa uma localização física que executa programas
de acesso às bases de dados. O nó CaixaEletrônico conecta-se
remotamente ao SiteBanco e estabelece uma colaboração que
Figura 12. Diagrama de Componentes para o caixa eletrônico desempenhará a funcionalidade requisitada.

24 Engenharia de Software Magazine - Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UML
 PROJETO

Dois programas executando no site, exibem um relaciona-

mento com este chamado implantação (deploy). Isto significa
que o nó SiteBanco é quem implanta os artefatos indicados.
Os programas que rodam nos servidores de aplicação no site
do banco exibem uma dependência em relação a um pacote
que representa todos os artefatos integrantes de um sistema
gerenciador de banco de dados (SGBD). O nó CaixaEletrônico
conecta-se com dois nós auxiliares que estão rotulados como
dispositivos periféricos ou devices. Como os três nós estão Figura 13. Representação de um nó de processamento
geograficamente localizados num espaço único, essa conexão
é feita por cabos multivias. Estes nós não possuem capacidade
de processamento e eventualmente nem mesmo memória. São
dispositivos auxiliares controlados por drivers. Um ou mais
componentes RotinaAcesso podem ser instanciados durante
uma sessão de execução do software. Isto está evidenciado atra-
vés de um relacionamento de agregação entre o componente
e o nó. Finalmente, o artefato principal, [Link], exibe
um relacionamento com o nó CaixaEletrônico denominado
manifestação. Isso significa que o artefato se manifesta através
do elemento físico representado pelo nó.

Conclusão
Os diagramas UML mais representativos e largamente
empregados são, sem dúvida, os diagramas de classes, de
sequência, 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 desestimu- Figura 14. Diagrama de Implantação
lar seu desenvolvimento. Isso é um antigo problema vestindo
roupa nova. Dispensar tempo com documentação que pode menos complexos) sistemas embarcados, ou seja, programas
ser considerada secundária sempre foi uma atividade prete- controladores de dispositivos e aparelhos eletrônicos espe-
rida e/ou abandonada. Para mudar essa realidade, que é uma cíficos. Alguns sistemas comerciais e/ou administrativos
questão de ‘cultura’ dos desenvolvedores, a UML disponibiliza podem apresentar processos tempo-dependentes, mas estas
todo um conjunto de modelos com notações apropriadas para dependências podem ser modeladas nos diagramas de estado
modelagem dos mais variados aspectos inerentes ao desenvol- e atividades.
vimento de sistemas.
Diagramas empregados na fase de implantação de siste-
mas compreendem Diagramas de Artefatos, Diagramas de Referências Bibliográficas
Componentes e Diagramas de Implantação. Embora pouco
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. [Link]. Rio de Janeiro:
empregados, são de grande importância para modelagem de
Campus-Elsevier, 2007. 370p.
sistemas de média a alta complexidade e que executam em
ambientes de processamento distribuídos. Seu emprego passa BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usuário. [Link]. Rio de Janeiro:
a ser quase obrigatório quando tais ambientes são extensos e Campus-Elsevier, 2006. 474p.
complexos.
FOWLER, Martin. UML essencial: um breve guia para a linguagem padrão de modelagem de
Diagramas de Artefatos de código fonte e executável passam
objetos. [Link]., Porto Alegre: Bookman, 2006. 160p.
a ser uma espécie de índice para localização de artefatos em
uma extensa rede de nós de processamento. Recursos como BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML
quantidade de memória e capacidade de processamento podem [Link]. Rio de Janeiro: Campus-Elsevier, 2006. 496p.
ser alocados e controlados mediante seu emprego e atualização
constante. Já os Diagramas de Componentes são uma obrigato-
Dê seu feedback sobre esta edição! Feedback
riedade para instalações que desenvolvem com essa filosofia. A eu
s
Dê

representação dos componentes e seus relacionamentos torna A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e

mais amena a difícil tarefa de manutenção. Para isso, precisamos saber o que você, leitor, acha da revista!
s

ta
Por fim, diagramas de temporização encontram seu melhor Dê seu voto sobre este artigo, através do link:
edição

emprego em especificações de sistemas de controle de am-

bientes, geralmente de tempo real e em pequenos (mas não [Link]/esmag/feedback

Edição 32 - Engenharia de Software Magazine 25

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software

Refatoração para Padrões – Parte 5

Implementando o padrão Strategy com Substituir lógica condicional por
Strategy

De que se trata o artigo?

Aborda o tema refatoração para padrões com o objeti-

U
ma prática comum a vários de- vo de mostrar como o desenvolvedor pode usá-lo para
senvolvedores, principalmente melhorar o código-fonte de suas aplicações.
os que não possuem conheci-
mento sobre padrões de projeto, é a de Para que serve?
criar extensos métodos com complexa Para prover conhecimento ao desenvolvedor sobre
lógica de seleção, com o objetivo de for- refatoração para padrões e demonstrar através de
Jacimar Fernandes Tavares
[Link]@[Link]
necer todos os caminhos para determi- um exemplo prático a aplicação das técnicas de refa-
É Aluno do Curso de Bacharelado em Ciên- nados comportamentos em um só lugar. toração para padrões Substituir Lógica condicional por
cia da Computação da FAGOC - Faculdade Tal prática é funcional e pode ser realiza- Strategy.
Governador Ozanam Coelho, Microsoft da em tempo hábil, mas outras questões
Student Partners. devem ser levadas em consideração. Em que situação o tema é útil?
Métodos com extensa lógica de seleção O tema se torna fundamental para desenvolvedo-
Marco Antônio Pereira Araújo possuem complexidade ciclomática ele- res que já estão familiarizados com padrões de pro-
maraujo@[Link] vada, o que pode vir a ser um problema jeto e já os implementam em seus softwares e que
É Doutor e Mestre em Engenharia de Sis- quando se pensa em manutenções futuras. querem saber mais sobre refatoração para padrões,
temas e Computação pela COPPE/UFRJ,
Especialista em Métodos Estatísticos Com-
A refatoração para o padrão Strategy forne- conhecendo os benefícios que sua utilização traz.
putacionais e Bacharel em Informática pela ce um mecanismo mais sofisticado que um
UFJF, professor do curso de Bacharelado em método com extensa lógica condicional, se
Ciência da Computação da FAGOC, professor bem aplicada. Contudo, refatorar para o Substituir Lógica condicional por Stra-
dos Cursos de Bacharelado em Sistemas de padrão Strategy não é uma tarefa simples, tegy, uma visão geral do que é o padrão
Informação do Centro de Ensino Superior
de Juiz de Fora, da Faculdade Metodista
visto que há vários conceitos e práticas de projeto Strategy, bem como as técni-
Granbery e da Universidade Severino Som- envolvidas neste processo. cas de refatoração Mover Método (ver
bra, professor do Curso de Tecnologia em A partir deste momento serão apresen- Nota do DevMan1), Introduzir Objeto
Análise e Desenvolvimento de Sistemas da tados conceitos e práticas que estão dire- Parâmetro, Substituir Condicional por
Fundação Educacional D. André Arcoverde. tamente ligados ao processo de refatorar Polimorfismo e Substituir Enumeração
Analista de Sistemas da Prefeitura de Juiz
de Fora, Editor da Engenharia de Software
para o padrão Strategy com a utilização por Subclasse. Ao final será abordada
Magazine. da técnica de refatoração para padrões a técnica de refatoração para padrões

26 Engenharia de Software Magazine - Refatoração para Padrões – Parte 5

 DESENVOLVIM ENTO

Substituir Lógica condicional por Strategy, onde um exemplo

prático de sua utilização será apresentado. Nota do DevMan 1
O padrão de projeto Strategy
Nome do padrão de projeto: Strategy. Pertencente ao con- Refatoração Mover Método
junto dos padrões de projeto classificados como Padrões A técnica de refatoração Mover Método foi apresentada no artigo da edição 29 da
Comportamentais. Engenharia de Software Magazine.
O problema: Em alguns momentos é possível encontrar apli-
cações com muito código escrito para determinar como será a
tomada de ações mediante algumas solicitações dos clientes da Listagem 1 – Classe Departamento.
aplicação. O padrão de projeto Strategy pode atuar neste sentido,
01. public class Funcionarios
uma vez que sua implementação possibilita a definição de uma 02. {
estrutura de classes responsáveis por implementar diferentes 03. ...
algoritmos que serão utilizados para definir novas estratégias 04. public Decimal RecuperaTotalSalarios(String nome, DateTime inicio,
DateTime final)
para um conjunto de objetos de uma classe, por exemplo. 05. {
As consequências: Com isso, consegue-se utilizar diferentes 06. ...
algoritmos de estratégia em tempo de execução, além de per- 07. return total;
08. }
mitir a definição de algumas variações desses algoritmos na 09. public Boolean DeletarRegistroSalarial(String nome, DateTime
estrutura de classes que compõem a estratégia. inicio, DateTime final)
10. {
11. ...
A refatoração Introduzir Objeto Parâmetro 12. return statusAcao;
Esta refatoração é pertencente ao grupo de refatorações classifi- 13. }
cadas como Tornando as Chamadas de Métodos Mais Simples. 14. public Decimal RecuperaValorTotalComissao(String nome,
DateTime inicio, DateTime final)
Nome da refatoração: Introduzir Objeto Parâmetro. 15. {
Resumo: Algumas classes possuem vários métodos que re- 16. ...
cebem vários parâmetros em comum. Neste contexto, cria-se 17. return comissao;
18. }
um objeto que possua os atributos mais usados pelos métodos 19. ...
e modifique-os para receberem um objeto, no lugar dos vários 20. }
dados que recebiam como parâmetros.
Motivação: Introduzindo objetos no lugar de vários dados Listagem 2 – Classe Dados.

como parâmetro, pode-se reduzir, e muito, o código duplica- 01. public class Dados
do, além de juntar os dados em um só lugar. Pode-se ainda 02. {
03. private String nome;
reduzir significativamente o número de parâmetros passados
04. private DateTime dataInicio;
ao método. 05. private DateTime dataFinal;
Mecânica:
06. public String Nome
• Cria-se a classe que terá atributos que substituirão os parâ-
07. {
metros passados aos métodos. 08. get { return nome; }
• Declare nela os atributos que deseja substituir pelos 09. set { nome = value; }
10. }
parâmetros.
• Modifique os métodos para receberem como parâmetro um 11. public DateTime DataInicio
objeto da classe criada, apagando os antigos parâmetros. 12. {
13. get { return dataInicio; }
• Execute os testes.
14. set { dataInicio = value; }
15. }
Exemplo: O exemplo a seguir vem de um sistema comercial 16. public DateTime DataFinal
17. {
do qual são extraídas várias informações, onde vários métodos
18. get { return dataFinal; }
são invocados para obtê-las. A Listagem 1 mostra o código da 19. set { dataFinal = value; }
classe Departamento. 20. }
Ao analisar o código da Listagem 1 percebe-se que há vários
21. public Dados(String nome, DateTime dataInicial, DateTime
pontos com código omitido. Isso é necessário para que o foco dataFinal)
fique somente na declaração dos métodos e não no corpo do 22. {
23. [Link] = nome;
método, que para esta refatoração não é importante.
24. [Link] = dataInicial;
Os métodos declarados possuem algo em comum: a lista de 25. [Link] = dataFinal;
parâmetros é idêntica entre eles. Primeiramente cria-se a classe 26. }
que terá atributos equivalentes aos parâmetros utilizados pelos
27. }
métodos, conforme a Listagem 2.

Edição 32 - Engenharia de Software Magazine 27

Listagem 3 – Classe Funcionarios refatorada. O método construtor da classe Dados, Listagem 2, fica res-
ponsável por instanciar o objeto Dados. Os métodos da classe
[Link] class Funcionarios
02. { Funcionarios, Listagem 1, depois de ter seus parâmetros subs-
03. public Funcionarios() tituídos por um objeto ficam como mostra a Listagem 3.
04. { Aparentemente o resultado da troca de parametros por um
05. }
06. public Decimal RecuperaTotalSalarios(Dados dadosNecessarios) objeto pode não paracer tão satisfatório mas, se aplicado em
07. { classes que possuem vários métodos com uma grande lista
08. Decimal total = 0; de parametros em comum, pode reduzir consideravelmente
09. return total;
10. } o código duplicado.
11. public Boolean DeletarRegistroSalarial(Dados dadosNecessarios) A refatoração Substit uir comando Condicional por
12. { Polimorfismo.
13. Boolean statusAcao = true;
14. return statusAcao; Esta refatoração é pertencente ao grupo de refatorações clas-
15. } sificadas como Simplificando Expressões Condicionais.
16. public Decimal RecuperaValorTotalComissao(Dados dadosNecessarios) Nome da refatoração: Substituir Comando Condicional por
17. {
18. Decimal comissao = 0.0m; Polimorfismo.
19. return comissao; Resumo: Substitui comandos condicionais que selecionam
20. } ações a serem executadas por métodos polimórficos.
21. }
Motivação: Usada para remover expressões condicionais
Listagem 4 – Classe Pessoa. para um determinado objetivo que se repetem em vários tre-
chos de código. Com isso, simplifica-se o projeto de código e
[Link] class Pessoa removem-se duplicações.
02. {
03. private Funcionario funcionario; Mecânica:
04. private String RecuperaTipoFuncionario() • Verifique o método que contenha uma sentença switch ou else
05. { ifs. Aplica-se a refatoração Extrair Método para que a expressão
06. return [Link]();
07. }
condicional fique sozinha no método, caso necessário.
08. public Decimal RecuperaValorSalario() • Usa-se Mover Método para levar o método que contem a
09. { sentença switch para a superclasse.
10. switch (RecuperaTipoFuncionario())
• Cria-se um método em cada uma das subclasses e cola-se
11. {
12. case “Mensalista”: nele o trecho de código da lógica condicional que se refere à
13. return [Link](); subclasse em questão. Caso a subclasse já possua um método
14. case “Diarista”: que possa ser usado para substituir o trecho da lógica condi-
15. return [Link]();
16. default:
cional, desconsidera-se este passo.
17. return 0; • Deleta-se o código da lógica condicional que acabou de
18. } copiar .
19. }
• Executa-se todos os passos até remover toda lógica
20. }
condicional.
Listagem 5 – Superclasse da hierarquia: classe Funcionario.
Exemplo: A Listagem 4 apresenta a classe Pessoa, que contem
[Link] abstract class Funcionario
uma sentença switch.
02. {
03. public abstract String RecuperaTipoFuncionario(); Nota-se que o método RecuperaValorSalario não possue
04. public abstract Decimal RecuperaSalario(); nada além da sentença switch, o que descarta a necessidade
05. } de aplicação da refatoração Extrair Método.
O segundo passo portanto requer que o método Recupera-
Listagem 6 – Subclasse da hierarquia: classe Mensalista.
ValorSalario seja movido para a superclasse da hierarquia. As
01. public class Mensalista: Funcionario Listagens 5, 6 e 7 mostram a hierarquia referida.
02. { Depois da aplicação do segundo passo da refatoração, a classe
03. ...
Funcionário ficará como na Listagem 8.
04. public override String RecuperaTipoFuncionario()
05. { Nota-se que o método RecuperaValorSalario agora tem um
06. return “Mensalista”; objeto funcionário como parâmetro. Isso é necessário para que
07. } o método continue funcionando após ter sido movido para a
08. public override decimal RecuperaSalario()
classe Funcionario.
09. {
10. return salario; O próximo passo consiste em criar métodos nas subclasses
11. } que tenham as mesmas funções que a logica condicional. O
12. } que quer dizer, por exemplo, que a classe Mensalista deve ter
um método que retorne o salario de um funcionario mensalista

28 Engenharia de Software Magazine - Refatoração para Padrões – Parte 5

 DESENVOLVIM ENTO

para substituir o case mensalista da sentença switch . Analisan- Listagem 7 – Subclasse da hierarquia: classe Diarista.
do as classes Mensalista e Diarista, perecebe-se que tal método
já existe. Agora, portanto, resta modificar o método Recupe- [Link] class Diarista: Funcionario
02. {
raValorSalario da classe Funcionario para eliminar a lógica 03. ...
condicional. A Listagem 9 mostra o resultado da mudança. 04. public override String RecuperaTipoFuncionario()
05. {
06. return “Diarista”;
A refatoração Substituir Enumeração por Subclasses 07. }
Esta refatoração é pertencente ao grupo de refatorações clas- 08. public override decimal RecuperaSalario()
sificadas como Organizando Dados. 09. {
10. return salario;
Nome da r efatoração: Subst it u i r Enu meração por 11. }
Subclasses. 12. }
Resumo: Substituição de enumerações por subclasses, pois
enumerações alteram o comportamento de uma classe. Listagem 8 – Classe Funcionário.

Motivação: Usa-se esta refatoração para dividir uma classe [Link] abstract class Funcionario
que possui características de uma classe que carrega mais 02. {
informação do que normalmente deveria carregar. Substi- 03. public abstract String RecuperaTipoFuncionario();

tuindo as enumerações por subclasses, consegue-se clarificar 04. public Decimal RecuperaValorSalario(Funcionario funcionario)
a intenção do código. 05. {
Mecânica: 06. switch (RecuperaTipoFuncionario())
07. {
• Analisa-se a enumeração e cria-se uma classe para cada valor 08. case “Mensalista”:
contido na enumeração, tornando-as subclasses da classe que 09. return [Link]();
contém a enumeração. 10. case “Diarista”:
11. return [Link]();
• Deletam-se os campos da enumeração e movem-se as carac- 12. default:
terísticas que são específicas das subclasses para elas. 13. return 0;
• Execute os testes. 14. }
15. }
16. }
Exemplo: A classe Pessoa possui uma enumeração chamada
TipoPessoa, onde Alunos é representado por 0, e Professores Listagem 9 – Classe Funcionario.
por 1. A classe Pessoa possui ainda métodos que realizam
[Link] abstract class Funcionario
operações para alunos e para professores, o que caracteriza 02. {
que a classe Pessoa possui comportamentos que poderiam 03. public abstract String RecuperaTipoFuncionario();
ser divididos por outras classes, conforme será feito nesta
04. public abstract Decimal RecuperaSalario();
refatoração. A Listagem 10 mostra a classe Pessoa.
Aplicando essa refatoração, parte do código da classe Pessoa 05. public Decimal RecuperaValorSalario(Funcionario funcionario)
poderá ser dividido em duas classes: Alunos e Professores. As- 06. {
sim será possível clarificar o código da classe Pessoa, ao movê-lo 07. return [Link]();
08. }
para as subclasses. As Listagens 11 e 12 mostram as subclasses
09. }
criadas a partir da análise dos campos da enumeração.
A classe Pessoa agora é a superclasse das subclasses Alunos Listagem 10 – Classe Pessoa com a enumeração TipoPessoa.
e Professores. Agora para clarificar e reduzir a complexidade
[Link] class Pessoa
da classe Pessoa, move-se todo conhecimento específico para
02. {
as respectivas subclasses que, neste caso, implica em mover o
método AlterarSenhaAluno para a classe Alunos e Recuperar- 03. public enum TipoPessoa
NomeProfessor para Professores, conforme Listagens 13 e 14. 04. {
05. Alunos = 0,
Para finalizar, basta apagar a enumeração da classe Pessoa e
06. Professores = 1
ajustar as chamadas à enumeração para as novas mudanças. 07. }
A partir desse momento, todo código que antes era desti- 08. public void AlterarSenhaAluno(String novaSenha)
nado à classe Pessoa, agora dever ser analisado e escrito 09. {
10. ...
na subclasse que melhor se encaixar nos objetivos da nova
11. }
funcionalidade.
Até este ponto foram apresentados os conceitos e práticas que 12. public void RecuperaNomeProfessor(Int32 id)
o desenvolvedor precisa para iniciar o processo de aprendizado 13. {
14. ...
sobre a refatoração para o padrão Strategy. A partir deste mo-
15. }
mento será apresentada a técnica de refatoração para padrões 16. }
Substituir Lógica condicional por Strategy.

Edição 32 - Engenharia de Software Magazine 29

 Listagem 11 – Subclasse Alunos.
Motivação: Métodos com lógica condicional de grande
complexidade podem dificultar a tarefa de entendimento do
[Link] class Alunos : Pessoa método e assim dificultar a análise de qual trecho da lógica
02. {
03. } condicional será executada e qual ação será efetuada. Esta téc-
Listagem 12 – Subclasse Professores.
nica de refatoração para padrões fornece um mecanismo onde a
lógica condicional poderá ser eliminada. Isto se torna possível
[Link] class Professores : Pessoa graças à implementação do padrão Strategy que fornecerá um
02. {
03. } mecanismo baseado em polimorfismo e que possibilitará que
as subclasses da estratégia criada possuam cada uma delas
Listagem 13 – Classe Alunos. uma das ações que a lógica condicional removida possuía.
Vantagens: Permite a remoção de lógica condicional, simpli-
[Link] class Alunos : Pessoa
02. { ficando o projeto de código existente; torna algoritmos mais
03. public void AlterarSenhaAluno(String novaSenha) claros de se entender; permite que um algoritmo seja trocado
04. { por outro em tempo de execução.
05. ...
06. } Desvantagens: Complica um projeto de código existente
quando outro mecanismo mais simples poderia resolver o
07. } problema, neste caso, um mecanismo baseado em herança;
dificulta a visualização de como dados são passados entre
Listagem 14 – Classe Professores.
os objetos.
[Link] class Professores : Pessoa Mecânica: Busca-se por um método que possua lógica con-
02. { dicional a ser removida.
03. public void RecuperaNomeProfessor(Int32 id)
04. { 1. Cria-se uma classe Strategy. Seu nome deve ser compatível
05. ... com a função do método escolhido e terminado com a palavra
06. } Strategy.
07. }
2. Utiliza-se a refatoração Mover Método levando o método
Listagem 15. Classe Emprestimos. escolhido para a classe criada no passo 1. Deve-se deixar uma
cópia do método no seu local de origem e modificá-la para que
[Link] class Emprestimos
delegue ao método movido para a classe criada no passo 1.
02. {
03. public Decimal emprestimoMinimo = 50.00m; Caso o método escolhido faça referência a outros métodos da
04. public Decimal salarioMinimo = 510.0m; classe onde está escrito, devem-se movê-los também para classe
criada no passo 1. A refatoração Introduzir Objeto Parâmetro
05. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)
06. { permite a redução de parâmetros a serem passados para as
07. if (renda <= (salarioMinimo / 2)) estratégias definidas. Caso necessário, ela deve ser utilizada.
08. {
3. Modifique o código cliente para se adequar às novas
09. return emprestimoMinimo;
10. } mudanças.
11. else if(renda <= salarioMinimo) 4. Utiliza-se a refatoração Substituir Condicional por Polimor-
12. {
fismo no método presente na classe criada no passo 1. Talvez
13. return ((renda * 10)/ 100) + taxa;
14. } seja necessária a aplicação da refatoração Substituir Enumera-
15. else if(renda <= (salarioMinimo * 2)) ção por Subclasses. Para se certificar se o uso desta refatoração
16. {
se aplica, considera-se o contexto em que ela deve ser aplicada.
17. return ((renda * 20) / 100) + 2* taxa;
18. } Compila-se a aplicação e executam-se testes.
19. else
20. {
Exemplo: A Listagem 15 mostra a classe Emprestimos, onde
21. return ((renda * 50) / 100) - (taxa * 5);
22. } é possível perceber que o método CalcularEmprestimo possui
23. } grande quantidade de lógica condicional para calcular o em-
24. }
préstimo com base na taxa de juros e na renda do cliente.
Aplicando a refatoração para padrões em questão, tem-se a clas-
se CalcularEmprestimoStrategy, como mostra a Listagem 16.
A refatoração para padrões Substituir Lógica condicional Prosseguindo, tem-se a criação de um método em Calcu-
por Strategy larEmprestimoStrategy que receberá a lógica condicional
Resumo: Alguns métodos possuem complexa lógica condi- presente no método CalcularEmprestimo (Listagem 15). A
cional para escolher e executar determinados cálculos. Para Listagem 17 mostra o resultado.
lidar com isto, define-se uma hierarquia de classes Strategy Move-se o corpo do método CalcularEmprestimo (Listagem 15)
onde cada subclasse ficará responsável por executar um tipo para o corpo do método Calcular (Listagem 17). Deve-se também
de cálculo da lógica condicional. mover todo o código presente na classe CalcularEmprestimo

30 Engenharia de Software Magazine - Refatoração para Padrões – Parte 5

 DESENVOLVIM ENTO

(Listagem 15) que o código movido esteja utilizando. O resultado da lógica condicional em questão. Depois, deve-se modificar a
pode ser visto na Listagem 18. classe CalcularEmprestimoStrategy para abstrata e modifica-se
Modifica-se o método CalcularEmprestimo da classe Emprés- seu método Calcular para abstrato, permitindo que os métodos
timos (Listagem 15), para que ele delegue à classe CalcularEm- recém criados nas subclasses o implementem. As Listagens 20,
prestimoStrategy. A Listagem 19 mostra o resultado. 21, 22, 23 e 24 mostram o resultado destas mudanças.
Utilizando herança e polimorfismo, analisa-se o método Calcular A refatoração para padrões Substituir Lógica Condicional por
na classe CalcularEmprestimoStrategy (Listagem 18). Para cada Strategy está finalizada. Cumpriu-se o objetivo, que era a imple-
tipo de cálculo que ele produz, no caso 4 (um pra cada condicional, mentação do padrão Strategy. O benefício citado na descrição da
cria-se uma subclasse para a classe CalcularEmprestimoStrategy. refatoração era o de simplificar o projeto de código existente.
Tais subclasses devem conter um método Chamado Calcular, Isto se torna visível se analisado o método CalcularEmprestimo
e o seu corpo deve conter um dos tipos específicos de calculo (Listagem 15). A lógica condicional que escolhia qual tipo de

Listagem 16. Classe CalcularEmprestimoStrategy. Listagem 20. Subclasse MeioSalarioMinimoStrategy.

1. public class CalcularEmprestimoStrategy 1. public class MeioSalarioMinimoStrategy: CalcularEmprestimoStrategy

2. { 2. {
3. public override Decimal Calcular(Decimal renda, Decimal taxa)
3. } 4. {
5. return ((renda * 10) / 100) + taxa;
Listagem 17. Classe CalcularEmprestimoStrategy 6. }
7. }
[Link] class CalcularEmprestimoStrategy
2. { Listagem 21. Subclasse SalarioMinimoStrategy.
3. public Decimal Calcular(Decimal renda, Decimal taxa)
4. { 1. public class SalarioMinimoStrategy: CalcularEmprestimoStrategy
5. return 0.0m;
2. {
6. }
3. public override Decimal Calcular(Decimal renda, Decimal taxa)
7. }
4. {
5. return ((renda * 10) / 100) + taxa;
Listagem 18. Classe CalcularEmprestimoStrategy 6. }
7. }
1. public class CalcularEmprestimoStrategy
2. {
3. public Decimal emprestimoMinimo = 50.00m; Listagem 22. Subclasse DoisSalariosMinimosStrategy.
4. public Decimal salarioMinimo = 510.0m;
1. public class DoisSalariosMinimosStrategy: CalcularEmprestimoStrategy
5. public Decimal Calcular(Decimal renda, Decimal taxa) 2. {
6. { 3. public override Decimal Calcular(Decimal renda, Decimal taxa)
7. if (renda <= (salarioMinimo / 2)) 4. {
8. { 5. return ((renda * 20) / 100) + 2 * taxa;
9. return emprestimoMinimo; 6. }
10. } 7. }
11. else if (renda <= salarioMinimo)
12. {
Listagem 23. Subclasse RendaAltaStrategy.
13. return ((renda * 10) / 100) + taxa;
14. }
1. public class RendaAltaStrategy: CalcularEmprestimoStrategy
15. else if (renda <= (salarioMinimo * 2))
16. { 2. {
17. return ((renda * 20) / 100) + 2 * taxa; 3. public override Decimal Calcular(Decimal renda, Decimal taxa)
18. } 4. {
19. else 5. return ((renda * 50) / 100) - (taxa * 5);
20. { 6. }
21. return ((renda * 50) / 100) - (taxa * 5); 7. }
22. }
23. } Listagem 24. Superclasse CalcularEmprestimoStrategy.
24. }
Listagem 19. Classe Emprestimos 1. public abstract class CalcularEmprestimoStrategy
2. {
1. public class Emprestimos 3. public Decimal emprestimoMinimo = 50.00m;
2. { 4. public Decimal salarioMinimo = 510.0m;
3. private CalcularEmprestimoStrategy calcularEmprestimo;
4. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa) 5. public abstract Decimal Calcular(Decimal renda, Decimal taxa);
5. {
6. return [Link](renda, taxa);
6. }
7. }
8. }

Edição 32 - Engenharia de Software Magazine 31

cálculo executar foi diluída no padrão Strategy, onde cada sub- Referências Bibliográficas
classe de CalcularEmprestimoStrategy fica responsável pela
implementação de um método, que por sua vez fica responsável 1. GAMMA, Erich, 2000. Padrões de Projeto: soluções reutilizáveis de software orientado a
por um tipo de cálculo, e o método CalcularEmprestimo (Lis- objetos, 1ed. Porto Alegre: Bookman, 2000.
tagem 15) ficou como mostra a Listagem 19. 2. KERIEVSKY, Joshua. Refatoração para Padrões, 1ed. Porto Alegre: Bookman, 2008.

3. FOWLER, Martin. Refatoração: aperfeiçoando o projeto de código existente, 1ed. Porto Alegre:
Conclusão Bookman, 2004.
Um dos grandes benefícios dos padrões de projeto está re-
lacionado ao fato de permitir a criação de soluções flexíveis
e reutilizáveis. A aplicação do padrão Strategy neste artigo Dê seu feedback sobre esta edição! eu
Feedback

s
mostrou que o mecanismo criado aumentou a flexibilidade do

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

sobre e
código a partir do momento que tornou mais simples a inserção
Para isso, precisamos saber o que você, leitor, acha da revista!
de novas estratégias para novos tipos de cálculos, e ao mesmo

s
ta
edição
Dê seu voto sobre este artigo, através do link:
tempo tornou o código reutilizável, permitindo às estratégias
definidas serem reutilizadas em outros projetos. [Link]/esmag/feedback
Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Engenharia de Software
Sobre a Necessidade de Educação Continuada

De que se trata o artigo?

Apresenta a engenharia de software, destacando
sua importância no cenário atual de crescimento
Antonio Mendes da Silva Filho econômico mundial e apontando a necessidade de
[Link]@[Link] educação continuada de engenheiros de software.
Professor e consultor em área de tecnologia
da informação e comunicação com mais
de 20 anos de experiência profissional, é Para que serve?
autor do livros Introdução a Programação Conscientizar o engenheiro de software da ne-
Orientada a Objetos com C++, Arquitetura cessidade de criar uma “cultura” de engenharia

A
de Software, Programando com XML, todos o longo das últimas décadas de software que prioriza documentação ade-
pela Editora Campus/Elsevier, tem mais de
o software deixou de ser uma quada de software para apoiar rastreabilidade,
30 artigos publicados em eventos nacionais
e internacionais, colunista para Ciência e Tec- parte ínfima e de custo despre- manutenibilidade e reuso de artefatos de sof-
nologia pela Revista Espaço Acadêmico com zível dos sistemas para se tornar parte tware. Recomenda engenharia reversa e arqui-
mais de 60 artigos publicados, tendo feitos determinante e dispendiosa. Hoje em tetura de software como componentes para sua
palestras em eventos nacionais e no exterior. dia, tudo o que você ‘toca’ tem softwa- formação.
Foi Professor Visitante da University of Texas
re, seja no uso doméstico quanto nas
at Dallas e da University of Ottawa. Formado
em Engenharia Elétrica pela Universidade de organizações. Você encontra software Em que situação o tema é útil?
Pernambuco, com Mestrado em Engenharia nos caixas das farmácias, no mercado da O artigo identifica diversos fatos e tendências do
Elétrica pela Universidade Federal da Paraíba esquina, naquelas pequenas máquinas segmento de TI, discute cenário atual e apresen-
(Campina Grande), Mestrado em Engenharia que permitem milhões de transações ta recomendações para os profissionais de enge-
da Computação pela University of Waterloo e
com cartão de crédito e nos aviões que nharia de software que visam atender a deman-
Doutor em Ciência da Computação pela Uni-
vesidade Federal de Pernambuco. levam a pessoas pelos quatro cantos do da de desenvolvimento de sistemas de software
mundo. que satisfaçam restrições de custo, tempo (de
Incrível e intangível é o software. Isso desenvolvimento) e qualidade.
Conteúdo Multimídia! mesmo, software é um produto intangí-
vel, o qual é difícil descrever bem como
Neste artigo você encontra o vídeo: “Problemas
e suas causas no desenvolvimento de software”. avaliar. Por outro lado, comparativamente caráter corretivo ou evolutivo também
ao hardware é facilmente modificado, mais fáceis. Mas, isso é apenas verda-
[Link]/esmag tornando as manutenções sejam elas de de se o software tiver seu projeto bem

Edição 32 - Engenharia de Software Magazine 33

documentado. Documentação de um projeto é essencial para A fase de desenvolvimento concentra-se no projeto de es-
permitir a manutenção e evolução de um sistema de software. truturas de dados e arquitetura de software do sistema (isto
Para tanto, torna-se imprescindível ter ou, se ainda não tiver, criar é, como ele está organizado), conversão do projeto para uma
uma cultura (de engenharia de software) para adotar boas práticas linguagem de programação específica (ou seja, implementa-
da engenharia de software que compreendem os pilares do de- ção), realização de testes e avaliação.
senvolvimento de software de modo a atender às suas premissas Finalmente, a manutenção considera modificações e/ou
básicas: custo, tempo de desenvolvimento e qualidade. correções necessárias no sistema a fim de que este atenda aos
requisitos do sistema. Perceba que o processo de desenvolvi-
Engenharia de Software mento de um sistema de software tem duas grandes atividades
De acordo com o documento IEEE Std 610.12-1990 que apre- de interesse que envolve o desenvolvimento da porção de
senta o IEEE Standard Glossary of Software Engineering Terminol- software que implementa as funcionalidades do sistema, e
ogy ([Link] a atividade que a antecede e norteia o desenvolvimento, que
html), Engenharia de software é definida como “The application é o projeto de software. Esta última atividade é resultado do
of a systematic, disciplined, quantifiable approach to the development, levantamento e análise de requisitos que provê informações
operation, and maintenance of software; that is, the application of para decisões de projeto.
engineering to software.”
Sabe-se que software não é uma entidade física e, portanto, não Necessidade da Engenharia de Software
sofre qualquer tipo de desgaste (físico) como geralmente acon- No contexto atual, qual o nível de necessidade da engenharia
tece com o hardware. Entretanto, apesar de não sofrer desgaste de software?
físico como o hardware, software está sujeito a modificações A resposta é: crítico. E, mais ainda, há consequente demanda
que ocorrem durante o ciclo de vida. Essas modificações podem por profissionais da área qualificados.
acontecer devido à inserção de defeitos decorrentes do desen- A adoção das práticas de engenharia de software é essencial
volvimento os quais são geralmente corrigidos antes da entrega para assegurar a confiabilidade dos produtos e serviços de
do produto. Mas, observe que novos defeitos ainda podem ser (e software. As práticas compreendem instituir uma ‘cultura’ de
geralmente são) inseridos devido às modificações que o software engenharia de software, onde a equipe de projeto de sistemas
sofre devido a sua evolução. Por exemplo, toda vez que uma nova de software esteja comprometida com a documentação de to-
funcionalidade é desejada ou solicitada pelo cliente, torna-se dos os artefatos de um projeto de modo a prover suporte a:
necessário adicionar e/ou modificar as instruções já existentes 1. Rastreabilidade
no software. Como resultado dessas mudanças, novos defeitos 2. Manutenibilidade
podem ser introduzidos e, portanto, pode também causar a 3. Reuso
deterioração na qualidade do software.
A fase inicial do desenvolvimento de software na qual
Fases genéricas no desenvolvimento de software ocorre a definição do sistema considera o entendimento
Dentro do contexto discutido acima, é importante observar dos requisitos desejados além de claramente estabelecer a
que a manutenção é uma das fases que certamente o software origem do requisito. Essa informação será fundamental para
irá lidar. Outras duas fases são definição e desenvolvimento, a rastreabilidade.
como ilustrado na Figura 1. Observe que rastreabilidade está relacionada aos relacio-
Cabe destacar que o desenvolvimento de qualquer produto namentos entre os requisitos, as fontes dos requisitos, bem
(como, por exemplo, software) ou artefato, requer do enge- como o projeto de sistema. A rastreabilidade das fontes dos
nheiro de software saber quais os passos necessários para requisitos visa identificar e relacionar os requisitos às partes
alcançar o objetivo de ter o produto pronto (desenvolvido). interessadas (ou stakeholders) daqueles requisitos. Além disso,
Isso compreende as fases de definição, desenvolvimento e há o relacionamento en tre os requisitos (isto é, a dependência
manutenção, mostradas na Figura 1. existente entre eles) e a ligação de requisitos aos componentes
A fase de definição engloba a identificação de informações que do sistema em desenvolvimento.
deveriam ser processadas, funções e desempenho desejados, E, quanto a manutenibilidade?
tipo de interface a ser utilizada, tarefas que o sistema deveria Neste momento, é importante distinguir entre manutenção
prover suporte, perfil de usuários do sistema, dentre outras. que compreende um conjunto de atividades planejadas a fim
de realizar mudanças, enquanto que a evolução se refere àquilo
que de fato acontece com o software. E, nesse sentido, cabe
destacar que à medida que o software tem se tornado quase
ubíquo nos sistemas, ele tem também crescido em tamanho
(isto é, na quantidade de linhas de código) e complexidade.
Perceba que esse crescimento dos sistemas de software requer
mecanismos apropriados para documentação, rastreamento,
Figura 1. Fases genéricas no desenvolvimento de software e manutenção.

34 Engenharia de Software Magazine - Engenharia de Software

 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, documentação do código, cenários 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 não é desenvolver um
sistema de software desde seu início, 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 possível o software resultante de esforços Figura 2. Influências sobre o software
de desenvolvimentos anteriores, visando reduzir os custos,
tempo e riscos associados com novos desenvolvimentos. engenheiro de software considere os elementos influenciadores
sobre o software, destacados na Figura 2.
Cultura de Engenharia de Software Esse conjunto de ‘forças’ ilustradas na Figura 2 influenciam o
Instituir uma ‘cultura’ de Engenharia de Software significa software. Todavia, três dentre elas têm impacto determinante
adotar suas práticas e obter da equipe de projeto um compro- sobre o software que compreendem custo, prazo e qualidade
metimento de documentar adequadamente todos os artefa- (caracterizada pela confiabilidade que constitui atributo es-
tos de um projeto. Talvez você possa estar imaginando que sencial da qualidade).
dedicar esforço em documentar todos os artefatos produzidos
seja um esforço fútil e desnecessário. E, concordo com você Afinal, qual o problema com o software?
se estiver considerando desenvolver um pequeno sistema de Falibilidade de software (ou possibilidade de existência de
software para uma pequena farmácia ou mesmo para o ‘mer- falhas) e a consequente falta de confiabilidade, além do fato
cadinho da esquina’. Tal tarefa pode ser comparada ao esforço de que software é quase sempre modificado, resultando num
de você construir uma casinha de madeira para seu cachorro produto quase sem garantia. Observe que a única certeza que
de estimação. Você, sozinho, pode dar conta do recado. se tem é a de que o software será modificado e, portanto, a
No entanto, se você tiver a necessidade de informatizar documentação do projeto é essencial para permitir a rastrea-
um sistema de uma biblioteca de uma instituição que possui bilidade e, mais importante, a manutenibilidade.
cerca de 10.000 usuários (onde há renovação de quase 2.000 Para lidar com essa demanda, a engenharia de software
usuários por ano) e tem mais de 50.000 títulos entre livros, provê um conjunto de procedimentos, formalismos e técnicas
revistas e outros itens (com aquisição regular de novos títu- que visa a construção de sistemas de software que atendam os
los), então você terá a necessidade de trabalhar em equipe a requisitos funcionais e não funcionais. Note que a proposta
fim de desenvolver esse software. Aqui, torna-se prudente da engenharia de software compreende estabelecer e utilizar
documentar o projeto. Aqui, documentação não é um ‘luxo’, princípios de engenharia a fim de obter software de baixo
mas sim uma necessidade, pois tal sistema com certeza terá custo que seja confiável e opere de maneira efi ciente nas
modificações. máquinas onde for empregado.
Agora, pode-se considerar uma situação ainda mais extrema Como há uma certeza de que o software sofrerá modificações,
de documentação de projeto. Você tem noção de quantas linhas então os artefatos do projeto serão constantemente alterados
de código há num Boeing 777? durante o desenvolvimento de software. Nesse sentido, o
Um Boeing 777 tem mais de 4 milhões de linhas de código desenvolvimento de várias versões do sistema requer que a
(isto é, software) rodando em cerca de 1.300 processadores. equipe estabeleça mecanismos para controlar a evolução do
Agora, você imagina desenvolver tudo isso sem qualquer software pois, do contrário, a rastreabilidade do que foi alte-
planejamento ou documentação de projeto? rado pode ser comprometida.
Desenvolver um sistema como de uma biblioteca ou similar
requer atividades de modelagem para apoiar o projeto, um Reuso de Software
processo de desenvolvimento com atividades bem definidas, Reuso é considerado como uma espécie de ‘palpite’ para o
além de ferramentas que automatizem atividades do proces- futuro do software. Perceba que o aumento da produtividade
so. E, isso será ainda mais essencial no desenvolvimento de decorrente de uma adoção de cultura de reuso de artefatos de
sistemas de grande porte como, por exemplo, software utili- software pode implicar num conjunto de benefícios listados
zado em aviões, sistemas de comércio eletrônico e sistemas de abaixo:
administradoras de cartão de crédito. • Melhor qualidade;
Perceba que desenvolvimento de software tem sido e ain- • Maior produtividade;
da permanece uma atividade difícil, pois ela requer que o • Melhor uso de recursos;

Edição 32 - Engenharia de Software Magazine 35

• Atendimento a demanda de negócios; Dentro do contexto destacado acima, o profissional de enge-
• Menos tempo para entrega do produto; nharia de software deve considerar participar de programas
• Auxílio a questões complexas de sistemas (o reuso de forma de educação continuada de modo a atender a demanda por
sistemática implica numa recuperação de investimento de produtos inovadores, maiores e mais complexos. Nesse sentido,
qualquer tecnologia). um aspecto de suma importância no projeto de sistemas de sof-
Da mesma forma que se podem identificar as vantagens des- tware de grande porte é sua organização a qual é representada
tacadas acima, as empresas podem se deparar com limitações como um modelo arquitetural que consiste de componentes
como, por exemplo: computacionais e de conectores que permitem a interação
• Exige investimento inicial; entre esses componentes. Esta percepção corresponde à visão
• Um tanto de ‘aposta’ no futuro; arquitetural de software num projeto de sistema.
• Pode induzir a erros se não for adequadamente conduzido; É importante também considerar que uma questão antece-
• Pode resultar em custos maiores se não for devidamente dente a importância que a área de arquitetura de software tem
realizado; no contexto atual diz respeito à natureza do software, bem
• Deve ser empregado de maneira cautelosa em sistemas que como seu crescimento em termos de tamanho e complexidade.
requerem confiabilidade operacional. Vale lembrar que os problemas de desenvolvimento de sistemas
de software de larga escala foram inicialmente reconhecidos
A certeza que existe de que software é quase sempre modifi- durante a década de 60. Em razão disto, na década de 70,
cado requer do engenheiro de software o cuidado de documen- houve grande atenção dos desenvolvedores e pesquisadores
tar adequadamente o projeto para futura manutenção, futura para o projeto de software. Uma das idéias da época era que
necessidade de rastrear parte dos requisitos do projeto (para a atividade de projeto era separada da implementação, bem
adição ou alteração de funcionalidades), além de futuro reuso, como exigia notações e técnicas específicas.
implicando em possível redução de custo de desenvolvimento Já na década de 80, a pesquisa em engenharia de software
e aumento de produtividade. deixou o foco em projeto de software e esteve mais concen-
trada na integração de projetos, bem como no processo de
Sobre a necessidade de educação continuada projeto e gerenciamento de software. Como resultado desse
Nesse cenário de elevada demanda por software, quais os foco de pesquisa, houve o surgimento de várias técnicas de
componentes de qualificação profissional fundamentais para modelagem e projeto de software, sendo essas incorporadas
um engenheiro de software? Perceba que o cenário atual e de às linguagens de programação. Além disso, houve pesquisa
décadas vindouras requer educação continuada. e avanços nos métodos de análise, fazendo uso de técnicas de
Tecnologia da informação e, mais especificamente, software descrição formais, o que permitiu lidar melhor com problemas
tem sido e continuará a ser um produto demandado no mer- de inconsistência e ambiguidades.
cado global. Apesar da volatilidade verificada em segmentos No início da década de 90, houve um trabalho de catalogação
do mercado, os cenários indicam crescimento de demanda por de padrões de projeto do grupo conhecido como “Gang of Four”.
software e seus profissionais. De acordo com pesquisa da rea- Tais padrões são considerados como experiência de projeto que
lizada pela Forrester Research, Inc. informa que gastos a nível pode ser reutilizada. Ainda na década de 90, porém em sua
mundial no ano de 2009 foram de US$ 1,469 bilhões no setor segunda metade, a tecnologia baseada em componentes tem
de TI, sendo US$ 362 bilhões referentes a software, havendo ganhado proeminência. Isto pode ser justificado, em parte, de-
previsão que nos anos de 2010 e 2011 os gastos com software vido à aceitação das abordagens orientadas a objetos. É impor-
serão de aproximadamente US$ 400 e 440 bilhões, como mos- tante observar que a abordagem orientada a objetos tem sido
trado na Figura 3. Desse total, quase metade do mercado de difundida com a tecnologia de componentes de software.
software é pertinente aos EUA, enquanto que cerca de 10% do Adicionalmente, o desenvolvimento de técnicas de abstração
total é pertinente à América Latina. tem sido uma das principais fontes de avanço em termos de
desenvolvimento e programação de sistemas de software e
a década 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 organização do software
em sistemas de grande porte, diferentemente, do principal
foco de interesse em ciência da computação que recai sobre
as estruturas de dados e projetos de algoritmos. Dessa forma,
arquitetura de software requer notações, técnicas e ferramentas
Figura 3. Gastos em TI a nível mundial. (Fonte: Global IT Market Report, específicas. Num projeto arquitetural de software, os esforços
Forrester Research, Inc., 2010) concentram-se na organização do sistema, distribuição dos

36 Engenharia de Software Magazine - Engenharia de Software

 ENGENHARIA DE SOF T WARE

componentes, protocolos de comunicação, mecanismos de

sincronização e acesso a dados, dentre outros. requisitos
Tipo de Representação - Uma descrição de arquitetura de
software faz uso de notações baseadas em grafos, onde se tem
um conjunto de componentes e conectores interligando esses
arquitetura de software
componentes. Os componentes compreendem unidades de
computação que realizam tarefas tais como clientes, servi-
dores, banco de dados e objetos. Os conectores atuam como
mecanismos de interligação dando suporte à interação entre Implementação
os componentes. Exemplo disto são as chamadas de procedi-
Figura 4. Arquitetura como elo entre requisitos e implementação
mentos, pipes e protocolos de acesso.
Estilo Arquitetural - Um estilo arquitetural descreve os
tipos de componentes e conectores pertinentes a uma família componentes de um sistema de modo a minimizar o custo e
arquitetural bem como características topológicas e semânticas esforço de atualização e manutenção em um sistema. Assim,
de seus elementos. uma descrição arquitetural pode separar a funcionalidade de
Projeto a nível Arquitetural - O projeto arquitetural tem seu um componente de outros levando em conta as formas nas
foco nos compromissos assumidos durante o projeto, onde o quais esses componentes interagem uns com os outros. Isto
projetista ou arquiteto de software busca casar as propriedades permite que modificações nos componentes ou no mecanismo
de uma arquitetural a um conjunto de funcionalidades e atri- de conexão possam acontecer, possibilitando a adição de novas
butos de qualidade desejados no sistema a ser desenvolvido. características e/ou funcionalidades com custos de modifica-
Esta abordagem difere dos métodos de projeto de software ção devidamente estimados.
que definem um conjunto de passos que orientam o projetista Reuso - As descrições arquiteturais oferecem suporte ao
desde a análise de requisitos até a implementação. reuso em múltiplos níveis. Podem-se ter arquiteturas reutili-
záveis que fornecem a organização e o modelo de coordena-
É importante observar que o projeto a nível arquitetural ção usado em diversos sistemas. Também, tem-se o reuso de
vem para complementar os métodos de projeto, uma vez componentes que possibilita a reutilização de componentes
que no projeto arquitetural é feita a seleção de um estilo em vários sistemas. Além disso, pode-se ainda considerar os
arquitetural (ou combinação de estilos) de modo a satisfazer trabalhos existentes sobre arquiteturas de domínio específico,
um conjunto de funcionalidades e atributos de qualidade. que oferece suporte ao reuso.
Não é difícil identificar as contribuições que a disciplina Análise - Uma descrição da arquitetura fornece mais subsídios
de arquitetura de software tem proporcionado ao processo à análise, possibilitando-se checar a consistência e conformidade
de desenvolvimento de software. O projeto arquitetural com estilo arquitetural. Além disso, é verificado se requisitos
tem papel relevante, principalmente, no desenvolvimento não funcionais são suportados pela arquitetura sob análise.
de sistemas de grande porte, pois uma escolha inadequada Gerenciamento - Considerar a obtenção da arquitetura
de uma arquitetura em detrimento de outra pode acarretar de software de um sistema como marco num processo de
em resultados insatisfatórios em termos de desempenho, desenvolvimento constitui em assegurar as possibilidades
confiabilidade, interoperabilidade e outros requisitos não de expansão do sistema e custos envolvidos, bem como que
funcionais que são diretamente relacionados à arquitetura de os requisitos de capacidade operacional do sistema serão
software do sistema. Perceba que a arquitetura de software atendidos. Caso contrário, se este marco não existe, pode-se
de um sistema atua com um elo entre os requisitos e a imple- deparar com a situação na qual a arquitetura não acomoda
mentação. Esta visão é ilustrada na Figura 4. futuras expansões no sistema e/ou a capacidade operacional
Fornece ainda uma descrição abstrata do sistema, expondo do sistema fica aquém do desejado.
um conjunto de propriedades e ocultando outras. A arquite-
tura de software permite que engenheiros ou arquitetos de Um aspecto de suma importância a ser considerado é a natu-
software possam avaliar se um sistema pode ou não satisfazer reza evolutiva do processo de desenvolvimento de software,
um conjunto de requisitos. Um conjunto de contribuições ao bem como as novas possíveis aplicações onde software pode
processo de desenvolvimento de software, observadas ao ser usado. Esta característica evolutiva do software também
longo da década de 90, são destacadas abaixo. precisa ser considerada a nível arquitetural. Nesse sentido,
Compreensibilidade - A arquitetura de software consiste duas prováveis demandas incluem: (i) a crescente necessidade
de uma descrição de projeto em nível elevado de abstração, de integração de subsistemas e componentes de software e (ii)
o que simplifica a apresentação e entendimento de sistemas o uso de sistemas baseado em rede.
de grande porte. Adicionalmente, um modelo arquitetural Vale ressaltar que a necessidade de disponibilizar novos
ajuda a expor as restrições existentes no projeto. produtos, novos serviços e atualizar os existentes em função
Natureza Evolutiva - A natureza evolutiva dos sistemas da demanda e pressão do mercado tem influenciado a forma
de software requer que haja separação de interesses entre os na qual os sistemas de software são desenvolvidos.

Edição 32 - Engenharia de Software Magazine 37

 Colocar um novo sistema no mercado com um, dois ou três Do contrário, você será obrigado a fazer engenharia reversa
meses de antecedência em relação aos concorrentes pode sig- a fim de atender a necessidade de evolução do software. Por
nificar o sucesso de um produto e/ou a sobrevivência de uma outro lado, os conceitos e técnicas de engenharia reversa (que
empresa. Em função deste cenário, tem havido a tendência serão apresentados em artigo futuro) ajudam a ‘conscientizar’
de adquirir partes do sistema que já tenham sido desenvol- o profissional da importância de se ter um projeto de software
vidas por outros. Isto implica na possibilidade de concluir o adequadamente documentado.
desenvolvimento mais cedo de um produto, colocando-o no
mercado. Isto, contudo, implica na necessidade de efetuar a Referências
integração do sistema. Resultado disto tem sido o interesse
Software and higher education
por parte de empresas em buscar profissionais qualificados
[Link]
para realizar este trabalho de integração de subsistemas, onde
ele desenvolve código de integração, fazendo a ‘colagem’ dos Creating a Software Engineering Culture
subsistemas e/ou componentes. [Link]

Software Engineering Body of Knowledge

Conclusão [Link]
Engenharia de software é uma área fascinante, mas consi-
dero que devida atenção não tem sido dada à formação dos The Nature of Software: What’s So Special About Software Engineering?
[Link]
profissionais, objetivando conscientizá-los da importância da
documentação do projeto. Sem uma documentação adequada Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering
de projeto, a rastreabilidade dos artefatos, a manutenibilidade [Link]
e reuso de software fica comprometida.
Measuring and Sustaining the New Economy, Software, Growth, and the Future of
Observo que a maioria dos cursos de engenharia de software,
the U.S Economy: Report of a Symposium (2006)
tanto a nível de graduação quanto pós-graduação, dedicam [Link]
nenhuma ou uma ínfima parcela do tempo para a disciplina de
engenharia reversa de software, a qual considero como essen-
cial na formação do profissional de engenharia de software. Dê seu feedback sobre esta edição! Feedback
eu
Finalizando, este autor recomenda que a disciplina de en-

s
Dê
genharia reversa de software deva fazer parte da grade dos A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
cursos de Engenharia de Software, Computação e correlatos. Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
Por que? Observe que muitas empresas possuem sistemas Dê seu voto sobre este artigo, através do link:
(legados ou não) que requer manutenção e, para tanto, você [Link]/esmag/feedback
engenheiro de software necessita da documentação de projeto.

38 Engenharia de Software Magazine - Engenharia de Software

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Especificação de Casos de Uso

Aprenda através de alguns exemplos reais

De que se trata o artigo? através de casos de uso podem ser efetuadas em um

Este artigo apresenta inicialmente algumas definições nível de detalhe tal que informações importantes
associadas à engenharia de requisitos e à especificação para outras etapas do desenvolvimento como pla-
de requisitos através de casos de uso. Em seguida, são nejamento de testes, projeto e desenvolvimento não
apresentados alguns exemplos reais de especificação sejam omitidas.
de requisitos utilizando casos de uso. Além disso, este
artigo também apresenta algumas definições impor- Em que situação o tema é útil?
tantes sobre o diagrama de casos de uso e exemplifi- O assunto abordado é útil no dia a dia do analista
cará seu uso através de um exemplo prático. de requisitos na realização de suas atividades.
Rodrigo Oliveira Spínola
rodrigo@[Link] Para que serve?
Editor Chefe – Engenharia de Software Magazine O objetivo do artigo é explicitar de forma prática
Diretor de Operações - Kali Software (www. como a especificação dos requisitos do software
[Link])
Doutor e Mestre em Engenharia de Software

A
pela COPPE/UFRJ. Autor de diversos artigos
científicos sobre Engenharia de Software pu- engenharia de requisitos é um Mas o que podemos entender por re-
blicados em revistas e conferências renoma- termo usado para descrever quisitos? Existem diferentes definições
das, dentro e fora do país. Experiência de parti- as atividades relacionadas à encontradas na literatura técnica:
cipação em mais de 20 projetos de consultoria produção (levantamento, registro, vali- • Um requisito é uma característica do
para diferentes empresas tendo atuado com
dação e verificação) e gerência (controle sistema ou a descrição de algo que o
gerência de projetos, requisitos e testes de
software. Implementador certificado do MPS. de mudanças, gerência de configuração, sistema é capaz de realizar para atingir
BR, tendo também experiência atuando junto rastreabilidade, gerência de qualidade os seus objetivos;
a empresas certificadas CMMI. dos requisitos) de requisitos. A Figura 1 • As descrições das funções e restrições
representa essa definição. são os requisitos do sistema.
Conteúdo Multimídia!
Neste artigo você encontra o vídeo: “Trabalhan- Para ter acesso à esse artigo na íntegra acesse o leitor digital:
do com requisitos e casos de uso com a UML”
[Link]/esmag [Link]/esmag

Edição 32 - Engenharia de Software Magazine 39

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Entendendo melhor SOA e ESB

Importantes conceitos para demandas de negócio

De que se trata o artigo? possibilitando uma maior integração entre seus mo-
Apresentar, através de uma visão geral, os conceitos, delos de negócio.
diferenças e algumas características de SOA (Service Em que situação o tema é útil?
Oriented Architecture) e ESB (Enterprise Service Bus) Quando se pretende otimizar os recursos disponí-
e como estes podem ser úteis nas empresas que os veis nas empresas, através do reuso de componen-
adotam. tes e integração de serviços, sobretudo quando
se deseja buscar uma aproximação das áreas de
Para que serve? negócio e de TI, aumentando a visão e o poder de
Proporcionar às empresas um maior planejamento decisão por parte de seus gestores.
para implementação de seus sistemas distribuídos,

A
s empresas estão percebendo a criação de serviços de negócio inte-
cada vez mais a necessidade roperáveis que podem facilmente ser
de ter e manter suas infraestru- reutilizados e compartilhados entre
turas de TI prontas para acompanhar as diversas aplicações utilizadas nas
Lenildo Morais as mudanças do mercado. Este fator empresas.
lenildojmorais@[Link] implica diretamente no crescimento O Service-Oriented Architecture (SOA),
É analista de sistemas e analista de testes.
e na competitividade diante de seus ou Arquitetura Orientada a Serviços, é
Atualmente está cursando mestrado no cen-
tro de informática da UFPE em engenharia de concorrentes, independentemente do um estilo de arquitetura utilizado no
software com ênfase em testes e qualidade de segmento de atuação da mesma. Neste desenvolvimento de softwares onde
software. contexto, o SOA é uma abordagem uma aplicação é definida como um
arquitetural corporativa que permite conjunto de serviços.
Conteúdo Multimídia!
Neste artigo você encontra o vídeo: “Projeto de
Arquitetura de Software“ Para ter acesso à esse artigo na íntegra acesse o leitor digital:
[Link]/esmag [Link]/esmag

40 Engenharia de Software Magazine - Entendendo melhor SOA e ESB

 ARQUITE TUR A

Edição 32 - Engenharia de Software Magazine 41

42 Engenharia de Software Magazine - Entendendo melhor SOA e ESB