Baixe o app para aproveitar ainda mais
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,
Compartilhar