Edição33 2011

Modstia parte, sua
melhor opo para

se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
So programas voltados para a
formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
EDITORIAL
desenvolvimento de qualquer software, exceto programas muito simples, uma tarefa bastante complexa. Esse fato se tornou evidente
com a crise de software, o que originou o conceito de engenharia de
software como uma abordagem sistemtica, disciplinada e quantificvel para o

desenvolvimento, manuteno e descarte de software.
Ano 3 - 33 Edio - 2011
Impresso no Brasil
A engenharia de software surgiu inicialmente mais como uma promessa do

que uma realidade. De fato, muitos dos problemas ligados ao desenvolvimento e manuteno de software continuam sem soluo, apesar de muitos con-
Corpo Editorial
ceitos terem evoludo.
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
cia do significado do termo, constitui passo fundamental para o estudo e apro-
Entender o que significa manuteno de software, e principalmente a abrangnfundamento de solues para os problemas atrelados a essa tarefa.
Neste contexto, a Engenharia de Software Magazine destaca nesta edio o
artigo Dificuldades e Problemas Encontrados na Manuteno de Software.
Capa e Diagramao
Romulo Araujo - romulo@devmedia.com.br
Este artigo foca na discusso sobre as dificuldades encontradas na realizao

das atividades de manuteno de software. Para isso, apresenta a realizao
Coordenao Geral
Daniella Costa - daniella@devmedia.com.br
de um estudo de observao que foi conduzido com o objetivo de verificar
Revisor
Gregory Monteiro - gregory@clubedelphi.net
empenhada no desenvolvimento de software comercial. Alm disso, apresen-
Jornalista Responsvel
Kaline Dolabella - JP24185
identificados pelo estudo de caso, e aqueles registrados no passado, buscan-
Na Web
www.devmedia.com.br/esmag
Alm desta matria, esta edio traz mais sete artigos:
os problemas de manuteno de software existentes em uma organizao

ta uma comparao entre os problemas de manuteno de software atuais,
do inferir algum padro de evoluo nos mesmos.
E se voc fosse um DVD numa locadora?
Apoio
Mtodo de Anlise e Projetos em SOA

A importncia da Engenharia de Requisitos
Variabilidade em Linha de Produto de Software
Reengenharia de Software Orientado a Objetos
Refatorao para Padres - Parte 6
Computao em Nuvem
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
Isabelle Macedo e Uellen Goulart Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Cristiany Queiroz
publicidade@devmedia.com.br
Fale com o Editor!

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

Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spnola

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

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

eduspinola@gmail.com
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS)
onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
NDICE
Por trs do bvio
06 E se voc fosse um DVD numa locadora?
Glnio Cabral
Desenvolvimento
Para esta edio, temos um conjunto de 5 vdeo aulas.

Estas vdeo aulas esto disponveis para download no Portal
da Engenharia de Software Magazine e certamente traro
uma significativa contribuio para seu aprendizado. A lista
de aulas publicadas pode ser vista abaixo:
08 - Refatorao para Padres Parte 6

Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
14 - Computao em Nuvem
Gabriella Castro Barbosa Costa e Marco Antnio Pereira Arajo
Engenharia
28 - Mtodo de Anlise e Projetos em SOA
Henrique Shoiti Fugita e Davi Carvalho S., Jr.
Tipo: Processo
Ttulo: Especificao de casos de uso na prtica Partes 11 a 15
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Definir requisitos no uma atividade trivial. Uma das
formas de realizar esta atividade atravs da especificao de casos de
uso. Neste sentido, nesta srie de vdeo aulas apresentaremos um conjunto
de especificaes de casos de uso. Os cenrios sero especificados passo
a passo considerando tpicos como fluxo principal, fluxo alternativo e
regras de negcios.
34 - Dificuldades e Problemas Encontrados na Manuteno de Software

Mateus Maida Paduelli
46 - Reengenharia de Software Orientado a Objetos

Giuliano Prado de Morais Giglio
53 - A importncia da Engenharia de Requisitos

Helder Vincius F. de Oliveira
54 - Variabilidade em Linha de Produto de Software

Edson A. Oliveira Junior
Edio 05 - Engenharia de Software Magazine
Pos trs do bvio

Glnio Cabral
gleniocabral@yahoo.com.br
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
E se voc fosse um DVD

numa locadora?
I
magine que voc seja um filme em DVD exposto em uma

vdeo locadora. Sendo um filme, o que voc mais deseja?
Ser locado, claro. Mas h um srio problema: voc no
o nico DVD da locadora. H vrios outros que desejam
ser locados tambm.
Sei que parece loucura, mas a luta pela sobrevivncia pode
ser observada at mesmo no cotidiano dos DVDs. E olhe que
nem seres vivos essas pobres mdias so. Seja como for, os
filmes mais locados sempre sero aqueles que despertarem
um maior interesse no pblico. Como cinfilo assumido,
sou constantemente seduzido pelos melhores filmes de uma
locadora. Por isso desconfio que as tticas de diferenciao
utilizadas por essas mdias para chamar a minha ateno
so as seguintes:
Todo bom filme tem grandes atores em suas tramas
Dificilmente eu deixaria de alugar um filme estrelado por
Denzel Washington, Al Patino ou Danny Glover. So atores
consagrados que transformaram seus nomes em grandes
marcas de sucesso. Isso chama a ateno para o fato de que
o fator nome tem um grande peso no processo de diferenciao. Que tipo de marca voc tem construdo em torno do seu
Engenharia de Software - E se voc fosse um DVD numa locadora?
nome? Nos corredores corporativos seu nome sinnimo

de competncia, esforo e dedicao? O que seu nome tem
representado para o mercado de trabalho, e a que ele est
atrelado? Uma marca ou nome de credibilidade costumam
atrair olhares interessados mesmo em meio diversidade
de opes.
Todo bom filme traz comentrios elogiosos a seu
respeito
Dia desses aluguei o filme sueco de suspense policial
Os homens que no amavam as mulheres. Mesmo no
conhecendo nenhum dos seus atores acabei alugando o
filme apenas por que vi em sua capa o seguinte comentrio
da Revista Isto : O filme de grudar na cadeira.
Uma indicao ou uma boa referncia pode fazer toda a
diferena em determinado momento. Por isso muito importante deixarmos sempre uma boa impresso por onde
quer que venhamos a exercer nossas atividades. Essa postura costuma garantir valiosas indicaes ao nosso respeito.
Voc do tipo que deixa sempre as portas abertas por onde
passa? Ou especialista em fech-las com os cadeados da
antipatia, indiferena e individualismo?
por trs do bvio
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
D
s
D seu feedback sobre esta edio!
Feedback
eu
www.devmedia.com.br/esmag/feedback
sobre e
s
Todo bom filme tem que ter contedo

De nada adiantar para um filme ter bons atores, ter boas
referncias e ter uma excelente campanha de mdia se de fato
ele no for bom. Tudo no ter passado de uma propaganda

enganosa.
Por isso faa o seu dever de casa. No se contente apenas
em desenvolver competncias tcnicas, invista cada vez
mais nas competncias emocionais. Capacidade de liderana motivadora e habilidades para administrar conflitos so
posturas cada vez mais desejadas no mercado de trabalho.
Tenha contedo. Estude, se especialize, invista em voc. No
permita que as expectativas geradas em torno de um eficiente
marketing pessoal acabem gerando uma grande frustrao.
Seja sempre aquilo que voc apregoa.
edio
ta
Todo bom filme tem uma boa campanha de divulgao

A animao da Pixar Os Incrveis foi de fato incrvel. Mas
a sua campanha de divulgao foi muito mais incrvel ainda.
Por melhor que seja um filme, se ele no tiver uma boa campanha de marketing dificilmente ter alguma repercusso no
mercado. Por isso no basta ser bom e competente, preciso
fazer com que as pessoas percebam e vejam isso. Ter uma
boa poltica de contatos, manter uma boa aparncia, saber se
auto-promover com bom senso, estar sempre na hora certa
e no lugar certo e nunca deixar as portas se fecharem so
algumas das atitudes bsicas que devem compor o marketing
pessoal do produto chamado voc. Voc bom no que faz
e sabe disso? Ento faa como os Incrveis, saiba se divulgar.
Seja incrvel nisso tambm.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 6

Implementando o padro Decorator com Mover Embelezamento para Decorator
De que se trata o artigo?

Aborda o tema refatorao para padres com o
objetivo de mostrar como o desenvolvedor pode
us-lo para melhorar o cdigo-fonte de suas
aplicaes.
Para que serve?

Jacimar Fernandes Tavares
jacimar.tavares@studentpartners.com.br
Bacharel em Cincia da Computao FAGOC

- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor dos Cursos de Bacharelado em Sistemas
de Informao do Centro de Ensino Superior de Juiz de Fora, da Faculdade Metodista Granbery e da Universidade Severino
Sombra, professor do Curso Superior de
Tecnologia em Anlise e Desenvolvimento
de Sistemas da Fundao Educacional D.
Andr Arcoverde, Analista de Sistemas da
Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.
uando se est criando o desenho

de uma classe, o responsvel
por esta tarefa (projetista ou
at mesmo o desenvolvedor, em alguns
casos) costuma tomar alguns cuidados,
dentre eles: definir classes que reflitam
o negcio do cliente, criar mtodos e atributos necessrios ao contexto da classe e
ainda tomar o devido cuidado para que
uma classe no possua responsabilidade
que deveria pertencer outra classe.
Todos esses cuidados so vlidos, mas
ainda existe outro que muitas vezes
passa despercebido em alguns casos,
que est relacionado questo do embelezamento de uma classe.
Classes consideradas embelezadas
so aquelas que possuem diversas funcionalidades, alm das funcionalidades
bsicas. Tais funcionalidades so escritas
e usadas eventualmente, ou seja, no so
Engenharia de Software Magazine - Refatorao para Padres Parte 6
Para prover conhecimento ao desenvolvedor sobre refatorao para padres e demonstrar atravs de um exemplo prtico a aplicao da tcnica
de refatorao para padres Mover Embelezamento para Decorator.
Em que situao o tema til?

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

todo o momento. Conceitualmente no
h problemas quando uma classe possui
muitas funcionalidades (desde que as
funcionalidades realmente pertenam
a ela), mas isto dificulta a visualizao
do real objetivo da classe, visto que todo
Desen volvimento
esse cdigo de embelezamento pode atrapalhar a descoberta

do real objetivo da classe, em uma anlise posterior.
O padro de projeto Decorator fornece um mecanismo que
possibilita a criao de classes que carregaro consigo o
cdigo que embeleza a classe, onde cada decorador tem sua
funo. Dentro deste objetivo, que o de criar decoradores
para uma classe, est a refatorao para padres Mover
Embelezamento para Decorator, que ser apresentada neste
artigo. Contudo, para seu aprendizado, necessria a prvia apresentao de tcnicas de refatorao como Extrair
Interface, Substituir Condicional por Polimorfismo, Substituir Enumerao por Subclasse, Criar um Mtodo Padro,
Substituir Herana por Delegao e, por ltimo, Remover
Parmetro (ver Nota 1).
A partir deste momento sero apresentadas as refatoraes
participantes e, posteriormente, a tcnica de refatorao para
padres deste artigo.
O padro de projeto Decorator

Nome do padro de projeto: Decorator. Pertencente ao
conjunto dos padres de projeto classificados como Padres
Estruturais.
O problema: Devido ao fato de que o desenvolvedor tem
a liberdade de tratar cada instncia de uma classe de forma
diferente, o padro de projeto Decorator atua fornecendo
um mecanismo para que ele possa utilizar determinada
funcionalidade em um objeto, sem ter que fazer com que
a classe instanciadora desse objeto herde da classe que
contm a funcionalidade desejada. Uma implementao do
padro de projeto Decorator permite que todo cdigo que
compe um comportamento extra, mas no obrigatrio a
todas as instncias de uma classe, seja escrito nas classes
que o compe.
As consequncias: Com a implementao deste padro
de projeto, o desenvolvedor pode construir aplicaes mais
flexveis, dado que o comportamento no obrigatrio a todas
as instncias de uma classe seja implementado no Decorator,
evitando um aumento na quantidade de cdigo na classe
instanciadora do objeto.
Extrair Interface
Esta refatorao pertencente ao grupo de refatoraes
classificadas como Lidando com Generalizao.
Nome da refatorao: Extrair Interface.
Resumo: Em vrios pontos de um sistema pode-se perceber
que h uma grande utilizao de alguns mtodos de vrias
classes. Cria-se, portanto uma interface que permita aos
clientes da aplicao apontarem para a interface, ao invs
de apontar para diversas classes.
Nota 1: Refatorao Mover Mtodo
As tcnicas de refatorao Substituir Condicional por Polimorfismo, Substituir Enumerao por
Subclasse e Criar um mtodo Padro j foram apresentadas em outras edies da Engenharia
de Software Magazine, mais precisamente nas edies 30 e 32.
Motivao: Analisando algumas classes de um sistema, pode-se

perceber que algumas de suas funcionalidades em comum com as
outras esto sendo muito utilizadas em diversos pontos da aplicao. Isso dificulta a tarefa do programador que, neste caso, tem
que verificar classe por classe buscando essas responsabilidades.
Um recurso a criao de uma Interface que possua a declarao
desse grupo de responsabilidades, permitindo que o programador referencie a interface, ao invs de um grupo de classes.
Mecnica:
O primeiro passo consiste em criar uma interface vazia.
Segundo, declara-se o grupo de operaes em comum nas
diversas classes na interface.
Modifique as classes envolvidas para que passem implementar a interface.
Faa com que os clientes passem a referenciar a interface
ao invs das vrias classes.

Exemplo: O cdigo da Listagem 1 parte do cdigo de uma
classe chamada Usuarios, em um sistema web.
Ao analisar o cdigo desta classe percebe-se que h trs
mtodos (alm da parte omitida com reticncias), todos
com a responsabilidade de recuperar nomes, sendo um que
recupera nome de um vendedor (RecuperaNomeVendedor),
outro que recupera o nome do administrador (RecuperaNomeAdministrador) e, por ltimo, o que recupera nome
da secretaria (RecuperaNomeSecretaria). Neste contexto,
pode-se usar a refatorao Extrair Interface para criar uma
interface que conter mtodos que sero implementados pela
classe Usuarios, como mostra a Listagem 2.
Segundo, declara-se o grupo de operaes em comum nas
diversas classes na interface, como mostra a Listagem 3.
Os mtodos declarados na interface j esto implementados na classe Usuarios, portanto deve-se modificar a classe
Usuarios para que a implementao dos mtodos da interface
possa ocorrer, como mostra a Listagem 4.
Est concluda a refatorao Extrair Interface. Agora devese analisar todo o cdigo da aplicao em busca de pontos
que invocavam os mtodos que recuperam nome, da classe
Usuarios, modificar para que, a partir de agora, passem a
invocar os mtodos declarados na interface.
Substituir Herana por Delegao

classificadas como Lidando com Generalizao.
Nome da refatorao: Substituir Herana por Delegao.
Resumo: Subclasses que no herdam dados ou fazem uso
de uma pequena parte da interface da superclasse devem
ter seus mtodos ajustados a fim de que deleguem para a
superclasse atravs de um campo.
Motivao: Usada para simplificar o projeto de cdigo existente ao substituir uma herana por uma delegao. Com isso,
a subclasse que faz uso apenas de uma parte do cdigo de sua
superclasse, pode ter sua complexidade diminuda atravs da
delegao que deixa claro que apenas uma parte da classe pai
est sendo utilizada.
Listagem 1. Classe Usurios.
1. public class Usuarios

2. {
3.
4.
public String RecuperaNomeVendedor(Int32 id)
5.
{
6.
SqlConnection Conexao = Acesso.getConexao();
7.
String queryIDVendedor = SELECT NOME FROM TBVendedores
WHERE IDVENDEDOR = + id + ;
8.
String nome = ;
9.
SqlCommand Commando = new SqlCommand(queryIDVendedor,
Conexao);
10.
try
11.
{
12.
Commando.ExecuteNonQuery();
13.
SqlDataReader dados = Commando.ExecuteReader();
14.
while (dados.Read())
15.
{
16.
nome = Convert.ToString(dados[0]);
17.
}
18.
dados.Close();
19.
return nome;
20.
}
21.
catch
22.
{
23.
return nome;
24.
}
25.
}
26.
public String RecuperaNomeSecretaria(Int32 id)
27.
{
28.
29.
String queryIDSecretaria = SELECT NOME FROM TBSecretaria
WHERE IDSECRETARIA = + id + ;
30.
String nome = ;
31.
SqlCommand Commando = new SqlCommand(queryIDSecretaria,
Conexao);
32.
try
33.
{
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
10
48.
49.
50.
51.
}
catch
{
return nome;
}
public String RecuperaNomeAdministrador(Int32 id)

{
String queryIDAdministrador = SELECT NOME FROM
TBAdministrador WHERE IDADMINISTRADOR = + id + ;
String nome = ;
SqlCommand Commando = new SqlCommand
(queryIDAdministrador, Conexao);
try
{
{
}
dados.Close();
return nome;
}
catch
{
return nome;
}
}
...
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71. }
Mecnica:
Na subclasse, cria-se um atributo privado do tipo da superclasse.
Modificam-se os mtodos da subclasse para fazerem uso do
atributo privado criado.
Modifica-se a subclasse retirando sua classificao de classe
filha.
Exemplo: A classe Calculos possui vrios mtodos responsveis por realizar os mais diversos clculos requeridos em um
sistema de contas. A classe Emprestimos, calcula vrios tipos
de emprstimos e outras coisas associadas ao ato de fornecer
crdito a clientes. A Listagem 5 mostra a classe Emprestimos
e um mtodo em especial.
Um problema com essa hierarquia de classes, onde a classe
Emprestimos a subclasse da superclasse Calculos, que apenas
uma parte da classe Calculos est sendo herdada. Isso fica visvel
ao analisar-se o mtodo CalcularRiscoEmprestimo, que necessita do resultado provido pelos mtodos CalcularPorcentagem
e CalcularMedia, ambos pertencentes a classe Calculos.
Para remover esta herana usa-se uma delegao. Para isso,
cria-se um atributo privado da classe Calculos dentro da classe
Emprestimos, conforme Listagem 6.
{
}
dados.Close();
return nome;
Listagem 2. Interface IRecuperaNomes.
1. public interface IRecuperaNomes

2. {
3. }
Listagem 3. Interface com as declaraes das operaes.
1.
2.
3.
4.
5.
6.
public interface IRecuperaNomes

String RecuperaNomeVendedor(Int32 id);
String RecuperaNomeAdministrador(Int32 id);
String RecuperaNomeSecretaria(Int32 id);
Listagem 4. Modificao na declarao da classe Usurios.
1. public class Usuarios: IRecuperaNomes

2. {
3. ...
No mtodo CalcularRiscoEmprestimo, classe Emprestimos,

altera-se os pontos onde so invocados os mtodos CalcularPorcentagem e CalcularMedia. A partir deste momento, eles
passam a delegar classe Calculos e a herana poder ser
removida. A Listagem 7 apresenta a Classe Emprestimos com
a refatorao aplicada. Um comparativo entre antes e depois do
uso da refatorao pode ser feito com as Listagens 5 e 7.
Desen volvimento
Remover Parmetro
classificadas como Tornando as Chamadas de Mtodos Mais
Simples.
Nome da refatorao: Remover Parmetro.
Resumo: Alguns mtodos possuem parmetros que no
esto sendo usados. Neste contexto, aplica-se esta refatorao
e remove-se o parmetro.
Motivao: Alguns mtodos apresentam vrios parmetros.
Aps algumas mudanas nesse cdigo, pode ser que alguns desses parmetros no estejam mais sendo utilizados, mas esto presentes porque alguns desenvolvedores julgam que remov-lo no
necessrio, dado que posteriormente podem precisar dele.
Mecnica:
Analisando o mtodo que contm o parmetro que deseja
remover, certifique-se que realmente ele no est sendo usado,
inclusive por algum cdigo que o altere em uma hierarquia
de classes.
Crie um novo mtodo, removendo o parmetro desnecessrio.
Copie o corpo do mtodo com parmetro para o corpo do
mtodo recm criado e remova o mtodo antigo.
Execute seus testes.
O contedo necessrio para que o desenvolvedor possa
entender como se d o processo de refatorao para o padro
Decorator, atravs da refatorao para padres Mover Embelezamento para Decorator foi apresentado at este momento,
restando agora a apresentao da tcnica de refatorao para
padres que conta com um exemplo prtico.
Mover Embelezamento para Decorator

Resumo: Uma classe est carregando muito cdigo que a est
embelezando, ocultando assim a sua responsabilidade bsica. Criase um Decorator que receber este cdigo de embelezamento.
Motivao: Uma motivao para o uso desta refatorao est
no fato de que, com o decorrer do ciclo de vida da aplicao,
onde novas funcionalidades so inseridas em determinada
classe, a mesma pode chegar a um ponto onde entender qual
a responsabilidade bsica se torne uma tarefa difcil, ou seja,
o motivo que levou a sua criao pode no estar mais to claro,
pois devido a essas novas funcionalidades, muito cdigo novo
foi criado, o que caracteriza um embelezamento de classe.
Aplicando esta refatorao para padres, aliada ao padro de
projeto Decorator, pode-se criar um decorador que receber o
cdigo que embeleza a classe. Com isso, consegue-se manter
as classes da aplicao apenas com suas responsabilidades
bsicas, e o cdigo que fornece caractersticas que so usadas
apenas em alguns momentos fica no decorador.
Vantagens: Permite a simplificao de uma classe, ao remover cdigo de embelezamento; Permite a separao das
responsabilidades bsicas da classe do cdigo que a embeleza;
Permite remover cdigo duplicado ao centralizar o cdigo de
embelezamento em uma classe.
Desvantagens: Altera a identidade de um objeto ao usar o
cdigo do decorator; Dificulta a depurao do cdigo em alguns
momentos, visto que ele no est mais centralizado em uma

classe; Pode complicar um projeto devido combinao de
vrios decoradores.
Mecnica:
Crie uma classe ou interface que permita a declarao dos
mtodos que sero usados para embelezar a classe. Caso queira
usar uma interface, utiliza-se Extrair Interface.
Buscando pela lgica que embeleza a classe, se encontrada
expresses condicionais, aplica-se Substituir Condicional por
Polimorfismo, e em alguns contextos, talvez seja necessrio a
utilizao da refatorao Substituir Enumerao por Subclasses. Outro ponto a se considerar a utilizao da refatorao
Criar um Mtodo Padro, caso seja necessrio. Move-se o
cdigo do embelezamento para a subclasse criada.
A hierarquia de classes criada deve ser substituda, aplicando
a refatorao Substituir Herana por Delegao.
Listagem 5. Classe Emprestimos.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public class Emprestimos : Calculos

{
...
private void CalcularRiscoEmprestimo(ArrayList
listaMesesContribuicaoINSS, Decimal valorSalario)
{
Decimal valorMaximoEmprestimo = CalcularPorcentagem
(valorSalario, 10.0m);
Decimal mediaAnual = CalcularMedia(listaMesesContribuicaoINSS);
if (valorMaximoEmprestimo > 100.0m && mediaAnual > 10.0m)
{
...
}
}
...
}
Listagem 6. Classe Emprestimos com o atributo delegado da classe Calculos.
1.
2.
3.
4.
5.
6.
public class Emprestimos : Calculos

{
...
private Calculos calculo;
{ ...
Listagem 7. Classe Emprestimos depois da refatorao.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class Emprestimos

{
...
private Calculos calculo;
{
Decimal valorMaximoEmprestimo = calculo.CalcularPorcentagem
(valorSalario, 10.0m);
Decimal mediaAnual = calculo.CalcularMedia
(listaMesesContribuicaoINSS);
if (valorMaximoEmprestimo > 100.0m && mediaAnual > 10.0m)
{
...
}
}
...
}
11
Listagem 8. Classe Cliente.
1. public class Cliente

2. {
3.
4. public Cliente CriarCliente(Int64 id, String nome, String cpf, String rg)
5. {
6.
Cliente cliente = new Cliente();
7.
cliente.ID = id;
8.
cliente.Nome = nome;
9.
cliente.Cpf = Cpf;
10. cliente.Rg = rg;
11. return cliente;
12. }
13. public Boolean EditarCliente(Int64 id, String nome, String cpf, String rg)
14. {
15. Cliente cliente = CriarCliente(id, nome, cpf, rg);
16. if (GravarEdicao(cliente))
17. {
18.
return true;
19. }
20. else
21. {
22.
return false;
23. }
24. }
25. public Boolean ExcluirCliente(Int64 id)
26. {
Listagem 9. Classe DecoradorCliente.
1. public class DecoradorCliente: Cliente

2. {
3. }
Listagem 10. Classe DecoradorCliente.
1. public class DecoradorCliente: Cliente

2. {
3. public Boolean MudarCategoriaCliente(Int64 id, String categoria)
4. {
5. Cliente cliente = Recuperar(id);
6. cliente.Categoria = categoria;
7. if (cliente.GravarEdicao(cliente))
8. {
9.
return true;
10. }
11. return false;
12. }
13. }
Listagem 11. Classe DecoradorCliente. (modificada)
1. public class DecoradorCliente

2. {
3. private Cliente objCliente;
5. {
6. Cliente cliente = objCliente.Recuperar(id);
9. {
10.
return true;
11. }
12. return false;
13. }
14. }
12
27.
28.
29.
30.
31.
32.
33.
34.
35. }
if (ExcluirnoBanco(id))
{
return true;
}
else
{
return false;
}
36. public Cliente ConsultarCliente(Int64 id)

37. {
38. return Recuperar(id);
39. }
41. {
42. Cliente cliente = Recuperar(id);
45. {
46.
return true;
47. }
48. return false;
49. }
50.
51. }
Certifica-se que o esquema de delegao est correto, aplicando algumas modificaes. Caso necessrio, utiliza-se ainda
a refatorao Remover Parmetro.
Execute testes.
Exemplo: O exemplo a ser utilizado bem simples, para
permitir um maior foco no processo de refatorao para o
padro Decorator, dado que os exemplos existentes na literatura tcnica sobre este padro de projeto alguma vezes so
complexos. Comeando o processo, ser criada uma classe que
ser responsvel por carregar o cdigo de embelezamento da
classe Cliente.
A classe Cliente por sua vez foi definida em um sistema
de pequeno porte, com a responsabilidade inicial, e que se
manteve nica por um tempo considervel, que era apenas de
carregar os mtodos responsveis por manter os clientes, no
caso criar, editar, excluir e consultar. Posteriormente, novas
funcionalidades foram inseridas. Neste processo de mover o
embelezamento para o decorador, ser movido apenas o comportamento que faz uma mudana no objeto cliente, alterando
sua categoria. O primeiro passo envolve a criao de uma classe
que ser responsvel por carregar o embelezamento. Ela ir
herdar da classe Cliente. A Listagem 8 mostra a classe Cliente,
e a Listagem 9 mostra a declarao da classe decoradora.
Toda lgica pertencente ao embelezamento que se deseja
mover, deve ser levado para a classe definida na Listagem 9.
O resultado pode ser visto na Listagem 10.
Certificado que tudo funciona como antes, deve-se agora aplicar Substituir Herana por Delegao, removendo a definio
de herana. A Listagem 11 mostra as mudanas realizadas na
Desen volvimento
Listagem 12. Classe Cliente.
1. public class Cliente

2. {
3.
4. private DecoradorCliente decorador;
5.
7. {
8. return decorador.MudarCategoriaCliente(id, categoria);
9. }
10. ...
11. }
mas como algumas vezes isso no ocorre, tem-se as refatoraes que permitem que esses problemas sejam resolvidos.
Com o conhecimento sobre a tcnica de refatorao para o
padro Decorator o desenvolvedor poder, a partir da leitura,
ser capaz de separar cdigo de responsabilidade bsica de uma
classe de cdigo de embelezamento.
Referncias
1. GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a
objetos, 1ed. Porto Alegre: Bookman, 2000.
2. KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.
3. FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
Concluso
Implementar classes pode ser uma tarefa simples para todos

que possuem conhecimento em algum tipo de linguagem de
programao, mas conhecer a linguagem no garantia de
que o produto final ser de qualidade. Como visto, antes de se
escrever uma classe vrios fatores devem ser levados em conta,

Feedback
eu
13
sobre e
s
edio
ta
D
s
classe DecoradorCliente e a Listagem 12 mostra o resultado

das mudanas na classe Cliente, para se adaptar ao esquema
de delegao sugerido pelo passo 4.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Computao em Nuvem
Uma aplicao prtica usando o Google App Engine
Gabriella Castro Barbosa Costa

gabriellacbc@gmail.com
Bacharel em Sistemas de Informao pelo

Centro de Ensino Superior de Juiz de Fora
e Tcnica em Informtica Industrial pelo
CEFET-MG. Atua como desenvolvedora
Web desde 2008.

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor dos Cursos de Bacharelado em Sistemas
de Informao do Centro de Ensino Superior de Juiz de Fora, da Faculdade Metodista Granbery e da Universidade Severino
Sombra, professor do Curso Superior de
Tecnologia em Anlise e Desenvolvimento
de Sistemas da Fundao Educacional D.
Andr Arcoverde, Analista de Sistemas da
Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.
14
m departamentos de Tecnologia
da Informao, h cerca de duas
dcadas atrs, j se agrupavam
computadores de forma a simular um
nico computador com maior capacidade computacional. A clusterizao,
como chamada, permitiu a comunicao entre computadores que, neste
contexto, so tambm denominados ns,
equilibrando a demanda computacional.
Usando softwares de gerenciamento de
clusters, os processos so executados na
CPU (Central Processing Unit - Unidade
Central de Processamento), com maior
disponibilidade de processamento naquele instante.
Em 1990, surge uma nova tecnologia, conhecida por Grid Computing, ou
Computao em Grade, que teve como
premissa uma analogia com o fornecimento de energia eltrica. Se recursos
como energia podem ser fornecidos por
Engenharia de Software Magazine - Computao em Nuvem
Este artigo apresenta o processo de desenvolvimento de uma aplicao Web que faz uso da plataforma de desenvolvimento App Engine do Google. O
aplicativo a ser desenvolvido oferece os recursos de
um dicionrio da lngua portuguesa e um tradutor
Portugus/Ingls e Ingls/Portugus.
Para que serve?

Classificado no modelo de servio PaaS (Platform as
a Service Plataforma como Servio), o Google App
Engine oferece servios de desenvolvimento de aplicaes em nuvem, permitindo aos desenvolvedores
a criao dos prprios aplicativos web utilizando a
infraestrutura das aplicaes do Google.

Plataformas ofertadas como servio permitem
que o usurio faa uso de toda uma plataforma
de desenvolvimento de aplicaes voltadas para
a Computao em Nuvem um novo paradigma
da computao que vem ganhando fora desde
2006, caracterizando-se principalmente por
uma profunda modificao dos modelos tradicionais de utilizao dos recursos de TI. As aplicaes que fazem uso do Google App Engine so
fceis de criar, manter e escalar de acordo com a
necessidade do usurio.
Desen volvimento
terceiros, isso tambm poderia ocorrer com os recursos de

computao. A Computao em Grade expandiu os conceitos
de clusters, pois possibilita um melhor aproveitamento dos
recursos, utilizando-se de momentos ociosos dos recursos
computacionais das mquinas interligadas, pertencentes a
diferentes domnios e distribudas geograficamente. Grades
computacionais so muito utilizadas para fins cientficos, como
em grandes universidades.
A Computao em Nuvem, ou Cloud Computing, utiliza-se
dos conceitos da Computao em Grade, oferecendo recursos de data centers a usurios que no querem preocupar-se
em adquirir a infraestrutura necessria para montar uma
grade computacional. Este novo paradigma vem ganhando
fora desde 2006, caracterizando-se principalmente por uma
profunda modificao dos modelos tradicionais de utilizao
dos recursos de TI.
Muitas pessoas acreditam que a Computao em Nuvem um
novo paradigma que ser responsvel por grandes transformaes no atual mundo de TI. Outras acreditam, simplesmente,
que este paradigma apenas uma evoluo repaginada da j
conhecida Utility Computing ou Computao Utilitria.
A Computao em Nuvem pode ser resumidamente definida como um modelo tecnolgico que permite o acesso a um
conjunto de recursos computacionais atravs de uma rede, por
demanda, de forma rpida e sem a necessidade de grandes
configuraes.
Este paradigma tem como principal caracterstica mudar o
foco dos departamentos de TI para projetos estratgicos, ao
invs de simplesmente manter recursos em funcionamento
(como os data centers), enquanto reduz custos operacionais e
de capital.
Segundo Taurion (2009), a ideia da Computao em Nuvem
bastante sedutora, pois prope uma forma de utilizar recursos
ociosos, diminuir custos para as organizaes, possibilitar aos
usurios domsticos acesso amplo aos seus dados e aplicativos
atravs de qualquer dispositivo com acesso Internet e, tudo
isso, sem pagar por licenas de uso de software. Por outro lado,
o uso deste modelo est altamente subordinado a uma Internet
de boa velocidade, consistente e estvel. A interoperabilidade
entre diferentes nuvens pode ser vista como um problema, j
que ainda no existem padres claramente definidos. Deve-se
levar em conta tambm a questo da segurana no trfego de
dados confidenciais atravs da nuvem.
O avano das aplicaes Web 2.0, a disseminao da Internet
banda larga e a presso por melhores infraestruturas computacionais nas organizaes so fatores que influenciam e
favorecem a utilizao deste paradigma emergente.
Cada vez mais, as organizaes esto voltando-se para a Computao em Nuvem como um meio de baixo custo e de rpido
tempo de entrega de solues ao mercado. Grandes empresas
como Amazon, Google, Salesforce e IBM j fazem uso deste
paradigma e vm obtendo satisfatrios resultados.
O Google App Engine possibilita a execuo de aplicativos
Web na infraestrutura de nuvem prpria do Google, aproveitando todo o poder de processamento da empresa. Seus
recursos so escalveis, de forma dinmica, medida que o

trfego e a necessidade de armazenamento aumentam, tornando simples e fcil a manuteno dos aplicativos que fazem
uso desta plataforma.
Neste contexto, com intuito de apresentar como se d o
desenvolvimento deste tipo de aplicao, neste artigo ser
desenvolvida uma aplicao prtica, usando o Google App Engine, plataforma de desenvolvimento em nuvem gratuita, para
demonstrar uma das solues de Computao em Nuvem.
O Google App Engine

O Google considerado como uma das empresas pioneiras
na utilizao da Computao em Nuvem. O exemplo de maior
destaque o mecanismo de busca ofertado por esta empresa
que usado por milhares de pessoas. Como o mecanismo
requer uma grande capacidade de processamento e necessita
acessar milhares de megabytes de dados, a soluo encontrada
pela empresa foi agrupar centenas de milhares de servidores
em data centers espalhados por todo o mundo.
Para aproveitar a imensa capacidade da nuvem computacional, o Google passou a disponibilizar outros servios alm da
busca, como o YouTube, Google Maps, Google Apps e tambm
o Google App Engine.
Classificado no modelo de servio PaaS (Platform as a Service
- Plataforma como Servio), o Google App Engine oferece servios de desenvolvimento de aplicaes em nuvem, permitindo
aos desenvolvedores a criao dos prprios aplicativos web
utilizando a infraestrutura das aplicaes Google.
Como os aplicativos alocados no Google App Engine encontram-se na nuvem do Google, no h necessidade de manter
servidores. As aplicaes para esta plataforma so fceis de
criar, manter e escalar de acordo com a necessidade do usurio. Alm disso, o Google fornece um ambiente de desenvolvimento local que simula o Google App Engine em qualquer
computador desktop.
Atualmente so suportadas as linguagens de programao
Python e Java. O armazenamento de dados faz uso do Big Table,
um sistema de armazenamento distribudo de gerenciamento
de dados estruturados que se destina ao armazenamento em
larga escala.
O ambiente de desenvolvimento Java, que ser usado no decorrer deste trabalho, compatvel com o padro Servlet Java
e tambm possibilita o uso de JSPs (Java Server Pages).
Como principal vantagem desta plataforma de desenvolvimento em Nuvem, pode-se citar o fato de a utilizao da
infraestrutura do Google estar associada credibilidade que
a empresa ganhou no decorrer dos anos e tambm garantia
de disponibilidade ofertada.
O uso da plataforma gratuito dentro das cotas estabelecidas
pelo Google (disponveis para acesso atravs do link Limites
de uso dos recursos do Google App Engine) e o usurio consegue ter acesso aos recursos consumidos por sua aplicao
atravs de um painel de monitoramento dashboard onde
tambm possvel efetuar o controle de verses e visualizar
relatrios dos usurios e tarefas ao utilizar o aplicativo.
15
Outra grande vantagem a opo dada ao usurio de possuir

um servidor local para testes das aplicaes antes de envila nuvem, sendo que somente a API para envio de e-mails
no funciona localmente (para desenvolvedores que utilizam
como ferramenta de desenvolvimento o Eclipse, a utilizao da
infraestrutura do Google ainda pode ser simplificada atravs
da instalao de um plugin).
Figura 1.CloudDictionary - Dicionrio
Como o uso gratuito do Google App Engine possui algumas

limitaes quanto ao nmero de chamadas a cada recurso
oferecido por dia e por minuto, caso os limites disponveis
sejam excedidos, o usurio poder efetuar um upgrade de conta,
pagando pelos recursos extras a serem utilizados.
CloudDictionary: a aplicao a ser desenvolvida

Ser desenvolvida uma aplicao Web em nuvem, em Java,
que faz uso da plataforma de desenvolvimento App Engine do
Google e oferece os recursos de um dicionrio da lngua portuguesa, conforme exibido na Figura 1, e tambm um tradutor
de palavras desta lngua para o ingls e vice versa, conforme
a Figura 2. Tal aplicao teve como motivao verificar, de
forma prtica, a viabilidade, vantagens e desvantagens do
Google App Engine.
A aplicao desenvolvida, chamada CloudDictionary, faz
uso da integrao de um servio que encontra-se fora da nuvem Dicionrio Michaelis por meio da chamada de uma
URL externa.
Configurao do ambiente de desenvolvimento
Figura 2. CloudDictionary -Tradutor
Para o desenvolvimento desta aplicao foi utilizado o ambiente de desenvolvimento gratuito Eclipse SDK (Software Development Kit - Kit de Desenvolvimento de Software), verso 3.6.0,
cujo download encontra-se disponvel em http://www.eclipse.
org/downloads/, pois existe um plugin para este ambiente que
possibilita o desenvolvimento e o upload das aplicaes para a
nuvem do Google de forma mais fcil.
Aps a instalao do Eclipse, deve-se proceder a instalao
do plugin para o Eclipse da App Engine, de acordo com os
seguintes passos:
Passo 1: No menu Help, clicar em Install New Software.
Passo 2: Em Workwith, conforme Figura 3, colar a url: http://
dl.google.com/eclipse/plugin/3.6 e clicar em Add....
Passo 3: Selecione todos os checkboxes e em seguida no boto
Next (Figura 4) para a instalao do plugin, do Google App
Engine Java SDK e do Google Web Toolkit SDK.
Passo 4: Na prxima tela checar se os 3 itens a serem instalados, conforme definido anteriormente esto presentes; se
sim, clique em Next.
Passo 5: Selecionar I accept the terms of the license agreements
e, em seguida, clique em Finish (Figura 5).
Passo 6: Aps a instalao, clicar em Restart Now para
reiniciar o Eclipse e concluir instalao do plugin do Google
App Engine.
Aps seguir esses passos, o ambiente de desenvolvimento j
est pronto para a criao de aplicaes usando a Google App
Engine. Ao reiniciar o Eclipse, sero exibidos trs novos cones,
conforme a Figura 6.
Nota
Figura 3. Instalao do plugin da plataforma App Engine para Eclipse:

Install New Software
16
possvel desenvolver uma aplicao sem a utilizao desse ambiente especfico, sendo
necessrio apenas o uso do SDK do Google App Engine para Java o download encontra-se
em http://code.google.com/intl/pt-BR/appengine/downloads.html.
Desen volvimento
Os cones exibidos na Figura 6 possuem as seguintes funcionalidades, respectivamente:

O primeiro abre o assistente de criao de projeto do Google
App Engine para Java;
O segundo serve para compilar um projeto que faz uso da
GWT (Google Web Toolkit), uma ferramenta desenvolvida pela
Google que facilita as tarefas de criao, reutilizao e manuteno de bases de cdigo JavaScript e componentes AJAX para
construo de interfaces Web mais amigveis e rpidas;
O terceiro cone, o mini-jato, serve para efetuar o upload
de um projeto que faz uso da plataforma App Engine para a
nuvem do Google.
Criao de um novo projeto Web para a aplicao
Figura 4. Instalao do plugin da plataforma App Engine para

Eclipse: Plugins e SDKs
A seguir, sero descritos os passos para criao de um projeto

Web para a aplicao em construo.
Primeiro, clica-se no cone para criao de um novo projeto
web (Figura 7).
Em seguida, deve-se definir o nome do projeto e do pacote.
Aps isto, desmarque a opo Use Google Web Toolkit (vide
Figura 8), j que no sero utilizados muitos recursos de JavaScript ou AJAX, e clicar no boto Finish.
A aplicao CloudDictionary dever possuir a estrutura de
arquivos e diretrios exibida na Figura 9, que ser detalhada
no decorrer deste artigo.
Criao da pgina principal da aplicao e da folha de

estilos
No projeto criado, deve-se renomear o arquivo index.html
para index.jsp que ser a pgina inicial da aplicao em
Figura 5.Instalao do plugin da plataforma App Engine para

Eclipse: aceite dos termos de utilizao
Figura 6. cones do Google App Engine no Eclipse
Figura 7. Criao de novo projeto
Figura 8. Dados do novo projeto
17
questo. Este arquivo incluir um cabealho com as opes

de links de toda a aplicao (Dicionrio, Tradutor, Contato) e
um texto de apresentao, vide Listagem 1.
Observao: Ao renomear um arquivo .html para .jsp, ou
ao criar um arquivo .jsp, o Eclipse pode exibir um cone de
erro em todos os arquivos dessa extenso, conforme pode ser
visto na Figura 10.
Esse problema pode ser solucionado alterando o caminho
da JRE utilizada pelo projeto. Para isto, basta clicar no menu
Window, opo Preferences. Na prxima tela, clicar em Installed JREs, selecionar a JRE instalada e clicar no boto Edit,
conforme Figura 11.
Listagem 1. index.jsp
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<%@include file=cabecalho.html %>

<div id=page>
<div id=content>
<div class=post>
<br />
<h1 class=title>
<a href=#> Bem vindo ao CloudDictionary!</a>
</h1>
<br /><br />
<h2>Aqui voc encontra:</h2>
<br /><br />
- Um dicionrio atualizado da Lngua Portuguesa
<br /><br />
- Um tradutor Portugus-Ingls e Ingls-Portugus
<br /><br /><br />
<h1 class=title>
<a href=#>Escolha a opo desejada no menu superior.</a>
</h1>
<br />
</div>
</div>
<div style=clear: both;> </div>
</div>
<%@include file=rodape.html %>
Figura 9. Estrutura da aplicao

CloudDictionary
18
Figura 10.Erro ao renomear um

arquivo .html para .jsp
Passo 3: Na prxima tela, clique no boto Directory... e indique o diretrio da jdk instalada, de acordo com a Figura 12
e clique no boto Finish.
Como o arquivo index.html foi renomeado, necessria a
alterao do arquivo web.xml que referencia o arquivo que
ser a pgina inicial do sistema, conforme pode ser visto na
Figura 13.
Em seguida deve-se criar uma nova pgina html, com o nome
cabecalho.html, que contm os links para todas as pginas da
aplicao, e cujo cdigo fonte encontra-se na Listagem 2.
Em seguida, deve-se efetuar a criao de uma nova pgina
html, com o nome rodape.html, que ser o rodap padro
para todas as pginas da aplicao e cujo cdigo fonte
encontra-se na Listagem 3.
Figura 11. Alterar caminho da JRE
Figura 12. Definir caminho da JRE
Desen volvimento
O prximo passo ser a criao do arquivo style.css, responsvel pelos estilos que sero aplicados aos elementos da
aplicao. Esta folha de estilos foi retirada do site Free CSS
Templates, sendo necessrios apenas alguns ajustes para que
ela se adequasse aplicao em questo. Alguns fragmentos
podem ser visualizados na Listagem 4.
Criao do Dicionrio e do Tradutor

Para a criao da pgina do dicionrio, deve ser criada uma
nova pgina jsp, nomeada dicionario.jsp, que inclui o cabealho da aplicao, um campo de input de texto para inserir a
palavra a ser buscada e um boto de busca. Por fim, includo
o rodap da aplicao, conforme Listagem 5.
A pgina dicionario.jsp, anteriormente criada, consiste em
um formulrio para envio de dados a um servlet ServletDictionary.java (ponto principal do CloudDictionary que faz
uso do URL Fetch Service do Google App Engine para acessar
os servios de um dicionrio externo nuvem, o dicionrio
online da lngua portuguesa Michaelis, da editora Melhoramentos. Para evitar que a pgina inteira fosse recarregada,
foi usado o arquivo dicionario.js (Listagem 6), para interligar o arquivo jsp ao servlet. Este arquivo deve ser criado no
diretrio js.
Para a criao da pgina do tradutor deve ser criada uma
nova pgina jsp, nomeada tradutor.jsp, que inclui o cabealho da aplicao, um campo de input de texto para inserir a
palavra a ser traduzida, dois radio buttons onde escolhe-se o
tipo da traduo a ser realizada e um boto de busca. Por fim,
includo o rodap da aplicao, conforme Listagem 7.
A pgina tradutor.jsp, consiste em um formulrio para
envio de dados ao mesmo servlet usado pelo formulrio do
arquivo dicionario.jsp. Para evitar que a pgina inteira fosse
recarregada, foi usado o arquivo tradutor.js (Listagem 8),
para interligar o arquivo jsp ao servlet. Este arquivo deve ser
criado no diretrio js.
O passo seguinte a criao do ServletDictionary.java.
Esse servlet chamado tanto pela pgina de dicionrio
quanto pelo tradutor do CloudDictionary. A principal funo
consiste em efetuar uma chamada a uma URL do dicionrio
externo a ser usado, atravs do servio URL Fetch do Google
App Engine, conforme Figura 14 e Listagem 9. Por fim, o
cdigo HTML retornado pelo dicionrio externo tratado e
exibido na pgina da aplicao desenvolvida (no dicionrio
ou no tradutor).
Aps a criao do servlet, necessrio que este esteja corretamente mapeado no arquivo web.xml, conforme pode ser
visto na Figura 15.
Listagem 2. cabecalho.html
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN>

<html>
<head>
<meta http-equiv=content-type content=text/html;charset=iso-8859-1>
<title>Gabriella Castro - Cloud Dictionary</title>
<link href=style.css rel=stylesheet type=text/css/>
</head>
<body>
<div id=header-wrapper>
<div id=header>
<div id=logo>
<h1><a href=index.jsp><span>Cloud</span>Dictionary</a></h1>
</div>
<div id=menu>
<ul>
<li><a href=dicionario.jsp>Dicionrio</a></li>
<li><a href=tradutor.jsp>Tradutor</a></li>
<li><a href=contato.jsp>Contato</a></li>
<li><a href=creditos.jsp>Créditos</a></li>
</ul>
</div>
</div>
</div>
<div id=wrapper>
Listagem 3. rodape.html
01 </div>
02 <div id=footer>
03 <p> - 2010 - Gabriella Castro - </p>
04 </div>
05 </body>
06 </html>
Figura 13. Alterao do arquivo web.xml
Criao da pgina para Contato

Para complementar a aplicao desenvolvida, deve ser criado
um novo arquivo, contato.jsp, com um formulrio que permite
o envio de mensagens ou sugestes para o e-mail do autor, que
far uso do servio de envio de e-mails do Google App Engine.
Este formulrio pode ser visualizado na Figura 16 e o cdigo
fonte deste encontra-se na Listagem 10.
Figura 14. Servio URL Fetch do Google App Engine
19
Listagem 4. style.css
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
...
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
/*
Design by Free CSS Templates
http://www.freecsstemplates.org
Released for free under a Creative Commons Attribution 2.5 License
*/
body {
margin: 0 auto;
padding: 0;
background: #FFFFFF;
font-family: Arial, Helvetica, sans-serif;
font-size: 14px;
color: #3C3D3F;
}
h1, h2, h3 {
margin: 0;
padding: 0;
font-weight: normal;
color: #FF3000;
}
h1 {
font-size: 2em;
}
#wrapper {
padding: 0;
}
/* Header */
#header {
overflow: hidden;
width: 1000px;
height: 60px;
margin: 0px auto 20px auto;
}
/* Logo */
#logo {
float: left;
width: 300px;
margin: 0;
padding: 0;
color: #000000;
Listagem 5. dicionario.jsp
01 <%@include file=cabecalho.html%>
02 <script type=text/javascript src=js/dicionario.js></script>
03 <div id=page>
04 <h3>Dicionrio</h3>
05 <div id=content>
06 <div class=post>
07 <h2 class=title><a href=#>Digite a palavra:</a></h2>
08 <br />
09 <input type=text id=palavra></input>
10 <br /><br />
11 <button id=search-submit class=botao
12 onclick=procuraPalavra(palavra.value)>
13
Buscar
14 </button>
15 <br />
16 <div class=entry>
17
<span id=resultado></span>
18 </div>
19 </div>
20 </div>
21 <div style=clear: both;> </div>
22 </div>
23 <%@include file=rodape.html %>
20
63 }
64 #logo h1 {
65 letter-spacing: -1px;
66 font-size: 2.8em;
67 color: #0C0C0C;
68 }
...
83 #logo a {
84 border: none;
85 background: none;
86 text-decoration: none;
87 color: #45302C;
88 }
...
121 /* Menu */
122 #menu {
123 float: right;
124 width: 600px;
125 }
126 #menu ul {
127 margin: 0px;
128 padding: 0px 0px 0px 15px;
129 list-style: none;
130 }
131 #menu li {
132 float: left;
133 }
134 #menu a {
135 display: block;
136 float: left;
137 height: 37px;
138 padding: 13px 30px 0px 30px;
139 text-decoration: none;
140 text-transform: uppercase;
141 font-family: Arial, Helvetica, sans-serif;
142 font-size: 14px;
143 font-weight: bold;
144 color: #0C0C0C;
145 }
Aps, deve-se criar um novo arquivo JavaScript contato.js.

Este arquivo dever conter uma funo para validao do formulrio, conforme Listagem 11, de forma a impedir o envio do
e-mail sem que os campos sejam corretamente preenchidos.
Para o funcionamento do formulrio, deve ser criado um novo
servlet ServletContato.java. Esse servlet tem como funo principal a utilizao do servio de envio de mensagens da plataforma.
Ele realiza o envio de mensagens de acordo com os campos informados no formulrio de contato para um email previamente
definido (Listagem 12 linha 27). Uma restrio do Google App
Engine que esse servio de envio de mensagens s pode partir
de e-mails previamente cadastrados na rea de administrao
da aplicao (Figura 17). Portanto, como o objetivo de um formulrio de contato enviar um e-mail para o responsvel pela
aplicao e no possvel colocar como remetente o e-mail que
foi informado no campo do formulrio, deve-se colocar o e-mail
cadastrado na plataforma como o remetente e o e-mail da pessoa
que efetuou o contato no corpo da mensagem.
Aps criar o servlet, necessrio que ele esteja corretamente
mapeado no arquivo web.xml, conforme pode ser visto na
Figura 18.
Desen volvimento
Listagem 6. dicionario.js
Listagem 8. tradutor.js
01 var xmlhttp;
02 function procuraPalavra(palavra) {
03 xmlhttp=null;
04 if (window.XMLHttpRequest){
05 //Para IE7, Firefox, Opera, etc.
06 xmlhttp=new XMLHttpRequest();
07 }
08 else if (window.ActiveXObject) {
09 //Para IE6, IE5
10 xmlhttp=new ActiveXObject(Microsoft.XMLHTTP);
11 }
12 if (xmlhttp!=null){
13 xmlhttp.onreadystatechange=status;
14 var url = /servletdictionary?word=+palavra;
15 xmlhttp.open(GET,url,true);
16 xmlhttp.send(null);
17 }
18 else {
19 alert(Seu navegador no oferece suporte a XMLHTTP.);
20 }
21 }
22 function status() {
23 if (xmlhttp.readyState==4){
24 // 4 = loaded
25 if (xmlhttp.status==200){
26 // 200 = OK
27 d
ocument.getElementById(resultado).innerHTML=
28 xmlhttp.responseText;
29 }
30 else{
31 alert(Erro ao acessar o dicionrio: + xmlhttp.statusText);
32 }
33 }
34 }
01 var xmlhttp;
02 function procuraPalavra(palavra, lingua) {
03 xmlhttp=null;
04 if (window.XMLHttpRequest){
05 //Para IE7, Firefox, Opera, etc.
06 xmlhttp=new XMLHttpRequest();
07 }
08 else if (window.ActiveXObject) {
09 //Para IE6, IE5
10 xmlhttp=new ActiveXObject(Microsoft.XMLHTTP);
11 }
12 if (xmlhttp!=null){
13 xmlhttp.onreadystatechange=status;
14 var url = /servletdictionary?word=+palavra+&lang=+lingua;
15 xmlhttp.open(GET,url,true);
16 xmlhttp.send(null);
17}
18 else {
19 alert(Seu navegador no oferece suporte a XMLHTTP.);
20 }
21 }
22 function status() {
23 if (xmlhttp.readyState==4){
24 // 4 = loaded
25 if (xmlhttp.status==200){
26 // 200 = OK
27 document.getElementById(resultado).innerHTML=
28 xmlhttp.responseText;
29 }
30 else{
31 alert(Erro ao acessar o tradutor: + xmlhttp.statusText);
32 }
33 }
34 }
35 function getValue(radio) {
36 var obj = document.getElementById(lingua);
37 obj.value=radio;
38 }
Listagem 7. tradutor.jsp
01 <%@include file=cabecalho.html %>

02 <script type=text/javascript src=js/tradutor.js></script>
03 <div id=page>
04 <h3>Tradutor</h3>
05 <div id=content>
06 <div class=post>
07 <h2 class=title><a href=#>Digite a palavra:</a></h2>
08 <br />
09 <input type=text name=palavra id=palavra />
10 <br />
11 <input type=radio name=chk value=1 checked
12 onclick=getValue(this.value) /> Portugus / Ingls
13 <input type=radio name=chk value=2
14 onclick=getValue(this.value) /> Ingls / Portugus<br>
15 <input type=hidden name=lingua id=lingua value=1 />
16 <br />
17 <button id=search-submit class=botao
18 onclick=procuraPalavra(palavra.value, lingua.value)>
19
Buscar
20 </button>
21 <br />
22 <div class=entry>
23
<span id=resultado></span>
24 </div>
25 </div>
26 </div>
28 </div>
29<%@include file=rodape.html %>
Figura 15. Alterao do arquivo web.xml ServletDicitionary
Figura 16. Formulrio de contato
21
Listagem 9. ServletDictionary.java
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
package clouddictionary;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.URL;
import javax.servlet.ServletException;
import javax.servlet.http.*;
import java.util.ArrayList;
import java.net.URLEncoder;
33
34
@SuppressWarnings(serial)
public class ServletDictionary extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
String resultado = ;
resp.setContentType(text/plain);
try {
String palavra = req.getParameter(word);
String language = req.getParameter(lang);
if (palavra == null)
throw new Exception(Informe a palavra a ser buscada.);
palavra = palavra.trim();
if (palavra.length() == 0)
throw new Exception(Informe a palavra a ser buscada.);
String busca=;
if (language == null){
busca = http://michaelis.uol.com.br/moderno/portugues/
index.php?lingua=portugues-portugues&palavra=;
}
else{
if (language.equals(1)){
index.php?lingua=portugues-ingles&palavra=;
}
41
42
43
44
45
46
47
48
49
50
51
52 }
53 catch (Exception ex) {
54
resultado = Erro: + ex.getMessage();
55
resp.getWriter().println(resultado);
56 }
57 }
58 @Override
59 public void doPost(HttpServletRequest req, HttpServletResponse resp)
60 throws ServletException, IOException {
61 doGet(req, resp);
62 }
63 }
35
36
37
38
39
40
else if (language.equals(2)){
index.php?lingua=ingles-portugues&palavra=;
}
}
String a = URLEncoder.encode(palavra,iso-8859-1);
busca += a;
URL url = new URL(busca);
BufferedReader reader = new BufferedReader(new InputStreamReader
(url.openStream()));
StringBuffer response = new StringBuffer();
String line;
ArrayList lines = new ArrayList();
while ((line = reader.readLine()) != null) {
lines.add(line);
}
String wishedLine = (String) lines.get(284);
response.append(wishedLine);
reader.close();
resultado = response.toString();
resp.getWriter().println(resultado);
Listagem 10. contato.jsp
01 <%@include file=cabecalho.html %>

02 <script type=text/javascript src=js/contato.js></script>
03 <div id=page>
04 <h3>Contato</h3>
05 <div id=content>
06 <div class=post>
07
<form name=form_contato id=form_contato
action=ServletContato method=POST onSubmit=
return validaForm()>
08
<table id=contato align=center>
09
<tr>
10
<td>
11
Nome:
12
</td>
13
<td>
14
<input type=text name=nome id=nome size=25/><br/>
15
</td>
16
</tr>
17
<tr>
18
<td>
19
Email:
20
</td>
21
<td>
22
<input type=text name=email id=email size=25/><br/>
23
</td>
22
24
</tr>
25
<tr>
26
<td>
27
Mensagem:
28
</td>
29
<td>
30
<textarea name=mensagem id=mensagem cols=19>
31
</textarea><br/>
32
</td>
33
</tr>
34
<tr>
35
<td colspan=2>
36
<input type=reset class=botao value=Limpar>
37
<input type=submit class=botao value=Enviar>
38
</td>
39
</tr>
40
</table>
41
</form>
42 </div>
43 </div>
45 </div>
46 <%@include file=rodape.html %>
Desen volvimento
Conforme a linha 31, da Listagem 12, se a mensagem for

enviada, ocorrer um redirecionamento para a pgina contatoSucesso.jsp, cujo cdigo encontra-se na Listagem 13.
Atravs do navegador pode-se acessar a aplicao. A Figura 20

exibe a pgina inicial do CloudDictionary sendo utilizado
localmente.
Conforme a linha 34, da Listagem 12, se a mensagem no for

enviada, ocorrer um redirecionamento para a pgina contatoErro.jsp, cujo cdigo encontra-se na Listagem 14.
Efetue o upload da aplicao para a nuvem do Google
Executando a Aplicao
Inicialmente, caso o usurio da plataforma App Engine no

possua uma conta vinculada ao Google, voc dever cri-la.
Caso contrrio, basta efetuar o login no link de acesso conta
do Google App Engine.
Para executar a aplicao localmente, basta clicar com o boto

direito no projeto desenvolvido, selecionar a opo Run as e clicar
na opo Web Application, como pode ser visto na Figura 19.
Listagem 11. contato.js
01 function validaForm(){
02 d = document.form_contato;
03 if (d.nome.value == ){
04 alert(O campo + d.nome.name + deve ser preenchido!);
05 d.nome.focus();
06 return false;
07 }
08 if (d.email.value == ){
09 alert(O campo + d.email.name + deve ser preenchido!);
10 d.email.focus();
11 return false;
12 }
13 parte1 = d.email.value.indexOf(@);
14 parte2 = d.email.value.indexOf(.);
15 parte3 = d.email.value.length;
16 if (!(parte1 >= 3 && parte2 >= 6 && parte3 >= 9)) {
17 alert (Email invlido!);
18 d.email.focus();
19 return false;
20 }
21 if (d.mensagem.value == ){
22 alert (O campo + d.mensagem.name + deve ser preenchido!);
23 d.telefone.focus();
24 return false;
25 }
26 return true;
27 }
Figura 17. Cadastro de e-mails autorizados para enviar mensagens
Figura 18. Alterao do arquivo web.xml ServletContato
Listagem 12. ServletContato.java
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
package clouddictionary;
import java.io.IOException;
import java.util.Properties;
import javax.mail.Message;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
import javax.servlet.ServletException;
import javax.servlet.http.*;
@SuppressWarnings(serial)
public class ServletContato extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType(text/plain);
try {
String nome = req.getParameter(nome);
String email = req.getParameter(email);
String msgm = req.getParameter(mensagem);
String mensagem = Nome: + nome + \n +

Email: + email + \n +
Mensagem: + msgm;
23
24
25
26
27
Properties props = new Properties();

Session session = Session.getDefaultInstance(props, null);
Message msg = new MimeMessage(session);
msg.setFrom(new InternetAddress(gabriellacbc@gmail.com));
msg.addRecipient(Message.RecipientType.TO, new InternetAddress
(gabriellacbc@gmail.com));
msg.setSubject(CloudDictionaty - Contato);
msg.setText(mensagem);
Transport.send(msg);
resp.sendRedirect(contatoSucesso.jsp);
28
29
30
31
32 }
33 catch (Exception ex) {
34
resp.sendRedirect(contatoErro.jsp);
35 }
36 }
37 @Override
38 public void doGet(HttpServletRequest req, HttpServletResponse resp)
39 throws ServletException, IOException {
40 doPost(req, resp);
41 }
42 }
23
Em seguida, uma nova aplicao dever ser criada. Para isto

basta clicar no boto Create Application, conforme Figura 21.
Uma conta gratuita permite a criao de at dez aplicaes.
Voc dever ento informar o identificador e o ttulo da aplicao. Neste exemplo foram usados como identificador gabidictionary e ttulo Dicionrio nas Nuvens. Aps isto, deve-se
clicar no boto Create Application, conforme Figura 22.
Na IDE Eclipse, deve-se selecionar o projeto desenvolvido
e clicar no cone do Google App Engine, exibido em destaque
na Figura 23.
Conforme exibido na Figura 24, deve-se informar o e-mail e
a senha da conta do Google que foi usado no primeiro passo.
Como o primeiro upload desta aplicao, deve-se clicar no
link App Engine Project settings.
Na tela aberta, conforme Figura 25, deve-se informar no
campo Application ID o mesmo identificador da aplicao que
foi usado anteriormente e, no campo seguinte, a verso da
aplicao.
Listagem 13. contatoSucesso.jsp
01
02
03
04
05
06
07
08
09
10

<div id=page>
<div id=content>
<div class=post>
<h1 class=title>Mensagem enviada!</h1>
</div>
</div>
</div>
Listagem 14. contatoErro.jsp
01
02
03
04
05
06
07
08
09
10
11
12
13

<div id=page>
<div id=content>
<div class=post>
<h1 class=title>
Erro ao enviar mensagem!<br/>
Tente novamente!
</h1>
</div>
</div>
</div>
Figura 21. Criar aplicao
Figura 19. Rodar a aplicao no servidor local
Figura 22. Dados da aplicao
Figura 20. Pgina inicial do CloudDictionary
24
Figura 23. Deploy App Engine Project
Desen volvimento
Clica-se ento no boto Deploy, conforme exibido na Figura 24,

e aguarde o trmino do upload da aplicao, at que a mensagem da Figura 26 seja exibida.
Aps os passos anteriores, a aplicao j poder ser acessada
atravs de qualquer navegador web, no endereo <identificador_da_aplicao>.appspot.com.br.
O Google App Engine fornece tambm um painel de controle para monitoramento das aplicaes que se encontram na
nuvem do Google, exibido na Figura 27. O painel de controle
pode ser acessado ao clicar no nome da aplicao criada, que
pode ser visualizado na Figura 21.
Concluso
Este artigo abordou a criao de uma aplicao real que se
encontra em funcionamento na nuvem do Google e faz uso de
sua plataforma, a App Engine, mostrando que vivel e que a
plataforma, mesmo sendo gratuita, de grande utilidade e funciona nos moldes propostos pelo paradigma da Computao
em Nuvem. Vale ressaltar que atualmente a plataforma tem
como desvantagem a limitao quanto ao uso de linguagens
de programao (permite apenas Phyton e Java), porm oferece
Figura 24. Dados de acesso conta do Google App Engine
Figura 25. Application ID e verso da aplicao
o uso de APIs bem definidas e alto grau de escalabilidade.

Outra grande vantagem o fato de que os desenvolvedores
que fazem uso da plataforma no precisam preocupar-se,
em um momento inicial, com questes como hospedagem,
armazenamento e crescimento das aplicaes. A plataforma
mostrou-se bastante til para aplicaes simples e que no
requerem um alto nvel de segurana em seus processos e
que so voltadas a um nmero crescente de usurios, alm de
disponibilizar uma documentao apropriada e de qualidade
fornecida pelo prprio Google.
Como uma forma de aprimorar o que foi aprendido neste
artigo, uma dica seria implementar a mesma aplicao em
outras plataformas oferecidas em nuvem pela Microsoft ou
pela Amazon, por exemplo.
Figura 26. Mensagem de trmino do upload
Figura 27. Painel de monitoramento de uma aplicao no Google App

Engine
25
Referncias
COSTA, Gabriella Castro Barbosa. CloudDictionary, 2010. Disponvel em: <http://gabidictionary.
appspot.com>.
GOOGLE. Top ten advantages of Googles cloud, 2010f. Disponvel em: <http://www.google.com/
apps/intl/en/business/cloud.html>.
Eclipse, SDK. Downloads, 2010. Disponvel em: <http://www.eclipse.org/downloads/>.
IRANI, Romin K. Google App Engine Java Experiments. [S.I.]: Romin K. Irani, 2010.
GOOGLE, App Engine. Downloads, 2010a. Disponvel em: <http://code.google.com/intl/pt-BR/

appengine/downloads.html>.
MELL, Peter; GRANCE, Tim. The NIST Definition of Cloud Computing, 2009. Disponvel em: <http://
csrc.nist.gov/groups/SNS/cloud-computing/>.
GOOGLE, Application Engine. Google Code, 2010b. Disponvel em: <http://code.google.com/intl/

pt-BR/appengine/>.
MICHAELIS. Dicionrio Online, 2009. Disponvel em: <http://michaelis.uol.com.br/>.
GOOGLE. Google Web Toolkit, 2010e. Disponvel em: <http://code.google.com/intl/pt-BR/

webtoolkit/>.
Links
Limites de uso dos recursos do Google App Engine

http://code.google.com/intl/pt-BR/appengine/docs/quotas.html
Free CSS Templates
http://www.freecsstemplates.org
Google Application Engine - Acesso conta
http://www.appengine.google.com
26
TAURION, Cezar. Cloud computing: computao em nuvem: transformando o mundo da tecnologia

da informao. Rio de Janeiro: Brasport, 2009.
VELTE, Antony T; VELTE, Toby J; ELSENPETER, Robert. Cloud Computing: A Practical Approach. [S. l.]:
McGraw-Hill, 2010.

Feedback
eu
sobre e
s
Michaelis Dicionrio Online

http://michaelis.uol.com.br/
RITTINGHOUSE, John; RANSOME, W; JAMES, F. Cloud Computing. [S. l.]: CRC Press, 2009.
D
s
GOOGLE. Google Trends, 2010d. Disponvel em: <http://www.google.com/trends?q=

cloud+computing>.
MILLER, Michael. Cloud Computing: Web-Based Applications That Change the Way You Work and
Collaborate Online. Indianapolis: Que, 2009.
edio
ta
GOOGLE. Bigtable: A Distributed Storage System for Structured Data, 2010c. Disponvel em:
<http://labs.google.com/papers/bigtable.html>.
Desen volvimento
27
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Mtodo de Anlise e Projetos em SOA

Identificando e especificando servios em projetos com abordagem SOA

Um dos principais desafios ao se construir solues
na abordagem SOA a complexidade na fase de Anlise e Projeto. Neste artigo descrevemos um mtodo
de Anlise e Projeto em SOA criado a partir do estudo
de propostas existentes e de boas prticas.
Henrique Shoiti Fugita

henrique.fugita@escalainfo.com.br
Henrique Fugita lder da equipe de arquitetura da Escala Informtica, atuando h

mais de 5 anos em projetos de SOA e BPM
para diversos clientes. engenheiro de
computao e mestre pela POLI/USP. Possui certificaes em SOA e RUP pela IBM e
em Java pela Sun.
Davi Carvalho S., Jr.

Davi.carvalho@escalainfo.com.br
Davi Carvalho CTO na Escala Informtica.

Atua na rea de tecnologia a quase 20 anos
e certificado em SOA pela IBM. bacharel
em Computao (UFC), tem ps-graduao
em Engenharia de Software (UNICAMP) e
MBA pelo INSPER (antes IBMEC So Paulo).
Trabalhou em empresas como Zetax e Lucent Technologies, em projetos no Brasil e
nos EUA. Antes de fazer parte da equipe da
Escala, foi CIO na Transit Telecom.
28
o artigo publicado na Engenharia de Software Magazine

de nmero 31, apresentamos o
MAPOS (Mtodo de Anlise e Projeto
Orientado a Servios), uma abordagem
aplicada s fases de Anlise e Projeto de
projetos seguindo a Arquitetura Orientada a Servios (SOA). O MAPOS visa
orientar a identificao e especificao
de servios a partir dos modelos e requisitos de negcio.
Para compreender a aplicao prtica
do mtodo proposto, vamos apresentar
neste artigo um estudo de caso, baseado em um cenrio fictcio, mas com
caractersticas de projetos reais em que
o MAPOS foi empregado.
Estudo de Caso
O exemplo de aplicao do mtodo descrito a seguir trata da automao de um
processo de negcio de uma instituio
Engenharia de Software Magazine - Mtodo de Anlise e Projetos em SOA
Para que serve?

O mtodo serve como orientao para que arquitetos
e analistas sejam capazes de identificar e especificar
servios de forma consistente, resultando em solues que sigam efetivamente os princpios da abordagem SOA. O estudo de caso busca aprofundar o entendimento do leitor a respeito do mtodo proposto
atravs da descrio de um exemplo prtico.

Com a adoo da abordagem SOA, espera-se obter
benefcios como aumento do reuso e flexibilidade
para atender s demandas do negcio. Mas para
que benefcios se concretizem, fundamental
que os servios sejam devidamente identificados
e especificados.
bancria fictcia. O processo de negcio

em questo o Cadastro de Cliente,
que descreve a lgica de negcio para
avaliao e cadastro de um novo cliente
Proje to
da instituio. Trata-se de um processo de pr-cadastro

de pessoas fsicas e jurdicas, pelo qual novos clientes em
potencial abriro uma conta, obtero um financiamento ou
solicitaro um carto de crdito.
No estudo de caso, partimos de uma situao em que
o processo quase inteiramente manual, sendo apoiado somente pelo Sistema de Cadastro de Clientes, uma
aplicao legada construda com tecnologia baseada em
componentes. A instituio bancria decide adotar as
abordagens SOA em conjunto com uma plataforma de BPM
para realizar a automao do processo de negcio.
Modelagem de Processo as-is e to-be

Esta tarefa tem como objetivo elaborar os modelos de
processo de negcio, isto , documentar o processo de
negcio na sua forma atual (as-is) e o processo futuro (tobe), contendo as mudanas propostas.
O processo as-is deve ser levantado por um Analista de
Processos junto s reas envolvidas na execuo manual do
processo atual. Com base neste levantamento, o Analista
de Processos deve documentar o modelo de processo as-is,
atravs de diagramas (por exemplo, diagrama de atividades da UML ou notao BPMN) e descries textuais.
Na Figura 1, exemplificado um diagrama do processo
as-is em notao BPMN. No diagrama, o papel responsvel
Figura 1. Diagrama do processo as-is

Tarefa
pela execuo de cada tarefa indicado por sua cor. Observe que todas as tarefas so inteiramente manuais ou
exigem interao de uma pessoa com um sistema.
Aps o levantamento do processo atual, devem ser detectados pontos de melhoria e oportunidades de automao de
atividades manuais. Desta maneira, o Analista de Processos
prope um modelo de processo to-be, contendo as melhorias e tarefas automatizadas que visaram o atendimento
s necessidades de negcio levantadas. Neste exemplo,
o Analista de Processo automatiza parte do processo na
plataforma BPM, em que o fluxo do processo orquestrado
pela plataforma e apoiado por um conjunto de servios.
O diagrama do processo to-be pode ser visualizado na
Figura 2. Observe que nesta proposta, uma parte das
tarefas atribuda ao papel Sistema, que representa a
plataforma BPM que orquestra as chamadas a servios e
tarefas humanas.
Normalmente, o modelo de negcio pode ser composto por:
diagrama do processo de negcio, documento de Especificao de Tarefas e descrio textual de regras de negcio.
Complementando o diagrama do processo, o Analista
de Processo elabora uma descrio textual de cada tarefa, detalhando os passos envolvidos em sua execuo.
A Tabela 1 apresenta as descries de cada tarefa do
processo to-be.
Figura 2. Diagrama do processo to-be

Descrio
Informar dados do cliente
O Atendente da Agncia preenche um formulrio Web com os dados cadastrais do cliente (nome, CPF/CNPJ, endereo, telefone, e-mail, etc.). O formulrio valida
os dados inseridos, como formato de CPF, CNPJ, etc.
Verificar existncia do cliente
O Sistema verifica no cadastro se o cliente com o CPF ou CNPJ informado j existe.
Enviar notificao de cliente existente
O Sistema envia um e-mail para o cliente informando que seu cadastro j existe no banco.
Verificar situao do CPF/CNPJ
O Sistema consulta os servios do Serasa e do SPC para verificar a situao de crdito do CPF ou CNPJ do cliente.
Enviar notificao de negao de cadastro
O Sistema envia um e-mail para o cliente informando que seu cadastro foi negado, pois sua situao de crdito encontra-se irregular.
Determinar lista de documentos
O Sistema verifica quais documentos devem ser apresentados obrigatoriamente pelo cliente de acordo com seu tipo (pessoa fsica ou jurdica).
Receber e digitalizar documentos
O Atendente da Agncia recebe os documentos fsicos do cliente e digitaliza, para que o Sistema armazene uma cpia eletrnica dos documentos.
Conferir documentos
O Back-Office analisa os documentos digitalizados e verifica se todos os documentos obrigatrios foram entregues e so vlidos.
Reagendar visita
O Atendente da Agncia telefona para o cliente por telefone e agenda uma visita para que o cliente traga os documentos necessrios agncia.
Gravar dados do cliente
O Sistema grava no cadastro os dados do novo cliente.
Enviar notificao de sucesso
O Sistema envia um e-mail para o cliente informando que seu cadastro foi realizado com sucesso.
Tabela 1. Descrio das tarefas do processo to-be
29
Identificao de Servios Candidatos

Aps a elaborao do modelo de processo to-be, composto
pelo diagrama do processo mais as descries das tarefas,
o Arquiteto de Servios inicia a identificao de servios
candidatos. Esta atividade recebe como entrada o modelo de
processo to-be e tem como objetivo definir um conjunto inicial
de servios, identificados a partir do processo.
As operaes candidatas devem ser identificadas a partir da
anlise das descries das tarefas, seguindo a sequncia das
tarefas determinada pelo diagrama do processo. No texto de
descrio de cada tarefa, possvel identificar funes que
devem ser executadas pelo Sistema, tanto nas tarefas do Sistema quanto nas tarefas humanas. Em alguns casos, uma tarefa
inteira pode ser considerada uma operao candidata, enquanto em outros, apenas alguns passos de uma tarefa podem ser
considerados operaes candidatas. As operaes identificadas
nas tarefas do processo so listadas na Tabela 2.
Aps a identificao, as operaes candidatas devem ser agrupadas em servios candidatos, baseando-se na similaridade
e correlao entre elas. Como orientao geral, procuram-se
agrupar operaes que manipulem os mesmos tipos de dados
ou que executem lgica semelhante.
Tarefa
Informar dados do cliente
Operao Candidata
Verificar existncia de cliente
Validar nmero de CPF

Validar nmero de CNPJ
Validar dados do cliente
Enviar notificao de cliente existente
Enviar e-mail
Verificar situao do CPF/CNPJ

Enviar notificao de negao de cadastro
Consultar Serasa
Consultar SPC
Enviar e-mail
Determinar lista de documentos
Consultar documentos obrigatrios
Receber e digitalizar documentos
Armazenar documento
Conferir documentos
(nenhuma operao)
Reagendar Visita
(nenhuma operao)
Enviar Notificao de Sucesso
Enviar e-mail
Tabela 2. Operaes candidatas do processo
Para as operaes que manipulam dados de cliente, pode-se

criar um servio Cliente. O mesmo critrio pode ser utilizado para criar um servio Documento. J as consultas ao
Serasa e ao SPC, por serem operaes de lgica semelhante,
podem ser agrupadas em um servio Consulta Crdito.
Para as operaes de validao de CPF e CNPJ, podemos
criar um servio Validao e para a operao de envio de
e-mail, um servio Email.
A Figura 3 mostra os contratos definidos para representar
os servios candidatos identificados.
Aps a definio dos servios candidatos, devem ser elaboradas descries textuais de cada servio candidato e de
cada operao, definindo os dados de entrada e sada e a
lgica executada.
Anlise de Gap
Aps a identificao dos servios candidatos, o mtodo
prossegue com a Anlise de Gap. O objetivo bsico desta
anlise localizar, nas aplicaes existentes (legado), as funes necessrias para os servios candidatos, chegando a um
cenrio de reuso para cada operao candidata.
Para analisar os cenrios de reuso, o mtodo orienta a
consultar um repositrio de servios e recursos reusveis
ou fontes de documentao das aplicaes existentes. O cenrio mais comum encontrar uma arquitetura que ainda
no possui um repositrio de servios reusveis. Neste caso
recorre-se documentao dos sistemas legados. Especificamente neste cenrio, o legado existente o Sistema de
Cadastro de Clientes.
Como resultado desta anlise, foram obtidos os cenrios de
reuso apresentados na Tabela 3.
A lgica necessria para as operaes Gravar dados de cliente e Verificar existncia de cliente do servio Cliente j
eram realizadas por uma aplicao legada, neste caso o componente GerenciadorPessoa pertencente ao Sistema de Cadastro
de Clientes. Entretanto, a operao Verificar existncia de
cliente era realizada apenas parcialmente pelo componente
GerenciadorPessoa, j que este possua apenas um mtodo
de busca de cliente para realizar esta verificao.
As operaes do servio Consulta Crdito j so executadas por servios externos do Serasa e do SPC e podem ser
reusados diretamente.
Verificou-se tambm a existncia de uma biblioteca de classes utilitrias LibCorporativa que continha mtodos que
realizavam as operaes Validar nmero de CPF e Validar
nmero de CNPJ do servio Validao e Enviar e-mail
do servio Email.
Os cenrios de reuso analisados devem ser documentados
juntamente com as descries das operaes.
Anlise de Realizao
Figura 3. Servios candidatos identificados
30
Na Anlise de Realizao, cada operao candidata avaliada

quanto ao seu cenrio de reuso identificado anteriormente.
Nesta etapa, deve ser decidido como cada operao de servio
ser realizada.
Proje to
Servio Candidato
Operao Candidata
Cliente
Validar dados de cliente

Gravar dados de cliente
Documento
Consulta Crdito
Validao
Email
Consultar documentos obrigatrios

Armazenar documento
Consultar Serasa
Consultar SPC
Validar nmero de CPF
Validar nmero de CNPJ
Enviar e-mail
Cenrio de Reuso
Operao parcialmente realizada por aplicao legada (componente GerenciadorPessoa do Sistema de
Cadastro de Clientes)
Operao no existente
Operao realizada por aplicao legada (componente GerenciadorPessoa do Sistema de Cadastro de
Clientes)
Operao no existente
Operao no existente
Operao realizada por servio existente (servio de consulta do Serasa)
Operao realizada por servio existente (servio de consulta do SPC)
Operao realizada por aplicao legada (biblioteca de classes LibCorporativa)
Tabela 3. Cenrios de reuso para as operaes candidatas
As possibilidades de realizao dos servios candidatos

devem ser analisadas pelo Arquiteto de Servios e discutidas com os responsveis pelo repositrio de servios ou
pela arquitetura corporativa. As decises de realizao
resultantes da anlise devem ser registradas nas descries
das operaes e servios candidatos. Para cada contrato de
servio, deve ser indicado qual ser sua realizao.
Foram obtidas as seguintes decises de realizao.
Servio Cliente
Para realizar este servio, decidiu-se criar um novo Web
Service que seria responsvel por invocar os mtodos do
componente GerenciadorPessoa do Sistema de Cadastro
de Clientes e implementar as funes das operaes no
existentes. No caso da operao Verificar existncia de
cliente, o Web Service dever implementar a lgica necessria para retornar o resultado desejado.
Servio Documento
Como as duas operaes deste servio no existiam, um
novo Web Service ser implementado para executar suas
funes. Como este servio armazena algumas informaes
persistentes (como os documentos digitalizados), deve ser
utilizada uma base de dados para apoiar o servio.
Servio Consulta Crdito

Para este servio, ambas as operaes j so realizadas
por um servio existente, porm externo organizao.
Para manter a padronizao dos servios, decidiu-se criar
um novo Web Service para encapsular o acesso aos servios
externos, abstraindo a localizao do servio original e
detalhes especficos. Para tal, o Web Service dever executar
lgica de mediao, como mapeamento de mensagens e
roteamento.
Servios Validao e Email

Operaes implementadas por dois novos Web Services responsveis por encapsular as classes da biblioteca utilitria
LibCorporativa. A realizao dos servios SvcCorporativo pode ser visualizada na Figura 4.
Figura 4. Realizao dos servios
Especificao de Servios
A atividade de especificao de servios tem como objetivo
detalhar as classes de mensagens e as interfaces de servios,
inclusive com a descrio tcnica de cada operao, para chegar
aos artefatos que comporo o contrato do servio.
Como as operaes foram descritas apenas textualmente, neste
momento h a necessidade de se definirem os parmetros das
operaes, permitindo a identificao de algumas mensagens.
Por exemplo, para a operao Gravar dados de cliente do
servio Cliente, definiu-se que um parmetro de entrada da
operao seria uma mensagem com vrios campos representando os dados do cliente e o parmetro de sada (ou de retorno)
seria um indicador de sucesso da gravao (boolean).
Desta maneira, devem-se definir as mensagens utilizadas nas
operaes de servios a partir das definies do processo. Para
a implementao dos Web Services, as mensagens devem ser
formalmente modeladas como esquemas XSD (XML Schema
Definition).
O Arquiteto de Servios deve definir tambm informaes
adicionais nos contratos de servios, tais como:
Especificao do tipo de dado de cada atributo das classes
de mensagens;
Especificao do tipo de dados de cada parmetro de
operao;
Seleo dos parmetros das operaes com base na lgica a
ser implementada;
31
Especificao de requisitos no-funcionais, como segurana

(autenticao e autorizao).
Para a especificao formal dos contratos dos Web Services, so
utilizadas interfaces WSDL (Web Service Definition Language).
Alm dos contratos formais dos servios, o Arquiteto de
Servios define tambm a qual camada pertence cada servio,
de acordo com seu nvel de granularidade e relevncia para
a lgica de negcio. A classificao dos servios nas camadas
pode ser vista na Figura 5.
Verificao dos Princpios

O objetivo desta atividade verificar se cada especificao de
servio criada atende aos princpios de orientao a servios
e se esto adequados a integrarem o portflio de servios da
organizao.
A verificao dos princpios deve ser realizada em uma
reunio envolvendo o Arquiteto de Servios, os responsveis
pelo portflio de servios ou pela arquitetura corporativa e o
gerente do projeto sendo executado.
Abaixo, so descritos os resultados obtidos da verificao de
cada um dos servios projetados.
Servio SvcClientePF
A operao Validar existncia de cliente pode ser considerada como possuindo alto potencial de reuso, podendo ser reusada por outros processos de negcio. Entretanto, para tornar
o servio mais reusvel, pode-se adicionar outras operaes
interface, j existentes no componente GerenciadorPessoa
encapsulado pelo servio, como Remover dados de cliente
e Obter cliente por nome.
As operaes podem ser especificadas no contrato do servio,
mas no seriam implementadas imediatamente no projeto em
questo. As atividades de implementao do projeto podem
focar somente nas operaes necessrias para suportar o processo de negcio Cadastro de Cliente e as outras operaes
podem ser implementadas como parte de outro projeto, com
esforo e prazo dimensionados para tal.
Figura 5. Camadas de servios
32
O nvel de granularidade do servio pode ser considerado

adequado. J a autonomia do servio pode ser um ponto de
ateno, uma vez que os componentes encapsulados pertencem
a um sistema legado e possuem relacionamentos com outros
componentes.
Servios Documento
O servio foi considerado com nvel de granularidade de
negcio por trabalhar com uma entidade relevante para o
processo de negcio documento. A avaliao do servio
constatou sua autonomia, pois toda sua lgica estava contida
em um novo Web Service, sem dependncia com outros sistemas externos.
Servio Consulta Crdito

O servio foi considerado com nvel de granularidade adequado para reuso, uma vez que implementa operaes de baixa
granularidade. Porm o servio pode ter problemas relacionados a autonomia e acoplamento, uma vez que baseado em
servios providos por entidades externas.
Servios Validao e Email

Estes servios foram projetados desde o incio de forma a
serem altamente reusveis, com operaes utilitrias de baixa
granularidade e aplicveis a diversos contextos de negcio.
Portanto, eventuais ajustes poderiam incluir apenas a adio
de novas operaes, j presentes nas classes da biblioteca
LibCorporativa.
Reviso dos Servios

Na reviso, quaisquer no conformidades detectadas durante
a verificao dos princpios devem ser corrigidas nos artefatos
que compem a especificao dos servios.
Neste estudo de caso, a reviso limita-se apenas aos ajustes
nos contratos de servios, adicionando-se as operaes recomendadas durante a Verificao dos Princpios.
Orquestrao de Servios
Durante a orquestrao de servios, o modelo de processo
to-be elaborado no incio do projeto convertido em um modelo
de implementao, que deve ser trabalhado para tratar todas
as regras de negcio modeladas e adequar-se aos servios
especificados.
O fluxo de trabalho do processo pode ser automatizado na
plataforma BPM utilizando-se a linguagem WS-BPEL (Web
Services Business Process Execution Language). Alm da prpria
estrutura do processo (tarefas, decises e conexes), necessrio tambm implementar no processo os seguintes aspectos:
Variveis;
Lgica de tratamento de dados;
Lgica de deciso nos ns do tipo Choice (if-then-else);
Dados de correlao de instncias de processo;
Tempo de expirao de atividades com tal requisito;
Mapeamento das interfaces geradas no WS-BPEL para as
interfaces WSDL dos servios utilizados pelo processo.
Proje to
podem ser incorporadas ao processo de desenvolvimento da

organizao, por exemplo, incluindo-se na fase Anlise e Projeto
do Rational Unified Process (RUP).
A FacTI (Fundao de apoio capacitao de TI), em CampinasSP, um exemplo de utilizao do MAPOS para fazer o mapeamento dos processos com o objetivo de mapear os processos
atuais (as-is), definir e otimizar os novos processos (to-be), e
preparar todo o ecossistema de legados para uma arquitetura
orientada a servios (SOA).
Entretanto, no podemos dizer que a discusso esteja esgotada
uma vez que as tecnologias relacionadas a SOA vm evoluindo
rapidamente e trazem oportunidades de adaptao do MAPOS
para lidar com abordagens como Business Rules Management
Systems (BRMS), RESTful Services, computao em nuvem,
computao em grid e muitas outras.
Figura 6. Composio do servio de orquestrao Cadastro de Cliente
A partir da construo da lgica de orquestrao do processo

em WS-BPEL, devem ser conduzidas as atividades de implementao dos servios, integrao dos servios ao processo e
testes de todos os elementos desenvolvidos.
A partir deste ponto podem ser utilizadas tecnologias como
Java EE ou Microsoft .NET para implementao dos Web Services, e plataformas BPM para automao do processo, como IBM
WebSphere Process Server, Oracle BPM Suite ou jBPM.
Concluso
ERL, T. SOA: Principles of Service Design. Estados Unidos: Prentice Hall, 2007. 608 p.
FUGITA, H. S.; HIRAMA, K. MAPOS: Mtodo de Anlise e Projeto Orientado a Servios. Dissertao
(Mestrado) Ps-Graduao em Engenharia Eltrica, Escola Politcnica, Universidade de So
Paulo, So Paulo, 2009.
IBM. Rational Method Composer, version 7.2. IBM Rational, 2007.
KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA. Estados Unidos: Prentice Hall, 2004. 408 p.
MARKS, E. A.; BELL, M. Service Oriented Architecture: A Planning and Implementation Guide for
Business and Technology. Estados Unidos: John Wiley & Sons, 2006. 384 p.
PAPAZOGLOU, M. P.Web Services: Principles and Technology. Estados Unidos: Prentice Hall, 2007.
784 p.
PAPAZOGLOU, M. P.; VAN DEN HEUVEL, W. J. Service-Oriented Design and Development
Methodology. International Journal of Web Engineering and Technology (IJWET), v. 2, no. 4, pp.
412-442, 2006.
ZIMMERMANN, O. et al. Analysis and Design Techniques for Service-Oriented Development and
Integration. IBM Press, 2005.

Feedback
eu
33
sobre e
s
O estudo de caso descrito procurou demonstrar por meio

de um exemplo a aplicao prtica do MAPOS em um projeto
seguindo as abordagens SOA e BPM. Apesar de as abordagens
poderem ser adotadas separadamente, elas apresentam diversos
benefcios quando empregadas em conjunto. Com o surgimento
do padro WS-BPEL, a utilizao conjunta de SOA e de BPM foi
viabilizada e potencializada. O WS-BPEL permite a composio
e orquestrao de servios a partir de definies de processos,
criadas por analistas de negcio. Desta maneira, aumenta-se o
alinhamento dos servios desenvolvidos com as metas e estratgias de negcio.
A aplicabilidade do mtodo no se limita a projetos deste tipo
e porte, podendo ser adaptado para os mais variados tipos de
projetos e estruturas organizacionais. As atividades do MAPOS
ERL, T. Service-Oriented Architecture: Concepts, Technology and Design. Estados Unidos:

Prentice Hall, 2005. 792 p.
D
s
Implementao e Teste
Referncias
edio
ta
Aps implementado, o processo em WS-BPEL foi encapsulado

pelo servio de orquestrao Cadastro de Cliente, que por sua
vez ser composto pelos outros servios. Para tal, foi necessrio
tambm definir a interface WSDL e as mensagens em XSD para
o servio de orquestrao. A Figura 6 mostra a composio do
servio de orquestrao Cadastro de Cliente.
Engenharia
Dificuldades e Problemas Encontrados na

Manuteno de Software
Mateus Maida Paduelli

Bacharel e mestre em computao pela
Universidade de So Paulo. J atuou em
diversas organizaes com o tema manuteno de software e atualmente servidor pblico federal.
34
desenvolvimento de qualquer
software, exceto programas
muito simples, uma tarefa
bastante complexa. Esse fato se tornou
evidente com a crise de software, o
que originou o conceito de engenharia
de software como uma abordagem sistemtica, disciplinada e quantificvel
para o desenvolvimento, manuteno e
descarte de software.
A engenharia de software surgiu inicialmente mais como uma promessa do
que uma realidade. De fato, muitos dos
problemas ligados ao desenvolvimento
e manuteno de software continuam
sem soluo, apesar de muitos conceitos
terem evoludo.
Entender o que significa manuteno
de software, e principalmente a abrangncia do significado do termo, constitui passo fundamental para o estudo
e aprofundamento de solues para os
problemas atrelados a essa tarefa.
Neste contexto, este artigo foca na discusso sobre as dificuldades encontradas
Este artigo foca na discusso sobre as dificuldades

encontradas na realizao das atividades de manuteno de software. Para isso, apresenta a realizao de um estudo de observao que foi conduzido com o objetivo de verificar os problemas
de manuteno de software existentes em uma
organizao empenhada no desenvolvimento de
software comercial.
Para que serve?

Este texto indicado para aqueles profissionais
que atuam com manuteno de software no seu
dia-a-dia e que desejam entender melhor os atuais desafios em torno desse tema.

A manuteno de software hoje um assunto
presente em organizaes que desenvolvem
e mantm software. Isso se deve necessidade de sempre ajustar e melhorar o produto
de software de acordo com as mais diversas
necessidades. Diante desse fato, entender o
significado e abrangncia do termo manuteno de software pode auxiliar organizaes e
profissionais interessados no tema a melhor
conduzir seus esforos quando precisam manter seus produtos.
Engenharia de Software Magazine - Dificuldades e Problemas Encontrados na Manuteno de Software
M anuten o
na realizao das atividades de manuteno de software. Para

isso, apresenta a realizao de um estudo de observao que
foi conduzido com o objetivo de verificar os problemas de
manuteno de software existentes em uma organizao empenhada no desenvolvimento de software comercial. Alm disso,
apresenta uma comparao entre os problemas de manuteno
de software atuais, identificados pelo estudo de caso, e aqueles
registrados no passado, buscando inferir algum padro de
evoluo nos mesmos.
Antes de iniciarmos a discusso sobre as dificuldades e problemas encontrados nas atividades de manuteno de software,
iremos apresentar rapidamente algumas definies associadas
rea de manuteno.
Atividade de Manuteno de Software

Este tpico tem por objetivo destacar as caractersticas, tipos
e desafios para a manuteno de software. Trata-se de um tpico importante para esclarecer alguns pontos pertinentes ao
assunto que sero considerados ao longo deste artigo.
Definies
A atividade de manuteno de software caracterizada pela
modificao de um produto de software j entregue ao cliente,
para a correo de eventuais erros, melhora em seu desempenho, ou qualquer outro atributo, ou ainda para adaptao
desse produto a um ambiente modificado.
Embora a definio trate genericamente qualquer produto de
software, existem diferenas entre a manuteno de softwares
com propsitos distintos.
Uma primeira classificao representa aqueles softwares
construdos com base em uma especificao rgida e bem
definida, cujos resultados esperados so bem conhecidos. Por
exemplo, um software construdo para realizar operaes
com matrizes (adio, multiplicao e inverso). Nesse tipo
de software, uma vez que tenha sido construdo considerando
a correta implementao do mtodo, dificilmente haver a
necessidade de manutenes.
J em uma segunda classificao, so agrupados os softwares
que constituem implementaes de solues aproximadas
para problemas do mundo real, uma vez que solues completas somente so conseguidas na teoria nesses casos. Como
exemplo, pode-se citar um jogo de xadrez. Embora suas regras
sejam bem definidas, no possvel construir um software que
calcule a cada passo todos os possveis movimentos de peas
do tabuleiro, de forma a determinar o melhor movimento. Isso
porque o nmero de movimentos possveis muito grande
para ser calculado em um intervalo de tempo relativamente
curto. A tcnica utilizada para desenvolver esse tipo de soluo
baseia-se em descrever o problema de forma abstrata e ento
definir os requisitos de software a partir dessa abstrao.
Percebe-se que esse tipo de sistema j abre espao para diferentes interpretaes por parte do desenvolvedor, o que tende
a produzir software com maior necessidade de manuteno
do que quando comparado aos da classificao anterior. Por
considerar uma abstrao para especificao de requisitos, a
necessidade de mudana pode aparecer caso a abstrao mude,

na medida em que um maior entendimento do problema seja
alcanado.
Finalmente, uma terceira e ltima classe de softwares
considera mudanas no ambiente onde o software vai ser
utilizado, caracterstica no existente nas duas classificaes
anteriores.
Um software integrante da terceira classificao corresponde
quele criado com base em um modelo dos processos abstratos
envolvidos no sistema, e precisar mudar sempre que ocorrer
mudanas nesses modelos, sendo, portanto, parte do ambiente que ele modela. Um exemplo desse tipo de software seria
aquele que apresenta informaes da economia de um pas.
medida que a economia passa a ser mais bem compreendida,
o modelo muda e com ele a abstrao do problema, causando
uma necessidade inevitvel de manuteno no software. Esse
tipo de software, comumente encontrado no dia-a-dia das
organizaes, tem interesse particular neste trabalho.
Alm de considerar tipos diferentes de software, o processo
de manuteno no corresponde a uma atividade isolada.
Durante a sua execuo, diferentes partes precisam interagir
de forma que os objetivos da manuteno sejam entendidos e
os resultados esperados alcanados. Essas partes so:
Organizao Cliente: essa organizao corresponde ao
adquirente do software, conforme definido pela norma ISO/
IEC 12207. Isso significa a organizao que possui o software
e requisita o servio de manuteno.
Mantenedor: trata-se da organizao que oferece o servio
de manuteno.
Usurio: representa a organizao ou pessoa que utiliza o
software em questo, valendo-se de suas funcionalidades para
automatizar e facilitar tarefas.
Naturalmente, existe um relacionamento entre essas partes
e a constituio de um fluxo para os pedidos de manuteno,
conforme esquematizado na Figura 1.
Figura 1. Fluxo envolvido na manuteno de software
35
A organizao solicitante deve possuir algum responsvel

pela solicitao de manuteno, que ser encarregado de verificar os requisitos e informar o mantenedor. Esse responsvel
dever considerar os erros e dificuldades apontadas pelo
help-desk, que corresponde ao departamento diretamente
encarregado do dilogo com os usurios.
Do lado do mantenedor, a organizao que presta o servio
deve possuir algum responsvel por avaliar as requisies,
julgando-as apropriadas ou no para os objetivos do software e da organizao solicitante. Uma vez que os pedidos de
manuteno so aceitos, deve existir algum responsvel por
estabelecer um cronograma de entrega, que dever considerar
as prioridades e interesses de ambas as partes. Esse cronograma dever ser seguido pela equipe de manuteno, que
compreende o pessoal envolvido diretamente em atender s
solicitaes.
Finalmente, o papel do usurio consiste em utilizar o software reportando problemas para o help-desk, que por sua
vez informar o responsvel pelas solicitaes de manuteno,
fechando o ciclo.
Tipos de Manuteno
As aes ligadas atividade de manuteno de software
foram classificadas de acordo com sua natureza em trs categorias: corretivas, adaptativas e perfectivas.
Manutenes do tipo corretivas visam corrigir defeitos
de funcionalidade, o que inclui acertos emergenciais de
programa. Pfleeger (2001) expe um exemplo desse tipo de
manuteno, que consiste em um usurio apresentando um
problema de impresso em um relatrio. O nmero de linhas
impresso por folha muito grande, o que causa sobreposio
de informaes. O problema foi identificado como uma falha no
driver da impressora, provocando a necessidade de se alterar
o menu do relatrio para aceitar um parmetro adicional que
determina o nmero mximo de linhas impressas por folha.
Manutenes do tipo adaptativas referem-se a adequar o
software ao seu ambiente externo. O exemplo apontado por
Pfleeger (2001) ilustra bem essa categoria. Suponha um gerenciador de banco de dados, que faz parte um sistema maior de
hardware e software. Em uma atualizao do gerenciador, os
programadores perceberam que as j existentes rotinas de acesso a disco precisavam agora de mais um parmetro adicional.
Essa manuteno corresponde a uma manuteno adaptativa,
uma vez que teve por finalidade adequao do software ao seu
ambiente e no a correo de um defeito.
Manutenes do tipo perfectivas tm por objetivo acrescentar
novos recursos de funcionalidade ao software, normalmente
em razo de solicitaes dos usurios. Significam ainda rePlanejada
No-Planejada
Reativa
Corretiva
Adaptativa
Emergencial
Pr-ativa
Perfectiva
Tabela 1. Definies IEEE para as categorias de manuteno de software
36
projetar partes de um software, de forma a tornar mais simples

a compreenso e utilizao do mesmo. Como exemplo, pode-se
citar o pedido do usurio por um novo relatrio com informaes
que at ento no podiam ser obtidas do banco de dados.
A unio das categorias adaptativa e perfectiva sugerida por
Pigoski (1996), que prope uni-las em uma nica denominada
aprimoramentos. Essa classificao estaria de acordo com
organizaes que geralmente utilizam o termo manuteno
para se referir execuo de pequenas mudanas no software,
enquanto o termo desenvolvimento usado para os demais
tipos de modificaes.
Uma quarta categoria de manuteno apresentada por alguns autores. Essa categoria se refere a manutenes do tipo
preventivas que buscam identificar previamente possveis fontes de problemas no software e corrigi-las antecipadamente.
A IEEE traz ainda uma categoria a mais chamada emergencial. Essa categoria caracterizada pela execuo de uma
manuteno corretiva no planejada, com o intuito de manter
o software operacional. Tal classificao insere a idia de manuteno planejada e no-planejada, bem como manuteno
reativa e pr-ativa, como ilustrado na Tabela 1.
Para efeito de estudo, neste artigo ser considerada a classificao de tipos de manuteno considerando: corretivas,
adaptativas, perfectivas e preventivas.
Estudo de Caso
A partir de agora apresentaremos um estudo de caso que foi
conduzido com o objetivo de verificar os problemas de manuteno de software existentes em uma organizao empenhada
no desenvolvimento de software comercial. Essa organizao
mantm uma base de dados contendo registros histricos de
manutenes efetuadas sobre um sistema de informao por
ela desenvolvido e mantido.
Descrio da Organizao
Criada em 1993, a organizao estudada corresponde a uma
software-house, que desenvolve e mantm alguns softwares
voltados rea mdica e de sade. composta por uma unidade na cidade de So Carlos - SP, responsvel pelo desenvolvimento e manuteno, e outra unidade na cidade de So Paulo,
dedicada venda e consultoria.
O software estudado corresponde a um sistema de porte
mdio voltado odontologia, mais precisamente ao gerenciamento de operadoras odontolgicas, sendo, no entanto,
um produto com caractersticas tpicas grande maioria dos
softwares que se sujeitam a gerenciar algum ramo de atividade
comercial. So exemplos de recursos oferecidos pelo software:
cadastro de clientes, cadastro de fornecedores, emisso de
boletos bancrios, controle financeiro, relatrios analticos
complexos, controle de estoques, suporte a multiusurio, controle de permisso de acesso a diferentes mdulos, controle
de fluxo de caixa, emisso de faturas, emisso de relatrios
especficos para prestao de contas a rgos de fiscalizao
do governo, integrao com sistemas web etc.
M anuten o
Relativamente ao nmero de clientes, no momento da pesquisa, existiam 41 clientes (operadoras de odontologia), envolvendo desde organizaes de pequeno porte, com at 5.000
associados cada, utilizando o software em cerca de 5 computadores, at empresas maiores, com mais de 50 mquinas em
rede, utilizando o software de maneira simultnea e contando
com at 150.000 associados. Normalmente essas empresas de
maior porte so estruturadas por departamentos, e cada departamento utiliza um mdulo especfico do software.
Dinmica de Manuteno
Neste tpico so abordadas as caractersticas da maneira
de trabalhar da organizao, expondo como registra, altera e
entrega as suas manutenes.
Uma observao inicial se faz necessria, e se refere possvel
confuso entre o que seria uma tarefa de desenvolvimento
e o que seria uma atividade de manuteno, no contexto do
software estudado. De uma forma objetiva, o software aqui
referido encontra-se desenvolvido, uma vez que est em uso
por muitos clientes, ou seja, um produto de software j
entregue ao cliente. Partindo-se desse pressuposto, qualquer
solicitao, seja por parte de clientes, seja por observao de
algum profissional que atue sobre o software, ser classificada
como uma manuteno, ainda que exija criar um mdulo novo
ou refazer um j existente.
Registro de Manutenes
Os registros de manutenes so inseridos na base de dados
de trs formas distintas: (i) pelo prprio cliente, atravs do
sistema de help-desk disponvel no site da organizao; (ii)
pelos consultores da empresa, aps visita ao cliente e levantamento de necessidades de manuteno; (iii) pelos prprios
programadores, que podem identificar necessidades de manuteno medida que evoluem o software. Uma interface
especfica baseada na web foi criada para a insero desses
registros na base.
Cada registro contm diversas informaes, como por exemplo, qual o cliente que solicita, grau de prioridade, quem realizar a manuteno, tempo gasto previsto para a atividade, tipo
de manuteno, status da implementao, datas de insero do
chamado e data prevista para entrega, observaes, descrio
da soluo adotada, entre outras.
Aps o registro de um chamado, sua execuo depender da
anlise de viabilidade, efetuada pelo responsvel pelo produto.
O procedimento adotado est resumido na Figura 2.
Eventualmente, solicitaes de manuteno so consideradas
inviveis, sendo canceladas pelo responsvel por essa avaliao. Uma vez cancelada, esse fato informado ao respectivo
cliente, podendo ser revisada a necessidade para que uma
proposta de manuteno mais adequada seja registrada.
Uma caracterstica do sistema de controle de chamados a
interao que oferece entre mantenedor/cliente. Essa interao
ocorre da seguinte maneira: quando o cliente registra alguma
necessidade de manuteno, automaticamente a equipe de
suporte e o analista responsvel pelos cronogramas e testes,
Figura 2. Etapas envolvidas na solicitao de manutenes

Status do chamado
Cliente recebe e-mail
Pendente
Sim
Em execuo
Sim
Cancelado
Sim
Em testes
No
Em homologao
Sim
Concludo
Sim
Tabela 2. Situaes possveis para os chamados de manuteno
recebem um e-mail informando que uma nova solicitao foi

feita. Diversos status so atribudos a uma solicitao, e a cada
troca de status, o cliente pode receber um e-mail informando o
andamento de sua solicitao. Na Tabela 2 esto representados
os status possveis para as solicitaes, e em quais mudanas
o cliente recebe um e-mail de notificao.
Na situao em testes, o cliente no recebe notificao, pois
esse status utilizado para controle interno. Uma solicitao
em testes significa que est com a alterao no cdigo-fonte
efetuada e disponvel para o analista responsvel realizar os
testes preliminares a fim de produzir a verso de homologao, que ento disponibilizada ao cliente. Somente quando a
solicitao tiver sido testada e a verso de homologao estiver
concluda e fornecida ao cliente, o analista responsvel ir
alterar o status para em homologao, permitindo ento o
envio da notificao ao cliente. A situao concludo ocorre
quando a verso de homologao finalmente for instalada no
ambiente de produo do cliente.
Para o status de cancelado, o cliente informado apenas que
sua solicitao foi negada, e que para maiores esclarecimentos
ele deve entrar em contato com a equipe de suporte.
Por fim, destaca-se que o cliente pode, a qualquer momento,
conferir os status de seus chamados, consultando sua rea
privativa no site da organizao, que oferece acesso ao helpdesk tanto para incluso de novos chamados, como para
acompanhamento por meio dos diferentes status.
Controle de Verses
Os clientes tm sua disposio uma rea privativa no
site da organizao, atravs do qual podem realizar o
37
download de verses atualizadas do software, medida que

so disponibilizadas.
Essa disponibilizao de verses ocorre mensalmente, podendo incluir rotinas de manuteno no banco de dados, quando
necessrias, alm dos componentes de software alterados. As
atualizaes de banco de dados so efetuadas automaticamente
no momento em que o cliente abre o software pela primeira
vez, aps a atualizao. Uma caracterstica relevante a de
que o software sempre ser o mesmo independente do cliente,
ou seja, no existem verses distintas para clientes diferentes,
todos utilizam uma verso nica que pode ser configurada de
acordo com necessidades especficas de cada cliente (mdulo
de opes de sistema do software).
Aps a disponibilizao de uma nova verso, o sistema
de controle de chamados consultado e as manutenes de
software pendentes so consideradas, e ento definidas quais
entraro na verso do ms seguinte. Essas manutenes so
encaminhadas para os programadores (que consultam no
sistema de chamados suas atividades pendentes), devendo
seguir as datas programadas para entrega do mdulo/arquivo
alterado. As datas de entrega no so para o usurio final,
mas sim para o analista responsvel, que ir test-las, e ento
disponibilizar uma verso de homologao do software.
Essa verso fornecida a um grupo de clientes com os quais
foi estabelecido um acordo para realizao desses testes. Isso
ocorre na ltima semana do ms que antecede aquele de disponibilizao da nova verso.
A idia de disponibilizar verses intermedirias a um ou
mais clientes para testes reais em ambiente parte do de produo, corresponde a uma das tcnicas de teste apresentadas
por Pressman (2005), intitulada teste beta. Segundo o autor,
esse o tipo de teste conduzido nas instalaes do prprio
cliente, sem acompanhamento do desenvolvedor, estando o
cliente responsvel por registrar problemas e inform-los em
intervalos regulares.
Figura 3. Padro de numerao de verses
Figura 4. Linha do tempo para disponibilizao de verses
38
Evidentemente entre a data de estabelecimento de cronograma para os chamados pendentes e a data de liberao da nova
verso, surgem normalmente chamados novos e urgentes, que
no podem esperar at prxima verso. No geral, procura-se
evitar essa situao, mas quando ocorrem, verses intermedirias modificadas a partir da ltima verso oficial, somente
com a alterao urgente ora solicitada, so disponibilizadas e
apenas para o cliente que precisou da manuteno urgente.
Um padro para nomenclatura das verses foi adotado, buscando atrelar a verso ao seu ms de lanamento, bem como
informar o nmero da reviso atual da verso (caso a verso
oficial tenha necessitado de alguma alterao emergencial).
Na Figura 3 ilustrado um exemplo do padro de numerao
adotado.
Os dois ltimos dgitos so incrementados em uma unidade,
medida que a verso for passando por manutenes emergenciais (aquelas que no podem ser acumuladas para a verso do
ms seguinte). No exemplo da Figura 3, a verso em questo
a oficial (reviso 00), do ms de abril de 2007.
A verso de homologao, uma vez testada pelo perodo
de uma semana nos clientes selecionados, e com eventuais
problemas detectados e corrigidos, oficialmente convertida
em uma verso final (oficial), e disponibilizada no site para
todos os clientes, na primeira semana do ms seguinte ao de
testes. Na Figura 4 ilustrado esse processo.
Durante a fase de manuteno no cdigo-fonte, utilizado
um software de controle de verso (Microsoft Source Safe),
que trabalha da seguinte forma: cada desenvolvedor que for
alterar algum arquivo (que faz parte do projeto do software)
realiza uma operao de check-out desse arquivo do repositrio (o qual armazena o projeto todo), ficando nesse momento
responsvel pelo arquivo, impedindo que qualquer outra
pessoa possa realizar check-out do mesmo arquivo. Diz-se
que o arquivo fica travado para o programador x. Somente
quando a manuteno for concluda, o arquivo submetido a
um check-in, voltando para o repositrio e ficando livre para
uso por outro programador.
medida que alteraes vo sendo entregues e disponibilizadas
no repositrio, o analista responsvel, realiza o check-out dos
arquivos alterados e procede com testes preliminares. Uma vez
que a data de liberao da nova verso para homologao se aproxima, esse analista realiza um check-out completo de todo o projeto
do software, e realiza testes gerais, a fim de compor a verso de
homologao para envio aos clientes pr-estabelecidos.
Durante a homologao, eventualmente esses clientes so
acompanhados pessoalmente por algum consultor, ou remotamente via apoio por telefone, e-mail, VNC (software que
permite conexo ao desktop remoto do cliente), entre outros.
Na medida em que problemas so verificados, se forem erros
nas manutenes realizadas para a verso que ser disponibilizada, esses erros so imediatamente corrigidos e a verso de
homologao atualizada. Se forem problemas novos (novas
necessidades de alteraes ainda no previstas), eles so registrados e ento programados para disponibilizao em verses
posteriores do software.
M anuten o
Metodologia
A metodologia utilizada para a execuo do estudo de caso
buscou, por um lado, estudar a base de dados na qual esto
os registros de manuteno, e, por outro lado, entrevistar os
profissionais responsveis pela tarefa de manuteno. A forma
como cada etapa foi conduzida est descrita a seguir.
Parte A Base de Dados

Na primeira etapa, o foco dos esforos centrou-se em extrair
da base de dados totais a respeito de diferentes caractersticas
das manutenes efetuadas no software. Esses totais foram
obtidos por meio de consultas SQL base, sendo que as totalizaes buscadas esto resumidas na Tabela 3.
Finalmente, os nmeros obtidos foram utilizados para construo de grficos mostrados mais adiante neste artigo.
Valor
Objetivo
Distribuio de solicitaes mensalmente
Verificar algum padro na distribuio
Tempo em dias para entrega de solicitaes
Verificar o tempo de resposta ao cliente
Totais de solicitaes por grupo de prioridade
Verificar a expectativa do usurio
Totais por tipo de manuteno
Verificar distribuio entre os tipos
Tempo de desenvolvimento e manuteno
Verificar esforo necessrio em cada fase
Tabela 3. Caractersticas de manuteno consideradas e seus objetivos
Parte B Questionrio e Entrevista

A segunda etapa do levantamento de dados foi realizada com
o auxlio de questionrio e entrevistas.
O questionrio elaborado visou obter dos profissionais envolvidos com manuteno de software caractersticas de seu
trabalho dirio, coletando uma gama de informaes para
anlise posterior junto com os dados da Parte A.
Aps a elaborao do questionrio foram realizadas entrevistas individuais com essas pessoas, procurando-se registrar
todo comentrio e informao relevante para o propsito da
entrevista.
Figura 5. Total mensal de solicitaes de manuteno
Anlise dos Dados Coletados

A partir de agora apresentaremos os resultados das duas
formas utilizadas para obteno de dados: a pesquisa na base
de dados e as entrevistas. A base de dados, no momento da
pesquisa, contava com mais de 3700 solicitaes de manuteno, e as entrevistas foram realizadas com 8 pessoas ligadas
diretamente manuteno do software.
Estatsticas sobre a Base de Dados

Partindo dos totais obtidos com a base de dados, algumas
figuras puderam ser construdas.
Inicialmente, na Figura 5, apresentado o nmero de solicitaes registradas mensalmente desde a implantao do sistema
de registro de manutenes.
Nota-se que no existe uma constncia no nmero de manutenes por ms, o que sugere uma imprevisibilidade nas
necessidades de manuteno por parte dos clientes. Em abril
de 2005 foi registrado o maior nmero de chamados de manuteno (355). Os dados representam uma mdia de 163,45
solicitaes de manuteno por ms (desvio padro de 83,7).
Constatou-se ainda que a mdia de solicitaes diria de 8,59
novas requisies. Uma possvel razo para a existncia de
pocas com maior incidncia de pedidos de manuteno seria o
fato de o nmero de solicitaes entregues naquele ms ter sido
maior, o que normalmente acarretaria mais falhas colaterais,
ou seja, aquelas que acabam incidindo em outros mdulos do
software, apesar dos testes e da homologao em clientes.
Figura 6. Dias necessrios para a concluso de manutenes
Os registros de solicitaes de manuteno incluem desde operaes simples, que resultam em poucos dias para a
implementao, at solicitaes mais complexas, que podem
levar semanas, e at meses, para serem concludas. Solicitaes
desse porte normalmente exigem que o projeto de um ou mais
mdulos seja reestruturado, o que justifica o tempo gasto para
entrega ao cliente.
A distribuio, em termos de dias gastos para a implementao de manutenes, mostrada na Figura 6.
Um estudo do grfico revela que as manutenes de menor
grau de complexidade ocupam a maior parte do tempo dos
mantenedores. No entanto, existem manutenes com complexidade suficiente para exigir mais de dois meses de trabalho.
Observou-se que a grande quantidade de manutenes de
menor complexidade acaba por interferir no tempo de entrega das manutenes mais complexas, gerando atrasos. Isso
ocorre em funo da grande expectativa do cliente no sentido
de obter respostas rpidas, o que fora os mantenedores a
liberar primeiro as manutenes mais simples. Na Figura 7
mostrado qual o grau de prioridade indicado pelo cliente ao
fazer as suas solicitaes de manuteno.
39
Figura 7. Distribuio de prioridades das

manutenes
em avaliar e prevenir problemas futuros no software (0% em

manuteno preventiva), o que poderia ser feito por um processo de reengenharia. Fica evidente que o enfoque est em
manter o software em funcionamento, adequando-o na medida
em que as necessidades surgem, ou seja, seria uma postura de
aguardar acontecer e no de buscar prevenir.
esperado, pela literatura, que o tempo empenhado em
tarefas de manuteno exceda o tempo de desenvolvimento, e
esse fato buscou ser comprovado pela comparao entre tempo
gasto com o desenvolvimento da primeira verso entregue ao
cliente e o tempo gasto com a manuteno at ento. Para isso,
elegeram-se trs mdulos representativos do software analisado (aqui referenciados por mdulo 1, mdulo 2 e mdulo 3),
com o intuito de contabilizar o tempo gasto em desenvolvimento e o gasto em manuteno. O tempo de desenvolvimento
inclui tempo gasto em projeto, codificao e testes.
Esse resultado apresentado na Figura 9, que considera os
registros de manuteno efetuados.
De acordo com o mostrado na figura, percebe-se que a organizao consumiu, nos trs exemplos, mais de 60% do esforo
empregado em atividades de manuteno, e esse percentual
tende a subir com o passar do tempo.
Ambiente e Equipe de Manuteno

Figura 8. Distribuio dos problemas entre os
tipos de manuteno
Figura 9. Tempo consumido em desenvolvimento versus em manuteno
Nota-se que o cliente busca respostas rpidas, considerando

com prioridade elevada a maior parte dos chamados de manuteno efetuados.
Do ponto de vista dos quatro tipos de manuteno software
(adaptativa, perfectiva, corretiva e preventiva), realizou-se a
quantificao das manutenes efetuadas dentro desses tipos.
Para esse levantamento, foi considerada a classificao das manutenes informada em cada registro feito na base de dados.
O resultado obtido apresentado na Figura 8.
Os valores apresentados apontam que o maior esforo da
organizao est em atender requisies de novas funcionalidades, mostrando enfoque em manuteno perfectiva. Uma
constatao preocupante foi a de que no existe uma ateno
40
Durante a entrevista com os responsveis pelas manutenes,

constatou-se que no existe um procedimento padro a ser
seguido para a execuo das manutenes. O que existe uma
preocupao em agendar datas de entrega para as solicitaes
cujos clientes responsveis insistem em respostas mais rpidas,
o que freqentemente acaba inviabilizando a metodologia de
disponibilizao de atualizaes descrita anteriormente. Casos
de manutenes de urgncia, quando ocorrem, so priorizados
em detrimento das demais.
Observou-se tambm que o cdigo-fonte modificado no
documentado de maneira adequada, sendo muitas vezes atribudas somente pequenas notas, ou o nmero do chamado que
resultou na modificao de um trecho de cdigo. Esse nmero
de chamado est relacionado com o registro de necessidade de
manuteno efetuado pelo cliente, podendo um futuro mantenedor consultar do que se tratou a manuteno, buscando pelo
nmero do chamado informado no cdigo-fonte no sistema de
registro de manutenes.
Os profissionais encarregados de tarefas de manuteno relataram ainda que nem sempre o cliente compreende totalmente
o que est solicitando, muitas vezes gerando discusses entre
empresa/cliente, o que est relacionado com os problemas de
comunicao entre usurio e desenvolvedor. Muitas vezes
o cliente acredita que uma determinada manuteno ser
suficiente para adequar o software sua nova necessidade de
negcio, quando na verdade no suficiente. Essa dificuldade
de compreenso do software pelo prprio cliente acaba por
gerar situaes de desgaste na relao entre empresa-cliente.
Prazo de entrega sempre um problema quando no existe
um processo para conduzir a manuteno. Esse foi outro fato
verificado, uma vez que nem sempre a manuteno, com data
M anuten o
agendada e informada ao cliente, pode ser entregue no prazo

combinado, geralmente em funo de re-trabalho em manutenes j realizadas, ou mudanas de prioridades de entrega.
Em parte esse atraso decorre do fato de o mantenedor ser
tambm a pessoa que desenvolve, de forma que a tarefa de
desenvolvimento precisa mesclar-se com a de manuteno,
contribuindo para a diminuio do desempenho do mantenedor. Isso se agrava quando testes em uma nova funcionalidade
esto sendo feitos em paralelo a alguma correo solicitada
pelo cliente.
Outro ponto importante refere-se ao baixo interesse dos profissionais envolvidos em tarefas de manuteno, fato que pode
ser comprovado pelo interesse desses profissionais em deixar a
atividade de manuteno para dedicar-se ao desenvolvimento.
Esse interesse foi manifestado por todos os profissionais de
manuteno entrevistados.
A poltica de testes utilizada, embora prevista como uma
alternativa pela literatura, nesse caso especfico no vinha
apresentando os resultados esperados. Nem sempre o cliente
tinha tempo e boa vontade para avaliar uma verso de testes
em ambiente separado daquele de produo, culminando com
problemas nas manutenes efetuadas surgindo quando a
verso oficial j estava no site e em uso pela maior parte dos
clientes em seus ambientes de produo.
Problemas Identificados
Aps obter e analisar os dados, foi possvel montar a Tabela 4,
que envolve os principais problemas de manuteno identificados na organizao.
Os problemas, como pode ser observado, foram classificados de
acordo com sua natureza em problemas gerenciais e tcnicos.
de caso, e aqueles registrados no passado, buscando inferir

algum padro de evoluo nos mesmos. Alm disso, estabelece
um rol de problemas de manuteno de software, publicados
por diferentes autores, na forma de uma lista de dificuldades
inerentes atividade de manuteno, para fins de anlise nos
prximos captulos. Procurou-se estabelecer uma denominao direta e simples para os problemas, facilitando a leitura,
o entendimento e posteriores referncias.
Problemas do Passado versus Problemas Atuais

Os problemas identificados no estudo de caso permitem o
surgimento da seguinte questo: Os problemas de manuteno
de software de hoje guardam relao com aqueles verificados
no passado? A resposta a essa questo fornecer indcios da
maneira como a mudana da tecnologia pode estar ou no
influenciando tanto o agravamento como o surgimento de
problemas.
Partindo desse princpio, constatou-se que existe um alinhamento mais ou menos regular entre os problemas do passado
com os atuais, o que permitiu a construo da Tabela 5. O
quadro associa os problemas relacionando-os de acordo com
a sua natureza.
Embora no se estabelea uma equivalncia exata, essa tabela
mostra uma semelhana muito grande entre a natureza dos
problemas obtidos em cada levantamento.
Problemas de Manuteno Publicados

A relao de problemas de manuteno de software identificada pode ser visualizada na Tabela 6, construda de forma
a mostrar os problemas e suas respectivas fontes. Em virtude
Ausncia de um processo de manuteno de software
Concluses Parciais
Problemas de manuteno de software

Este captulo apresenta uma comparao entre os problemas
de manuteno de software atuais, identificados pelo estudo
Grande expectativa dos usurios
Problemas Gerenciais
Elevada rotatividade de membros e funes dentro da equipe

Sobrecarga de tarefas
Estimativa de prazo no condizente com a complexidade do software
Baixa motivao entre profissionais de manuteno
Ausncia de manuteno preventiva
Falhas de comunicao com o usurio
Atrasos na entrega
Registro inexistente ou superficial de manutenes anteriores
Problemas Tcnicos
A classificao dos problemas de manuteno identificados

na organizao quanto a sua natureza, permite observar que
aqueles ligados a questes gerenciais esto mais presentes
do que os de carter mais tcnico. De fato, constatou-se que
conciliar dificuldades tcnicas de manuteno com os anseios
dos usurios no uma tarefa simples, e infelizmente no vem
obtendo o sucesso desejado.
A ausncia de um processo de manuteno de software formal,
como dita normas de engenharia de software, no seria de todo
condenvel se o processo interno criado pela prpria organizao funcionasse de maneira satisfatria. O que se observou foi
que a presso gerada pelos clientes muitas vezes prejudica o
cumprimento correto da seqncia de passos estipulada pela
prpria organizao para tratar a manuteno de software.
Por fim, a inexistncia de manuteno preventiva um fato
que precisa ser analisado em conjunto com os objetivos de
negcio da organizao e com seus projetos em relao vida
til do software que mantm.
Ausncia de um ambiente computacional especfico para manuteno

Validao insuficiente de manutenes efetuadas
Documentao insuficiente ou superficial
Falta de compreenso do software e suas estruturas
Tabela 4. Problemas de manuteno de software
41
da lista relativamente extensa, optou-se por dividi-la em categorias para promover melhor organizao e facilidade de
leitura. A numerao seqencial atribuda a cada problema
tem o intuito nico de facilitar as referncias posteriores,
no guardando qualquer outro significado. Faz-se necessrio dizer que a separao dos problemas a seguir no
rigorosamente exata, uma vez que muitos deles poderiam
ser classificados em mais de uma categoria.
A relao anterior, embora seguramente no exaustiva,
apresenta de forma geral os principais problemas que
recaem sobre a atividade de manuteno de software.
Outros problemas que eventualmente existam e no foram
citados, so demasiados especficos de certo domnio,
ou fortemente relacionados a algum dos problemas j
citados. Dessa forma, acredita-se que a listagem anterior
seja representativa das dificuldades mais importantes
em manuteno de software, no se prendendo a nenhum
domnio especfico de software.
Problemas de manuteno e os grupos de processos

da norma ISO/IEC 12207
A norma ISO/IEC 12207 representa um padro internacionalmente adotado que engloba processos para o ciclo de vida
de software. Neste tpico, a norma utilizada para criar uma
relao de causa e conseqncia com os problemas de manuteno de software apresentados anteriormente.
Essa relao se estabelece da seguinte maneira: a norma
apresenta grupos de processos (que por sua vez englobam
diversos outros processos), que visam atingir alguma fase
do ciclo de vida de software, guiando-o com as melhores
prticas. Assim, a no verificao de um grupo de processos,
acarretar problemas para a respectiva fase (e conseqncias
para as futuras).
Dessa maneira, foi possvel a construo da Tabela 7, na qual
so relacionados os grupos de processos da norma, com os problemas de manuteno, procurando estabelecer uma relao de
causa (a no verificao do respectivo grupo) e consequncia
(problema derivado). Para essa distribuio, verificaram-se,
para cada grupo, seus processos e as
determinaes de suas respectivas
Problemas apontados por Lientz e Swanson (1980)
Problemas atuais
tarefas. O no atendimento a uma das
- Registro inexistente ou superficial de manutenes anteriores;
Baixa qualidade da documentao dos sistemas
tarefas do processo, automaticamente
- Documentao insuficiente ou superficial.
relaciona o problema ao processo, e em
Necessidade constante dos usurios por melhorias e novas - Grande expectativa dos usurios;
um nvel mais alto, ao grupo ao qual
funcionalidades
- Falhas de comunicao com o usurio.
esse processo pertence.
- Ausncia de um processo de manuteno de software;
A distribuio grfica das informa- Sobrecarga de tarefas;
Falta de uma equipe de manuteno
es
anteriores est representada na
- Ausncia de manuteno preventiva;
Figura
10.
- Ausncia de um ambiente computacional especfico para manuteno.
Percebe-se,
pela figura anterior, que
- Estimativa de prazo no condizente com a complexidade do software;
Falta de comprometimentos com cronogramas
existe
uma
grande
concentrao de
- Atrasos na entrega.
problemas
relacionados
principal- Baixa motivao entre profissionais de manuteno;
mente
com
fatores
de
ordem
gerencial,
Treinamento inadequado do pessoal de manuteno
- Validao insuficiente de manutenes efetuadas;
ligados
interao
com
pessoas
e
- Falta de compreenso do software e suas estruturas.
processos,
respondendo
por
47,1%
dos
Rotatividade dos profissionais
- Elevada rotatividade de membros e funes dentro da equipe.
problemas.
Tabela 5. Comparao entre problemas de manuteno de software
Dentre os dez grupos de processos,
cinco ficaram sem nenhum problema
relacionado. Os grupos de aquisio e
de fornecimento apresentam uma razo
clara: esto relacionados criao de
um produto de software novo, portanto
fortemente ligadas ao desenvolvimento,
o que no foi considerado. O grupo de
melhoria de processo pode ser visto sob
duas perspectivas, que consideram a
existncia ou no de processos implantados na organizao. Na primeira das
vises, assumindo que a organizao
possua processos implantados, os problemas de manuteno poderiam ser
associados a falhas nesses processos,
alegando-se que seriam essas falhas as
responsveis diretamente pela maioria
dos problemas de manuteno. Isso, no
Figura 10. Distribuio dos problemas nos grupos de processos
42
M anuten o
Fatores de Gerncia
Problema
Referncias
01. Falta de comprometimento com cronogramas
Lientz e Swanson (1980); Estudo de Caso
02. Treinamento inadequado da equipe de manuteno
Lientz e Swanson (1980); Dekleva (1992); Dart et al. (2001); Estudo de Caso
03. Ausncia de um profissional responsvel exclusivamente ao controle de configurao de software
Dart et al. (2001)
04. Viso organizacional diferenciada para a equipe de desenvolvimento e para a equipe de manuteno
Dart et al. (2001)
05. Dificuldades de comunicao entre a equipe de manuteno e a prpria organizao
Dart et al. (2001)
06. Software desenvolvido visto pela gerncia como no construdo para a manuteno
Dart et al. (2001)
07. Mantenedores desconhecem planos da organizao com relao equipe de manuteno
Dart et al. (2001)
08. Contratao de temporrios para auxlio na manuteno leva ao menor controle sobre a atividade
Dart et al. (2001)
09. Experincias com manutenes anteriores no so disseminadas dentro da prpria organizao e entre novos
Dart et al. (2001); Estudo de Caso
membros da equipe
10. Dificuldade na medio do desempenho da equipe de manuteno
Dekleva (1992)
11. Ausncia de adoo de padres, metodologias e procedimentos de manuteno
Dekleva (1992); Estudo de Caso
12. Falta de suporte da gerncia
Dekleva (1992)
13. Sobrecarga de tarefas
Estudo de Caso
14. Ausncia de manuteno preventiva
Estudo de Caso
15. Estimativa de prazo no condizente com a complexidade do software
Estudo de Caso
Fatores de Infraestrutura
Problema
Referncias
16. Necessidade de suporte automatizado gerncia de configurao de software
Dart et al. (2001)
17. Ferramentas para manuteno precisam ser diferentes daquelas de desenvolvimento
Dart et al. (2001)
18. Falta de recursos tecnolgicos adequados
Dart et al. (2001); Estudo de Caso
19. Estagnao tecnolgica no ambiente de trabalho
Dart et al. (2001)

Fatores humanos equipe
Problema
Referncias
20. Falta de uma equipe de manuteno
Lientz e Swanson (1980)
21. Elevada rotatividade dos profissionais
Lientz e Swanson (1980); Dekleva (1992); Estudo de Caso
22. Mantenedores lamentam por no possurem contato com estado-da-arte da tecnologia
Dart et al. (2001)
23. Preferncia dos profissionais por trabalhos de desenvolvimento
Dart et al. (2001)
24. Manuteno de software vista como uma tarefa no prestigiosa
Dekleva (1992); Dart et al. (2001); Estudo de Caso
25. Falhas de comunicao com o usurio
Estudo de Caso
26. Mtodos inadequados de testes
Dekleva (1992); Estudo de Caso
27. Documentao insuficiente ou superficial (software alterado)
Lientz e Swanson (1980); Dekleva (1992) ; Dart et al. (2001); Estudo de Caso
Fatores humanos cliente
Problema
Referncias
28. Necessidade constante dos usurios por melhorias e novas funcionalidades
Lientz e Swanson (1980); Estudo de Caso
29. Falta de compreenso dos usurios a respeito de suas reais necessidades de software
Estudo de Caso
30. Mudanas freqentes de prioridades (clientes)
Dekleva (1992)
Fatores de software
Problema
Referncias
31. Baixa qualidade da documentao dos sistemas (software original)
Lientz e Swanson (1980); Dekleva (1992); Dart et al. (2001); Estudo de Caso
32. M qualidade do cdigo-fonte original
Dekleva (1992); Dart et al. (2001)
33. Necessidades de integrao com softwares incompatveis
Dart et al. (2001)
34. Plataformas heterogneas dificultam a definio de ferramentas adequadas
Dart et al. (2001)
Tabela 6. Problemas de manuteno de software lista geral
43
Problemas
Categoria Processos Fundamentais
Grupo de Processos de Aquisio
Grupo de Processos de Fornecimento
Grupo de Processos de Engenharia
(11), (26), (29), (33), (34)
Grupo de Processos de Operao
(25)
Categoria Processos Organizacionais

Grupo de Processos de Gerncia
(01), (04), (05), (06), (07), (08), (12), (13), (14),

(15), (20), (21), (24), (30), (31), (32)
Grupo de Processos de Melhoria de Processo

Grupo de Processos de Recursos e Infra-estrutura
(02), (09), (10), (17), (18), (19), (22), (23)
Grupo de Processos de Reuso

Categoria Processos de Apoio
Grupo de Processos de Gerncia de Configurao
(03), (16), (27), (28)
Grupo de Processos de Garantia de Qualidade

Tabela 7. Grupos de processos no observados e as respectivas consequncias
entanto, no corresponde realidade, j que normalmente

os processos no existem nas organizaes.
Em outra viso do grupo de melhoria de processo, agora
considerando que a organizao no possua processos
implantados, seria inadequado valer-se desse fato para
se associar a esse grupo praticamente todos os problemas
de manuteno, sob a alegao de que existem como resultado da ausncia de processos adequados para tratar a
manuteno de software. A inadequao desse posicionamento se justifica pelo fato de que possvel estabelecer
uma melhor relao dos problemas com outros processos
da norma, muitas vezes de forma direta, valendo-se para
isso das tarefas estipuladas para cada processo. O no
cumprimento de uma tarefa especfica, automaticamente relaciona o processo correspondente com algum dos
problemas j apresentados. Assim, pode-se concluir que
a norma capaz de fornecer indcios de quais processos
especficos inexistem ou so falhos para a ocorrncia de
cada problema, permitindo ento distribu-los de forma
mais precisa e no associ-los todos ao grupo de melhoria
de processo sob a alegao genrica de sua ausncia na
organizao.
O prximo grupo a considerar o de reuso, que tambm
parece ter uma razo clara para ter permanecido sem
problemas associados. No simples tratar o reuso de
artefatos de software nem mesmo durante o desenvolvimento. O que dizer ento da atividade de manuteno,
normalmente com necessidades imprevisveis e muitas
vezes inditas para o contexto do software. Dificilmente
ser possvel valer-se de solues prontas, o que torna
o grupo de processos de reuso com pouca ou nenhuma
importncia para a reduo de problemas de manuteno
de software.
Finalmente, o grupo de processos de garantia de qualidade tambm no teve problemas relacionados em razo
44
de existirem outros processos da norma com tarefas

especficas no atendidas que melhor se encaixam como
fonte do problema. Por exemplo, considere o processo
de garantia de qualidade (os processos do grupo so:
garantia de qualidade, verificao, validao, reviso
conjunta, auditoria e avaliao de produto). O objetivo
principal desse processo prover garantias de que os
produtos de trabalho e processos obedeam aos planos
predefinidos para o software. Note, no entanto, que os
problemas de manuteno de software normalmente so
frutos da ausncia de planejamento ou do planejamento
falho da manuteno, sendo que o correto planejamento
e execuo so tarefas reservadas a outro processo (processo de Manuteno de Software e Sistema). Assim, a
existncia de processos com tarefas mais especficas
acabou por evitar que problemas de manuteno fossem relacionados a processos do grupo de garantia de
qualidade.
No entanto, fcil perceber que a palavra qualidade
extremamente conhecida em diversos contextos, mesmo
aqueles no relacionados a software, chegando a ser
quase intuitivo pensar que algo feito com qualidade
resultar em menos problemas ou maior satisfao do
usurio. Esse raciocnio leva concluso de que, embora
sem problemas associados diretamente, os processos do
grupo de garantia de qualidade devem ser observados
como recurso de apoio execuo com qualidade das
tarefas de manuteno como um todo.
Consideraes Finais
Embora tenha se produzido neste artigo uma relao de
problemas com base em apontamentos feitos por outros
autores, e tambm pelo estudo de caso realizado, entende-se que no se trata de uma relao fixa e exaustiva. Em
diferentes abordagens futuras, nomes diferentes podem
ser utilizados para se referirem s mesmas dificuldades.
razovel pensar ainda que novos problemas surjam,
constituindo novas categorias de problemas, distintas
das aqui definidas.
Esse fato, porm, no invalida ou torna de todo desatualizado o que foi exposto, j que a literatura, e tambm
o estudo de caso apresentado, apontam uma relativa
estabilidade entre os problemas mais relevantes ao
longo do tempo.
admissvel, tambm, que o surgimento de novas
tcnicas de programao, novas tecnologias e metodologias, influenciem a forma como as organizaes
trabalham, e nesse caso poderiam reduzir os problemas
aqui apresentados.
Outra observao necessria se faz com relao aos
problemas e os tamanhos de software sobre os quais
incidem. O que ocorre, de fato, que os problemas
apresentados incidem de maneira geral sobre qualquer
tamanho de software, variando apenas a nfase que o
problema representa para cada tamanho de software.

Feedback
eu
edio
ta
Referncias
Bennett, K. H.; Rajlich, V. T. (2000) Software maintenance and evolution: a roadmap, In: Conference
on The Future of Software Engineering, Limerick, Ireland, June.
Bennett, K. H.; Ramage, M.; Munro, M. (1999) Decision Model for Legacy Systems, IEEE Proceedings
on Software (TSE), v.146, n. 3, p. 153-159.
Bhatt, P.; Shroff, G.; Misra, A. K. (2004) Dynamics of software maintenance, ACM SIGSOFT Software
Engineering Notes, v. 29, n. 5, p. 1-5.
Basili, V. (1990) Viewing Maintenance as Reuse-Oriented Software Development, IEEE Software,
v. 7, n. 1, p. 19-25.
Chapin, N. (1986) Software maintenance: A different view, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
Dart, S.; Christie, A. M.; Brown, A. W. (2001) A Case Study in Software Maintenance, Technical
Report, Carnegie Mellon University.
Dekleva, S. M. (1990)Annual Software Maintenance Survey: Survey Results,Software Maintenance
Association, Vallejo, California, USA.
________. (1992) Delphi study of software maintenance problems, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
De Lucia, A., Pompella, E., Stefanucci, S. (2004) Effort estimation for corrective software
maintenance. In: 14th International Conference on Software Engineering and Knowledge
Engineering, Ischia, Italy, July.
IEEE (1998) Std 1219 IEEE Standard for Software Maintenance, Institute of Electrical and
Eletronic Engineers, New York, NY, USA.
ISO/IEC 12207 (1998) Standard for Information Technology - Software Lifecycle Processes,
International Standard Organization, New York, NY, USA.
ISO/IEC 15504 (2003) Software Process Assessment, International Standard Organization, New
York, NY, USA.
Koskinen, J.; Salminen, A.; Paakki, J. (2004) Hypertext support for the information needs of
software maintainers, Journal of Software Maintenance and Evolution: Research and Practice, v.
16, n. 3 , p. 187-215.
Kung, H.; Hsu, C. (1998) Software Maintenance Life Cycle Model, In: International Conference on
Software Maintenance, Bethesda, Maryland, USA.
Lehman, M. M. (1974) Programs, Cities, Students, Limits to Growth?, In: Imperial College of Science
Technology, London, England, May.
________. (1980) On Understanding Laws, Evolution and Conservation in the Large Program
Life Cycle, Journal of Systems and Software (JSS), v. 1, n. 3, p. 213-221.
________. (1991) Software Engineering, the Software Process and their Support, IEEE
Software Engineering Journal: Special Issues on Software Environments and Factories, v. 1, n. 3,
p. 213-221.
________. (1996) Laws of Software Evolution Revisited. In: 5th European Workshop on
Software Process Technology, Nancy, France, October.
Lientz, B. P.; Swanson, E. B. (1980) Software Maintenance Management,Reading, MA, Addison-Wesley.
Niessink, F. (1999) Software Maintenance Research in the Mire?,In: Annual Workshop on Empirical
Studies of Software Maintenance (WESS99), Oxford, United Kingdom, September.
Pfleeger, S. L. (2001) Software Engineering: theory and practice. Second Edition, New Jersey,
Prentice Hall.
Pigoski, T. M. (1996) Practical Software Maintenance: Best Practices for Managing Your Software
Investment,Willey Computer Publishing.
Polo, M.; Piattini, M.; Ruiz, F.; Calero, C. (1999) Roles in the maintenance process, ACM SIGSOFT
Software Engineering Notes, v. 24, n. 4, p. 84-86.
Polo, M.; Piattini, M.; Ruiz, F. (2003) Using a qualitative research method for building a software
maintenance methodology, Software Practice and Experience, v.32, n. 13, p. 12391260.
Pressman, R. S. (2005) Software Engineering: a practitioners approach, 6.ed., McGrawHill Higher
Education.
Singh, R. (1996). International Standard ISO/IEC 12207 Software Life Cycle Processes, Software
Process Improvement and Practice, vol. 2, p. 3550.
Sneed, H. M. (2003) Critical Success Factors in Software Maintenance, In: International Conference
on Software Maintenance, Amsterdam, The Netherlands, September.
Sommerville, I. (2003) Engenharia de Software, 6.ed., So Paulo, Addison Wesley.
Silva, L.de P.; Santander,V.F.A.(2004)Uma Anlise Crtica dos Desafios para Engenharia de Requisitos em
Manuteno de Software,In:Workshop em Engenharia de Requisitos,Tandil, Argentina, Dezembro.
Souza, S. C. B. de; Neves, W. C. G. das; Anquetil, N.; Oliveira, K. M. de. (2004) Documentao Essencial
para Manuteno de Software II, In: I Workshop de Manuteno de Software Moderna, Braslia,
DF, Brasil, Outubro.
Ulrich, W. M. (1990) The evolutionary growth of software reengineering and the decade ahead.
American Programmer, v. 3, n. 10, p. 14-20.
Visaggio, G. (2001)Assessing the Maintenance Process Through Replicated, Controlled Experiment.
Journal of Systems and Software, v. 44, n. 3, p. 187-197.
Yourdon, e. (1992) Anlise Estruturada Moderna,traduo da terceira edio, Rio de Janeiro, Campus.
45
sobre e
s
Por fim, a relao estabelecida entre os problemas e os grupos da norma, permite uma viso inicial das caractersticas
do processo de ciclo de vida de software que devem ser
tomadas com maior ateno para o contexto de minimizao
de problemas de manuteno de software.
D
s
M anuten o
Engenharia
Reengenharia de Software Orientado a

Objetos
Padres de reengenharia para garantia de qualidade
Este artigo apresenta questes envolvendo a
manuteno de software evolutiva e adaptativa,
conceitos sobre Reengenharia de Software e elucidao dos padres para reengenharia de software
Para que serve?

Ampliar o conhecimento sobre reengenharia de
software, saber identificar e aplicar os Padres
para a Reengenharia e, auxiliar os gerentes de
projeto em TI e Analistas de Sistemas na adoo de
reengenharia de sistemas legados procedimentais
para o paradigma orientado a objetos

Giuliano Prado de Morais Giglio
giulianopmg@yahoo.com.br
desenvolvedor Delphi desde 1997, com

ampla experincia em aplicaes Win32.
Graduado em Informtica pela UFJF, com
Especializao em Desenvolvimento de
Aplicaes para Web pelo Centro de Ensino
Superior de Juiz de Fora, e Mestrado em
Computao pela UFF. Atualmente professor universitrio em diversas instituies, em cursos de Sistemas de Informao,
e atua como consultor, pesquisador e desenvolvedor de aplicaes Java, sobretudo
na plataforma J2EE para Web, e J2ME, sendo especialista em aplicaes Mobile.
46
uitas organizaes tm enfrentado problemas com o uso

e a manuteno de sistemas
de software construdos para serem
executados em uma variedade de tipos
de hardware e programados em linguagens obsoletas. Com o passar do tempo,
a tarefa de realizar a manuteno tornase mais complexa e mais cara e, ainda,
esses sistemas tornam-se cada vez mais
desorganizados devido s inmeras
tentativas de adaptaes e incluses de
novas funcionalidades. H ainda muitos
Engenharia de Software Magazine - Reengenharia de Software Orientado a Objetos
Na avaliao de um re-projeto de um sistema

legado procedimental, apoiar a melhoraria da
qualidade dos processos de software e do planejamento de questes administrativas em projetos de TI e, garantir a qualidade do processo de
reengenharia de software orientado a objetos.
softwares nessa situao devido rpida

evoluo das ferramentas, tecnologias e
mtodos, conseguida pelas indstrias de
computadores e empresas de tecnologia
da informao. Sendo assim, as organizaes tm trs alternativas: manter os
Proje to
softwares legados com a situao j descrita de desorganizao

e custos cada vez maiores, reconstruir os softwares ou realizar
a reengenharia tanto para aumentar sua manutenibilidade
quanto para implement-los em um paradigma mais atual
com ou sem mudana de linguagem.
No caso de manter um software legado, apenas efetuando-se
as manutenes para que o mesmo continue operando, muitos
problemas podem ocorrer, tais como a alocao de pessoal
para essa tarefa que pode ter uma porcentagem bastante significativa do esforo de uma organizao, alm da falta de sua
documentao, comum nesses casos e que torna ainda mais
crtica a situao.
A opo pela reconstruo de um software legado tambm
tem problemas associados. O fato de que software tem regras
de negcios embutidas, que podem no estar documentadas
e a possibilidade das pessoas que as dominam no estarem
mais na empresa, faz com que a sua completa reconstruo no
seja to confivel. Alm disso, outro problema dessa opo o
custo do re-desenvolvimento global do software, geralmente
muito alto, consumindo tempo e recursos que, na maioria das
vezes, as empresas no dispem.
A engenharia reversa e/ou reengenharia so as formas que
muitas organizaes esto buscando para manter/refazer seus
softwares, livrando-se das manutenes difceis e da degenerao de suas estruturas. Por esse motivo, importante que o
resultado desse processo seja confivel.
Nas ltimas dcadas, o fator qualidade com relao ao processo de desenvolvimento de software foi bastante estudado
tendo sido elaborados vrios modelos de melhoria e amadurecimento do mesmo, o que elevou sua capacitao para a
gerao de software.
Assim, no processo de reengenharia, a garantia da qualidade
tambm foi encarada como mais uma etapa do processo. A
definio de um processo completo de software deve incluir
atividades de controle de projeto, garantia da qualidade, gerenciamento de configurao, alm de ferramentas e mtodos
de engenharia de software.
A definio de padres de reengenharia tem sido abordada
por diversos autores atualmente, pela necessidade da existncia de diretrizes mais consistentes para guiar a realizao
do processo.
Este artigo foi baseado no trabalho escrito por LEMOS (2002),
o qual prope que a qualidade de processo de desenvolvimento
de software desafio tambm no processo de reengenharia.
Dessa forma, no trabalho supracitado, a aplicao de modelos
de melhoria da qualidade, originalmente utilizados no processo de desenvolvimento de software, em apoio ao processo de
reengenharia tambm utilizada, com o objetivo de tornar o
processo de reengenharia orientada a objetos mais eficiente
e maduro.
LEMOS (2002) optou por descrever esse processo utilizandose padres, pelo fato de tornarem o aprendizado, pelos engenheiros de software, mais fcil dado seu formato padronizado.
Dessa forma, foi proposto um Processo de Reengenharia
Orientada a Objetos, denominado PRE/OO esperando auxiliar
engenheiros de software a realizar a reengenharia de sistemas

legados, obtendo sua completa re-estruturao, de forma
facilitada.
Conhecendo a Engenharia Reversa

O termo engenharia reversa teve sua origem na anlise do
hardware, em que a prtica de extrao de projetos de produtos
concludos comum, sendo aplicada para a melhoria desses
produtos e anlise de produtos de competidores.
Nesse contexto, a engenharia reversa pode ser definida
como o processo de desenvolvimento de um conjunto de especificaes para um sistema de hardware complexo atravs
do exame ordenado dos componentes do sistema. Enquanto
que para o hardware o objetivo tradicional da engenharia
reversa duplicar o sistema, para o software esse processo
mais frequentemente utilizado para se obter um suficiente
entendimento do mesmo no nvel de desenvolvimento. Portanto, define-se engenharia reversa para um software como
o processo de anlise para identificar seus componentes e
inter-relacionamentos e criar representaes do mesmo em
outra forma ou num nvel mais alto de abstrao.
Abstrao pode ser definida como a tarefa de utilizar apenas
assuntos relevantes ao propsito em questo. Dois conceitos
podem ser derivados:
Nvel de Abstrao: acontece entre as fases do ciclo de vida
do software. Quanto mais prximo se estiver da implementao, menor o nvel de abstrao e quanto mais prximo da fase
de especificao de requisitos, maior o nvel de abstrao;
Grau de Abstrao: acontece dentro de uma mesma etapa
do ciclo de vida do software. Se as informaes forem pouco
detalhadas, o grau de abstrao alto. Se as informaes forem
bastante detalhadas, baixo o grau de abstrao.
H duas categorias de engenharia reversa: a redocumentao
e a recuperao de projeto. A redocumentao, tambm chamada de visualizao de cdigo, utilizada na criao de representaes a partir de informaes obtidas apenas da anlise
do cdigo fonte, com o objetivo de recuperar a documentao
do software. A recuperao de projeto, tambm chamada de
entendimento de programa, utiliza alm do exame do cdigo,
o conhecimento do domnio das informaes relativo ao software e as dedues, com o objetivo de obterem-se informaes
com um nvel mais alto de abstrao.
O entendimento de programas uma forma mais crtica de
engenharia reversa, pois tenta aproximar-se do raciocnio
humano na busca de entendimento.
Nos ltimos anos, as pesquisas a respeito da engenharia reversa produziram mtodos para anlise de cdigo, incluindo
decomposio de software, anlise das dependncias estticas
e dinmicas, uso de mtricas, alm da explorao e visualizao do software (redocumentao). Entretanto, o cdigo do
software no contm todas as informaes necessrias sendo
que o conhecimento sobre sua arquitetura e sobre o domnio
da aplicao, alm das restries implcitas que, geralmente, s
existem na mente de quem construiu e utilizou o software.
47
Com a engenharia reversa possvel abstrair informaes a

partir do cdigo existente e tambm do conhecimento e experincia dos usurios, produzindo documentos consistentes com
o cdigo fonte, melhorando o desenvolvimento subsequente,
facilitando a manuteno e a reengenharia. Entretanto, reprojetar e documentar um sistema j existente tarefa bem mais
difcil do que realizar um novo projeto.
Para que as questes tcnicas relativas ao processo de
engenharia reversa sejam tratadas de forma mais efetiva,
o processo deve tornar-se maduro, capaz de ser repetido,
e passvel de evoluo de modo que cada vez mais passos
possam ser executados por ferramentas automatizadas.
Mtodo de recuperao de projetos de softwares

legados
O Fusion/RE foi criado a partir do mtodo Fusion com
o objetivo de recuperar o projeto de softwares legados
procedimentais em uma forma orientada a objetos. Para a
realizao do processo de engenharia reversa a partir desse
mtodo no h necessidade de se ter a documentao do
software legado, pois possvel recuperar o projeto atravs
do cdigo fonte do software.
O mtodo foi inicialmente desenvolvido consistindo de
quatro passos que correspondem fase de engenharia reversa e, posteriormente, mais dois passos correspondentes
segmentao foram adicionados formando os seis passos
resumidos a seguir:
1. Revitalizao da arquitetura do software legado:
recuperada a documentao bsica do software, baseada
na documentao disponvel a respeito do mesmo. Esse
processo pode ser conduzido de forma manual ou com o
auxlio de ferramentas de extrao. Como resultado desse
passo tem-se uma lista de todos os procedimentos, com
sua descrio e hierarquia de chamadas (Lista Chama/
Chamado por);
2. Recuperao do Modelo de Anlise do Sistema Atual
(MASA): a partir das bases de dados e do cdigo criado um
pseudo modelo orientado a objetos do software legado. Esse
modelo pode ser entendido como uma abstrao orientada
a objetos preliminar, mesmo a implementao real tendo
sido feita de acordo com o paradigma procedimental. As
estruturas de dados (seus relacionamentos e cardinalidades)
so recuperadas e modeladas como sendo pseudo-classes de
objetos e os procedimentos do cdigo legado so a base para
a derivao dos mtodos. Muitos dos procedimentos podem
conter anomalias, ou seja, um mesmo procedimento pode
tratar com vrias estruturas de dados. H uma classificao
para os procedimentos:
(o) observador, o procedimento ou a funo que somente
consulta a estrutura de dados
(c) construtor, o procedimento ou a funo que altera a estrutura de dados ou altera e consulta a estrutura de dados
(i) implementao, o procedimento ou a funo que trata
apenas de aspecto de implementao, sem alterar ou consultar nenhuma estrutura de dados.
48
Aps a classificao dos procedimentos, so criados:

Modelo de Ciclo de Vida: retrata, atravs de expresses
regulares, o comportamento global do sistema
Modelo de Operao: descreve detalhadamente cada operao do software de forma textual
Modelo de Objetos: representa os conceitos existentes no
domnio do problema e suas relaes.
3. Criao do Modelo de Anlise do Sistema (MAS): os
diagramas criados no passo anterior so abstrados, as pseudoclasses do MASA so generalizadas e as anomalias dos procedimentos so eliminadas, transformando um procedimento
anmalo em quantos mtodos forem necessrios;
4. Mapeamento do MAS para o MASA: so mapeados as
classes, atributos e procedimentos do MAS para os elementos
correspondentes no MASA, documentando-se inclusive as
possveis incluses/excluses. Esse passo muito importante
para futuras manutenes e possvel reuso do software;
5. Elaborao do Projeto avante a elaborao dos modelos
da fase de projeto para que a engenharia avante seja feita
mudando-se o paradigma de procedimental para orientado a
objetos, mantendo-se ou no a linguagem procedimental em
uso. Os diagramas gerados nesse passo so:
Grafo de Interao de Objetos: mostra quais objetos participam da execuo de uma operao e a sequncia de troca de
mensagens entre eles, sendo construdo com base no Modelo
de Operaes;
Grafos de Visibilidade: estabelecem a forma de comunicao
entre as classes, especificando a interface para troca de mensagens do sistema;
Descries de Classes: complementam o Modelo de Objetos
do sistema, especificando quais os atributos de cada classe e
sua interface externa;
Grafos de Herana: definem as especializaes existentes
entre as classes complementando as Descries de Classes.
6. Segmentao do Sistema: os procedimentos com anomalias so transformados em mtodos. O cdigo examinado,
dividido em mtodos e so inseridos comentrios mostrando
a correspondncia entre eles. Esse passo elaborado com base
nos diagramas do projeto de construo do software.
Geralmente, aps a aplicao do mtodo Fusion/RE, percebese um aumento no nmero de mtodos em relao aos procedimentos do software legado, porm esses so sempre menores e
organizados de forma a aumentar as possibilidades de reuso e
melhorar a manutenibilidade do software. A segmentao no
altera a linguagem de programao, mas o software gerado
aps o processo pode, de maneira muito mais simples, ser
transformado para uma linguagem orientada a objetos.
A reengenharia
A reengenharia envolve basicamente duas etapas: alguma
forma de engenharia reversa (para se alcanar um nvel mais
alto de abstrao) e a engenharia avante ou reestruturao.
Proje to
Esse processo indicado para os softwares que ainda tm

alta utilidade, mas difcil manuteno, sendo feito utilizandose mtodos que proporcionam maior qualidade ao software.
Atualmente, o uso da orientao a objetos tem mostrado uma
boa perspectiva, tanto para o desenvolvimento do software
quanto para sua posterior manuteno.
De acordo com JACOBSON (1991), a reengenharia pode
ser categorizada segundo os cenrios nos quais ocorrem a
transformao de softwares procedimentais para softwares
orientados a objetos:
Reengenharia completa da tcnica de implementao, sem
alterao de funcionalidade, em que o cenrio composto
das seguintes etapas:
- Preparao do modelo de anlise, com base no software a
ser reconstrudo;
- Mapeamento de cada objeto de anlise para a implementao
do software antigo;
- Reprojeto do software utilizando-se metodologias orientadas a objetos.
Reengenharia parcial sem alterao da funcionalidade, em
que o cenrio parcialmente alterado, de modo que o software
parea ser totalmente orientado a objetos. Consiste das etapas:
- Identificao das partes do software que sero re-implementadas usando-se a orientao a objetos;
- Preparao de um modelo de anlise das partes selecionadas
anteriormente;
- Mapeamento de cada objeto modelado a partir da antiga
implementao do software;
- Execuo dos passos anteriores at a interface entre as partes
mantidas e remodeladas do software se tornarem aceitveis;
- Execuo em paralelo:
- Projeto do novo software e de sua interface com o antigo
software,
Modificaes no software antigo e adio da interface com
o novo software;
Integrao e teste das partes mantidas e re-implementadas
do software.
Reengenharia com alterao da funcionalidade. Esse cenrio de um processo normal da engenharia de construo, no
qual so adicionadas novas funcionalidades ao software e o
mesmo re-implementado com o uso de uma tcnica orientada
a objetos. As principais etapas deste cenrio so:
- Alterao no modelo de anlise de acordo com os requisitos
incorporados ao software;
- Reprojeto do software.
A categorizao da reengenharia se d de acordo com a abrangncia que esse processo ir ter com relao ao software:
Converso do programa fonte: a forma mais simples de
reengenharia, na qual o cdigo fonte escrito em uma linguagem traduzido para outra linguagem;
Reestruturao do programa: aplicvel quando a estrutura
do software est corrompida dificultando seu entendimento
como, por exemplo, a existncia de funes duplicadas ou

nunca chamadas.
O processo de segmentao
Segmentao o processo de reengenharia com mudana
da orientao de procedimental para orientao a objetos,
preservando-se as funcionalidades do software e a linguagem
de programao. Assim, realizada a adaptao do cdigofonte, de acordo com os recursos disponveis na linguagem,
de forma a implement-lo com caractersticas orientadas a
objetos.
A segmentao, como visto anteriormente, pode ser conduzida seguindo-se o mtodo Fusion/RE, sendo o ltimo passo
desse mtodo. Esse passo foi subdividido em quatro partes,
executadas gradualmente e ao fim de cada uma so realizados
testes funcionais com o objetivo de garantir a preservao das
funcionalidades do software. Podemos descrever a segmentao resumidamente, da seguinte forma:
1. So criadas as classes de acordo com o Modelo de Objetos
obtido na terceira fase do Fusion/RE (obteno do MAS). Os
mtodos sem anomalias so diretamente inseridos nas classes
correspondentes. Os mtodos anmalos tm escolhidas as
classes que melhor os representam e, ento, feita a insero.
Alm disso, so inseridas referncias a esses procedimentos
nas classes que esses mtodos alteram e/ou observam;
2. feita a quebra dos mtodos anmalos em vrios sendo
que cada um passa a alterar ou observar apenas uma classe,
qual posteriormente associado;
3. So criados os mdulos que contm as descries das classes
e os prottipos de mtodos associados a elas. Da so criados os
mdulos que contm a implementao de cada classe;
4. So criadas as classes dependentes do tipo de implementao usada, como: pilhas, listas ou rvores.
O processo de segmentao varia de acordo com a linguagem
procedimental utilizada, em relao ao modo de implementao de suas estruturas de dados e dos recursos computacionais
a serem utilizados com o objetivo de tornar o cdigo pseudoorientado a objetos.
Contextualizando a manuteno
A manuteno de software uma das fases mais problemticas de seu ciclo de vida, caracterizando-se por um alto custo
e baixa velocidade de implementao. Porm, uma atividade
inevitvel, principalmente tratando-se de softwares teis, para
os quais os usurios constantemente solicitam mudanas e
agregaes de novas funcionalidades.
Podemos classificar a manuteno de software em quatro
categorias principais:
Manuteno Corretiva: alterao de um software de forma
a corrigir seus defeitos e assim garantir a continuidade de
sua operao;
Manuteno Adaptativa: adio ou modificao de funcionalidades um software para adapt-lo s mudanas ocorridas
em seu ambiente;
49
Manuteno Evolutiva: incluso de novas funcionalidades

ao software alm das originais a pedido do usurio;
Manuteno Preventiva: mudana do software para tornar
sua manuteno mais fcil (aumento da manutenibilidade).
Entre os principais fatores da dificuldade de entendimento
de um software encontram-se a parcial ou completa inexistncia de documentao e/ou sua desatualizao. Desse modo,
observa-se que a manutenibilidade de software est fortemente
relacionada com a disponibilidade de documentao atualizada sobre o mesmo.
A engenharia reversa e, posteriormente, a segmentao podem ser utilizadas com grande proveito no entendimento e na
re-documentao de software, de forma a melhorar sua manutenibilidade, sendo uma forma de manuteno preventiva.
Padres para realizao de reengenharia

Os sistemas legados no esto limitados ao paradigma
procedimental e a linguagens como COBOL. Atualmente
encontram-se sistemas legados orientados a objetos implementados em C++, SmallTalk ou Java. Originalmente, a orientao
a objetos prometeu a construo de sistemas mais flexveis e
de fcil evoluo. Porm, notou-se que esses sistemas legados
precisam passar pelo processo de reengenharia com o objetivo
de satisfazerem novos requisitos, tornarem-se mais flexveis
ou, simplesmente, seguir o projeto orientado a objetos. Dessa
forma, autores criaram uma linguagem de padres, a qual
pode ser utilizada no somente no processo de engenharia
reversa, como tambm durante a reengenharia de sistemas
como alternativa de prover a reestruturao de sistemas

orientados a objetos.
Os padres apresentam o seguinte formato: Nome, Intuito,
Contexto, Problema, Soluo, Exemplos, Avaliao, Justificativa, Padres Relacionados, Usos Conhecidos e Contexto
Relacionado, os quais foram agrupados em quatro grupos,
como mostra a Figura 1.
Cada grupamento contm padres tratando uma situao
similar da engenharia reversa, segundo a Tabela 1.
O FAPRE/OO uma famlia de padres para a reengenharia
orientada a objetos de sistemas legados procedimentais. Essa
famlia formada por quatro grupos cada um agrupando os
padres relacionados a situaes similares da engenharia
reversa (3 grupos) e da engenharia avante (1 grupo), descritos
a seguir:
Grupo 1 - Modelar os Dados do Legado: agrupa padres que
extraem informaes a partir dos dados e do cdigo fonte do
sistema legado, de forma a conduzir as aes do engenheiro
de software durante o primeiro contato com o sistema.
Grupo 2 - Modelar a Funcionalidade do Sistema: agrupa
padres para obter a funcionalidade do sistema legado, criando
modelos que representam as Regras de Negcios da Empresa
e capacitando o engenheiro de software a obter um entendimento detalhado dos componentes do sistema, aprofundando
assim, sua compreenso sobre estes.
Grupo 3 - Modelar o Sistema Orientado a Objetos: agrupa
padres para se obter o Diagrama de Classes e os Diagramas
de Sequncia do sistema, atravs da interao dos produtos
obtidos pelos padres dos grupos anteriores. O resultado
de sua aplicao o MAS (Modelo de Analise do Sistema),
modelo orientado a objetos que serve como base ao processo
de reengenharia.
Grupo 4 - Gerar o Sistema Orientado a Objetos: agrupa os
padres de engenharia avante, responsveis pela re-implementao do software legado a partir dos modelos orientados
a objetos gerados com a aplicao dos padres.
Figura 1. Agrupamentos da linguagem de padres

Grupo
Quando um importante software legado no pode mais evoluir naturalmente para satisfazer as mudanas nos requisitos
ele, frequentemente, submetido ao processo de reengenharia. Os padres de reengenharia apresentam novas solues
para uma soluo legada recorrente que j no apropriada e
Descrio
Primeiro Contato
Os padres desse grupo descrevem os procedimentos a serem tomados pelo engenheiro de software no primeiro contato com o sistema legado
Entendimento Inicial
Os padres desse grupo descrevem como o engenheiro de software pode obter o entendimento inicial do software, documentado principalmente na forma de diagramas
de classes
Captura de detalhes do modelo Os padres desse grupo descrevem como o engenheiro de software pode obter o entendimento detalhado de um particular componente do software
Preparao da reengenharia
Como a engenharia reversa precede a reengenharia, este grupo inclui alguns padres que auxiliam na preparao dos passos subsequentes da engenharia avante
Tabela 1. Grupos de Padres de Reengenharia
50
Proje to
descrevem como realizar a migrao da soluo legada nova

soluo. Padres de reengenharia codificam e registram o conhecimento sobre como modificar softwares legados: ajudam
a diagnosticar problemas e identificar os pontos fracos que
dificultam o desenvolvimento adicional do sistema, alm de
ajudar a encontrar solues mais apropriadas aos novos requisitos. O formato proposto para os padres de reengenharia so
descritos segundo a Tabela 2.
POOLEY et al. (1998) apresentam a idia de padres de reengenharia de software, adaptada a partir de padres de projeto,
como forma de identificar procedimentos bem sucedidos
de projetos de reengenharia e, a partir deles, criar padres
disponveis para uso em novos projetos. Segundo os autores,
a vantagem da utilizao de padres de reengenharia em
auxlio aplicao de metodologias, vem do fato de que em
estudos conduzidos atualmente, nos quais se busca desenvolver metodologias de reengenharia, a obteno de resultados
tm sido extremamente dificultada pelo fato destas terem
que ser suficientemente genricas. Padres de reengenharia
so propostos como maneira de codificao e disseminao
de boas prticas de reengenharia de software, facilitando a
compreenso e a utilizao das metodologias existentes.
H muitos sistemas modernos originalmente bem construdos de forma orientada a objetos ou baseados em componentes, porm de difcil manuteno pelo fato de sua estrutura ter
se tornado obscura por modificaes de vrios anos. Nesse
caso, a reengenharia pode ser uma soluo atrativa como

forma de reestruturao, mas a dificuldade em encontrar
especialistas para a realizao desse processo dificulta a
adoo dessa soluo. O desenvolvimento de novos materiais
e tcnicas poderia minimizar esse problema. Como contribuio, foram criados padres de reengenharia, que podem
ser utilizados como um modo de transferir conhecimentos,
dada a pouca quantidade de bibliografia nessa rea, em
comparao com as disponveis sobre o desenvolvimento
de sistemas.
Os padres funcionam como unidades auxiliares na transferncia de conhecimento por serem pequenos e especficos, a
ponto da comunidade de especialistas poder valid-los efetivamente. O formato adotado por muitos autores para descrio
dos padres propostos foi: Nome, Contexto, Problema, Soluo e Consequncias. O tamanho reduzido de cada padro
torna possvel sua utilizao em complemento s metodologias
adotadas, porm no eliminam a necessidade do uso das mesmas, mas influenciam e so influenciados por elas.
Os padres de reengenharia apresentados tm por objetivo
comum o aumento da facilidade da implementao desse
processo, dada a forma padronizada e bem documentada
dos grupos que o descrevem. Desse modo, prev-se a melhor
aplicabilidade por parte do engenheiro de software e, consequentemente, maior qualidade dos produtos gerados, ou
seja, do software orientado a objetos resultante.
Item
Descrio
Nome do Padro
Utiliza-se uma pequena sentena contendo um verbo que enfatiza o tipo de transformao de reengenharia
Intuito
Uma descrio do processo, juntamente com o resultado e por que o mesmo desejvel
Aplicabilidade
Motivao
Estrutura
Processo
Indica quando o padro aplicvel ou no. Esta seo inclui:

uma lista de sintomas: experincias na ocorrncia de reuso, manuteno ou mudanas no sistema
uma lista de metas da reengenharia: qualidades aperfeioadas por meio da aplicao do padro
uma lista de padres relacionados
Apresenta um exemplo concreto, o qual tem por objetivo familiarizar o leitor para que este entenda melhor a apresentao mais abstrata do problema que segue nas
sees Estrutura e Processo. O exemplo deve explicar claramente a estrutura do sistema de legado existente, a estrutura do sistema aps submetido ao processo de
reengenharia e a relao entre os dois, alm de descrever seu estado antes e depois da aplicao do padro
Descreve a estrutura do sistema antes e depois da reengenharia. So identificados os Participantes e as Colaboraes. Nessa seo tambm so discutidas as vantagens
e desvantagens da estrutura alvo em comparao estrutura inicial
Esta seo subdividida em trs partes: Deteco, Receita e Dificuldades. Sabe-se que o cdigo, frequentemente, indica ao engenheiro de software onde est o problema
e o processo de reengenharia deve ter como objetivo evitar que o cdigo resultante da reengenharia no obstrua o desenvolvimento adicional. Porm, h casos em que
pode ser interessante descobrir automaticamente onde podem ser aplicados padres diferentes.
A seo Deteco descreve mtodos e ferramentas para descobrir quando o cdigo est sofrendo com problemas realmente srios em que o processo escolhido pode
ajudar a aliviar ou a resolver estes problemas.
A seo Receita diz como realizar a reengenharia e suas possveis variantes.
Discusso
Questes Especficas da Linguagem
A seo Dificuldades discute situaes em que a reengenharia impossvel ou sua aplicao comprometida por outros problemas existentes.
Nesta seo, avaliada a relao entre o custo e o benefcio da aplicao do padro. A soluo legada comentada para mostrar por que tal soluo era boa num dado
perodo de tempo, mas insuficiente ou inadequada para o problema atual. Discute-se qual o custo para detectar este problema, sua magnitude e o benefcio da aplicao
do padro. Esta discusso deve ajudar o engenheiro de software a decidir se a aplicao do padro ou no vivel neste caso especfico
Lista o que, especificamente, deve ser solucionado para cada linguagem, verificando-se quais as dificuldades e facilidades encontradas em cada uma
Tabela 2. Formato para os Padres de Reengenharia
51

D
s
que tanto o processo como o produto gerado com a aplicao

do processo de reengenharia tenham qualidade, ou seja, contemplem todos os requisitos existentes no software legado.
Isto pode ser alcanado aplicando as diversas estratgias de
melhoria da qualidade e modelos de maturidade do processo
de desenvolvimento, tais como o SPICE, PDCA, SW-CMM,
dentre outros tantos.
Alm disso, utilizando a UML, o engenheiro de software
capaz de prover os modelos de anlise e projeto do software
durante sua reengenharia. Pelo fato de haver vrias ferramentas de modelagem UML, a documentao gerada a partir delas
pode facilmente ser detalhada, expandida ou melhorada.
Feedback
eu
Referncias
1. (CHIKOFSKY, 1990) CHIKOFSKY, J. E.; CROSS, J. H. Reverse Engineering and Design Recovery: A
Taxonomy. IEEE Software. Volume 7, nmero 1, pginas 13-17. 1990.
nfase na Garantia da Qualidade. Dissertao de Mestrado em Computao. Departamento de

Computao. Universidade Federal de So Carlos So Carlos/SP. 2002.
2. (COLEMAN, 1994) COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H. and HAYES, F.
Object-Oriented Development The Fusion Method. Prentice Hall. ISBN 0133388239. 1994.
12. (PENTEADO, 1996a) PENTEADO, R. A. D. Um mtodo para Engenharia Reversa Orientada a

Objetos. Tese (Doutorado em Fsica Computacional). Instituto de Fsica de So Carlos, Universidade
de So Paulo So Carlos/SP. 1996a.
3. (CORTES, 2001) CORTS, M. L.; CHIOSSI, T. C. S. Modelos de Qualidade de Software. Srie Ttulos em
Engenharia de Software. Editora da Unicamp. Instituto de Computao. 2001.
4. (COSTA, 1996) COSTA, R. J.; SANCHES, R. Ferramentas de Engenharia Reversa no Apoio Qualidade
de Software. Relatrio Tcnico n 45, ICMC-USP So Carlos. 1996.
5. (DEMEYER et al., 1999) DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. A Pattern Language for Reverse
Engineering. Proceedings of the 4th European 5th European Conference on Pattern Languages
of Programming and Computing. Paul Dyson (Ed.) Universittsverlag Konstanz GmbH, Konstanz,
Germany. July 1999.
6. (DEMEYER et al., 2000) DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. A Pattern Language for Reverse
Engineering. Proceedings of the 5th European Conference on Pattern Languages of Programming
and Computing. Andreas Rping (Ed.). 2000.
7. (DEMEYER et al., 2000b) DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. Tie Code and Questions: a
Reengineering Pattern. Proceedings of the 5th European Conference on Pattern Languages of
Programming and Computing. Andreas Rping (Ed.). Pginas 209-217. 2000b.
8. (DUCASSE, 1999) DUCASSE, S.; RICHNER, N.; NEBBE, Two Reengineering Patterns: Eliminating Type
Checking. In Proceedings of 4th European Conference on Pattern Languages of Programming and
Computing. Paul Dyson (Ed.). UVK Universittsverlag Konstanz GmbH, Konstanz, Germany. July 1999.
9. (DUCASSE, 1999) DUCASSE, S.; RICHNER, N.; NEBBE, Type Checking Elimination: Two Object
Oriented Reengineering Patterns. In Proceedings of 6th Working Conference on Reverse
Engineering). IEEE Computer Society Press, pginas 157-168. 1999.
10. (JACOBSON, 1991) JACOBSON, I.; LINDSTRM, F. Re-engineering of Old Systems to an Object
Oriented Architecture. SIGPLAN Notices. Volume 26, nmero 11, pginas 340-350. 1991.
11. (LEMOS, 2002) LEMOS, G. S. PRE/OO Um Processo de Reengenharia Orientada A Objetos com
52
13. (PENTEADO, 1998b) PENTEADO, R. A. D.; BRAGA, R. T. V.; MASIERO, P. C. Improving the Quality of
Legacy Code by Reverse Engineering. IV International Conference on Information Systems Analysis
and Synthesis. Orlando, Flrida. Pginas 364-370. 1998b.
14. (PENTEADO, 1998) PENTEADO, R. A. D.; MASIERO, P. C.; BRAGA, R. T. V.; PRADO, A. F. Reengineering
of Legacy Systems Based on Transformations Using the Object Oriented Paradigm. V Working
Conference on Reverse Engineering IEEE. Honolulu, Hawaii. Pginas 144-153. 1998.
15. (PENTEADO, 1999) PENTEADO, R. A. D.; MASIERO, P. C.; CAGNIN, M. I. An Experiment of Legacy
Code Segmentation to Improve Maintainability. III European Conference on Software Maintenance
and Reengineering IEEE. Amsterd, Holanda. Pginas 111-119. 1999.
16. (POOLEY, 1998) POOLEY, R.; STEVENS, P. Software Reengineering Patterns. 1 SEBPC Legacy
Systems Workshop. Grey College, University of Durham, February 1998.
17. (PRESSMAN, 2006) PRESSMAN, R. S. Engenharia de Software. McGraw-Hill Higher Education. 2006.
18. (RECCHIA, 2002) RECCHIA, E. L. Engenharia Reversa e Reengenharia Baseada em Padres.
Dissertao (Mestrado em Cincia da Computao). Programa de Ps-Graduao em Cincia da
Computao, Universidade Federal de So Carlos So Carlos/SP. Junho 2002.
19.(RECCHIA, 2002) RECCHIA, E.L.; PENTEADO, R.A.D.FaPRE/OO: Uma Famlia de Padres para Reengenharia
Orientada a Objetos de Sistemas Legados Procedimentais.SugarloafPLoP2002 The Second Latin American
Conference on Pattern Languages of Programming.Itaipava, Rio de Janeiro.Agosto, 2002.
20. (REKOFF, 1985) REKOFF, M. G. Jr. On Reverse Engineering. IEEE Trans. Systems, Man, and
Cybernetics. Volume maro-abril, pginas 244-252. 1985.
21. (SOMMERVILLE, 2007) SOMMERVILLE, I. Engenharia de Software. 8 Edio. Addison Wesley
Publishing Co. 2007.
sobre e
s
No existe na literatura um processo nico, definido e documentado para a conduo da reengenharia orientada a objetos.
Dessa forma, a partir dos trabalhos [6] [19], observou-se que
padres podem ser elaborados para direcionar o engenheiro
de software na conduo desse processo por tratar-se de uma
forma til e didtica de descrever seus passos e atividades.
A importncia da engenharia reversa dentro do processo de
reengenharia para o aumento da manutenibilidade de sistemas legados, pelo fato de se gerar toda a sua documentao,
muitas vezes inexistente ou desatualizada. Com a recuperao
da documentao de sistemas legados atravs da engenharia
reversa, pode-se obter ganhos significativos de entendimento
do software auxiliando na etapa de manuteno. Em seguida,
com o processo de engenharia avante do produto possvel
prover a sua implementao em plataformas, ambientes e/ou
paradigmas mais modernos.
A qualidade de processo, atualmente bastante referenciada
em se tratando do processo de desenvolvimento de software,
deve ser considerada pelo fato da importncia de se garantir
edio
ta
Concluso
Engenharia
A importncia da Engenharia de Requisitos

Fator crtico para o sucesso do projeto de desenvolvimento de software

Neste artigo veremos que unindo a Engenharia de
Requisitos a bons processos de qualidade poderemos
minimizar de maneira substancial o risco do fracasso
do projeto.
de suas atividades. A leitura prover tambm um

conhecimento inicial em relao Engenharia de
Requisitos e o resumo dos melhores processos de
qualidade utilizados nos dias de hoje.

Para que serve?
Esse artigo destina-se a profissionais das reas de
Requisitos e Qualidade, que buscam cada vez mais o
entendimento de melhores prticas para a melhoria
Helder Vincius Fernandes de

Oliveira
heldervinicius@gmail.com
Graduado em Sistemas de Informao,

Ps-Graduado em Engenharia de Software com nfase em Gerencia de Projetos,
IBM Certified Solution Designer IBM
Rational Unified Process V7.0, Analista de
Requisitos.
m um projeto de software o Levantamento de Requisito a etapa

onde ocorre a busca do entendimento, documentao, conhecimento do
fluxo de trabalho e detalhamento de todos
os objetivos que buscam ser alcanados.
Nesta etapa uma grande quantidade de
conhecimento tcnico por parte do cliente
utilizada, e todo requisito captado
armazenado para ser utilizado em todas
as fases do desenvolvimento.
Esse tema til para profissionais que atuam

no desenvolvimento de software e identificam
problemas nos requisitos elicitados que acabam
contribuindo para o fracasso do projeto.
Apesar das inovaes advindas da

Engen haria de Software, grandes
projetos de desenvolvimento continuam sendo abandonados no meio
do caminho, e os ndices de fracasso
continuam a assolar grandes companhias de desenvolvimento. Muitos
desses fracassos ocorrem devido a
falhas nos processos seguidos pelas
instituies e da pouca importncia
dada fase de anlise.
Contedo Multimdia!
Neste artigo voc encontra o vdeo:
Engenharia de Requisitos
Para ter acesso esse artigo na ntegra acesse o leitor digital:
53
Engenharia
Variabilidade em Linha de Produto de Software

Como identificar, delimitar e representar variabilidade nos principais
modelos UML de uma linha de produto de software
Neste artigo veremos o conceito de variabilidade em

linha de produto de software e como possvel identificar, delimitar e representar variabilidades por meio
de modelos UML.
Pesquisadores e gerentes/arquitetos de software

que pretendem adotar ou esto em processo de
transio do modelo tradicional de desenvolvimento de produtos individuais para a abordagem
de linha de produto de software. Alm disso, tambm devem ser consideradas as organizaes que
j possuem uma linha de produto, mas no realizam efetivamente a atividade de gerenciamento
de variabilidades.
Para que serve?

Edson A. Oliveira Junior
edson@edsonjr.pro.br
Doutor em Cincia da Computao pelo Instituto de Cincias Matemticas e de Computao (ICMC) da Universidade de So Paulo
(USP). Pesquisador ativo na comunidade
de Engenharia de Software, tendo como
temas principais: processo de software, linha de produto de software, arquitetura de
software e avaliao, mtricas de produto
e processo, engenharia de software experimental, modelos e metamodelos UML e
Model-Driven Engineering (MDE). Possui
vrios artigos em peridicos e conferncias
de destaque na rea. Possui as certificaes
Java: SCJA, SCJP, SCJD e SCWCD.
Introduzir o conceito de variabilidade em linha de

produto de software, bem como fornecer uma forma
de identificar, delimitar e representar variabilidade
usando uma notao amplamente consolidada tanto
na academia como na indstria.
este artigo veremos como

possvel identificar, delimitar
e representar variabilidade em
modelos de casos de uso, classes e componentes de linha de produto de software
(LP) baseados na notao UML (Unified
Modeling Language). Para tanto, utilizaremos a LP Arcade Game Maker (AGM)
do Software Engineering Institute (SEI) para
ilustrar os respectivos conceitos.
Linha de produto de software

A abordagem de linha de produto
de software (LP) vem se consolidando
com o passar dos anos como uma forma efetiva de reutilizao de artefatos
de software tanto na indstria quanto
na academia [2][6][11]. Vrias so as
abordagens existentes na literatura que
visam melhoria do processo de adoo
e desenvolvimento de LP.
Contedo Multimdia!
Neste artigo voc encontra o vdeo:
Reutilizao de Software
Para ter acesso esse artigo na ntegra acesse o leitor digital:
54
Engenharia de Software Magazine - Variabilidade em Linha de Produto de Software
reutiliz a o
55

Edição33 2011

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Edição33 2011

Caricato da

Copyright:

Formati disponibili

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

software como uma abordagem sistemtica, disciplinada e quantificvel para o

A engenharia de software surgiu inicialmente mais como uma promessa do

ceitos terem evoludo.

cia do significado do termo, constitui passo fundamental para o estudo e apro-

Este artigo foca na discusso sobre as dificuldades encontradas na realizao

de um estudo de observao que foi conduzido com o objetivo de verificar

empenhada no desenvolvimento de software comercial. Alm disso, apresen-

identificados pelo estudo de caso, e aqueles registrados no passado, buscan-

Alm desta matria, esta edio traz mais sete artigos:

os problemas de manuteno de software existentes em uma organizao

Mtodo de Anlise e Projetos em SOA

Fale com o Editor!

Desejamos uma tima leitura!

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

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

08 - Refatorao para Padres Parte 6

34 - Dificuldades e Problemas Encontrados na Manuteno de Software

46 - Reengenharia de Software Orientado a Objetos

53 - A importncia da Engenharia de Requisitos

54 - Variabilidade em Linha de Produto de Software

Edio 05 - Engenharia de Software Magazine

Pos trs do bvio

E se voc fosse um DVD

magine que voc seja um filme em DVD exposto em uma

Engenharia de Software - E se voc fosse um DVD numa locadora?

nome? Nos corredores corporativos seu nome sinnimo

por trs do bvio

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

D seu feedback sobre esta edio!

Edio 32 - Engenharia de Software Magazine

Todo bom filme tem que ter contedo

ele no for bom. Tudo no ter passado de uma propaganda

Todo bom filme tem uma boa campanha de divulgao

Refatorao para Padres Parte 6

De que se trata o artigo?

Para que serve?

Bacharel em Cincia da Computao FAGOC

Marco Antnio Pereira Arajo

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

uando se est criando o desenho

Engenharia de Software Magazine - Refatorao para Padres Parte 6

Em que situao o tema til?

funcionalidades que sero utilizadas a

esse cdigo de embelezamento pode atrapalhar a descoberta

O padro de projeto Decorator

Motivao: Analisando algumas classes de um sistema, pode-se

Substituir Herana por Delegao

Edio 33 - Engenharia de Software Magazine

Listagem 1. Classe Usurios.

1. public class Usuarios

public String RecuperaNomeAdministrador(Int32 id)

Listagem 2. Interface IRecuperaNomes.

1. public interface IRecuperaNomes

public interface IRecuperaNomes

Listagem 4. Modificao na declarao da classe Usurios.

1. public class Usuarios: IRecuperaNomes

No mtodo CalcularRiscoEmprestimo, classe Emprestimos,

Engenharia de Software Magazine - Refatorao para Padres Parte 6