Engenharia de Software ed35

Prévia do material em texto

www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O
PÓS-GRADUAÇÃO
Engenharia de Software: 
Desenvolvimento Java
Engenharia de Software: 
Desenvolvimento .NET
GRADUAÇÃO
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator 
SQL Server 2008
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti
A Escola Superior da Tecnologia da 
Informação oferece as melhores 
opções em cursos, formações, 
graduações e pós-graduações para 
profissionais de desenvolvimento 
e programação. 
São programas voltados para a 
formação de profissionais de elite, 
com aulas 100% práticas, corpo 
docente atuante no mercado, 
acesso à mais atualizada biblioteca 
de TI do Rio, laboratórios equipados 
com tecnologia de ponta, salas de 
estudo e exames.
r/esti
TURMAS
NO RIO DE
JANEIRO
Modéstia à parte, sua
melhor opção para
se destacar no mercado!
 
Corpo Editorial 
Colaboradores
Rodrigo Oliveira Spínola
Marco Antônio Pereira Araújo 
Eduardo Oliveira Spínola
Capa 
Romulo Araujo - romulo@devmedia.com.br
Diagramação
Janete Feitosa
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br
Revisor
Gregory Monteiro - gregory@clubedelphi.net
Caroline Velozo - carolinelopes@devmedia.com.br
Jornalista Responsável
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Ano 3 - 35ª Edição - 2011 Impresso no Brasil
“O 
sucesso de uma organização depende em grande parte sobre como ela compre-
ende por completo seus processos de negócio e como ela os realiza da forma 
mais eficaz e mais eficiente. Esses processos de negócio nas organizações podem 
estar atualmente funcionando bem, mas sem a visão da realidade, nunca se saberá quando eles 
podem representar algum perigo ou dificuldade. Uma vez que você os entende perfeitamente 
e enxerga sua realidade, é possível que você os otimize de tal forma que além de evitar que eles 
deixem de ser fonte de perigo ou dificuldades, passem a gerar resultados mais satisfatórios. Toda 
vez que você otimiza os processos de negócio da sua organização, você gera benefícios substan-
ciais para ela na forma de redução dos custos, ganho de maior eficiência, aumento da retenção 
dos seus clientes, maior satisfação dos funcionários, e, porventura, maior rentabilidade.”
“Mesmo as pequenas otimizações em processos relativamente simples podem trazer muitos 
benefícios para sua organização. Dominar o básico da otimização de processos de negócio irá 
ajudá-lo a aumentar a vantagem competitiva da sua organização e possibilitar o crescimento 
sustentável do seu negócio. Em outras palavras, irá fazer com que a sua organização deixe de ser 
apenas uma boa organização e passe a ser... uma ótima.”
Neste contexto, a Engenharia de Software Magazine destaca nesta edição o artigo “Otimização 
de Processos de Negócio usando BPM”. Neste artigo, parte de uma série que será publicado a 
partir desta edição, você irá descobrir os elementos principais para a condução de uma iniciati-
va de otimização de processos de negócio. Você irá iniciar aprendendo um pouco mais sobre a 
natureza dos processos de negócio e os benefícios adquiridos com a otimização deles. Você irá 
se familiarizar também com as características principais de uma abordagem de otimização de 
processos de negócio, além de encontrar sugestões e estratégias para a implementação de um 
projeto de otimização, incluindo o planejamento do projeto, a análise de um processo existente, 
o redesenho deste processo de negócio, a aquisição dos recursos para implementação do novo 
processo, como colocar o novo processo em produção, e, finalmente, sobre como monitorar e 
continuamente melhorar esse novo processo.
Além desta matéria, esta edição traz mais seis artigos:
• Você é um bom procrastinador?
• Implantando a gerência de configuração de software em empresas de médio porte
• Introdução à verificação de diagramas de classe – Parte 1
• Reengenharia de software orientado a objetos
• SOA - Interoperabilidade entre múltiplos sistemas
• Refatoração para Padrões – Parte 8
Desejamos uma ótima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spínola 
rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em 
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação 
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-
trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e 
Desenvolvimento Orientado a Objetos. Consultor para implementação 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.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos 
Computacionais e Bacharel em Matemática com Habilitação em Informática pela 
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação 
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em 
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, 
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
eduspinola@gmail.com
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) 
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia 
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
Apoio
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. 
Se você tiver algum problema no recebimento do seu exemplar ou precisar de 
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço 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 informações sobre veiculação de anúncio 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 sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, 
entre em contato com os editores, informando o título e mini-resumo do tema que você 
gostaria de publicar:
Rodrigo Oliveira Spínola - Colaborador
rodrigo.devmedia@gmail.com
EDITORIAL
 
 ÍNDICE
Por trás do óbvio
06 – Você é um bom procrastinador?
Glênio Cabral
Desenvolvimento
07 - SOA - Interoperabilidade entre múltiplos sistemas
Leandro Wong Kong San e Marco Antônio Pereira Araújo 
18 - Refatoração para Padrões – Parte 8
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo 
Engenharia
28 - Introdução à verificação de diagramas de classe – Parte 1 
Waldemar Pires Ferreira Neto
38 - Reengenhariade software orientado a objetos 
Giuliano Prado de Morais Giglio e Gizelle Sandrini Lemos
51 - Otimização de Processos de Negócio usando BPM – Parte 1
Ricardo S. Ferreira 
Tipo: Processo 
Título: Especificação de casos de uso na prática – Partes 21 a 25
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Definir requisitos não é uma atividade trivial. Uma das 
formas de realizar esta atividade é através da especificação de casos de 
uso. Neste sentido, nesta série de vídeo aulas apresentaremos um conjunto 
de especificações de casos de uso. Os cenários serão especificados passo 
a passo considerando tópicos como fluxo principal, fluxo alternativo e 
regras de negócios.
Caro Leitor, 
Para esta edição, temos um conjunto de 5 vídeo aulas. 
Estas vídeo aulas estão disponíveis para download no Portal 
da Engenharia de Software Magazine e certamente trarão 
uma significativa contribuição para seu aprendizado. A lista 
de aulas publicadas pode ser vista abaixo:
Edição 05 - Engenharia de Software Magazine 5 
6 Engenharia de Software - E se você fosse um DVD numa locadora?
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-
co. Idealizador do site de educação infantil www.novainfancia.com.br.
Você é um bom procrastinador?
Por trás do Óbvio
Dê seu feedback sobre esta edição!
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, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Procrastinar é algo ruim? No que depender do famoso ditado “nunca deixe para fazer amanhã o que se pode fazer hoje”, sim. No entanto, o ato de empurrar com a 
barriga determinadas tarefas do dia-dia é muito mais comum 
do que se pode imaginar. E há uma boa razão para isso: nem 
todos conseguem administrar bem o seu tempo no contexto 
agitado em que vivemos.
Por isso considero que talvez a grande questão não seja como 
desenvolver hábitos e práticas visando a não procrastinação. 
Talvez o “X” da questão seja como procrastinar bem. Isso mes-
mo, há a boa procrastinação, e praticá-la é uma grande arte.
Mas se há uma boa procrastinação, concluímos que há uma 
má. Então, o que caracteriza a má procrastinação?
Os maus procrastinadores costumam adiar tarefas e ativi-
dades sem nenhum tipo de critério. Todos nós temos uma 
infinidade de atividades no dia-dia e algumas, naturalmente, 
são mais urgentes que outras. O mau procrastinador adia 
para depois atividades muitas vezes urgentes e que exigem 
uma prioridade maior. Ou seja, ele não tem critérios para 
estabelecer o que pode e o que não pode ser prorrogado. Para 
piorar ainda mais a situação, o mau procrastinador não sabe 
a hora de parar de procrastinar. Ele simplesmente entra numa 
espécie de transe e se deixa levar pelo torpor causado pela 
procrastinação, esquecendo-se de todos os prazos e metas 
que envolvem suas ações. Resultado? Estresse, sensação de 
incompetência e desmotivação. 
Mas há bons procrastinadores. Diferentes dos maus, os ar-
tistas da boa procrastinação sabem identificar com maestria 
as atividades que podem e que não podem ser adiadas. Por 
isso, mesmo empurrando algumas ações com a barriga, sabem 
fazê-lo sem prejudicar as execuções das prioridades. Talvez 
isso explique porque os bons procrastinadores nunca são tidos 
como incompetentes, uma vez que dão conta das atividades 
essenciais. Além disso, os bons procrastinadores têm um 
dom incomparável: sabem o momento exato de parar com a 
procrastinação. É como se de alguma forma desenvolvessem 
a habilidade de no momento certo parar de procrastinar, 
conseguindo assim concluir determinadas tarefas a tempo. 
Isso, naturalmente, exige sensibilidade, atenção e uma boa 
dose de estresse. 
Não há como negar que o bom mesmo é evitar este tipo de 
comportamento. Afinal, até mesmo os bons procrastinadores 
sofrem com os efeitos colaterais de suas ações. Um deles, como 
já foi dito, é o alto grau de estresse que envolve o término das 
atividades. Como sempre vão deixando pra depois, concluir 
atividades num curto espaço de tempo é por demais desgastan-
te. Além disso, os bons procrastinadores também sofrem com 
a culpa de não terem aproveitado corretamente o seu tempo. E 
não há coisa pior do que termos a sensação de que desperdiça-
mos nosso tempo com atividades nada produtivas. 
Por isso, que possamos procrastinar cada vez menos para 
aproveitarmos melhor as 24 horas que compõem nossos dias. 
Mas se a correria do cotidiano tornar a procrastinação inevi-
tável, lembre-se: seja um bom procrastinador. Afina de contas, 
antes tarde do que nunca.
Edição 35 - Engenharia de Software Magazine 7 
Leandro Wong Kong San
leandrowks@gmail.com
Bacharel em Sistemas de Informação pela 
Faculdade Metodista Granbery. Atua como 
desenvolvedor de aplicações Desktop em C# e 
atualmente está cursando MBA na FGV.
Marco Antônio Pereira Araújo 
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas 
e Computação pela COPPE/UFRJ, Especialista 
em Métodos Estatísticos Computacionais e 
Bacharel em Informática pela UFJF, professor 
dos Cursos de Bacharelado em Sistemas de 
Informação do Centro de Ensino Superior 
de Juiz de Fora, da Faculdade Metodista 
Granbery e da Universidade Severino Som-
bra, professor do curso de Bacharelado em 
Ciência da Computação da FAGOC, professor 
do Curso Superior de Tecnologia em Análise 
e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de 
Sistemas da Prefeitura de Juiz de Fora, Editor 
da Engenharia de Software Magazine.
De que se trata o artigo?
Este artigo apresenta os principais conceitos da Arqui-
tetura Orientada a Serviços (SOA - Service Oriented Ar-
chitecture) e explora a razão de utilizá-la, abordando 
também a interoperabilidade, conceito-chave de SOA 
e de sistemas distribuídos. Será apresentado como 
construir uma aplicação dentro do estilo SOA através 
da utilização de Web Services e BPEL, demonstrando 
na prática a integração entre sistemas, interoperabili-
dade e o uso de ferramentas e tecnologias para criação 
de serviços compostos.
Para que serve?
Uma importante necessidade para negócios e TI é 
a interoperabilidade, que pode ser descrita como a 
habilidade de diferentes sistemas se comunicarem 
uns com outros. A Arquitetura Orientada a Serviços é 
uma abordagem que pode oferecer interoperabilida-
de e ajudar os sistemas a permanecerem escaláveis e 
flexíveis enquanto crescem, além de melhorar o ali-
nhamento entre TI e negócio. Várias tecnologias im-
portantes e padrões têm sido definidos para suportar 
uma infraestrutura SOA. Uma das possíveis maneiras 
de implementar SOA é usando Web Services, que são 
baseados em um conjunto de padrões amplamente 
aceitos e utilizados, que cobrem a interoperabilidade. 
Em que situação o tema é útil?
SOA permite que empresas façam mudanças mais 
rapidamente quando necessário, economizando 
tempo e dinheiro. Através do alinhamento entre 
necessidades de negócio e a capacidade da TI de 
atender a essas necessidades, SOA ajuda a tornar 
a organização mais ágil através de reusabilidade, 
diminuindo o custo de desenvolvimento, integra-
ção e manutenção.
SOA
Interoperabilidade entre múltiplos sistemas
As grandes corporações de hoje querem flexibilidade, agilidade, redução de custos, 
melhora na eficiência das pessoas e dos 
processos, e responder rapidamente a 
mudanças. Desafios e oportunidades 
surgem a cada dia e as empresas de-
vem ser ágeis para redefinir e adaptar 
seu modelo de negócios, processos e es-
truturas organizacionais. Porém, existe 
o problema da lacuna entre negócio e 
a TI. A unificação de uma organização 
através do alinhamento entre TI com 
negóciotraz uma maior flexibilidade, 
aumento na agilidade e produtividade. 
A TI passa a entender profundamente 
Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes 
abordagens de apoio ao desenvolvimento de projetos de software
8 Engenharia de Software Magazine - SOA
as prioridades de negócios e as informações fornecidas pelos 
sistemas acabam sendo mais precisas e no prazo adequado. 
SOA possibilita que isto seja feito de forma a atender as neces-
sidades da organização como um todo. 
Além disso, estas empresas dependem de sistemas e apli-
cativos para funcionar e este ambiente computacional está se 
tornando cada vez mais heterogêneo e complexo. Construir, 
executar e gerenciar aplicações em um ambiente deste tipo é 
uma tarefa difícil. SOA permite que empresas façam mudanças 
mais rapidamente quando necessário, economizando tempo 
e dinheiro. Através do alinhamento entre necessidades de 
negócio e a capacidade da TI de atender a essas necessidades, 
SOA ajuda a tornar a organização mais ágil através da aplicação 
de reusabilidade, diminuindo o custo de desenvolvimento, 
integração e manutenção.
O reuso de aplicações pode ser feito através da combinação 
de vários serviços expostos pelas aplicações existentes. Os de-
senvolvedores não precisam criar aplicações totalmente novas, 
reduzindo o tempo do processo de desenvolvimento. E como 
SOA é baseado em padrões, os desenvolvedores não precisam 
gastar tempo aprendendo as várias novas tecnologias que sur-
gem a cada dia. Isto significa redução nos custos da empresa ao 
deixar de comprar novas aplicações e na contratação de desen-
volvedores com algum conhecimento novo ou específico.
Assim, SOA é uma estratégia que inclui aspectos técnicos 
e organizacionais. No mundo da computação distribuída, 
processos de negócios são distribuídos e é necessário que haja 
interoperabilidade entre diferentes sistemas.
Interoperabilidade
Muitos sistemas em uma grande empresa não foram de-
senvolvidos para serem capazes de se comunicar com outros 
sistemas. Eles foram desenvolvidos com interfaces, protocolos 
proprietários e formas de comunicação diferentes dificultando 
muito a integração. Para permitir que aplicações empresariais 
possam se comunicar, são utilizados padrões e formatos de ar-
quivos entre os sistemas. Isso pode ser bom para algum tipo de 
integração pequena, mas pode ser inviável quando o número 
de aplicações a serem integradas se torna grande. A Figura 1 
mostra os problemas com a integração tradicional.
A Figura 1 mostra que, para que um sistema se comunique 
com o outro, o integrador de sistemas teria que aprender novas 
tecnologias e novas Interfaces de Programação de Aplicativos 
(APIs) de cada sistema para que pudesse realizar a integração. 
Para integrar dois ou três sistemas, não haveria muito proble-
ma, porém a integração de vários sistemas seria complicada.
Estas mesmas empresas possuem sistemas novos e os chama-
dos sistemas legados, distribuídos em um cenário de alta he-
terogeneidade tecnológica. Interoperabilidade é um requisito 
fundamental em um ambiente desses. Segundo Josuttis (2008), 
“interoperabilidade é a habilidade dos sistemas diferentes se 
comunicarem uns com os outros”.
Existem várias abordagens para construir sistemas que aten-
dam aos requisitos da interoperabilidade. Uma delas é SOA. Na 
visão de SOA, a interação entre clientes e serviços fracamente 
acoplados demonstra ampla interoperabilidade. Esse é o objetivo 
desta arquitetura: interoperabilidade entre diferentes platafor-
mas e linguagens de programação. Clientes e serviços devem 
se comunicar e se entender independente da plataforma. Para 
isso, devem usar uma forma padronizada de se comunicar. Com 
o advento do XML e da sua grande aceitação, os sistemas, hoje, 
podem ser integrados mais facilmente. Os sistemas passam a 
“conversar” utilizando a mesma “linguagem”.
Serviços
Um dos elementos principais da arquitetura SOA são os 
serviços. Um serviço fornece uma funcionalidade específica 
de negócio como criar um cliente, analisar o histórico de cré-
dito de uma pessoa, transferir dinheiro, e assim por diante. 
Um serviço pode fornecer uma funcionalidade distinta, como 
converter um tipo de moeda em outro, ou realizar um conjunto 
de funcionalidades, como manipular várias operações em um 
sistema de reservas aéreas. Uma arquitetura orientada a ser-
viços é uma forma de compartilhar serviços de uma maneira 
generalizada e flexível.
Uma grande empresa, por exemplo, pode ter softwares de 
diferentes fabricantes, como SAP, BEA, Microsoft, e algumas 
funcionalidades desses softwares podem ser úteis no negó-
cio para outras entidades como fornecedores ou clientes. A 
empresa pode aproveitar esses sistemas e disponibilizá-los 
como serviços. 
Tecnicamente, um serviço é uma descrição de uma ou mais 
operações em que são usadas mensagens para trocar dados 
entre um fornecedor (também chamado de provedor) e um 
consumidor (também chamado de requisitante). Um forne-
cedor é um sistema que implementa um serviço de tal forma 
que outros sistemas possam chamá-lo. Um consumidor é um 
sistema que chama um serviço. Os serviços são conectados a 
outros serviços usando um método de trocas de mensagens 
(Figura 2) baseado em documentos XML. O consumidor de 
serviço pode enviar uma mensagem de requisição para o 
fornecedor do serviço e aguardar que o fornecedor envie uma 
mensagem de resposta (Figura 2).
Na orientação a serviços são utilizados padrões baseados 
em protocolos e interfaces convencionais - normalmente Web Figura 1. Sistemas com protocolos proprietários
Edição 35 - Engenharia de Software Magazine 9 
ARQUItEtUR A
Services - para facilitar o acesso à lógica de negócios e infor-
mações existentes nos serviços. Deve-se lembrar que Web 
Services são uma das possíveis maneiras de implementar uma 
infraestrutura SOA, pois SOA não está vinculada a nenhuma 
tecnologia específica.
Características dos serviços
Para o uso efetivo dos serviços seguem algumas caracterís-
ticas principais:
• Os serviços devem ser independentes. Um serviço indepen-
dente “é um serviço cuja capacidade de funcionar não é con-
trolada nem inibida por outros serviços”. Essa autonomia faz 
com que os serviços se adaptem mais facilmente a mudanças 
em termos de disponibilidade e escalabilidade.
• Os serviços não devem ter estado (stateless), ou seja, não devem 
gerenciar suas informações de estado, caso contrário, deixaria 
de ter fraco acoplamento. “[..] todos os dados da instância do 
serviço (processo ou thread) que executam a chamada são des-
cartados após a chamada” (JOSUTTIS, 2008). Nenhum estado é 
mantido quando há diferentes chamadas de serviço.
• Os serviços devem ter a capacidade de se compor. Compo-
sição é o processo no qual os serviços são combinados para 
produzir aplicações compostas ou serviços compostos. Isto 
permite que a lógica seja representada em diferentes níveis 
de granularidade e promove a reusabilidade na criação de 
camadas de abstração. 
A Figura 3 mostra um exemplo de composição de serviços 
onde três serviços são combinados para formar um único 
serviço.
Assim que os serviços são criados, eles podem ser combi-
nados em serviços mais complexos, aplicações ou processos 
de negócios entre funções. Como os serviços existem inde-
pendentemente uns dos outros, ou da infraestrutura de TI 
subjacente, eles podem ser combinados e reutilizados com total 
flexibilidade. E conforme os processos de negócios evoluem, as 
práticas e regras de negócios podem ser ajustadas sem sofrer 
limitações das aplicações subjacentes.
Figura 2. Troca de mensagens entre provedor e consumidor de serviços
Figura 3. Aplicações compostas
Os serviços devem ter a capacidade de serem descobertos, ou 
seja, devem ser visíveis, permitindo que consumidores locali-
zem e descubram serviços reutilizáveis.Para isso, deve-se ter 
uma infraestrutura para ajudar a organizar e descobrir servi-
ços. Esta infraestrutura são os repositórios e os registros.
Os serviços devem ser reutilizáveis (Figura 4), ou seja, de-
vem ser serviços autônomos, sem estado (stateless), passíveis 
de descoberta e que podem ser parte de uma aplicação ou 
serviço composto. 
Os serviços devem ter acoplamento fraco, ou seja, devem ter 
a capacidade de serem combinados para a criação de serviços 
compostos e serem facilmente descombinados em seus compo-
nentes funcionais. Isto pode ser conseguido, segundo Bechara 
(2010), limitando dependências, escondendo as implementa-
ções do consumidor através do encapsulamento das funciona-
lidades do serviço de uma maneira que as mudanças feitas em 
uma aplicação causem menos impacto em outras aplicações. 
Em grandes sistemas distribuídos, reduzir as dependências 
Figura 4. Serviços reutilizáveis
10 Engenharia de Software Magazine - SOA
leva a uma melhor escalabilidade, flexibilidade e tolerância às 
falhas. Assim, modificações ou as falhas de um sistema terão 
menos consequências em outros sistemas.
BPEL
Quando o processo de negócio é um processo executado 
apenas por mecanismos computacionais, ou seja, apenas por 
serviços automatizados que representam algum valor para a 
empresa, chega-se à tecnologia chamada BPEL (Linguagem de 
Execução de Processos de Negócio). Em projetos de adoção de 
SOA, chega-se a um momento em que os serviços existentes 
em uma organização são usados para compor processos de 
negócio. Esses processos de negócio são transformados em 
processos executáveis, baseados no uso de um ou mais servi-
ços. Usando BPEL, pode-se criar novos serviços baseando-se 
em serviços existentes. Esta linguagem desempenha um papel 
importante dentro da modelagem e execução dos processos de 
negócio em ferramentas e mecanismos.
O BPEL é uma linguagem baseada em XML que descreve 
cursos e sequências do negócio, ou seja, descreve processos 
executáveis. É basicamente uma linguagem para implementar 
composições de serviços. Assim, um novo Web Service é defi-
nido através da composição de um conjunto de serviços exis-
tentes. Essa composição (chamada de Processo) indica como 
a interface do serviço se encaixa dentro da execução completa 
da composição. Esta interface é descrita como uma coleção de 
portTypes WSDL e as operações suportadas podem ser do tipo 
somente entrada ou entrada-saída (request-response) .
Cada passo no processo é chamado de uma atividade. Existem 
várias atividades primitivas que são utilizadas para permitir 
a execução e a passagem de parâmetros entre as chamadas 
dos serviços. Essas atividades servem para lidar com situa-
ções comuns de programação, como declaração de variáveis, 
atribuição e cópia de valores e chamadas a serviços. Algumas 
atividades são:
• <invoke>, utilizado para invocar uma operação em algum 
Web Service;
• <receive>, para aguardar por uma mensagem para a operação 
da interface do serviço a ser invocado externamente, 
• <reply>, para gerar uma reposta de uma operação de entrada/
saída;
• <assign>, utilizado para atribuir variáveis. 
Ainda, essas atividades podem ser combinadas para formar 
algoritmos mais complexos, passando a ter a habilidade de de-
finir loops (<while>) e declarações do tipo case (<switch>). 
O BPEL não possui notação gráfica padrão e os fornecedores 
de ferramentas BPM têm criado suas próprias interpretações 
visuais. E como ler e escrever arquivos BPEL manualmente é 
tedioso e sujeito a erros, normalmente usa-se uma ferramenta 
BPEL para modelar e executar um processo.
Criando uma aplicação SOA
Para ilustrar os conceitos de SOA, procurou-se desenvolver 
um protótipo de um sistema de pagamento de cartão de crédito 
envolvendo uma loja de produtos online e a operadora de 
cartão de crédito.
Este estudo de caso tem como objetivo demonstrar a inte-
gração entre sistemas e a sua interoperabilidade utilizando a 
estratégia de Web Services dentro do estilo SOA. A interope-
rabilidade entre sistemas será demonstrada através da criação 
de dois fragmentos de sistemas utilizando as linguagens Java 
e C#.
 Será visto agora o cenário de negócio que apresenta algumas 
necessidades de integração.
A empresa fictícia PortalShop, voltada ao ramo de venda de 
produtos pela Internet, deseja incluir a forma de pagamento 
por cartões de crédito no seu portal que, atualmente, é feita 
somente por transferência bancária. O cliente que optasse por 
pagar com cartão de crédito seria redirecionado para uma pá-
gina onde entraria com o número do cartão. Neste momento, 
os dados do pedido (nome do cliente, número do cartão, valor 
do pedido e descrição) seriam incluídos no sistema da loja e 
um pedido de processamento do pagamento via cartão seria 
enviado à operadora. O resultado dessa operação seria enviado 
à loja e exibido ao cliente.
Serão criados três serviços: o primeiro, do portal, com o nome 
de ServicoCadastraPedido cadastrará o pedido no banco de 
dados do portal, o segundo, também do portal, alterará o status 
do pedido cadastrado para Autorizado ou Não autorizado e 
se chamará ServicoAlteraStatusPagto, e o terceiro, ServicoPro-
cessaCartao, da operadora, fará o processamento do cartão de 
crédito e retornará o resultado.
Esses três serviços serão combinados para formar um serviço 
que será consumido pela página do portal. A página do portal 
será a camada de interação entre o cliente e a aplicação.
Os serviços do portal e a página WEB serão criados na pla-
taforma .NET Framework, em ASP.NET (C#), e o serviço da 
operadora feito em Java. A criação de serviços compostos será 
feita utilizando BPEL.
As ferramentas utilizadas foram o GlassFish ESB v2.2, com-
posta por componentes do OpenESB e o servidor de aplicações 
Glassfish 2.1.1, a IDE NetBeans 6.7.1 e o Visual Studio 2008.
Será necessário também o uso de base de dados para a 
persistência dos dados. Para isso será usado o MySQL. Para a 
conectividade entre as aplicações .NET e o MySQL será usado 
o MySQL Connector/NET.
Implementação dos Web Services
Inicialmente, será implementado um Web Service no Visual 
Studio. Um Web Service em .NET consiste em uma página 
.asmx que contém a funcionalidade do Web Service, ou seja, 
a sua implementação. Depois que a página .asmx é criada e 
publicada em um servidor .NET, o Web Service passa a ser 
acessível através da WEB. 
O .NET provê uma página de informações muito útil sobre o 
Web Service criado mostrando todos os métodos, parâmetros 
e informações sobre como acessar o Web Service através da 
web. Esta página também oferece uma área onde o Web Service 
pode ser testado.
Edição 35 - Engenharia de Software Magazine 11 
ARQUItEtUR A
O primeiro serviço (ServicoCadastraPedido) disponibilizado 
pelo portal realizará apenas o cadastro do pedido no banco 
de dados do Portal. Este serviço recebe como parâmetros o 
nome do cliente, o número do cartão, o valor do pedido e a 
sua descrição. Após o cadastro, o serviço retornará o número 
do pedido.
A primeira coisa a fazer para implementar um Web Service 
é criar uma classe com todo o seu escopo. Essa classe deve ter 
os métodos que serão expostos pelo Web Service, isto é, terá a 
implementação do serviço. O código-fonte da classe Servico-
CadastroPedido é mostrado na Listagem 1.
O atributo [WebMethod] informa que o método será exposto 
pelo Web Service. O método CadastrarPedido insere os dados 
no banco de dados e retorna o número do pedido que é o 
número da linha do registro inserido. Na Figura 5, além da 
página de informações sobre o serviço, tem-se o exemplo da 
mensagem SOAP que o serviço deve receber e a mensagem 
que é retornada.
O segundo Web Service, feito também em .NET, apenas al-
terará o status de pagamento de um pedido. Este Web Service 
recebe como parâmetros o número do pedidoe uma string 
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Linq;
using MySql.Data.MySqlClient;
namespace WebServiceCadastraPedido
{
 [WebService(Namespace = “http://monografia.org/”)]
 [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
 [ToolboxItem(false)]
 public class ServicoCadastraPedido : System.Web.Services.WebService
 {
 [WebMethod]
 public int CadastrarPedido(string numeroCartao, double 
 valorPedido, string nomeCliente, string descricaoPedido)
 {
 String _conexaoMySQL = “”;
 MySqlConnection con = null;
 int idPedido = 1;
 
 _conexaoMySQL = “datasource=localhost; 
 username=root;password=123456;database=portalshop”;
 try
 {
 String sql = “INSERT INTO pedidos (numeroCartao, valorPedido, 
 nomeCliente, descricaoPedido, statusPagto)” +
 “VALUES (@numeroCartao, @valorPedido, @nomeCliente, 
 @descricaoPedido, @status)”;
 con = new MySqlConnection(_conexaoMySQL);
 MySqlCommand cmd = new MySqlCommand(sql, con);
 cmd.Parameters.AddWithValue(“@numeroCartao”, numeroCartao);
 cmd.Parameters.AddWithValue(“@valorPedido”, valorPedido);
 cmd.Parameters.AddWithValue(“@nomeCliente”, nomeCliente);
 cmd.Parameters.AddWithValue(“@descricaoPedido”, 
 descricaoPedido);
 cmd.Parameters.AddWithValue(“@status”, “Aguardando 
 pagamento”);
 con.Open();
 cmd.ExecuteNonQuery();
 String sql2 = “SELECT idpedido FROM pedidos ORDER BY idpedido 
 DESC LIMIT 1”;
 MySqlCommand cmd2 = new MySqlCommand(sql2, con);
 MySqlDataReader reader = cmd2.ExecuteReader();
 while (reader.Read())
 {
 idPedido = reader.GetInt32(0);
 }
 reader.Close();
 }
 catch (Exception ex)
 {
 throw ex;
 }
 finally
 {
 con.Close();
 }
 return idPedido;
 }
 }
}
Listagem 1. ServicoCadastroPedido
Figura 5. Página com informações sobre o serviço que cadastra o pedido 
e exemplo da mensagem SOAP
12 Engenharia de Software Magazine - SOA
que é o valor retornado pelo serviço disponibilizado pela 
operadora de cartão. A Listagem 2 mostra o código-fonte da 
classe ServicoAlteraStatusPagto.
Este serviço altera o status do pedido com a string enviada 
pelo consumidor deste serviço e retorna o valor “OK” caso a 
operação seja feita com sucesso.
Este serviço também pode ser reutilizado para alterar o 
status de pagamento de um pedido por uma outra aplicação. 
Um funcionário do Portal, por exemplo, pode consumir este 
serviço para alterar o status de pagamento de um pedido feito 
por transferência bancária.
Listagem 2. ServicoAlteraStatusPagto
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Linq;
using MySql.Data.MySqlClient;
namespace WebServiceAlteraStatus
{
 [WebService(Namespace = “http://tempuri.org/”)]
 [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
 [ToolboxItem(false)]
 
 public class ServicoAlteraStatusPagto : System.Web.Services.
WebService
 {
 [WebMethod]
 public string AlteraStatusPedido(int numeroPedido, string status)
 {
 String _conexaoMySQL = “”;
 MySqlConnection con = null;
 _conexaoMySQL = “datasource=localhost;username= 
 root;password=123456;database=portalshop”;
 try
 {
 String sql = “UPDATE pedidos SET statusPagto = 
 @statusPagto WHERE idpedido = @idpedido “;
 con = new MySqlConnection(_conexaoMySQL);
 MySqlCommand cmd = new MySqlCommand(sql, con);
 cmd.Parameters.AddWithValue(“@idpedido”, numeroPedido);
 cmd.Parameters.AddWithValue(“@statusPagto”, status);
 con.Open();
 cmd.ExecuteNonQuery();
 }
 catch (Exception ex)
 {
 throw ex;
 }
 finally
 {
 con.Close();
 }
 return “OK”;
 }
 }
}
Listagem 3. ServicoProcessaCartao
package br.com.integracao.portalshop;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import java.util.Random;
/**
 *
 * @author Leandro
 */
@WebService()
public class ServicoProcessaCartao {
 private Random rndObject;
 @WebMethod(operationName = “processaCartaoCredito”)
 public String processaCartaoCredito(@WebParam 
 (name = “numeroCartao”)
 String numeroCartao, @WebParam 
 (name = “valorCompra”) double valorCompra) {
 
 if (rndObject == null) {
 rndObject = new Random();
 }
 int numeroAleatorio = rndObject.nextInt(10);
 
 if (numeroAleatorio > 5) {
 return “Autorizado”;
 } else {
 return “Não autorizado”;
 }
 }
}
O terceiro Web Service (ServicoProcessaCartao) será dispo-
nibilizado pela operadora de cartão de credito. Na implemen-
tação deste serviço, foi feito apenas com que o Web Service 
criasse um número aleatório qualquer e uma condição que 
simula o resultado de processamento do cartão retornando o 
valor “Autorizado” ou “Não autorizado”. Este serviço foi feito 
em Java para demonstrar a interoperabilidade entre as duas 
linguagens. O código-fonte da classe ServicoProcessaCartao 
é mostrado na Listagem 3.
Web Services desenvolvidos em Java possuem a anotação @
WebService e a anotação @WebMethod para os métodos que 
serão disponibilizados pelo Web Service. 
Nesta implementação foi criada uma condição em que é re-
tornada uma string dependendo do número aleatório gerado. 
Caso o número aleatório fosse maior que cinco, o retorno seria 
uma string com o valor “Autorizado”, caso contrário, “Não 
autorizado”.
Também se pode testar o Web Service criado no NetBeans e 
visualizar a página de informações do serviço através de uma 
página Web (Figuras 6 e 7), como no Visual Studio.
Esses Web Services podem ser utilizados independentemente 
dos outros, além de poderem ser reutilizados em outros pro-
jetos. Porém, será demonstrada a combinação desses serviços 
para a formação de um único serviço através do uso de BPEL. 
Para isso, esses Web Services devem estar disponibilizados, 
ou seja, devem permitir aos clientes o seu acesso através da 
Edição 35 - Engenharia de Software Magazine 13 
ARQUItEtUR A
publicação das especificações das suas interfaces. Assim, deve-
se ter o caminho do arquivo WSDL de cada um. Em .NET, o 
caminho dos arquivos WSDL pode ser recuperado clicando-se 
em “descrição do serviço” na página de informações do Web 
Service. No NetBeans, o caminho do arquivo WSDL é dado 
nas propriedades do Web Service. 
Criação do processo BPEL
Com BPEL, podem-se criar novos serviços baseando-se em 
serviços existentes. Assim, têm-se serviços compostos (também 
chamados de serviços orquestrados) através da criação de um 
novo serviço. Portanto, um processo BPEL pode ser, em última 
instância, um Web Service.
O processo BPEL será criado no NetBeans e será compostapelos três Web Services e consumido pela página Web. Como 
um processo BPEL é um Web Service, com uma interface bem 
definida, um arquivo WSDL dele deve ser criado. Os tipos de 
dados para entrada e saída das mensagens do serviço devem 
ser definidos usando XSD (XML Schema Definition). Então, 
o primeiro a se fazer é criar um arquivo XML Schema que 
será usado pelo arquivo WSDL. O XML Schema é mostrado 
a Figura 8.
Nesse arquivo XML Schema, foram definidos todos os tipos 
de dados que serão trabalhados dentro do processo BPEL. 
Os tipos definidos refletem exatamente os tipos usados nos 
serviços disponibilizados.
Agora será criado um arquivo WSDL que irá definir a inter-
face do processo BPEL. Isto é necessário, pois ele será usado 
para que o consumidor do processo possa enviar mensagens 
via SOAP. 
A criação do arquivo WSDL é feita no NetBeans através de um 
assistente em que pode ser feita a importação do arquivo XML 
Schema criado anteriormente para definir os tipos de dados 
que serão consumidos. Nesse assistente também são solicita-
dos detalhes sobre as operações que este serviço do processo 
BPEL disponibilizará. Na caixa “Operation Name” será usado 
“ProcessarCartaoCredito” como o nome do método que será 
disponibilizado por este serviço. Na caixa suspensa chamada 
de “Operation Type” deve ser configurada a opção “Request-
Response Operation”, pois um dos serviços irá retornar um 
valor, informando o resultado da operação. A seção “Input” 
diz respeito ao tipo usado como entrada do método e a seção 
“Output” o valor retornado depois da execução do método. 
O processo irá receber como argumento o tipo “pedido” que 
foi definido no arquivo XML Schema e o valor de retorno do 
Figura 6. Página de teste do serviço ProcessaCartao
Figura 7. Resultado da operação ProcessaCartao
Figura 8. Arquivo XML Schema
método será baseado no tipo “ResultadoPagtoCartao”, também 
definido no arquivo de Schema. As Figuras 9 e 10 mostram 
como criar o arquivo WSDL e como configurar os parâmetros 
de entrada e saída deste método.
Depois de criar o arquivo WSDL, cria-se o processo BPEL. 
No NetBeans, após criar um projeto do tipo Módulo BPEL, é 
iniciado o designer visual de criação do processo onde se pode 
criar toda a lógica relacionada ao processo usando a notação 
BPEL sem precisar conhecer os detalhes da linguagem. 
O processo BPEL, quando finalizado, ficará conforme apre-
sentado na Figura 11.
Figura 9. Assistente para criação do arquivo WSDL
14 Engenharia de Software Magazine - SOA
Em BPEL, existem os chamados partner links. Um partner 
link é um mecanismo usado pelo BPEL para interagir com os 
serviços externos. Partners podem ser clientes que invocam o 
serviço ou Web Services externos. Conforme a Figura 11, existe 
um partner que será invocado pela aplicação cliente e três Web 
Services externos que serão invocados pelo processo.
Figura 10. Configuração dos parâmetros do Processo BPEL
Figura 11. Processo BPEL no designer do NetBeans
Para configurar os partner links, deve-se arrastar os arquivos 
WSDL de cada serviço adicionado ao projeto e o próprio WSDL 
do processo para dentro do designer. O NetBeans irá apresen-
tar uma caixa de diálogo para a criação de um novo partner 
link de cada serviço com valores padrões já configurados.
Após executar esses passos, o designer do NetBeans deverá 
apresentar quatro partner links.
Agora, para iniciar a criação da lógica do processo deve-se 
configurar um elemento chamado Receive. Um Receive é um 
componente do BPEL responsável por receber uma mensagem 
de entrada. Para isso, deve-se arrastar o elemento Receive da 
paleta de componentes até o desenho do processo. Depois 
disso, deve-se dar um duplo clique em cima do seu ícone no 
processo para ativar o Editor de Propriedades. A Figura 12 
mostra como deve ser feito este processo de configuração 
do Receive.
Agora que se tem uma entrada de dados do processo BPEL, 
deve-se definir o comportamento interno. De acordo com o que 
foi definido, o processo deverá cadastrar um pedido no banco 
de dados do Portal. Para isso, deve-se realizar uma chamada 
ao ServicoCadastraPedido. Em termos de BPEL, quando se 
quer fazer uma chamada a um serviço referenciado como 
um partner link, deve-se usar o elemento Invoke. Para isso, 
arrasta-se o elemento Invoke de forma que ele fique abaixo do 
elemento Receive. A configuração deste elemento é mostrada 
na Figura 13.
Até este momento, o processo irá receber um parâmetro 
de entrada, que será uma instância do tipo Pedido e, depois, 
fará uma chamada ao serviço que cadastra o pedido passado 
como parâmetro. Em seguida, o processo deverá chamar o 
serviço da operadora de cartão para processar o pagamento 
do pedido. Para isso, deve-se arrastar outro elemento Invoke 
para dentro do designer de forma que fique situado abaixo 
do último elemento Invoke adicionado. A configuração deste 
elemento é mostrada na Figura 14.
Figura 12. Configuração do elemento Receive
Figura 13. Configuração do elemento Invoke
Edição 35 - Engenharia de Software Magazine 15 
ARQUItEtUR A
O mesmo passo deve ser repetido para chamar o serviço 
que altera o status de pagamento de um pedido no banco de 
dados do Portal.
Depois de ter a lógica necessária ao cenário, configura-se um 
elemento do tipo Reply. Ele é usado para retornar algum valor 
como resposta à chamada ao processo. Para isso, deve-se ir à pa-
leta de componentes e arrastar o elemento Reply para dentro do 
designer de modo que ele fique acima do elemento Process End. 
A configuração do elemento Reply é mostrada na Figura 15.
Agora deve ser configurado como será feita a passagem de 
variáveis entre as chamadas aos serviços e o valor que será 
passado para o elemento Reply. Em BPEL, isso é feito utili-
zando o elemento Assign. Este elemento deve ser arrastado da 
paleta de componentes para dentro do designer de forma que 
fique situado entre cada elemento Invoke, depois do elemento 
Receive e antes do elemento Reply. Dando dois cliques sobre 
cada elemento Assign, é executado o BPEL Mapper para a 
configuração das passagens de variáveis. Os mapeamentos 
são mostrados nas Figuras 16, 17 e 18.
Neste primeiro mapeamento foi feito com que o conteúdo 
das variáveis populadas pela aplicação cliente, no momento 
Figura 14. Configuração do elemento Invoke chamando o serviço da 
operadora de cartão
Figura 15. Configuração do elemento Reply
Figura 16. Mapeamento do primeiro elemento Assign Figura 17. Mapeamento do segundo elemento Assign
Figura 18. Mapeamento do terceiro elemento Assign
da chamada ao processo, fosse passado na chamada ao serviço 
ServicoCadastraPedido. 
A partir deste mapeamento, o mecanismo do BPEL fará cópias 
dos valores das variáveis contidas originalmente no objeto 
“pedido” recebido pelo processo e usará estas cópias como 
16 Engenharia de Software Magazine - SOA
parâmetros de entrada ao serviço ServicoCadastraPedido.
O mesmo mecanismo de mapeamento deve ser feito para 
todas as invocações restantes do nosso modelo.
A configuração do Assignment do elemento Reply é mostra-
da na Figura 19. Foi usado um elemento do tipo Concat para 
concatenar os valores das strings retornadas por cada serviço 
Figura 19. Configuração elemento Assign responsável pelo 
carregamento da variável ProcessarCartaoCreditoOut
Listagem 4. Página ASP.NET cliente
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
public partial class _Default : System.Web.UI.Page 
{
 protected void Page_Load(object sender, EventArgs e)
 {
 }
 protected void Button1_Click(object sender, EventArgs e){
 ProcessoPagamentoCartao.Pedido pedido = new 
 ProcessoPagamentoCartao.Pedido();
 
 pedido.nomeCliente = TextBox3.Text;
 pedido.valorCompra = Convert.ToDouble(TextBox1.Text);
 pedido.numeroCartao = TextBox2.Text;
 pedido.descricaoPedido = TextBox4.Text;
 ProcessoPagamentoCartao.processoPagamentoCartao 
 PortTypeClient processamentoCartao = 
 new ProcessoPagamentoCartao.processoPagamento 
 CartaoPortTypeClient();
 
 string resultado = processamentoCartao.processoPagamento 
 CartaoOperation(pedido);
 
 Console.WriteLine(resultado);
 Label1.Text = resultado;
 }
} 
chamado. O resultado das strings concatenadas é passado à 
variável ProcessarCartaoCreditoOut. A intenção é exibir ao 
usuário o resultado de todas as operações, a saber, o cadas-
tro do pedido, o processamento do pagamento e a alteração 
do status de acordo com o resultado do processamento do 
pagamento.
Agora que se tem o processo BPEL definido, deve ser 
feito o Deploy deste processo dentro do servidor Glassfish. 
Para que o processo BPEL possa ser distribuído, deve-se 
empacotá-lo dentro de um projeto do tipo Composite Ap-
plication. Cria-se, então, um projeto de aplicação composta 
escolhendo a opção Composite Application na criação de 
um novo projeto SOA no NetBeans e coloca-se o módulo 
BPEL como sendo o módulo JBI que será distribuído dentro 
do servidor GlassFish. 
Para isso, deve-se clicar com o botão direito do mouse em 
cima do projeto criado e escolher a opção “Add JBI Module” 
e adicionar o projeto BPEL. Feito isso, tem-se o processo de 
processamento de pagamento efetivamente finalizado. Para 
fazer o deploy, deve-se clicar com botão direito do mouse em 
cima do projeto de aplicação composta e escolher a opção 
“Deploy”’. O NetBeans se encarregará de fazer o processo 
de build nos projetos e de realizar a implantação do novo 
processo BPEL dentro do servidor.
Criação do aplicativo cliente para o processo BPEL
Para consumir o processo BPEL como sendo um Web 
Service, será criada uma página Web. Essa página será a 
aplicação cliente, ou seja, será a aplicação que consumirá o 
serviço composto. A partir das mensagens que este cliente 
irá enviar para o processo, pode-se testar o comportamento 
da execução do processo BPEL. O código-fonte da classe para 
a página ASP.NET é mostrado na Listagem 4.
Nesta classe foi criado um evento que é disparado quando 
se clica no botão da página. Quando este evento é disparado, 
uma instância do tipo pedido é criada e, depois, são atribu-
ídos os valores para cada atributo do objeto. Em seguida, 
um objeto do tipo processoPagamentoCartaoPortTypeClient 
é criado e o seu método (processoPagamentoCartaoOpera-
tion()) é chamado passando como argumento o objeto do tipo 
pedido, e seu retorno é passado à variável “resultado”.
Ao receber a mensagem via SOAP, o mecanismo do Glass-
Fish inicia a criação de uma nova instância do processo. Em 
seguida, envia a mensagem de início para o processo BPEL e 
dispara o envio de uma mensagem contendo os parâmetros de 
entrada do processo, neste caso, o objeto do tipo pedido. Neste 
momento, o elemento Receive do processo BPEL se encarrega 
de desencadear o resto do fluxo lógico do processo.
Deve-se lembrar que a aplicação cliente não necessaria-
mente deve ser uma página WEB. Ela pode ser também, 
uma aplicação desktop, bastando adicionar o serviço como 
referência ao projeto.
Para a visualização dos dados e o resultado, foi criado um 
banco de dados com a tabela “pedidos”. A Figura 20 mostra 
o resultado de algumas operações.
Edição 35 - Engenharia de Software Magazine 17 
ARQUItEtUR A
Conclusão
Com a onda de novas tecnologias, de mainframes para banco 
de dados cliente/servidor, ERP, aplicações WEB, aplicações 
Java, e agora serviços, as empresas passam a enfrentar um 
mosaico de aplicações distribuídas em um grande cenário 
computacional heterogêneo. 
A Arquitetura Orientada a Serviços fornece princípios e atua 
como um guia para transformar o conjunto de recursos existen-
tes de TI heterogêneos, distribuídos, complexos e não flexíveis 
em recursos integrados, simplificados e altamente flexíveis, e 
que podem ser alterados e compostos para suportar mais obje-
tivos do negócio. Novas soluções passam a ser implementadas 
com o mínimo de impacto em outros sistemas. 
Ao encapsular a lógica de aplicações legadas, os serviços 
podem oferecer uma forma padronizada de comunicação com 
grandes e novos sistemas com suporte a novas alterações com 
também o mínimo de impacto.
SOA promove a padronização da representação dos dados em 
formato XML, e através de serviços “sem estado”, maximiza 
o reuso, disponibilidade e escalabilidade. Através da reutili-
zação de software, o custo de desenvolvimento é reduzido e a 
implementação é acelerada.
Na parte prática do artigo foram construídas duas partes de 
uma aplicação, demonstrando na prática a integração desses 
dois fragmentos, o fraco acoplamento, reuso, composição de 
serviços e interoperabilidade. Foi visto também como a tecno-
logia BPEL se encaixa no modelo SOA.
Figura 20. Consulta da tabela pedido após a execução do processo
BECHARA, Gabriel. What is a Reusable Service? 
http://www.oracle.com/technology/pub/articles/bechara_reusable_service.html. 
ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design.Prentice Hall, 2005.
JBOSS. Why ESB and SOA. 
http://docs.jboss.org/jbossesb/whitepapers/WhyESB.pdf
JENNINGS, Frank; SALTER, David.Building SOA-Based Composite Applications Using NetBeans 
IDE 6: design, build, test, and debug service-oriented applications with ease using XML, BPEL, 
and Java web services. PacktPublishing, 2008.
JOSUTTIS. Nicolai M. SOA na prática. Rio de Janeiro: Alta Books, 2008.
MICROSOFT. Conheça a Arquitetura Orientada a Serviços (SOA - Service OrientedArchitecture). 
http://www.microsoft.com/brasil/servidores/biztalk/solutions/soa/overview.mspx
MICROSOFT. Ativando uma “Arquitetura Orientada a Serviços Realista” na Plataforma Microsoft. 
http://download.microsoft.com/download/e/7/8/e78469ef-eed4-4f08-8fbe-8918404ca088/
Real_World_SOA.doc
ORT. Ed. Service-Oriented Architecture and Web Services: Concepts, Technologies, and Tools. 
http://java.sun.com/developer/technicalArticles/WebServices/soa2/soa2.pdf
Referências
Dê seu feedback sobre esta edição!
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, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
18 Engenharia de Software Magazine - Refatoração para Padrões – Parte 8 
Jacimar Fernandes Tavares 
jacimar.tavares@studentpartners.com.br
Bacharel em Ciência da Computação FAGOC 
- Faculdade Governador Ozanam Coelho, Mi-
crosoft Student Partners.
De que se trata o artigo?
Aborda o tema refatoração para padrões com o ob-
jetivo de mostrar como o desenvolvedor pode usá-
lo para melhorar o código-fonte de suas aplicações. 
Para que serve?
Para prover conhecimento ao desenvolvedor sobre 
refatoração para padrões e demonstrar através de 
exemplos práticos a aplicação das técnicas de refa-
toração para padrões Substituir Envio condicional 
por Command e Extrair Composite.
Em que situação o tema é útil?
O tema se torna fundamental para desenvolve-
dores que já estão familiarizados com padrões de 
projeto e já os implementam em seus softwares 
e que querem saber mais sobre refatoração para 
padrões, conhecendo os benefícios que sua uti-
lização traz.
Refatoração para Padrões – Parte 8 
Implementando os padrões Command e Composite através das técnicas de 
refatorações para padrões
A criação de lógicacondicional é o recurso utilizado pelos desenvolvedores para permitir 
que diferentes caminhos possam ser 
tomados durante a execução de uma 
aplicação. Um problema neste sentido 
está relacionado ao tamanho do código 
que contém a lógica condicional. Caso 
ele seja extenso demais, pode vir a se 
tornar complicado de entender e manter. 
Lógica condicional criada para executar 
diversos tipos de ações pode centralizar 
muito código em uma única classe do 
sistema. 
A definição de uma técnica de refatora-
ção para padrões que permita simplificar 
essa lógica condicional ao implementar 
o padrão de projeto Command, permite 
que o código responsável por executar as 
diversas ações seja dividido por diversas 
classes command. A refatoração para 
Marco Antônio Pereira Araújo 
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas 
e Computação pela COPPE/UFRJ, Especialista 
em Métodos Estatísticos Computacionais e 
Bacharel em Informática pela UFJF, professor 
dos Cursos de Bacharelado em Sistemas de 
Informação do Centro de Ensino Superior 
de Juiz de Fora, da Faculdade Metodista 
Granbery e da Universidade Severino Som-
bra, professor do curso de Bacharelado em 
Ciência da Computação da FAGOC, professor 
do Curso Superior de Tecnologia em Análise 
e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de 
Sistemas da Prefeitura de Juiz de Fora, Editor 
da Engenharia de Software Magazine.
padrões Substituir Envio condicional 
por Command auxilia neste processo.
As 27 técnicas de refatoração para 
padrões existentes implementam diver-
sos padrões de projeto baseando-se no 
contexto de um problema encontrado 
no código de algumas aplicações. Com 
isso, elas apresentam padrões de projeto 
Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes 
abordagens de apoio ao desenvolvimento de projetos de software
Edição 35 - Engenharia de Software Magazine 19 
DESENvoLvIMENto
que podem ser implementados com base em diferentes pro-
blemas, como é o caso do padrão Composite. Neste artigo sua 
implementação se dá com base em um problema: código 
duplicado responsável pela manipulação de composites. Nesse 
contexto, surge a necessidade de remover código duplicado 
que pode estar em diferentes subclasses de uma hierarquia. 
Para tal tarefa, o código é movido para a superclasse e a du-
plicação é eliminada. Essa modificação será possível com a 
aplicação da refatoração para padrões Extrair Composite (ver 
Nota do DevMan 1). 
Para um melhor entendimento das refatorações para padrões 
abordadas neste artigo é necessário que o desenvolvedor co-
nheça previamente as técnicas de refatoração Extrair Método, 
Extrair Classe, Extrair SuperClasse e Extrair Interface, por se-
rem parte fundamental no processo de aplicação da refatoração 
para padrões Substituir envio condicional por Command, e ain-
da conhecer as técnicas de refatoração Renomear Método, Subir 
Método na Hierarquia e Substituir Algoritmo, que, juntamente 
com a refatoração Extrair Método, constituem os pré-requisitos 
necessários para a aplicação da técnica de refatoração para 
padrões Extrair Composite (ver Nota do DevMan 2).
A sequência apresentada pelo autor das refatorações para 
padrões (KERIEVSKY, 2008) traz a técnica Formar Template 
Method após a técnica Substituir envio condicional por Com-
mand, contudo, é destacado que a técnica em questão é idêntica 
à técnica de refatoração Criar um Método Padrão (FOWLER, 
2004) (edição de número 30 da revista Engenharia de Software 
Magazine). Portanto, neste artigo será apresentada apenas uma 
visão geral sobre Formar Template Method, permitindo que os 
conceitos já vistos na apresentação da técnica de refatoração 
Criar um Método Padrão sejam relembrados.
O padrão de projeto Command
Nome do padrão de projeto: Command (GAMMA, 2000). 
Pertencente ao conjunto dos padrões de projeto classificados 
como Padrões Comportamentais.
O problema: Algumas aplicações interagem com o usuário 
através de interfaces gráficas, onde também é possível perceber 
várias solicitações vindas por parte desses que a manipulam. 
Essas solicitações geralmente acabam exigindo do sistema a 
execução de alguma operação, como por exemplo, a execução 
de determinado método em uma classe. O padrão de projeto 
Command permite então que as solicitações em um sistema 
sejam encapsuladas em um objeto e então uma hierarquia de 
classes decida e execute métodos, conforme o tipo de solicitação 
feita pelo usuário.
As consequências: Com a implementação de um Command 
consegue-se reduzir o acoplamento entre, por exemplo, inter-
faces e classes responsáveis por manter métodos que executam 
determinadas operações.
Refatoração Renomear Método
Esta refatoração é pertencente ao grupo de refatorações 
classificadas como Tornando as Chamadas de Métodos Mais 
Simples.
N o t a d o D e v M a n 1
Relembrando conceitos
Uma breve descrição do padrão de projeto Composite foi apresentada no artigo 
da edição de número 30 da Engenharia de Software Magazine e relembrada na edi-
ção de número 34.
N o t a d o D e v M a n 2
Refatorações apresentadas em outros artigos
As técnicas de refatoração Extrair Método, Extrair Classe, Extrair Superclasse, Ex-
trair Interface e Subir Método na Hierarquia foram apresentadas em outras edições 
da Engenharia de Software Magazine, mais precisamente nas edições de número 
29, 30, 33 e 34. 
Nome da refatoração: Renomear Método
Resumo: Um método possui um nome que não deixa claro 
qual é a sua função. Refatore-o alterando para um nome que 
reflita seu objetivo.
Motivação: Alguns métodos possuem nomes que dificultam, 
à primeira vista, a identificação da sua função, que nestes 
casos só é descoberta quando se analisa o corpo do método. 
Isso dificulta o trabalho de quem está analisando o código. 
Baseado nisso, indica-se esta refatoração para melhorar a 
legibilidade do código.
Mecânica: 
• Certifique-se de que o método não tem sua assinatura imple-
mentada em uma super ou subclasse. Caso tenha, cada passo 
da mecânica deve ser repetido em todas as implementações 
existentes.
• Cria-se um novo método com o nome desejado.
• Move-se o corpo do método para o método recém criado e 
apaga-se o método antigo.
• Modifique os pontos que chamam o método antigo, para 
que, a partir desse momento, passem a referenciar o método 
novo.
• Execute seus testes.
Exemplo: Considerando o método da Listagem 1, pode-se 
perceber que seu nome não revela seu real objetivo que é o 
de verificar se existem campos vazios na interface. Isso só é 
percebido caso o programador analise o código, o que não é 
recomendado. 
Aplicando a refatoração Renomear Método, tem-se um mé-
todo que demonstra seu objetivo já no próprio nome, como 
mostra a Listagem 2.
Refatoração Substituir Algoritmo
Esta refatoração é pertencente ao grupo de refatorações clas-
sificadas como Compondo Métodos.
Nome da refatoração: Substituir Algoritmo
20 Engenharia de Software Magazine - Refatoração para Padrões – Parte 8 
Resumo: Alguns trechos de código parecem ser complexos 
de entender e há uma forma mais simples de representar o 
problema. Substitui-se o trecho de código complexo por algo 
mais simples.
Motivação: É comum um desenvolvedor criar um trecho de 
código que, mais tarde ao lê-lo novamente, encontre uma forma 
mais simples de resolver o mesmo problema. Esta refatoração 
é indicada para essas situações, pois permite que o desenvol-
vedor esteja sempre substituindo código complexo por código 
mais fácil de entender.
Mecânica:
• Comente o trecho de código que pretende substituir.
• Crie um novo trecho de código que possua a mesma função 
do trecho comentado, mas agora cuidando para que seja mais 
simples que o que será substituído.
• Teste a aplicação para se certificar de que o códigocriado 
tem a mesma função que o código a ser substituído.
• Apague o código comentado.
Observações: Esta técnica de refatoração é muito simples de 
ser aplicada. Devido a este fato, não será apresentada a seção 
exemplo como as demais refatorações, assim como sugerido 
pelo criador das técnicas (FOWLER, 2004).
Após conhecidas as técnicas de refatoração necessárias para 
o entendimento das técnicas de refatoração para padrões 
que este artigo aborda, o desenvolvedor poderá iniciar o 
processo de aprendizagem das técnicas de refatoração para 
Listagem 1. Método antes da refatoração.
1. private Boolean Verificar(String login, String senha)
2. {
3. if (login.Length == 0)
4. {
5. LabelEntrada.Text = “ Insira um Login”;
6. return false;
7. }
8. else if(senha.Length == 0)
9. {
10. LabelEntrada.Text = “Insira uma Senha”;
11. return false;
12. ‘ }
13. return true;
14. }
Listagem 2. Método depois da refatoração.
1. private Boolean DetectarCamposVazios(String login, String senha)
2. {
3. if (login.Length == 0)
4. {
5. LabelEntrada.Text = “ Insira um Login”;
6. return false;
7. }
8. else if(senha.Length == 0)
9. {
10. LabelEntrada.Text = “Insira uma Senha”;
11. return false;
12. }
13. return true;
14. }
padrões Substituir Envio Condicional por Command e Extrair 
Composite. 
Substituir Envio Condicional por Command
Resumo: Lógica condicional é utilizada para executar deter-
minadas ações e enviar solicitações a outros pontos da apli-
cação. Neste sentido, utiliza-se um Command que encapsulará 
as ações e solicitações a serem executadas, cada uma em um 
command diferente.
Motivação: Em alguns momentos o desenvolvedor cria uma 
extensa lógica condicional que é utilizada para determinar 
qual ação ou tarefa deve ser executada naquele momento. 
Quando a lógica condicional é muito extensa, corre-se o risco 
de o projeto de código existente se tornar difícil de rastrear. 
Assim, tem-se um cenário onde o uso do padrão Command 
permitirá simplificar a lógica condicional, levando as ações a 
serem executadas para o command específico.
Vantagens: Permite a criação de um mecanismo mais simples 
e padronizado para executar diversas ações diferentes; Fornece 
um mecanismo que pode alterar o tipo de ação a ser executada 
em tempo de execução; Fácil implementação.
Desvantagens: Complica o projeto de código existente quan-
do a lógica condicional não é tão complexa.
Mecânica: 
1. Buscando pela classe que contém o envio condicional, 
utiliza-se a refatoração Extrair Método, produzindo métodos 
que correspondam aos envios do código localizado.
2. O passo 2 sugere que o passo 1 seja realizado até que não haja 
mais envios condicionais para serem substituídos por métodos.
3. Utilizando a refatoração Extrair Classe, deve-se criar uma 
classe para cada envio encapsulado através de um método 
definido no passo 1. Caso os métodos contenham muito código 
duplicado, usa-se a refatoração Criar um Método Padrão.
4. Ao aplicar a refatoração Extrair Superclasse ou Extrair In-
terface, tem-se um local onde deve ser declarado um método 
abstrato, que será implementado pelos métodos nas classes 
extraídas no passo 3.
5. O código cliente deve ser modificado para adaptar-se à 
hierarquia de classes criada.
6. Declaram-se objetos das classes extraídas no passo 3 na 
classe que contém o envio condicional. Essas instâncias serão 
usadas para invocar os métodos extraídos e que foram levados 
para as classes extraídas no passo 3. 
7. A classe que possuía o envio condicional é classificada 
como Command:Invoker (GAMMA, 2000). Ela deverá conter as 
chamadas aos comandos criados na hierarquia de classes ou 
que compartilham a mesma interface.
Exemplo: O exemplo a ser utilizado pertence a uma aplicação 
web onde o logon é feito após algumas verificações. O código 
do corpo do evento de clique do botão executa uma série de 
comandos, baseando-se em alguns critérios que determinam 
o envio condicional que será seguido. A Listagem 3 mostra o 
evento de um botão Entrar.
Edição 35 - Engenharia de Software Magazine 21 
DESENvoLvIMENto
Analisando a sentença switch, percebe-se que cada case 
possui uma grande quantidade de comandos que deverão 
ser executados. Neste cenário, atuará o padrão command. 
O primeiro passo envolve a aplicação da refatoração Ex-
trair Método, que criará métodos para encapsular o código 
presente no envio condicional, ou seja, o código dos cases do 
switch. A Listagem 4 mostra os métodos extraídos e a modi-
ficação no envio condicional para invocar os métodos.
Agora tem-se os métodos que estão encapsulando o coman-
do, resta agora criar uma hierarquia de classes, onde será 
definida uma classe para cada comando, bem como uma 
superclasse para essas classes, como sugerido no passo 4. 
Os métodos deverão ser movidos para as suas respectivas 
classes. Além disso, eles deverão ter seus nomes modifi-
cados, a fim de que todos compartilhem uma declaração 
abstrata na superclasse. O nome que os métodos assumirão 
será Direcionar. O resultado pode ser visto nas Listagens 
5, 6, 7, 8 e 9.
As mudanças realizadas removeram os métodos extraídos 
do formulário que contém o botão Enviar. O problema com 
essa ação é que o código das Listagens 6 a 9, linhas 10 e 11, 
fazem chamada a um método e a uma propriedade que estão 
no formulário e são partes dele. Isso requer que algumas mu-
danças sejam feitas nos métodos Direcionar. Posteriormente, 
os métodos Direcionar devem implementar um método 
declarado na superclasse Command, e o envio condicional 
(sentença switch) deve ser atualizado para adaptar-se à hie-
rarquia de comandos criada. As Listagens 10, 11, 12, 13, 14 
e 15 mostram os resultados dessas mudanças, o que finaliza 
esta refatoração para o padrão Command.
1. protected void ButtonEntrar_Click(object sender, EventArgs e)
2. {
3. String login = TextBoxLogin.Text;
4. String senha = TextBoxSenha.Text;
5. if (VerificaCampos(login, senha) == true)
6. {
7. classAcesso acesso = new classAcesso();
8. ArrayList listaDadosLogin = new ArrayList();
9. listaDadosLogin.Add(login);
10. listaDadosLogin.Add(senha);
11. String tipoLogado = acesso.CriarObjetoAcesso(listaDadosLogin);
12. String tipoUsuario = “”;
13. String idUsuario = “”;
14. String nomeUsuario = “”;
15. switch (tipoLogado)
16. {
17. case “ADMINISTRADOR”:
18. tipoUsuario = “ADMINISTRADOR”;
19. idUsuario = “1”;
20. nomeUsuario = “admim”;
21. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
22. Response.Redirect(“Administrador.aspx”);
23. break;
24. case “SECRETARIA”:
25. tipoUsuario = “SECRETARIA”;
26. idUsuario = “2”;
27. nomeUsuario = “sec”;
28. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
29. Response.Redirect(“Secretaria.aspx”);
30. break;
31. case “ALUNO”:
32. classAlunos objAluno = new classAlunos();
33. ArrayList dadosAluno = objAluno.PopulaCookies(login, senha);
34. tipoUsuario = “ALUNO”;
35. idUsuario = Convert.ToString(dadosAluno[0]);
36. nomeUsuario = Convert.ToString(dadosAluno[1]);
37. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
38. Response.Redirect(“Aluno.aspx”);
39. break;
40. case “PROFESSOR”:
41. classProfessores objProfessor = new classProfessores();
42. ArrayList dadosProfessor = objProfessor.PopulaCookies(login, senha);
43. tipoUsuario = “PROFESSOR”;
44. idUsuario = Convert.ToString(dadosProfessor[0]);
45. nomeUsuario = Convert.ToString(dadosProfessor[1]);
46. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
47. Response.Redirect(“Professor.aspx”);
48. break;
49. default:
50. LabelEntrada.Text = “ Falha ao Logar”;
51. TextBoxSenha.Text = “”;
52. break;
53. }
54. }
55. }
Listagem 3. Envio condicional.
Como foi destacado no início deste artigo, a refatoração para 
padrões Formar Template Method é semelhante à técnica de 
refatoração Criar um Método Padrão e, portanto, apenas uma 
breve descrição será apresentada.
Formar Template Method
Resumo: Alguns métodos numa hierarquia de classes são pare-
cidos, mas se analisados percebe-se pequenas diferenças. Aplica-
se esta refatoração para padrões e cria-se um método padrão.
Motivação: Uma motivação neste sentido é a remoção de 
código duplicado. Métodos parecidos, mas que se analisados 
percebe-se que há partes diferentes que escondem muito códi-
go duplicado. A parte comum aos métodos deve ser extraída em 
um método padrão que deverá ser levado a uma superclasse, 
enquanto o trecho de código incomum aos métodos deve ficar 
em métodos específicos nas subclasses, que serão invocados 
polimorficamente.
Vantagens: Permite a remoção de código duplicado; simpli-
fica o projeto de código existente; Facilita a customização de 
algoritmos nas subclasses.
Desvantagens: Complica algumas subclasses ao adquirir 
vários métodos responsáveis pela implementação das parti-
cularidades do método padrão.
Extrair Composite
Resumo: Extrai-se uma superclasse responsável pela imple-
mentação de um composite quando houver subclasses imple-
mentando o mesmo composite.
Motivação: O uso desta refatoração para padrões permite ao 
desenvolvedor mover o código similar para uma superclasse e 
22 Engenharia de Software Magazine - Refatoração para Padrões – Parte 8 
01. public void ComandoAdministrador(String tipoUsuario, String 
 idUsuario,String nomeUsuario)
02. {
03. tipoUsuario = “ADMINISTRADOR”;
04. idUsuario = “1”;
05. nomeUsuario = “admim”;
06. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
07. Response.Redirect(“Administrador.aspx”);
08. }
09. public void ComandoSecretaria(String tipoUsuario, String idUsuario, 
 String nomeUsuario)
10. {
11. tipoUsuario = “SECRETARIA”;
12. idUsuario = “2”;
13. nomeUsuario = “sec”;
14. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
15. Response.Redirect(“Secretaria.aspx”);
16. }
17. public void ComandoAluno(String tipoUsuario, String idUsuario, String 
 nomeUsuario, String login, String senha)
18. {
19. classAlunos objAluno = new classAlunos();
20. ArrayList dadosAluno = objAluno.PopulaCookies(login, senha);
21. tipoUsuario = “ALUNO”;
22. idUsuario = Convert.ToString(dadosAluno[0]);
23. nomeUsuario = Convert.ToString(dadosAluno[1]);
24. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
25. Response.Redirect(“Aluno.aspx”);
26. }
27. public void ComandoProfessor(String tipoUsuario, String idUsuario, 
 String nomeUsuario, String login, String senha)
28. {
29. classProfessores objProfessor = new classProfessores();
30. ArrayList dadosProfessor = objProfessor.PopulaCookies(login, senha);
31. tipoUsuario = “PROFESSOR”;
32. idUsuario = Convert.ToString(dadosProfessor[0]);
33. nomeUsuario = Convert.ToString(dadosProfessor[1]);
34. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
35. Response.Redirect(“Professor.aspx”);
36. }
37. protected void ButtonEntrar_Click(object sender, EventArgs e)
38. {
39. String login = TextBoxLogin.Text;
40. String senha = TextBoxSenha.Text;
41. if (VerificaCampos(login, senha) == true)
42. {
43. classAcesso acesso = new classAcesso();
44. ArrayList listaDadosLogin = new ArrayList();
45. listaDadosLogin.Add(login);
46. listaDadosLogin.Add(senha);
47. String tipoLogado = acesso.CriarObjetoAcesso(listaDadosLogin);
48. String tipoUsuario = “”;
49. String idUsuario = “”;
50. String nomeUsuario = “”;
51. switch (tipoLogado)
52. {
53. case “ADMINISTRADOR”:
54. ComandoAdministrador(tipoUsuario, idUsuario, nomeUsuario);
55. break;
56. case “SECRETARIA”:
57. ComandoSecretaria(tipoUsuario, idUsuario, nomeUsuario);
58. break;
59. case “ALUNO”:
60. ComandoAluno(tipoUsuario, idUsuario, nomeUsuario, login, 
 senha);
61. break;
62. case “PROFESSOR”:
63. ComandoProfessor(tipoUsuario, idUsuario, nomeUsuario, login, 
 senha);
64. break;
65. default:
66. LabelEntrada.Text = “ Falha ao Logar”;
67. TextBoxSenha.Text = “”;
68. break;
69. }
70. }
71. }
Listagem 4. Métodos extraídos
Listagem 5. Classe Command.
01. public abstract class Command
02. {
03. }
Listagem 6. Classe CommandAdministrador.
01. public class CommandAdministrador: Command
02. {
03. public void Direcionar(String tipoUsuario, String idUsuario, String 
 nomeUsuario)
04. {
05. tipoUsuario = “ADMINISTRADOR”;
06. idUsuario = “1”;
07. nomeUsuario = “admim”;
08. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
09. Response.Redirect(“Administrador.aspx”);
10. }
11. }
Listagem 7. Classe CommandSecretaria.
01. public class CommandSecretaria: Command
02. {
03. public void Direcionar(String tipoUsuario, String idUsuario, String 
 nomeUsuario)
04. {
05. tipoUsuario = “SECRETARIA”;
06. idUsuario = “2”;
07. nomeUsuario = “sec”;
08. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
09. Response.Redirect(“Secretaria.aspx”);
10. }
11. }
Listagem 8. Classe CommandAluno.
01. public class CommandAluno: Command
02. {
03. public void Direcionar(String tipoUsuario, String idUsuario, String 
 nomeUsuario, String login, String senha)
04. {
05. classAlunos objAluno = new classAlunos();
06. ArrayList dadosAluno = objAluno.PopulaCookies(login, senha);
07. tipoUsuario = “ALUNO”;
08. idUsuario = Convert.ToString(dadosAluno[0]);
09. nomeUsuario = Convert.ToString(dadosAluno[1]);
10. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
11. Response.Redirect(“Aluno.aspx”);
12. }
13. }
Edição 35 - Engenharia de Software Magazine 23 
DESENvoLvIMENto
Listagem 9. Classe CommandProfessor.
01. public class CommandProfessor: Command
02. {
03. public void Direcionar(String tipoUsuario, String idUsuario, String 
 nomeUsuario, String login, String senha)
04. {
05. classProfessores objProfessor = new classProfessores();
06. ArrayList dadosProfessor = objProfessor.PopulaCookies(login, senha);
07. tipoUsuario = “PROFESSOR”;
08. idUsuario = Convert.ToString(dadosProfessor[0]);
09. nomeUsuario = Convert.ToString(dadosProfessor[1]);
10. CriarSession(tipoUsuario, idUsuario, nomeUsuario);
11. Response.Redirect(“Professor.aspx”);
12. }
13. }
Listagem 10. Subclasse CommandAdministrador.
1. public class CommandAdministrador: Command
2. {
3. public override ArrayList Direcionar(String tipoUsuario,