Www.superdownload.us ES35

59

Transcript of Www.superdownload.us ES35

Page 1: Www.superdownload.us ES35
Page 2: Www.superdownload.us ES35

www.infnet.edu.br - [email protected] - 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çãoAná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

TURMASNO RIO DEJANEIRO

Modéstia à parte, suamelhor opção para

se destacar no mercado!

Page 3: Www.superdownload.us ES35

Corpo Editorial

ColaboradoresRodrigo Oliveira SpínolaMarco Antônio Pereira Araújo Eduardo Oliveira Spínola

Capa Romulo Araujo - [email protected]

DiagramaçãoJanete Feitosa

Coordenação GeralDaniella Costa - [email protected]

RevisorGregory Monteiro - [email protected] Velozo - [email protected]

Jornalista ResponsávelKaline Dolabella - JP24185

Na Webwww.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 [email protected] 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ú[email protected] 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í[email protected]É 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 Leitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

Cristiany [email protected]

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

[email protected]

EDITORIAL

Page 4: Www.superdownload.us ES35

Í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 - Reengenharia de software orientado a objetos Giuliano Prado de Morais Giglio e Gizelle Sandrini Lemos

51 - Otimização de Processos de Negócio usando BPM – Parte 1Ricardo S. Ferreira

Tipo: Processo Título: Especificação de casos de uso na prática – Partes 21 a 25Autor: Rodrigo Oliveira SpínolaMini-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:

Page 5: Www.superdownload.us ES35

Edição 05 - Engenharia de Software Magazine 5

Page 6: Www.superdownload.us ES35

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

Glênio [email protected]

É 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

seu Feedback

sob

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.

Page 7: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 7

Leandro Wong Kong [email protected]

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 [email protected]

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.

SOAInteroperabilidade 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ócio traz 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

Page 8: Www.superdownload.us ES35

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.

InteroperabilidadeMuitos 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çosUm 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

Page 9: Www.superdownload.us ES35

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çosPara 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çosFigura 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

Page 10: Www.superdownload.us ES35

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.

BPELQuando 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 SOAPara 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 ServicesInicialmente, 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.

Page 11: Www.superdownload.us ES35

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 pedido e 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

Page 12: Www.superdownload.us ES35

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

Page 13: Www.superdownload.us ES35

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 BPELCom 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á composta pelos 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

Page 14: Www.superdownload.us ES35

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

Page 15: Www.superdownload.us ES35

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

Page 16: Www.superdownload.us ES35

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 BPELPara 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.

Page 17: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 17

ARQUItEtUR A

ConclusãoCom 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

seu Feedback

sob

re esta edição

Page 18: Www.superdownload.us ES35

18 Engenharia de Software Magazine - Refatoração para Padrões – Parte 8

Jacimar Fernandes Tavares [email protected]

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ógica condicional é 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 [email protected]

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

Page 19: Www.superdownload.us ES35

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 CommandNome 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étodoEsta 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 1Relembrando conceitosUma 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 artigosAs 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étodoResumo: 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 AlgoritmoEsta refatoração é pertencente ao grupo de refatorações clas-

sificadas como Compondo Métodos.Nome da refatoração: Substituir Algoritmo

Page 20: Www.superdownload.us ES35

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ódigo criado 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 CommandResumo: 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.

Page 21: Www.superdownload.us ES35

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 MethodResumo: 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 CompositeResumo: 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

Page 22: Www.superdownload.us ES35

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 Command02. {03. }

Listagem 6. Classe CommandAdministrador.

01. public class CommandAdministrador: Command02. {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: Command02. {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: Command02. {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. }

Page 23: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 23

DESENvoLvIMENto

Listagem 9. Classe CommandProfessor.

01. public class CommandProfessor: Command02. {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: Command2. {3. public override ArrayList Direcionar(String tipoUsuario, String idUsuario, String nomeUsuario, String login, String senha)4. {5. tipoUsuario = “ADMINISTRADOR”;6. idUsuario = “1”;7. nomeUsuario = “admim”;8. dados.Add(tipoUsuario);9. dados.Add(idUsuario);10. dados.Add(nomeUsuario);11. return dados;12. }13. }

Listagem 11. Subclasse CommandSecretaria.

1. public class CommandSecretaria: Command2. {3. public override ArrayList Direcionar(String tipoUsuario, String idUsuario, String nomeUsuario, String login, String senha)4. {5. tipoUsuario = “SECRETARIA”;6. idUsuario = “2”;7. nomeUsuario = “sec”;8. dados.Add(tipoUsuario);9. dados.Add(idUsuario);10. dados.Add(nomeUsuario);11. return dados;12. }13. }

Listagem 12. Subclasse CommandAluno.

1. public class CommandAluno: Command2. {3. public override ArrayList Direcionar(String tipoUsuario, String idUsuario, String nomeUsuario, String login, String senha)4. {5. classAlunos objAluno = new classAlunos();6. ArrayList dadosAluno = objAluno.PopulaCookies(login, senha);7. tipoUsuario = “ALUNO”;8. idUsuario = Convert.ToString(dadosAluno[0]);9. nomeUsuario = Convert.ToString(dadosAluno[1]);10. dados.Add(tipoUsuario);11. dados.Add(idUsuario);12. dados.Add(nomeUsuario);13. return dados;14. }15. }

Listagem 13. Subclasse CommandProfessor.

1. public class CommandProfessor: Command2. {3. public override ArrayList Direcionar(String tipoUsuario, String idUsuario, String nomeUsuario, String login, String senha)4. {5. classProfessores objProfessor = new classProfessores();6. ArrayList dadosProfessor = objProfessor.PopulaCookies(login, senha);7. tipoUsuario = “PROFESSOR”;8. idUsuario = Convert.ToString(dadosProfessor[0]);9. nomeUsuario = Convert.ToString(dadosProfessor[1]);10. dados.Add(tipoUsuario);11. dados.Add(idUsuario);12. dados.Add(nomeUsuario);13. return dados;14. }15. }

Listagem 14. Superclasse Command.

1. public abstract class Command2. {3. public ArrayList dados = new ArrayList();4. public abstract ArrayList Direcionar(String tipoUsuario, String idUsuario, String nomeUsuario, String login, String senha);5. }

Listagem 15. Envio condicional.

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. Command commandAdm = new CommandAdministrador();19. commandAdm.Direcionar(tipoUsuario, idUsuario, nomeUsuario, login, senha);20. Response.Redirect(“Administrador.aspx”);21. break;22. case “SECRETARIA”:23. Command commandSec = new CommandSecretaria();24. commandSec.Direcionar(tipoUsuario, idUsuario, nomeUsuario, login, senha);25. Response.Redirect(“Secretaria.aspx”);26. break;27. case “ALUNO”:28. Command commandAln = new CommandSecretaria();29. commandAln.Direcionar(tipoUsuario, idUsuario, nomeUsuario, login, senha);30. Response.Redirect(“Aluno.aspx”);31. break;32. case “PROFESSOR”:33. Command commandProf = new CommandSecretaria();34. commandProf.Direcionar(tipoUsuario, idUsuario, nomeUsuario, login, senha);35. Response.Redirect(“Professor.aspx”);36. break;37. default:38. LabelEntrada.Text = “ Falha ao Logar”;39. TextBoxSenha.Text = “”;40. break;41. }42. }43. }

Page 24: Www.superdownload.us ES35

24 Engenharia de Software Magazine - Refatoração para Padrões – Parte 8

eliminar assim código duplicado. A refatoração Extrair Super-classe (FOWLER, 2004) é semelhante a esta, mas a diferença está na manipulação de composites. Quando se usa Extrair Composite, pode-se levar todo código pertencente ao composite para uma superclasse.

Vantagens: Permite a eliminação de código duplicado; Permite uma melhor visualização do problema modelado, ao tornar claro que funcionalidades podem ser herdadas da superclasse extraída.

Mecânica: 1. Cria-se uma classe que terá a responsabilidade de ser a su-perclasse de uma hierarquia. Ela será o composite.2. Defina subclasses para a superclasse de acordo com o contexto do código que se está analisando. Esta tarefa envolve abstração no sentido de analisar uma classe que faz uma composição de objetos com informações provenientes de outras classes.3. Com a refatoração Renomear Método, será possível mudar o nome de alguns métodos que deverão ser levados para as subclasses criadas. Ao mover os métodos para as subclasses, talvez seja necessária a utilização da refatoração Subir Método na Hierarquia. A refatoração Substituir Algoritmo talvez tenha que ser utilizada para melhorar o corpo de um método, mas se isto não for uma tarefa viável, usando a refatoração Extrair Método, é possível extrair um método que poderá subir na hierarquia. Para auxiliar ainda neste processo de remoção de código duplicado e simplificação do projeto de código existente, pode-se ainda utilizar a refatoração Criar um Método Padrão. 4. Enquanto houver cenário apropriado para o passo 3, ele deverá ser repetido.5. Caso necessário, modifica-se o código cliente permitindo que ele se comunique com a superclasse Composite.

Exemplo: O código que será utilizado possui uma sequência de métodos que são duplicados por vários pontos do código cliente. Para reduzir esta duplicação e obter os benefícios que a extração de um composite proporciona, inicia-se o processo de refatorar este código cliente. A Listagem 16 mostra a declaração dos métodos que são duplicados.

O passo 1 envolve a criação de uma classe que será o composite. Posteriormente, analisando o código da Listagem 16, percebe-se que as subclasses que deverão ser criadas podem ser abstraídas dos métodos RecuperaAvaliacoes, ExibeAlunos e SalvarNota. Cada um desses métodos serão movidos para uma subclasse e a superclasse Composite ficará responsável por manipular tais métodos, tornando-se o ponto único de acesso para eles, o que permitirá reduzir a duplicação no código cliente. A classe Composite e suas subclasses podem ser vistas nas Listagens 17, 18, 19 e 20.

Os métodos que estavam duplicados no código cliente foram centralizados em suas respectivas subclasses, e são invocados pelo composite que realiza a tarefa de trabalhar com as informa-ções fornecidas pelas subclasses. Para finalizar esta refatoração para padrões, basta atualizar o código cliente que possuía os métodos para invocarem o método LancarNota do composite, que se encarregará do resto.

Listagem 16. Métodos para lançar nota de uma avaliação.

1. public ArrayList RecuperaAvaliacoes(Int64 idprofessor, DateTime dataAvaliacao)2. {3. // Código omitido: Recupera as avaliações de um professor por data.4. }5. public void ExibeAlunos(String tituloAvaliacao)6. {7. // Código omitido: Lista alunos que fizeram a avaliaçao escolhida entre as retornadas8. }9. public Boolean SalvarNota(Int64 idAluno, Decimal nota)10. {11. // Código omitido: salva a nota do aluno referente a avaliacao escolhida.12. }

Listagem 17. Superclasse Composite.

1. public class Composite2. {3. public Boolean LancarNota(Int64 idProfessor, DateTime data)4. {5. ...6. Avaliacao avaliacao = new Avaliacao();7. Aluno aluno = new Aluno();8. Nota notaaluno = new Nota();

9. ArrayList lista = avaliacao.RecuperaAvaliacoes(idProfessor, data);10. aluno.ExibeAlunos(Convert.ToString(lista[alunoSelecionado]));

11. return notaaluno.SalvarNota(idAluno, nota);12. }13. }

Listagem 18. Subclasse Avaliacao.

1. public class Avaliacao: Composite2. {3. public ArrayList RecuperaAvaliacoes(Int64 idprofessor, DateTime dataAvaliacao)4. {5. // Código omitido: Recupera as avaliações de um professor por data. 6. }7. }

Listagem 19. Subclasse Aluno.

1. public class Aluno: Composite2. {3. public void ExibeAlunos(String tituloAvaliacao)4. {5. // Código omitido: Lista alunos que fizeram a avaliaçao escolhida entre as retornadas6. }7. }

Listagem 20. Subclasse Nota.

1. public class Nota: Composite2. {3. public Boolean SalvarNota(Int64 idAluno, Decimal nota)4. {5. // Código omitido: salva a nota do aluno referente a avaliacao escolhida. 6. }7. }

Page 25: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 25

DESENvoLvIMENto

ConclusãoNa série de artigos apresentados até este momento sobre refa-

toração para padrões é possível visualizar uma das principais preocupações das técnicas de refatoração para padrões, que foram citadas no artigo da edição de número 28 da Engenharia de Software Magazine: remover código duplicado e simplifi-car estruturas complexas. Estes problemas, se amenizados, podem contribuir para um menor risco de falhas relacionado à manutenção, o que é um dos grandes objetivos de quem desenvolve software.

GAMMA, Erich, 2000. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos,

1ed. Porto Alegre: Bookman, 2000.

KERIEVSKY, Joshua. Refatoração para Padrões, 1ed. Porto Alegre: Bookman, 2008.

FOWLER, Martin. Refatoração: aperfeiçoando o projeto de código existente, 1ed. Porto Alegre:

Bookman, 2004.

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

seu Feedback

sob

re esta edição

Page 26: Www.superdownload.us ES35

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

Page 27: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 27

DESENvoLvIMENto

Page 28: Www.superdownload.us ES35

28 Engenharia de Software Magazine - Introdução à verificação de diagramas de classe – Parte 1

Waldemar Pires Ferreira [email protected]

Mestre em Informática na área de Engenharia de Software - Universidade Federal de Campina Grande – UFCG. Bacharel em Ciência da Computação pela Universidade Federal de Campina Grande – UFCG.

De que se trata o artigo?Apresentaremos nesta série de artigos uma técni-ca baseada em templates de testes de design para a verificação de artefatos de diagramas de classes UML contra código Java. Nesta primeira parte de nosso artigo, apresentaremos os principais concei-tos envolvidos: UML 2.0, MDA, Teste de Design e DesignWizard.

Para que serve?Uma das principais contribuições em se aplicar teste de design é diminuir os custos do software. Custos

com a manutenção do software podem chegar até 90% do custo total do ciclo de vida do software. Den-tre esses custos destacamos o custo com a revisão de código. Em que situação o tema é útil?Verificação de conformidade com o design é espe-cialmente relevante em processos de desenvolvi-mento que promovem uma clara distinção entre artefatos de design e de implementação, como por exemplo, o RUP. E, especialmente, se equipes diferentes desenvolverem os artefatos de design e os de implementação.

Introdução à verificação de diagramas de classe – Parte 1Entendendo os conceitos

Engenharia

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

Uma atividade comum e fun-damental a todo processo de software é o design do softwa-

re. O design incorpora a descrição da estrutura do software, os dados que são manipulados pelo sistema, a descrição das interfaces entre os componentes do sistema, e algumas vezes o algoritmo usado. O design realiza importantes decisões da arquitetura do software e possui um papel crucial no desenvolvi-mento, implantação e evolução do siste-ma. Sendo assim, o design atua como o elo entre os requisitos e a implementação do software.

Contudo, nem sempre a implementação segue o design proposto. De acordo com testemunhos de alguns gerentes de fábri-cas de software do Brasil, isso raramente acontece. Documentação errônea ou ob-soleta é considerada uma das principais causas da baixa qualidade de software. Verificação de conformidade com o de-sign é especialmente relevante em proces-sos de desenvolvimento que promovem uma clara distinção entre artefatos de de-sign e de implementação, como por exem-plo, o RUP. E, especialmente, se equipes diferentes desenvolverem os artefatos de design e os de implementação.

Page 29: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 29

QUALIDADE DE SoFt WARE

Porém, a verificação de conformidade entre design e implementação é ainda um ponto em aberto na engenharia de software com poucas ferramentas de automação disponíveis. As principais ferramentas atualmente verificam o comportamento do sistema através de testes funcionais em detrimento à verificação da estrutura do sistema. Dentre as poucas que verificam estrutura, elas são em sua maioria manuais.

Para ilustrar a importância da conformidade entre o design do sistema e o seu código, consi-dere o processo de desenvolvimento ilustrado na Figura 1. Inicialmente, nesse processo, o arquiteto do software desenvolve o projeto do sistema, de forma que este contemple da me-lhor forma possível os requisitos do cliente. O projeto do sistema é um conjunto de artefatos que descrevem vários aspectos da forma como o sistema deve ser implementado. Dentre esses artefatos, um bastante usado para descrever a estrutura do sistema é o design estrutural, ele é responsável por exprimir a forma que a estrutura do código deve seguir. A etapa seguinte no processo de desenvolvimento é a etapa de implementação, é nessa etapa onde os programadores, baseados no projeto do sistema, implementam o código fonte desse sistema. Depois disso, vem a etapa de teste, onde diversos testes são executados, bugs podem ser descobertos e consertados. Por fim, a etapa de implantação, onde temos uma versão final do sistema pronta para ser usada. Um grande problema desse processo de desen-volvimento é que depois das diversas etapas intermediárias do processo, não há uma forma de garantir que o projeto do sistema ainda se mantém retido no código final.

A Figura 2 exibe o mesmo processo de desenvolvimento tratado anteriormente, sendo que agora o processo foi esten-dido com o uso de testes de design. Essa extensão teria um impacto mínimo no processo como um todo, tendo em vista que os arcos indicados com nome auto poderiam ser ações completamente automáticas.

Atualmente, a notação UML 2.0 é um formalismo padrão amplamente utilizado pela academia e pela indústria na es-pecificação de design de software. Essa notação é usada para descrever tanto características estruturais quanto comporta-mentais do software.

Há ainda alguns autores que propõem a verificação do design através do conceito de teste de design. Teste de design é um tipo de teste automático que verifica a conformidade de uma implementação em relação a regras de design explícitas. Con-tudo, regras de design expressas através de código de teste não é uma forma usual para especificar design. Para tanto existe a UML que é uma linguagem específica para esse fim.

Neste contexto, nós apresentaremos nesta série de artigos uma técnica baseada em templates1 de testes de design para a

Figura 1. Processo de desenvolvimento tradicional

verificação de artefatos de diagramas de classes UML contra código Java. Usando a abordagem, um designer que desenvol-va o design estrutural do sistema baseado em modelos UML será capaz de derivar automaticamente os testes de design para verificar se a implementação está de acordo com o de-sign proposto. Para a geração automática dos testes de design nós adotamos MDA, pois consideramos que essa abordagem consegue tratar todo o problema de aplicação de templates automaticamente com o uso de padrões internacionais, além do fato que um dos elementos do problema já envolve um dos padrões de MDA. Esta abordagem pode ser usada no desenvol-vimento do software como ferramenta para manter a sincronia entre os documentos de design e a implementação.

Nesta primeira parte de nosso artigo, apresentaremos os principais conceitos envolvidos: UML 2.0, MDA, Teste de Design e DesignWizard.

Overview da SoluçãoNossa solução para a verificação de artefatos do diagrama

de classe UML fundamenta-se na criação de um catálogo de templates de testes de design. Cada template é responsável por criar os testes capazes de verificar um tipo de artefato abordado nessa dissertação.

Figura 2. Extensão do processo de desenvolvimento

1 Template (ou “modelo de documento”) é um documento sem conteúdo, com apenas a apresentação visual (apenas cabeçalhos, por exemplo) e instruções sobre conteúdo de um documento a ser formado.

Page 30: Www.superdownload.us ES35

30 Engenharia de Software Magazine - Introdução à verificação de diagramas de classe – Parte 1

Tendo em vista que a aplicação dos templates de teste de design manualmente seria uma tarefa muito dispendiosa, desenvolvemos a ferramenta UDT (UML Design Tester). Essa ferramenta é capaz de aplicar automaticamente os templates de testes sobre os artefatos do diagrama de classe, e assim gerar, também automaticamente, os testes específicos para o design expresso pelo diagrama de classe. A Figura 3 apresenta uma visão geral do funcionamento do UDT. A implementação dessa ferramenta foi baseada nos conceitos de MDA para a geração automática de testes de design.

A ferramenta UDT, além de servir como forma de aplica-ção automática dos templates de teste, serviu também como plataforma para avaliação de toda a abordagem criada. Essa avaliação foi realizada através de um estudo de caso verifi-cando a conformidade entre o código de um sistema real e o seu diagrama de classe gerado através de engenharia reversa. Esse estudo de caso será apresentado em outro artigo desta nossa série.

Importância dos testes de designUma das principais contribuições em se aplicar teste de de-

sign é diminuir os custos do software. Custos com a manuten-ção do software podem chegar até 90% do custo total do ciclo de vida do software. Dentre esses custos destacamos o custo com a revisão de código. Um processo de revisão fortemente usado pelas empresas atualmente é o Design Peer Review. Uma desvantagem desse processo é o fato de que normalmente quem realiza a revisão do código é um programador sênior, ou seja, um custo por hora mais alto é requerido.

Dentre os custos com a manutenção de software, destaca-mos os custos para a organização com a perda de mercado decorrente do envelhecimento prematura do software. Uma das causas para o custo do software envelhecido é a diminui-ção da confiabilidade no código. Programas maiores e mais complexos com um projeto mal compreendido pela equipe levam à degradação do design do código, ocasionando numa complexidade desnecessária do código. Em outras palavras, quanto mais se altera um software sem ter conhecimento do projeto previsto para ele, maior será o esforço necessário para introduzir novas funcionalidades. Neste sentido, a técnica que começará a ser apresentada neste artigo é importante por dois motivos. Em primeiro lugar, a criação de testes de design para as diversas entidades dos diagramas pode ajudar os desenvol-vedores a compreender de uma forma mais clara como se deve

Figura 3. Overview da ferramenta UDT

implementar um sistema a partir dos diagramas construídos e como a implementação será verificada. Em segundo lugar, a técnica que será apresentada é um mecanismo capaz de manter uma constante verificação da conformidade com o design proposto, e assim promover uma maior confiabilidade ao código que está sendo desenvolvido.

Entendendo os conceitos básicosA partir de agora forneceremos o embasamento teórico aos

leitores acerca dos conceitos mais relevantes que utilizaremos ao longo desta série de artigos. Os conceitos que julgamos como essenciais para sua compreensão são: MDA (e MOF); Diagra-mas de Classes UML, um dos diagramas estruturais de UML (Unified Modeling Language) responsável por apresentar uma visão estática do projeto, mostrando uma coleção de elementos declarativos do modelo, tais como classes, tipos e seus relacio-namentos; Testes de Design, um tipo de teste que verifica se um código implementado segue um design previamente estabeleci-do; e, por fim, Design Wizard, uma biblioteca capaz de fornecer informações estruturais sobre um programa Java.

MDAEssa abordagem de desenvolvimento de software foi criada

pela OMG (Object Management Group) visando melhorar o processo de desenvolvimento de software, alterando o foco das ações onde se deve aplicar mais esforço durante o desen-volvimento de software.

MDA (Model Driven Architecure) representa uma visão de MDD (Model-Driven Development), sendo MDA a mais ado-tada até o presente momento. A ideia chave de MDA é mudar a ênfase de esforço e tempo empregados durante o ciclo de vida do software, focando-se na identificação de requisitos e organização do software através de modelos, ao invés de focar na implementação como é feito atualmente pelas metodologias tradicionais. Para alcançar esse objetivo, MDA sugere um conjunto de padrões de modelos:• O CIM (Computational Independent Model) descreve os modelos de negócio. Eles devem ser abstratos o suficiente para permitir especificar os processos do negócio, os stakeholders, os departamentos, as dependências entre os processos, etc. Esses modelos não devem necessariamente tratar diretamen-te sobre sistema de software usado no negócio, mas devem especificar como e quais áreas do negócio são contempladas por esse sistema. Os modelos de negócio e os modelos do sistema de software em si podem ser bem diferentes, pois o principal objetivo dos modelos do negócio é fornecer os requisitos que o software deve alcançar, além de mostrar o domínio da aplicação;• O PIM (Platform Independent Model) descreve como o sis-tema de software deve realizar a lógica do negócio da melhor forma possível. Ele é independente de plataforma pelo fato de que toda a descrição deve ser feita de uma forma tal que possa ser implementada por diversas tecnologias;• Os PSM (Platform Specific Model) especificam como os PIMs devem ser implementados para as tecnologias envolvidas na

Page 31: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 31

QUALIDADE DE SoFt WARE

solução. Um PIM pode ser traduzido em múltiplos PSM para diversas tecnologias. Por exemplo, um PIM pode descrever a arquitetura de sistema web cliente-servidor de múltiplas ca-madas. Já os PSM desse sistema podem descrever o software usando EJB, especificando as classes de controle de sessão, comunicação entre as camadas, etc. E outro PSM descrevendo o banco de dados relacional especificando as tabelas em si com linhas, colunas, chaves estrangeiras, etc. Sendo assim, um PIM pode ser traduzido em um ou mais PSMs. Para cada plataforma especifica, um PSM distinto será gerado. É fato que nos sistemas atuais uma vasta quantidade de tecnologias está sendo usada, dessa forma é comum encontrarmos vários PSMs para um único PIM;• Código é o nível mais baixo no desenvolvimento de uma aplicação na abordagem MDA. Os códigos são gerados a partir de cada PSM das tecnologias escolhidas. Nesse nível acontece a realização dos modelos PSM. Por exemplo, nesse nível é que estão os códigos na linguagem de código escolhida ou os esquemas das tabelas do banco de dados.

Meta-modelosO conceito de Meta-modelo é próximo ao das gramáticas

BNF (Backus-Naur Form) que descrevem um formalismo para definir se uma expressão pode ser considerada bem formada para uma determinada linguagem. Sendo que o contexto de Meta-modelagem é um pouco mais genérico, pois nem todas as entidades são baseadas estritamente em texto (como UML, que tem uma sintaxe gráfica). Além disso, Meta-modelos descrevem a sintaxe abstrata de um modelo, enquanto que gramáticas BNF descrevem a sintaxe concreta de uma linguagem.

Por exemplo, considere a declaração de classes nos diagramas UML. A Figura 4 mostra uma simplificação do Meta-modelo de UML referente à classe. Observando essa simplificação po-demos notar que esse meta-modelo especifica que toda Classe (Class) em UML deve possuir: Nome (Name) do tipo String e possuir 0(zero) ou mais atributos (Attribute). A Figura 5 mostra um modelo concreto de uma classe em UML. Podemos perce-ber que esse modelo especifica: Nome da classe (DataHandler), e o atributo que essa classe possui (self ).

Para ilustrar a aplicação de Meta-modelos, considere a UML. Com UML podemos descrever o modelo de uma aplicação qualquer. Por exemplo, podemos descrever um sistema web, especificando cada classe que trata a sessão no servidor, o aces-so ao banco de dados, etc. Já o meta-modelo de UML descreve como os modelos UML devem ser constituídos. Especificando, por exemplo, que toda classe deve possuir um nome, pertencer a um pacote, etc.

Há várias linguagens propostas para descrever meta-mode-los, chamadas meta-linguagens. Alguns exemplos de meta-linguagens são: MOF (Meta Object Facility), Ecore, KM3 (Kernel Meta Meta Model), etc. O padrão de meta-metalinguagem proposto pela OMG é MOF. Ela foi usada, por exemplo, para definir o meta-modelo de UML, OCL (Object Constraint Lan-guage) e os outros Meta-modelos propostos pela OMG.

Figura 4. Simplificação Meta-modelo de UML para Classe

Figura 5. Exemplo de um modelo de uma classe de acordo com o Meta-modelo simplificado

Transformações entre ModelosMDA possui um alto potencial de automação alcançado

através de transformações entre modelos, especialmente en-tre os modelos PIM, PSM e o código em sintaxe concreta. As transformações definem como os modelos de entrada podem ser mapeados para os modelos de saída, baseados nos seus meta-modelos. Por exemplo, a partir de um PIM de um sistema web, podemos executar algumas transformações sobre ele para gerarmos os PSMs descrevendo a implementação desse sistema usando EJB, outras transformações para criar o banco de dados relacional do sistema, e assim por diante. O mesmo acontece para as transformações textuais sendo que ao invés de modelos de saída, são gerados artefatos em sintaxe concreta.

A infraestrutura para as transformações em MDA possuem basicamente três elementos:• Linguagem de Transformação: assim como existem os meta-modelos que descrevem os modelos, existem as linguagens de transformação que definem como as transformações devem ser definidas. Elas podem ser classificadas em vários tipos: transformações declarativas, transformações imperativas, transformações por templates, transformações textuais, etc. Alguns exemplos de linguagens que podem ser usadas como linguagens de transformações são: QVT (Queries / Views / Transformations), que são transformações declarativas e im-perativas; ATL (ATLAS Transformation Language), também declarativas e imperativas; linguagens de programação, que são transformações imperativas; XSLT (XSL Transformations), que são transformações textual; JET, que são transformações por templates; etc. A linguagem de transformação padrão proposto pela OMG é QVT, sendo que ATL apesar de não ser o padrão da OMG, está em conformidade com todos os padrões propostos por ela, como UML, MOF e OCL;• Definição da Transformação: são as transformações escritas nas linguagens citadas anteriormente que, baseadas nos meta-modelos dos modelos de entrada, geram os modelos de saída,

Page 32: Www.superdownload.us ES35

32 Engenharia de Software Magazine - Introdução à verificação de diagramas de classe – Parte 1

também baseados em seus meta-modelos. É através dessas transformações que é definido como um PIM (por exemplo, o sistema web) vai gerar um PSM (a implementação do sistema em EJB), por exemplo;• Ferramentas de Transformação: são as ferramentas que dão suporte à execução das transformações. Alguns exemplos que podemos citar são: para executar transformações em QVT pode ser usado o Borland Together; para transformações ATL, o ATL-DT; para transformações XSLT, o Xalan; entre outros.

Transformações não se restringem somente a transformar de PIM para PSM e de PSM para o código em sintaxe concreta. Elas podem ser concebidas para transformar de qualquer nível de modelo para qualquer outro, inclusive para o mesmo nível (por exemplo, transformações de PSM em PSM executando algum refatoramento entre nesses modelos).

Arquitetura quatro camadas da OMGA OMG usa uma arquitetura de quatro camadas para mos-

trar os papéis dos seus padrões em MDA: Metameta-modelo, Meta-modelo, Modelos e Transformações. Na terminologia da OMG estas camadas são chamadas M0, M1, M2 e M3, que são descritos a seguir:• Camada M0: As Instâncias. Esta camada trata as instâncias reais no sistema, seja como objetos na memória, tuplas do banco de dados, etc. Por exemplo, em um momento de um sistema web poderia existir um cliente com o nome “Sr. Madruga” que mora na “Avenida Brasília” na cidade “Cidade do México”;• Camada M1: O Modelo do Sistema. Essa camada contém os modelos do sistema, ou seja, abstrações das instâncias reais

do sistema. Por exemplo, considerando o sistema web tratado anteriormente, no M1 estaria o conceito da classe Cliente, com as suas propriedades nome, rua e cidade;• Camada M2: Os Modelos dos Modelos. Os elementos que existem na camada M1 (por exemplo, classes, atributos, etc.) são por si mesmo instâncias dos elementos da camada M2. Em outras palavras, M2 conteria o meta-modelo dos modelos da camada M1. No exemplo da camada M1, o M2 seria o meta-modelo de UML;• Camada M3: O Modelo dos Meta-modelos. Seguindo a mesma linha de raciocínio podemos considerar que os Modelos da camada M2 são instâncias de modelos de mais alto nível, os meta-meta-modelos. No caso do meta-modelo de UML, o meta-meta-modelo seria o meta-modelo MOF ou qualquer outro formalismo capaz de descrever o meta-modelo de UML, como o meta-modelo KM3, ECORE, etc.

Na Figura 6 podemos observar o framework completo de MDA. Com todos os seus elementos: os modelos, meta-modelos e transformações; e os relacionamentos entre eles na forma como definimos anteriormente.

Diagrama de classes da UML2A UML possui uma vasta gama de diagramas capazes de

descrever tanto a estrutura, quanto o comportamento de um sistema de software. Dentre esses diagramas um amplamente adotado para descrever a estrutura de sistemas é o Diagrama de Classes. Trata-se de uma representação gráfica de uma visão estática do sistema que mostra uma coleção declarativa de elementos, tais como classes, pacote, entre outros, além de seus conteúdos e relacionamentos. Um diagrama de classes pode possuir certos elementos comportamentais, tais como operações. Contudo, o comportamento desses elementos só é expresso através de outros diagramas, ou artefatos.

Normalmente, são construídos vários diagramas de classes para mostrar a visão estática completa de todo um sistema. Diagramas de classes individuais necessariamente não significam divisões no modelo do sistema, mas podem somente mostrar divisões ló-gicas tais como pacotes ou diferentes perspectivas do sistema.

Dado o fato da UML2 ser bastante abrangente, o número de arte-fatos que podem ser usados no diagrama de classes, e as caracte-rísticas desses artefatos, é extenso. Por esse motivo, destacaremos nesse artigo os mais relevantes para nossa série de artigos.

ClasseClasse representa um conceito com a qual a aplicação pode

ser modelada. Uma classe é um descritor para um conjunto de objetos que compartilha os mesmos atributos, operações, relacionamentos e comportamentos. Uma classe pode modelar entidades físicas (como aviões, carros, pessoas, etc.), entidades da lógica do negócio (como um acordo, pessoa jurídica, etc.), entidades lógicas (como algoritmo, etc.), entidades da própria aplicação (como uma sessão, um formulário, etc.), entidades computacionais (como uma tabela hash) ou entidades compor-tamentais (como uma tarefa). Figura 6. Framework de MDA

Page 33: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 33

QUALIDADE DE SoFt WARE

A Figura 7 mostra um exemplo de uma classe, destacando algumas das características pertencentes à classe:1. nome (name): toda classe deve possuir um nome único que a identifique. Esse nome é formado com a composição do nome da classe, junto com o nome da hierarquia de entidades na qual ela está contida, normalmente um pacote, mas pode ser outra classe também;2. visibilidade (visibility): as classes possuem uma visibi-lidade relacionada à entidade na qual ela está contida. Essa visibilidade especifica como essa classe pode ser acessada pelas outras classes. Em UML existem quatro tipos de visibilidades predefinidas: public, significando que qualquer entidade que consiga alcançar o container da classe pode ver essa classe; protected, somente os elementos do próprio container e os dos subcontainers podem ver essa classe; private, somente a entidade proprietária desse elemento pode ter acesso a ele; package, somente os elementos do mesmo pacote ou dos subpacotes podem ver essa classe;3. super classes (superClass): UML segue o paradigma de orientação a objeto, portanto uma classe pode herdar de outra recebendo da classe pai toda a estrutura, relacionamentos e com-portamentos dela. UML permite generalizações múltiplas;4. classe abstrata: é uma característica que sinaliza se a classe pode ou não ser instanciada;5. interfaces realizadas (realizedInterface): interface é um padrão de comportamento para algumas entidades do projeto. Uma classe pode realizar várias interfaces simultaneamente.

OperaçãoUma operação especifica uma transformação no estado do

objeto possuidor da operação (e possivelmente no estado do resto do sistema alcançável por esse objeto) ou uma consulta com o valor de um dado acessível através desse objeto.

A Figura 8 mostra um exemplo de uma operação, destacando as características pertencentes à operação:1. assinatura: toda operação possui um nome único formado por vários elementos dentre. Nesta série de artigos conside-ramos como assinatura formada por três elementos: nome da operação, o nome dos parâmetros e o nome dos tipos dos parâmetros da operação;2. visibilidade: as operações possuem uma visibilidade que especifica quais outras entidades podem ter acesso a ela;3. tipo do retorno: é o tipo do valor retornado quando essa operação é invocada. Uma operação pode retornar um tipo do próprio projeto do sistema, um tipo primitivo ou não retornar nada (void);4. escopo: especifica a qual escopo essa operação pertence, ou seja, se ela pertence a qualquer instância de uma classe (classi-fier) ou somente a uma instância específica (instance).

AtributoUm atributo representa uma propriedade que todas as

instâncias de uma classe podem conter. Uma classe pode ter qualquer número de atributos, que podem ser resgatados ou capturados durante a execução de alguma operação.

A Figura 9 mostra um exemplo de um atributo, destacando as características pertencentes a atributo:1. nome: é um valor usado para identificar um atributo. Cada Atributo deve possuir um nome único aos moldes do que foi tratado em classe;2. visibilidade: especifica quais outras entidades do projeto podem ter acesso ao atributo;3. tipo: designa uma classe ou tipo de dado que o valor desse atributo deve obedecer;4. escopo: especifica a qual escopo esse atributo pertence, ou seja, se ele pertence a qualquer instância de uma classe (clas-sifier) ou somente a uma instância específica (instance).

InterfaceUma interface é uma coleção de operações que especificam

serviços de uma classe ou componente, descrevendo o com-portamento dessas entidades visível externamente. Raramente aparece sozinha, em geral são anexadas à classe ou ao compo-nente que a realiza. Elas são completamente abstratas, e não especificam qualquer estrutura (não podem incluir atributos) nem qualquer implementação.

A Figura 10 mostra um exemplo de uma interface, destacando as características pertencentes à interface que consideraremos ao longo desta série de artigos:1. nome: toda interface deve possuir um nome único que a identifique. O padrão de nomes deve seguir o mesmo que foi descrito para classe, anteriormente;2. visibilidade: especifica quais outras entidades do projeto podem realizar ou herdar dessa interface;

Figura 7. Características da classe

Figura 8. Características de operações

Figura 9. Características de atributos

Page 34: Www.superdownload.us ES35

34 Engenharia de Software Magazine - Introdução à verificação de diagramas de classe – Parte 1

Figura 10. Características de interface consideradas

3. herança: UML permite que uma interface herde de outras interfaces fazendo com que a interface filha possua não só as operações contidas nela, mas também as contidas nas interfaces mãe. Sendo assim, se uma classe realizar a interface filha, ela deve, além de implementar os métodos da interface realizada, realizar os métodos das interfaces mãe.

PacoteUm pacote é um agrupamento de elementos de um dia-

grama. Esses elementos podem ser quaisquer elementos de modelagem, incluindo outros pacotes. Ele tem a função de ser um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos.

A Figura 11 mostra um exemplo de um pacote, destacando as características pertencentes a pacote que serão consideradas nesta série de artigos:

1. nome: um valor único usado para identificar o pacote. A hie-rarquia de nomes segue a mesma mostrada para a hierarquia de nomes de classes mostrado anteriormente;2. elementos: são os elementos que estão agrupados neste pacote; 3. relacionamentos: nesse artigo tratamos especialmente de dois relacionamentos, «access» e «import». O relacionamento access significa que os elementos do pacote de origem podem acessar os serviços e estender (ou seja, especializar ou realizar) os elementos do pacote destino. O relacionamento «import» possui a mesma semântica do relacionamento «access» com o diferencial de que os elementos do pacote origem pode ainda acessar os serviços e estender os elementos dos pacotes que o pacote destino acessa ou importa.

AssociaçãoUma associação é um relacionamento entre duas ou mais

classes que descreve uma conexão entre elas. Uma mesma classe pode participar de várias associações ou até mesmo de uma mesma associação várias vezes. A função da associação é interconectar o sistema que está sendo projetado de forma que o esse sistema funcione e faça sentido.

A Figura 12 mostra um exemplo de uma associação, desta-cando as características pertencentes à associação que serão consideradas:1. nome: as associações possuem nomes para serem identifica-das. A identificação de uma associação é através do seu nome e dos nomes dos elementos que fazem parte da associação;2. membros: são os elementos (MemberEnd) que fazem parte da associação; 3. visibilidade: essa propriedade diz respeito a cada Member End da associação. Ela especifica quais outras entidades do projeto podem acessar cada MemberEnd;4. somente leitura: assim como a propriedade anterior, essa diz respeito a cada MemberEnd da associação. Ela especifica que os elementos que acessam essa associação podem somente ler o MemberEnd, contudo não podem modificá-lo;5. multiplicidade: essa propriedade especifica a quantidade de elementos que podem estar envolvidos na associação; 6. papel: descreve o nome que como o qual cada membro da associação (MemberEnd) pode acessar outro membro (MemberEnd).

Teste de DesignUm teste é uma atividade executada para avaliar a qualidade

de um produto, ou para melhorar esse produto identificando defeitos e problemas. Existem vários tipos de testes, alguns que podemos citar são: testes de unidade, que verificam se um programa (ou parte dele) possui um comportamento esperado; testes de cobertura, que verificam o quão o código está testado; dentre outros.

Dentre vários tipos de teste existentes, um deles é o Teste de Design. Eles são regras especificadas na forma de algoritmos que verificam propriedades do design de um código implemen-tado. Essas propriedades devem ser providas a partir do design

Figura 11. Características de pacotes consideradas

Figura 12. Características de associações consideradas

Page 35: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 35

QUALIDADE DE SoFt WARE

do software, seja a partir de um modelo conceitual presente somente na cabeça do projetista do sistema, seja através de uma série de diagramas UML que descrevem o sistema.

Testes de design se assemelham a testes de integração, pois ambos verificam se um código implementado mantêm as carac-terísticas do projeto do software. Porém, os testes de integração verificam se o código desenvolvido mantêm uma determinada funcionalidade projetada. Já teste de design verifica se a estru-tura desse código segue uma estrutura pré-determinada, sem considerar as funcionalidades que esse código possa ter.

Para desenvolver testes de design são necessários dois com-ponentes chave: (1) Analisador da estrutura do código, uma ferramenta capaz de extrair e disponibilizar informações sobre as entidades presentes no código, e seus relacionamentos; (2) Framework de teste, um framework capaz de colher infor-mações do extrator e verificar se elas condizem com o design esperado do software.

Nesse sentido, adotaremos uma infraestrutura para a cons-trução de testes de design para testar programas na linguagem Java. Para o analisador da estrutura do código adotamos uma biblioteca chamada Design Wizard. E como framework de teste foi adotado o JUnit. A ideia central dos testes de design é usar a biblioteca Design Wizard para extrair a estrutura do código do sistema a ser testado, e usando o framework JUnit, verificar se a estrutura extraída possui a estrutura esperada. A Listagem 1 mostra um exemplo de teste de design, que verifica para dado o sistema project (linhas 2-3) existe uma classe chamada A (li-nhas 4-5) e ainda se a classe A não invoca diretamente nenhum método ou atributo da classe B (linhas 6-8).

DesignWizardDesignWizard é uma biblioteca escrita em Java para dar su-

porte à realização de testes de design sobre aplicações também desenvolvidas em Java. Para a realização dos testes de design essa biblioteca atua como o analisador da estrutura do código. Ela é responsável por extrair informações sobre o código, or-ganizar essas informações e expô-las através de uma API que ofereça métodos para a aquisição dessas informações.

A Figura 13 descreve a arquitetura do DesignWizard. Essa ferramenta é composta por um extrator, um tradutor, um ge-renciador do design extraído e a API do DesignWizard.

O componente extrator usa o manipulador de bytecode ASM que é uma ferramenta que usa análise estática do código para ob-ter as instruções do bytecode da aplicação. O componente tradutor recebe as instruções do bytecode e as traduz para uma notação mais fácil de ser compreendida e manipulada por humanos.

As informações produzidas pelo tradutor são passadas para o gerenciador do design extraído. Este componente organiza essas informações na forma de um grafo, sendo os nós desses grafo as entidades presentes no código (classe, atributo, méto-do, etc.) e as arestas os relacionamentos entre essas entidades. Por exemplo, se uma classe C possuir os atributos a, b, então serão criados três nós, um para cada entidade, além disso, serão criadas duas arestas, uma entre o nó da classe C e o atributo a e outra entre os nós de C e b. Por fim, as informações sobre

Listagem 1. Exemplo de Teste de Design.

1 public void testCommunication() {2 DesignWizard dw;3 dw = new DesignWizard(“project.jar”);4 designwizard.ui.Classclazz;5 clazz = dw.getClass(“A”);6 Set<String> usedBy;7 usedBy = clazz.getClassesUsedBy();8 assertFalse(usedBy.contains(“B”));9 }

essa estrutura de dados podem ser acessadas através da API do DesignWizard. Essa API funciona como fachada entre a re-presentação do código e os testes de design usando o JUnit.

Destacamos algumas métodos da API do Design Wizard, mais informações podem ser encontradas no JavaDoc do Design Wizard.

A principal entidade da API do Design Wizard é a DesignWi-zard. Dentre os métodos dessa entidade destacamos:• new DesignWizard(caminhoDoProjeto:String). É um mé-todo construtor responsável por extrair a estrutura do código passado como parâmetro;• getClass(nomeDaClasse:String):ClassNode. Recupera da estrutura extraída uma representação da classe com o nome passado por parâmetro;• getPackage(nomeDoPacote:String):PackageNode. Recupera da estrutura extraída uma representação do Pacote com o nome passado por parâmetro.

Para representar uma classe ou interface o Design Wizard usa a entidade ClassNode. Dentre os métodos dessa entidade destacamos:• getSuperClass():ClassNode. Se a entidade for uma classe, esse método extrai do código a super classe da classe a qual o método foi invocado;• getModifiers():Modifier. Esse método é responsável por extrair do código a visibilidade da entidade;• isAbstract():boolean. Esse método é responsável por expor se a entidade extraída é ou não abstrata;

Figura 13. Arquitetura do DesignWizard

Page 36: Www.superdownload.us ES35

36 Engenharia de Software Magazine - Introdução à verificação de diagramas de classe – Parte 1

• isInterface():boolean. Esse método é responsável por expor se a entidade extraída é uma classe ou uma interface;• getImplementedInterfaces():Set<ClassNode>. Esse método é responsável por extrair do código todas as interfaces que são implementadas (se a entidade for uma classe) ou estendida (se a entidade for uma interface);• getMethod(nomeDoMetodo:String):MethodNode. Esse método é responsável por extrair da classe, um método com a mesma assinatura passada por parâmetro.

Para representar um método o Design Wizard usa a entidade MethodNode. Dentre os métodos dessa entidade destacamos:• getReturnType():ClassNode. Esse método é responsável por extrair do método o seu tipo de retorno;• isAbstract():boolean. Esse método é responsável por expor se o método extraído é ou não abstrato; • isStatic():boolean. Esse método é responsável por expor se o método extraído é ou não estático; • getModifiers():Modifier. Esse método é responsável por extrair do código a visibilidade do método.

Para representar um atributo o Design Wizard usa a entidade FieldNode. Dentre os métodos dessa entidade destacamos:• getDeclaredType():ClassNode. Esse método é responsável por extrair do atributo o seu tipo;• isAbstract():boolean. Esse método é responsável por expor se o atributo extraído é ou não abstrato;

1. The peer-review process. Learned Publishing, 15:247–258, Outubro 2002.

2. Altova UModel. http://www.altova.com/products/umodel/.

3. AMMA Project. Atlas Transformation Language, 2005. http://www.sciences.univnantes.fr/lina/atl/.

4. Anneke Kleppe, Jos Warmer e Wim Bast. MDA Explained: The Model Driven Architecture—

Practice and Promise. Addison-Wesley, 2003.

5. Api java 2 platform se v1.4.2, interface runnable. http://java.sun.com/j2se/1.4.2/docs/api/java/

lang/Runnable.html.

6. ArgoUML. http://argouml.tigris.org/.

7. Asm bytecode manipulation. http://asm.objectweb.org/.

8. ATL-DT. http://www.eclipse.org/m2m/atl/.

9. B. Hailpern and P. Tarr. Model-driven development: The good, the bad, and the ugly. IBM Systems

Journal, 45(3):451–461, 2006.

10. Borland Together. http://www.borland.com/br/products/together/.

11. Clint Morgan, Kris De Volder e Eric Wohlstadter. A static aspect language for checking design

rules. Em Brian M. Barry e Oege de Moor, editors, AOSD, volume 208 of ACM International Conference

Proceeding Series, páginas 63–72. ACM, 2007.

12. James J. Horning e Yang Meng Tan David Evans, John V. Guttag. LCLint: A tool for using

specifications to check code. Em Symposium on the Foundations of Software Engineering,

Dezembro 1994.

13. David H. Akehurst, Gareth Howells e Klaus D. McDonald-Maier. Implementing associations: UML

2.0 to java 5. Software and System Modeling, 6(1):3–35, 2007.

14. David Lorge Parnas. Software aging. Em Bruno Fadini, editor, Proceedings of the 16th

International Conference on Software Engineering, páginas 279–290, Sorrento, Italy, Maio 1994.

IEEE Computer Society Press.

15. Design Wizard. http://www.designwizard.org.

16. Ecore. http://www.eclipse.org/modeling/emf/?project=emf.

17. Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides. Design Patterns Elements of

Reusable Object-Oriented Software. Addison-Wesley, Massachusetts, 2000.

18. Len Erlikh. Leveraging legacy system dollars for E-business. IT Professional, 2(3):17–23, 2000.

19. Find Bugs. http://findbugs.sourceforge.net/.

20. Frédéric Jouault e Jean Bézivin. KM3: a DSL for metamodel specification. Em IFIP Int. Conf.

on Formal Methods for Open Object-Based Distributed Systems, LNCS 4037, páginas 171–185.

Springer, 2006.

21. Gail C. Murphy, David Notkin e Kevin Sullivan. Software re exion models: Bridging the gap

between source and high-level models. Em G. Kaiser, editor, Proc. 3rd ACM SIGSOFT Symp. on the

Foundations of Software Engineering, volume 20:4 of ACM SIGSOFT Software Engineering Notes,

páginas 18–28, Washington, DC, Outubro 1995.

22. Object Management Group. Meta object facility (MOF) specification. Technical Report ad/97-

08-14, Object Management Group, 1997.

Referências

• isStatic():boolean. Esse método é responsável por expor se o atributo extraído é ou não estático;• getModifiers():Modifier. Esse método é responsável por extrair do código a visibilidade do atributo.

Para representar um pacote o Design Wizard usa a entidade PackageNode. Dentre os métodos dessa entidade destacamos:• getAllClasses():Set<ClassNode>. Esse método é responsável por extrair do pacote todas as entidades pertencentes a ele ou a seus subpacotes.

Conclusão Com isto finalizamos este primeiro artigo de nossa série sobre

verificação de diagramas de classe. Nesta primeira parte foca-mos nossa discussão na apresentação dos principais conceitos que utilizaremos nesta série de artigos. Até a próxima.

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

seu Feedback

sob

re esta edição

Page 37: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 37

QUALIDADE DE SoFt WARE

23. Object Management Group. Mof model to text transformation language. Technical Report

ad/2004-04-07, Object Management Group, 2004.

24. JAS-metamodel. http://www.eclipse.org/gmt/am3/zoos/atlanticZoo.

25. Jesse E. Tilly e Eric M. Burke. Ant: The Definitive Guide. O’Reilly & Associates, Inc., pub-ORA:adr, 2002.

26. Java Emitter Templates. http://www.eclipse.org/articles/Article-JET/.

27. Jilles van Gurp e Jan Bosch. Design erosion: problems and causes. The Journal of Systems and

Software, 61(2):105–119, Março 2002.

28. Dalton Guerrero e Jorge Figueiredo João Brunet. Design tests: An approach to programmatically

check your code against design rules. Em Proc. 31th International Conference on Software

Engineering (ICSE 2009), New Ideas and Emerging Results, Maio 2009.

29. John Robert Taylor. An introduction to error analysis: The study of uncertainties in physical

measurements. páginas 128–129. University Science Books, 199.

30. JUnit. http://www.junit.org.

31. Len Bass, Paul Clements e Rick Kazman. Software Architecture in Practice. Addison Wesley, 1998.

32. MagicDraw UML. http://www.magicdraw.com/.

33. Mark Utting e Bruno Legeard. Practical Model-Based Testing: A Tools Approach. Morgan-

Kaufmann, 2006.

34. MDT OCL. http://www.eclipse.org/modeling/mdt/?project=ocl.

35. MOFScript. http://www.eclipse.org/gmt/mofscript/.

36. MySQL. http://www.mysql.com/.

37. Yann-Gael Gueheneuc e Pierre Leduc Naouel Moha. Automatic generation of detection

algorithms for design defects. Em ASE ’06: Proceedings of the 21st IEEE International Conference

on Automated Software Engineering (ASE’06), páginas 297–300, Washington, DC, USA, 2006. IEEE

Computer Society.

38. Nathaniel Ayewah, William Pugh, J. David Morgenthaler, John Penix e YuQian Zhou. Using

findbugs on production software. Em Richard P. Gabriel, David F. Bacon, Cristina Videira Lopes, e

Guy L. Steele Jr, editors, OOPSLA Companion, páginas 805–806. ACM, 2007.

39. Object Management Group. http://www.omg.org/.

40. Object Management Group, Framingham, Massachusetts. UML 2.0 Superstructure Specification,

Outubro 2004.

41. Object Management Group. MOF, 2006. http://www.omg.org/cgi-bin/doc?ptc/2005-11-01.

42. Object Management Group. The OCL 2.0 Specification, 2006. http://www.omg.org/technology/

documents/formal/ocl.htm.

43. OMondo - Eclipse UML. http://www.eclipsedownload.com/.

44. P. A. Stocks e D. A. Carrington. Test templates: a specification-based testing framework. Em

Proceedings of the 15th International Conference on Software Engineering, páginas 405–414.

IEEE Computer Society Press, April 1993.

45. Philippe Kruchten, Patricia Lago e Hans van Vliet. Building up and reasoning about architectural

knowledge. Em Christine Hofmeister, Ivica Crnkovic, e Ralf Reussner, editors, QoSA, volume 4214 of

Lecture Notes in Computer Science, páginas 43–58. Springer, 2006.

46. Poseidon for UML. http://www.gentleware.com/.

47. Ian Sommerville. Software Engineering. Addison-Wesley, 7th edition, 2004.

48. Stephen Eick, Todd Graves, Alan Karr, J. Marron e Audris Mockus. Does code decay? assessing the evidence

from change management data. IEEE Transactions on Software Engineering, 27(1):1–12, 2001.

49. Trung T. Dinh-Trong, Nilesh Kawane, Sudipto Ghosh, Robert B. France e Anneliese Amschler

Andrews. A tool-supported approach to testing UML design models. Em ICECCS, páginas 519–528.

IEEE Computer Society, 2005.

50. UDT - UML Design Tester. http://www.designwizard.org/index.php/UDT/.

51. Victor R. Basili, Gianluigi Caldiera e H. Dieter Rombach. Goal Question Metric Paradigm. Em

John J. Marciniak, editor, Encyclopedia of Software Engineering, volume 1, páginas 528–532.

John Wiley & Sons, 1994.

52. Visual Paradigm for UML. http://www.visual-paradigm.com/product/vpuml/.

53. Franklin Ramalho e Dalton Serey Waldemar Pires, Jo/ ao Brunet. Uml-based design test

generation. Em SAC ’08: Proceedings of the 2008 ACM symposium on Applied computing, páginas

735–740, New York, NY, USA, 2008. ACM.

54. William Wesley Peterson. Introduction to Programming Languages. Prentice Hall, Englewood

Cliffs, 1974.

55. Wolfgang Hesse. RUP - A process model for working with UML. Em Unified Modeling Language:

Systems Analysis, Design and Development Issues, páginas 61–74. 2001.

56. Xalan-Java Version 2.7.1. http://xml.apache.org/xalan-j/.

57. XSL Transformations. http://www.w3.org/TR/xslt/.

58. Rémi Douence e Pierre Cointe Yann-Gael Guéhéneuc, Hervé Albin-Amiot. Bridging the gap

between modeling and programming languages. Technical report, Computer Science Department,

École des Mines de Nantes, 2002.

Referências

Page 38: Www.superdownload.us ES35

38 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

Gizelle Sandrini Lemos([email protected])

Cursou graduação e mestrado em Ciência da Computação na UFSCar, especializando-se em engenharia de software. Tem sólida experi-ência em reengenharia de sistemas legados. Participou de consultoria para melhoria de processos de software utilizando modelos CMM e ISO 9000 em empresas de pequeno porte. Desenvolvedora, com larga experiência em orientação a objetos, em Delphi e Java. Atualmente cursa o último ano do doutorado em Ciência da Computação na Unicamp, com pesquisa na área de testes de software.

Giuliano Prado de Morais Giglio([email protected])

É desenvolvedor Delphi desde 1997, com ampla experiência em aplicações Win32. Gra-duado em Informática pela UFJF, com Espe-cialização em Desenvolvimento de Aplicações para Web pelo Centro de Ensino Superio de Juiz de Fora/MG, e Mestrado em Computação pela UFF/Niterói-RJ. Atualmente é professor universitário em diversas instituições, em cursos de Sistemas de Informação, e atua como consultor, pesquisador e desenvolvedor de aplicações Java, sobretudo na plataforma J2EE para Web, e J2ME, sendo especialista em aplicações Mobile.

De que se trata o artigo?Manutenção de software evolutiva e adaptativa. Neste contexto, apresenta a aplicação dos padrões para reen-genharia de software orientado a objeto.

Para que serve?Ampliar o conhecimento sobre reengenharia de software, saber identificar e aplicar Padrões para a Reengenharia, auxiliar os gerentes de projeto em TI e Analistas de Sistemas na adoção de reengenharia de sistemas legados procedimentais para o paradigma orientado a objetos.

Em que situação o tema é útil?Na avaliação de um re-projeto de um sistema lega-do procedimental, no apoio à melhoraria da quali-dade dos processos de software e do planejamento de questões administrativas em projetos de TI, e na garantia da qualidade do processo de reengenharia de software orientado a objetos.

Reengenharia de software orientado a objetosAplicando padrões na prática em busca da garantia de qualidade

Engenharia

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

Na edição 33 da Engenharia de Software Magazine, apresen-tamos os principais conceitos

sobre a reengenharia de sistemas orien-tados a objetos de sistemas legados, com a abordagem de padrões de melhoria da qualidade deste processo. O Fusion/RE foi criado a partir do método Fusion com o objetivo de recuperar o projeto de softwares legados procedimentais em uma forma orientada a objetos.

A experiência adquirida com a utiliza-ção do Fusion/RE em alguns sistemas norteou a sua evolução para o PRE/OO, que é um Processo de Reengenharia Orientada a Objetos com Ênfase na Garantia da Qualidade, proposto por Lemos (2002).

Essa evolução se fez necessária, pois a aplicação do método nem sempre pode ser feita de forma sequencial, como demonstrado no artigo anterior. O uso do Fusion/RE vem ocorrendo de forma evolutiva devido à necessidade do re-torno, algumas vezes, aos passos ante-riores para tornar seus resultados mais

completos. Porém, tem-se a necessidade de que um processo de reengenharia seja planejado e avaliado.

Dessa forma, o PRE/OO foi criado baseado nos clusters 2, 3 e 4, técnicas do Fusion/RE. A Figura 1 ilustra o proces-so de reengenharia orientada a objetos

Page 39: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 39

PRoJEto

denominado PRE/OO, o qual é organizado em sete clusters de padrões. Alguns padrões foram adaptados a partir da Família de Padrões para Reengenharia Orientada a Objetos proposta por RECCHIA (2002a), para a obtenção dos modelos de análise orientados a objetos, comprovando que o modelo evolutivo é o mais adequado.

Os clusters de padrões do PRE/OO dividem-se em:• padrões para a realização da reengenharia orientada a ob-jetos (clusters 3 a 7);• padrões para a melhoria da qualidade da reengenharia (clusters 1 e 2).

O PRE/OO foi desenvolvido para que engenheiros de sof-tware possam realizar a reengenharia orientada a objetos, inicialmente de softwares Delphi sem documentação e/ou desenvolvidos de forma não orientada a objetos. Assim, esses sistemas podem ter sua documentação recuperada e passam a refletir a forma orientada a objetos, mais estruturada e com maior capacidade de reuso de seus módulos.

Através da aplicação do PRE/OO obtém-se, num primeiro momento, O MASA (Modelo de Análise do Sistema Atual) que reflete a implementação legada e norteia o processo de reengenharia que resulta no MAS (Modelo de Análise do Sis-tema). O MAS contém a documentação completa que auxilia a engenharia avante orientada a objetos do sistema legado.

Ressalta-se que o PRE/OO pode ser considerado um processo genérico no que diz respeito à realização da reengenharia em softwares legados. Porém, podem ser necessárias algumas adaptações para a condução da reengenharia orientada a obje-tos em softwares legados desenvolvidos em outras linguagens procedimentais.

Para ilustrar sua aplicação, este artigo descreve o estudo de casos conduzido por Gizelle Lemos em (Lemos, 2002), de forma a exemplificar seu processo de implementação. Assim, trabalharemos a partir de agora em um aspecto prático dos conceitos iniciados na edição 33 da Engenharia de Software Magazine, e complementados neste.

Descrição do Software LegadoO software ControleGlobal para Lojas possui cerca de 20.000

linhas de código Delphi e foi desenvolvido por um programa-dor com experiência nas linguagens procedimentais Pascal, Clipper e C. Apesar do ambiente Delphi ter Object Pascal como linguagem de programação, que permite uma implementação totalmente de acordo com o paradigma orientado a objetos, o sistema foi desenvolvido seguindo a forma procedimental.

O software legado tem como funcionalidade principal a ges-tão do estoque e dos crediários de pequenas empresas do setor de comércio de vestuário. Um resumo de suas funcionalidades é descrito a seguir:• Caixa: o caixa diário é controlado, sendo sua movimentação proveniente da entrada de pagamentos de parcelas de credi-ários e de vendas efetuadas. Um relatório pode ser gerado com toda a movimentação diária do mesmo, caso solicitado pelo gerente;

Figura 1. Clusters de Padrões do PRE/OO

• Clientes: permite a inclusão, a atualização de dados e a exclusão de clientes cadastrados, além de conter funções de busca e de impressão de relatórios com informações perti-nentes, como por exemplo, a ficha cadastral completa de um determinado cliente;• Crediários: são consideradas como crediários as vendas de mercadorias aos clientes cadastrados, financiadas pela empresa em até cinco parcelas. Em caso de venda com pagamento em crediário, o valor das parcelas é calculado automaticamen-te pelo software, bem como os juros em caso de atraso no pagamento;• Estoque: as mercadorias comercializadas pela empresa são cadastradas em estoque e cada uma recebe um código que serve como identificador. Cada mercadoria tem seu preço médio controlado, proveniente dos custos de cada lote de mercadorias sob a quantidade total disponível. A frequência de saída e entrada de mercadoria também pode ser acompanhada por meio de relatórios. O estoque é dividido por cores e por grupos de mercadorias;• Fechamento: o fechamento de vendas, trocas e comissões dos vendedores é emitido a cada final de mês, em forma de diversos relatórios, para que se possa controlar os custos e lucros com relação a essas operações;• Trocas: as mercadorias vendidas pela empresa podem ser trocadas por outras, sendo que o software controla a entrada

Page 40: Www.superdownload.us ES35

40 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

e a saída de estoque quando essa operação ocorre, além do débito ou crédito decorrentes;• Vendas: a cada venda realizada, o software emite a nota fiscal correspondente, gerencia a saída de estoque, a inserção do registro do novo crediário (caso a venda não seja paga à vista) e faz o cálculo da comissão do vendedor;• Vendedores: são cadastrados e identificados por códigos emitidos pelo software, têm registrados seus créditos e débitos para com a empresa, além da comissão ganha durante o mês, a qual é calculada pelo software durante cada venda efetuada pelo vendedor a partir de porcentagem de ganho individual constante de seu cadastro.

Preparação e planejamento do processo de reengenharia com o PRE/OO

Cluster 1. Preparar e Planejar o Processo de ReengenhariaO processo de reengenharia orientada a objetos do software

legado ControleGlobal iniciou-se com a aplicação do cluster 1, de forma a prover a contextualização do projeto em questão, ou seja, o entendimento do projeto em seu domínio de aplicação seguido pelo planejamento das atividades contidas no PRE/OO.

Padrão 1: Preparar o Processo de ReengenhariaA preparação do processo de reengenharia para o software

legado, ControleGlobal, teve início com a definição dos limites

do projeto, o entendimento de seu escopo, a determinação dos produtos de trabalho a serem elaborados e das atividades a serem realizadas, ou seja, dos padrões necessários para a obtenção dos produtos desejados.

A partir da execução do sistema e do conhecimento de seu contexto pelo engenheiro de software, definiu-se e documen-tou-se o escopo do software legado no primeiro documento gerado a respeito do projeto, o qual se encontra ilustrado nas Figuras 2 e 3. Poderiam ser realizadas entrevistas com usuários e/ou utilizar-se outros produtos existentes, como manuais de operação, de forma a enriquecer as informações disponíveis;

Em seguida reuniram-se os demais produtos disponíveis a respeito do software, no caso, apenas o código-fonte e os ar-quivos de dados. Com essas informações foi possível definir quais os produtos de trabalho deveriam ser gerados e, a partir da descrição do PRE/OO, os padrões a serem aplicados para a elaboração de tais produtos.

A partir da elaboração do documento Levantamento de Ati-vidades, seguiu-se a determinação de como a reengenharia orientada a objetos do software legado seria realizada. Para isso, foi aplicado o padrão 2.

Padrão 2: Planejar o Processo de ReengenhariaO planejamento do processo foi realizado de forma a dispor as

atividades documentadas, a partir da aplicação do padrão 1, de acordo com o tempo disponível para a realização do PRE/OO, como ilustrado pelo campo Tempo Disponível para o Processo, das Figuras 4, 5 e 6. Assim, realizou-se a divisão do tempo

Figura 2. Levantamento de Atividade

Figura 3. Levantamento de Atividades do Software Legado

Figura 4. Plano para realização da reengenharia

Page 41: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 41

PRoJEto

entre os clusters de padrões a serem aplicados, considerando-se os diversos produtos de trabalho a serem elaborados.

Essa distribuição do tempo disponível entre os diversos pa-drões a serem aplicados foi feita manualmente, sem a utilização de métricas de esforço, considerando o número e a complexi-dade dos produtos obtidos com a aplicação de cada padrão. A complexidade de cada produto foi estimada empiricamente, ou seja, a partir de experiências anteriores do engenheiro de software na elaboração do produto.

Informações sobre a equipe responsável pela realização do PRE/OO, bem como o papel de cada integrante, foram omitidas pelo fato do processo ter sido realizado apenas por um enge-nheiro de software. Em seguida, foram definidos os itens de configuração controlados durante o PRE/OO, além do próprio Plano para Realização da Reengenharia.

Após a aplicação do cluster 1, no qual foram realizados a preparação e o planejamento da reengenharia, teve início a en-genharia reversa, primeira etapa do PRE/OO. A seção seguinte ilustra como foram aplicados os padrões dos clusters 3 a 5, os quais compõem essa etapa. O cluster 2, referente à melhoria da qualidade da reengenharia é utilizado durante todo o processo e, portanto, não será apresentado isoladamente.

Realização da etapa de engenharia reversa do PRE/OO

Cluster 3. Revitalizar a Arquitetura do Software LegadoO primeiro passo da engenharia reversa segundo o PRE/

OO foi iniciado na data prevista, com a aplicação do padrão 6, Elaborar Lista de Procedimentos e Funções. Após a elaboração e inspeção da Lista de Procedimentos e Funções, foi iniciada a construção da Lista “Chama/Chamado Por”, com a aplicação do padrão 7, Elaborar Lista “Chama/Chamado Por”, a partir das units CaixaDM.pas e Caixa.pas as quais possuem juntas cerca de 500 linhas de código e 16 procedimentos.

A Lista “Chama/Chamado Por” foi parcialmente elaborada durante a primeira volta no ciclo evolutivo, sendo completada no decorrer da etapa de engenharia reversa com a identificação, em outras units, dos pontos de chamada dos procedimentos e funções identificadas.

Padrão 6: Elaborar Lista de Procedimentos e FunçõesA visualização parcial da Lista de Procedimentos e Funções

composta a partir de um trecho do código-fonte legado é ilustrada na Figura 7 e o documento correspondente à sua Inspeção de Garantia da Qualidade, na Figura 8.

O código-fonte apresentado à direita da Figura 7 mostra procedimentos da unit Main.pas classificados como eventos (Ev) e outros como privados (Pv). Verifica-se que, no exemplo, nenhum procedimento ou função foi declarado na seção public da unit Main. Essa classificação foi realizada para os demais procedimentos e funções do software distribuídos nas 31 units

Figura 5. Plano para realização da reengenharia – Parte 2

Figura 6. Plano para realização da reengenharia – parte 3

Page 42: Www.superdownload.us ES35

42 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

restantes, num total de 340 procedimentos e funções docu-mentados na versão 1.1 da Lista de Procedimentos e Funções, obtida após a inspeção.

Como forma de facilitar sua posterior localização, um nú-mero sequencial único foi atribuído a cada procedimento e função documentado na Lista de Procedimentos e Funções, visualizado na Figura 7, na coluna à esquerda do nome de cada procedimento. A inspeção de garantia da qualidade da Lista de Procedimentos e Funções foi realizada manualmente verificando se todas as units haviam sido percorridas, se todos os nomes de procedimentos e funções haviam sido trans-critos de forma correta e a classificação fornecida estava de acordo com a área da unit em que o procedimento ou função encontrava-se declarado.

Padrão 7: Elaborar lista “Chama/Chamado Por”A numeração sequencial elaborada durante a aplicação do

padrão 6 foi mantida na Lista “Chama/Chamado Por” como forma de facilitar o mapeamento, podendo ser visualizada na

Figura 7. Composição de parte da Lista de Procedimentos e Funções.

coluna à esquerda do nome e descrição do procedimento, na Figura 9.

A composição da Lista “Chama/Chamado Por” foi realizada em mais de uma etapa. Primeiro, foram documentadas as descrições dos procedimentos e funções e a coluna Chama. A coluna Chamado por de cada procedimento e função foi completada ao longo do processo de revitalização da arquitetura.

De forma a exemplificar sua composição, o trecho de código fonte acima da Lista “Chama/Chamado Por”, na Figura 8, cor-responde à chamada ao procedimento PegaProximoIdx dentro do código-fonte do procedimento MovimentoCaixaTableAfterIn-sert da unit CaixaDM.pas.

O trecho de código-fonte abaixo da Lista “Chama/Chamado Por” ilustra o procedimento MovimentoCaixaAfterInsert que não chama nenhum procedimento ou função. Na correspondente à parte da Versão 1.0 da Lista “Chama/Chamado Por”, a coluna Chamado Por referente ao procedimento InserirValorNoCaixa encontra-se em branco, tendo sido preenchida apenas na se-gunda etapa da revitalização da arquitetura (Figura 10).

Os procedimentos e funções referentes às demais units do software legado foram classificados na Lista “Chama/Chama-do Por” da mesma forma anteriormente apresentada, sendo criadas versões quando necessário conforme as modificações e inserções de chamadas existentes no código-fonte legado.

Todo o controle de configuração foi realizado aplicando-se o padrão 5, Controlar a Configuração. Dessa forma, foi iniciada a documentação da Lista de Controle de Configuração, como

Figura 8. Documento de inspeção de garantia de qualidade da Lista de Procedimentos e Funções Figura 9. Composição de parte da Lista “Chama/Chamado Por”

Page 43: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 43

PRoJEto

ilustra a Figura 11, propiciando ao engenheiro de software o controle de alterações das diversas versões necessárias de cada produto de trabalho gerado.

Ao final da elaboração da Lista “Chama/Chamado Por” foi realizada a inspeção de garantia da qualidade para melhoria da mesma, com a aplicação do padrão 4, Realizar Inspeção de Garantia da Qualidade. Nessa inspeção foram verificados, a partir da classificação de cada procedimento e função descrito (Ev, Pv ou Pb), a coluna Chama do procedimento ou função e, em seguida, a coluna Chamado Por.

Ao final da revitalização da arquitetura foi originada a primeira baseline do projeto (Figura 12), com os produtos elaborados e inspecionados durante a condução do passo. A seguir, foi realizada a Inspeção de Acompanhamento do Pro-cesso, com o objetivo de verificar se o Plano para Realização da Reengenharia estava sendo cumprido de forma efetiva. A Figura 13 ilustra o documento criado após a inspeção.

Cluster 4. Elaborar Modelo de Análise do Sistema AtualO segundo passo do PRE/OO, conduzido a partir da aplicação

dos padrões do cluster 4, trata da construção do Modelo de Aná-lise do Sistema Atual (MASA) e foi realizado após a conclusão da Lista “Chama/Chamado por” com o objetivo de prover uma visão pseudo-orientada a objetos do software legado.

Padrão 8: Modelar dados do software LegadoA aplicação desse padrão baseou-se nos arquivos de dados

contendo os scripts SQL das estruturas das tabelas de dados utilizadas pelo software. Após a análise das cláusulas contidas em cada um desses arquivos, foi construída a Lista de Tabelas e Chaves, como ilustra a Figura 14. Nela, visualiza-se, no primei-ro quadro, o arquivo de dados com o script SQL referente à ta-bela de dados “Caixa”. A partir desse arquivo, foram extraídos o nome, os atributos e a chave primária da tabela de dados. O procedimento foi adotado para o script SQL com as informações referentes à tabela de dados “MovimentoCaixa”.

Figura 10. Visualização parcial da Versão 1.1 da Lista “Chama/Chamado Por”

Figura 11. Lista de Controle de Configuração referente ao passo de Revitalização da Arquitetura

Figura 12. Primeira baseline estabelecida durante a realização do estudo de caso

Figura 13. Documento de Inspeção de acompanhamento do Processo

A composição dessa lista foi realizada em duas etapas: • Obtiveram-se, a partir de cada arquivo, os nomes, atributos e chave(s) primária(s) das tabelas de dados e montaram-se, res-pectivamente, as colunas Tabela de Dados, Campos de Dados e Chave Primária da Lista de Tabelas e Chaves;• Percorreu-se a coluna Campos de Dados para cada tabela do-cumentada de forma a verificar se algum de seus atributos coin-cidia com a chave-primária de outra tabela. Em caso afirmativo, esse atributo foi transcrito para a coluna Chave Estrangeira;

Com base na Lista de Tabelas e Chaves foi elaborado o diagra-ma baseado no Modelo Entidade-Relacionamento (MER) para o estudo de caso. Cada tabela de dados originou uma entidade e todas as ocorrências de chaves estrangeiras originaram re-lacionamentos no DER (Diagrama Entidade-Relacionamento), como mostra a Figura 15. Após a composição do DER, foram aplicados os padrões 4 e 5, Realizar Inspeção para Garantia da Qualidade e Controlar a Configuração, de forma a controlar a qualidade do processo de reengenharia.

As cardinalidades do DER foram obtidas através da análise, por parte do engenheiro de software, do software legado e de

Page 44: Www.superdownload.us ES35

44 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

sua execução. Os tipos de relacionamentos entre as entidades foram obtidos através do exame das interfaces, observando-se o contexto dos relacionamentos.

Padrão 9: Criar Lista de AnomaliasA aplicação do padrão 9 deu origem à Lista de Anomalias,

que tem por objetivo mapear os acessos às tabelas de dados realizados nos procedimentos e funções descritos na Lista de Procedimentos e Funções, anteriormente criada. A Figura 16 ilustra sua composição, em que se pode notar que o procedi-mento MovimentoCaixaTableAfterInsert modifica o valor de um registro da tabela de dados “MovimentoCaixa” e, por esse motivo, é classificado como construtor (c), um procedimento ou função que altera a tabela de dados. Além disso, pode-se verifi-car o procedimento MovimentoCaixaTabelaAfterPost que observa o conteúdo das tabelas de dados “Caixa” e “Movimento Caixa”, sendo classificado como observador (o+), procedimento ou função que observa mais de uma tabela de dados.

Após a classificação de todas as anomalias relativas ao acesso a dados dos procedimentos e funções legados, foram realizadas a inspeção para garantia da qualidade e o controle de confi-guração necessário (aplicação dos padrões 4 e 5). Na inspeção foram observados, para cada procedimento e função, se o número e o critério de acesso às estruturas de dados estavam corretos. Outro item observado foi a classificação resultante da combinação dos diversos acessos às estruturas de dados.

A seguir, foi aplicado o padrão 10, Criar Visão OO dos Dados. Para isso, foram utilizados os produtos obtidos com a aplicação dos padrões anteriores desse cluster (padrões 8 e 9).

Padrão 10: Criar Visão OO dos DadosO objetivo da aplicação desse padrão é obter uma primeira

visão orientada a objetos do software procedimental, com a criação do Diagrama de Pseudo-Classes. A partir do DER e da Lista de Tabelas e Chaves, foram criadas as pseudo-classes

Figura 14. Composição da Lista de Tabelas e Chaves

Figura 15. Diagrama Entidade-Relacionamento do estudo de caso Figura 16. Composição da Lista de Anomalias

Page 45: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 45

PRoJEto

e seus atributos, como ilustra o destaque (b) da Figura 18. Os “métodos” de cada pseudo-classe foram originados a partir da Lista de Anomalias, como ilustra o destaque (a) da Figura 18.

Nota-se, no destaque (b) da Figura 18, que vários “méto-dos” são comuns a mais de uma pseudo-classe. Isso acontece porque eles têm operações de modificação e/ou observação às pseudo-classes envolvidas, ou seja, são anômalos. Os “métodos” que só ocorrem em uma pseudo-classe apenas consultando ou modificando seus dados, não possuem anomalias;

Os relacionamentos entre as pseudo-classes foram obtidos a partir do exame dos relacionamentos entre as entidades do DER, sendo ilustrados no Diagrama de Pseudo-Classes (Figura 17). A escolha do tipo de relacionamento (associação, agregação ou herança) foi realizada com base no contexto em que cada pseudoclasse estava inserida. Por exemplo, as entidades “Produtos”, “Estoque” e “Cor”, associam-se pelo relacionamento “TEM”, indicando que “Estoque” faz parte de “Produto” e “Cor” faz parte de “Estoque”, sugerindo dois relacionamentos por agregação.

A verificação se a agregação acontece por valor ou por referência foi feita analisando a ocorrência de dependência direta da pseudo-classe à outra a quem está agregada. No caso da pseudo-classe “Cor”, visualizada na Figura 17, não há dependência direta de “Estoque”, pois o registro de cada cor permanece gravado mesmo sem haver estoque cadastra-do, indicando uma agregação por referência. Já, o registro de estoque depende diretamente de haver produto cadastrado, indicando uma agregação por valor.

As associações refletem relacionamentos simples entre duas classes de mesmo nível. Durante a condução do estudo de caso, após a classificação das agregações, os demais relacionamentos foram classificados como associações.

Após a finalização do Diagrama de Pseudo-Classes foi feita a inspeção para a garantia da qualidade (padrão 4). Na inspeção foram verificados os seguintes aspectos: a distribuição dos métodos nas diversas pseudo-classes, a representatividade e as cardinalidades e os tipos dos relacionamentos. Não foram constatadas não-conformidades durante a inspeção, por esse motivo iniciou-se a aplicação do padrão 11, Criar Diagramas de Use Cases do MASA, com a elaboração dos Diagramas de Use Cases do MASA.

Padrão 11: Criar Diagramas de Use Cases do MASAAs bases para a composição dos Diagramas de Use Cases

foram as interfaces existentes e o código-fonte do software legado. Assim, cada interface do software legado gerou um ou mais use Cases. Um dos Diagramas de Use Cases gerados é ilustrado pela Figura 19, no qual percebe-se o destaque no use case CredBtnPgClick.

Os nomes dos use cases foram mantidos de acordo com a implementação, sendo modificados apenas no MAS, fato con-firmado a partir da Figura 20, em que visualiza-se o click no botão CredBtnPg originando o use case CredBtnPgClick.

Figura 17. Apresentação dos relacionamento no Diagrama de Pseudo-Classes

Figura 18. Composição das pseudo-classes

Page 46: Www.superdownload.us ES35

46 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

Terminada a elaboração dos Diagramas de Use Cases, foram feitas suas respectivas descrições.

Padrão 12: Descrever Use Cases do MASAA aplicação desse padrão baseou-se no escopo do software,

nas interfaces disponíveis e na execução do software legado. Vale salientar que outras fontes de informação podem ser utilizadas para compor tais descrições como, por exemplo,

Figura 19. Visualização parcial do Diagrama de Use Cases para o ator Cliente

Figura 20. Origem do Use Case CredBtnPgClick

Figura 21. Descrição do use case CredBtnPgClick

entrevistas com usuários, caso haja essa possibilidade. A des-crição do use case CredBtnPgClick, referenciado pela Figura 19, consta na Figura 21.

Essa descrição foi composta a partir da execução do softwa-re legado e da visualização do código-fonte. Nela, pode ser visualizada a origem do curso alternativo, executado quando se entra com um número de crediário não cadastrado no sistema.

As inspeções de garantia da qualidade para os diagramas e descrições gerados, foram efetuadas, aplicando-se o padrão 4. Nela, observou-se se todos os cursos alternativos haviam sido documentados e se o final de cada descrição de use case correspondia à realizada.

Ao fim do MASA foi realizada a inspeção de acompanha-mento de processo, aplicando-se o padrão 3. Na inspeção de acompanhamento foi detectado um pequeno atraso em relação ao tempo estimado para a conclusão do MASA. Porém, esse atraso não excedeu o tempo disponível para a reengenharia (70 dias), o que dispensou a tomada de ações corretivas. No caso da ocorrência de desvios consideráveis, o engenheiro de software responsável pelo planejamento do processo deve optar por redistribuir as atividades sem aumentar o tempo restante para o processo ou redimensionar o prazo limite para o final do projeto, conforme o atraso ocorrido e mover todas as atividades restantes de acordo com esse atraso. O registro da inspeção de acompanhamento do processo encontra-se ilustrado na Figura 22.

Após a realização da inspeção de acompanhamento de pro-jeto para a construção do MASA, foi estabelecida a segunda baseline, com a aplicação do padrão 5. A baseline encontra-se ilustrada na Figura 23.

A seção seguinte aborda a abstração do Modelo de Análise do Sistema Atual, a partir dos produtos obtidos com a aplicação dos padrões dos clusters 2 e 3, para a obtenção do Modelo de Análise do Sistema (MAS).

Cluster 5. Elaborar o Modelo de Análise do Sistema

Padrão 13: Abstrair Diagrama de Pseudo-ClassesO terceiro passo do PRE/OO, a obtenção do Modelo de Aná-

lise do Sistema (MAS), iniciado com a aplicação do padrão 13, analisou o contexto e os nome de todas as pseudo-classes do Diagrama de Pseudo-Classes (Figura 17), de forma a verificar a representatividade de cada uma com relação ao contexto do software. Dessa forma, a pseudo-classe “Caixa” foi eliminada por conter apenas as somatórias dos registros da pseudo-classe “MovimentoCaixa”. As demais pseudo-classes tiveram seus nomes melhorados.

Os atributos das pseudo-classes também foram verificados. Todas as modificações realizadas foram documentadas na Lista de Mapeamento MASA x MAS, parcialmente visualizada pela Figura 24, em que se nota a exclusão da pseudo-classe “Caixa” do modelo que incorpora os conceitos de orientação a objetos. Já a pseudo-classe “Clientes” foi substituída pela classe “Cliente” no MAS e teve os nomes de cinco de seus atributos

Page 47: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 47

PRoJEto

Figura 22. Inspeção de acompanhamento de processo realizada após o término do MASA

Figura 23. Segunda baseline do estudo de caso

substituídos. A classe “Troca”, do MAS, possui dois atributos a menos que a pseudo-classe “Trocas” que a originou, pelo fato de ter-se notado que estes não estavam sendo utilizados pelo software.

A partir da Lista de Anomalias foram verificados os proce-dimentos e funções com classificação (o) e (c). Esses procedi-mentos e funções tiveram sua funcionalidade analisada, no sentido de verificar se esta não poderia ser distribuída em mais de um método. Após a análise, cada método foi associado à classe que observava ou modificava. A Figura 25 mostra o exemplo do procedimento SavePosition que observa a pseudo-classe Clientes e foi convertido nos métodos ObterCodCliente e SalvarPosicaoTabela como forma de aumentar o reuso, já que apresenta duas funcionalidades distintas.

Dada a forma de implementação do software utilizado no es-tudo de caso, alguns procedimentos de abertura e fechamento dos componentes de acesso às tabelas de dados não tiveram mais utilidade pelo fato desses componentes não serem mais utilizados na re-implementação do software. Nesse caso, esses procedimentos foram eliminados ou tiveram sua classificação modificada.

O destaque (a) da Figura 26 ilustra o exemplo de um proce-dimento que foi eliminado por conter apenas a abertura do componente de acesso aos dados da tabela Cidades. O des-taque (b) da Figura 26 refere-se ao procedimento que fecha o componente de acesso aos dados da tabela Cidades e libera a memória alocada pela interface de Cidades. Esse procedi-mento foi mantido, porém com a classificação (i), referindo-se somente à forma de implementação utilizada, pelo fato de ter sido eliminada a parte do código-fonte de fechamento do componente Cidades.

A última etapa de abstração do Diagrama de Pseudo-Classes é a divisão dos procedimentos e funções anômalos, de forma a eliminar suas anomalias e transformá-los em métodos. Esta divisão foi conduzida no estudo de caso, analisando-se a funcionalidade de cada procedimento e função. No caso da funcionalidade presente (ou parte dela) já haver sido do-cumentada na forma de método (durante a associação dos métodos sem anomalias), esse foi aproveitado apenas sendo novamente referenciado. Por exemplo, caso algum método anômalo tivesse que obter o código do cliente como parte de sua funcionalidade, não precisaria ser novamente definido, podendo utilizar o método ObterCodCliente, anteriormente definido. Caso contrário, um novo método foi criado para prover a funcionalidade.

A Figura 27 ilustra a composição da Lista de Correspondência de Métodos Anômalos e, abaixo, o código-fonte referente ao procedimento anômalo Inserir Crediario dividido nos métodos AtualizarDataUltimaCompra (classe “Cliente”) e Create (classe “Crediario”). Verifica-se, ainda, que procedimentos de abertura e fechamento de componentes de acesso direto às tabelas de dados foram eliminados de diversos módulos do software. Outro fato que pode ser notado foi que alguns métodos pu-deram ser reutilizados, como o método ObterCodCliente da classe “Cliente”.

A seguir, foi elaborado o Diagrama de Classes referente ao Modelo de Análise do Sistema (MAS). Os relacionamentos entre as pseudo-classes do MASA foram analisados em função de sua representatividade com relação ao domínio da aplicação e quanto à possibilidade de haver melhor exploração dos con-ceitos disponíveis na orientação a objetos, como a herança.

A Figura 28 ilustra os relacionamentos entre as classes do MAS. Várias modificações foram realizadas em relação à Figura 17, que apresenta os relacionamentos entre as pseu-do-classes. Um exemplo é a inclusão dos relacionamentos de herança entre a classe “Orcamento” e “Venda”/”Troca”, que não existem no Diagrama de Pseudo-Classes, isso ocorreu

Figura 24. Visualização parcial da versão 1.0 da Lista de Mapeamento MASA x MAS

Page 48: Www.superdownload.us ES35

48 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

pelo fato de representarem melhor dessa forma o contexto em que estão inseridas no software. A classe “Cliente” passou a associar-se diretamente às classes “Venda” e “Tro-ca”, fato que não ocorria no MASA e que também pode ser comprovado analisando-se o escopo do software, pelo fato do cliente ser responsável pela realização das operações de venda e troca.

Continuando a elaboração do Modelo de Análise do Sistema, o próximo padrão aplicado foi Criar Diagramas de Use Cases do MAS.

Figura 25. Exemplo de um procedimento sem anomalias que foi convertido em dois métodos

Figura 26. Exemplo de um procedimentos sem anomalias que não foram convertidos em métodos Figura 28. Diagrama de Classes após a abstração do MASA

Figura 27. Composição da Lista de Correspondência de Métodos Anômalos

Page 49: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 49

PRoJEto

Padrão 14: Criar Diagramas de Use Case do MASA partir dos Diagramas de use cases do MASA e do Diagra-

ma de Classes, os uses cases foram abstraídos, originando os Diagramas de Uses Cases do MAS. Alguns uses cases tiveram seus nomes atualizados, acompanhando as modificações realizadas no Diagrama de Classes. O use case CaixaBtnFe-chaClick, foi transformado para FecharCaixaDiario, nome do evento que chama os métodos das classes necessárias de forma a prover o pagamento de uma parcela de crediário, quando solicitado por um cliente, como ser visto na linha marcada por (a) da Figura 29.

A Figura 30 ilustra o use case InserirCor responsável pela inserção de uma nova cor na tabela de dados de cores. Esse use case é tratado, no MASA, por um componente de acesso direto à tabela de dados “Cor”. No MAS, o use case passou a ser tratado pelo evento InserirCor, o qual acessa o método “Create” da classe “Cor”.

Todos os use cases abstraídos do MASA foram inseridos na Lista de Mapeamento dos Use Cases, de forma a registrar as modificações realizadas para o MAS. A Figura 29 ilustra parcialmente a lista elaborada para o estudo de caso. O destaque (b) ilustra a documentação do use case InserirCor.

Padrão 15: Descrever Use Cases do MASEsse padrão foi aplicado de forma a completar o Modelo

de Análise do Software, finalizando a engenharia reversa, primeira etapa do PRE/OO. As descrições dos use cases elabo-radas no MASA foram analisadas e, caso necessário, modi-ficadas para refletir as alterações realizadas no MAS. Os use cases do MASA tratados por componentes de acesso direto aos dados tiveram suas descrições elaboradas. A Figura 31 ilustra a descrição realizada para o use case InserirCor.

Ao final da obtenção do Modelo de Análise do Sistema, foi realizada a inspeção de acompanhamento do processo de reengenharia (Figura 32) e, em seguida, lançada a terceira baseline do estudo de caso (Figura 33), composta pelos pro-dutos gerados e inspecionados nesse passo.

Considerações finaisUma etapa posterior previsto pela Reengenharia de Sof-

tware OO seria a Engenharia Avante do sistema, a qual ire-mos abordar posteriormente, pois neste artigo procuramos evidenciar somente as etapas do processo de reengenharia e aplicação dos padrões para garantia da qualidade.

O planejamento proposto no PRE/OO capacita uma em-presa a prover o mínimo de visibilidade com relação às necessidades que serão geradas ao longo do processo de reengenharia orientada a objetos de sistemas procedimen-tais. Dessa forma, vários projetos podem ser conduzidos simultaneamente, levando à maior e melhor aproveitamento dos recursos (humanos, hardware e software) disponíveis na empresa.

A forma de descrição do processo por meio de padrões faci-lita o aprendizado pelos engenheiros de software, bem como a aplicação de partes isoladas do processo quantas vezes se

Figura 29. Visualização parcial da Lista de mapeamento de Use Cases

Figura 30. Use Case InserirCor do MAS

Figura 31. Visualização da descrição do use case InserirCor

Figura 32. Documento relativo à terceira inspeção de acompanhamento do processo

Page 50: Www.superdownload.us ES35

50 Engenharia de Software Magazine - Reengenharia de software orientado a objetos

Figura 33. Terceira Baseline de Projeto

fizerem necessárias para prover refinamentos de forma a gerar um produto final com qualidade.

Ao completar o processo de reengenharia de um software legado com a utilização do PRE/OO, é gerada toda a sua documentação, muitas vezes inexistente ou desatualizada devido às manutenções frequentes. Outro aspecto importante é a organização proposta pelo PRE/OO quanto à forma de implementação orientada a objetos apresentada pelos padrões do cluster 7, Re-implementar o Software, que considerou as arquiteturas mais atuais de im-plementação existentes, como a multicamadas, com seu aspecto modular de divisão das lógicas de negócios, armazenamento e interface. Essa forma de implementação pode ser adotada inde-pendentemente do tamanho do software legado, facilitando o reuso das classes durante as expansões ou em novos softwares.

(COLEMAN, 1994) COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H. and HAYES, F. Object-Oriented Development – The Fusion Method. Prentice Hall. ISBN 0133388239. 1994.

(LEMOS, 2002) LEMOS, G. S. PRE/OO – Um Processo de Reengenharia Orientada A Objetos com Ênfase na Garantia da Qualidade. Dissertação de Mestrado em Computação. Departamento de Computação. Universidade Federal de São Carlos – São Carlos/SP. 2002.

(PENTEADO, 1996a) PENTEADO, R. A. D. Um método para Engenharia Reversa Orientada a Objetos. Tese (Doutorado em Física Computacional). Instituto de Física de São Carlos, Universidade de São Paulo – São Carlos/SP. 1996a.

(RECCHIA, 2002) RECCHIA, E. L. Engenharia Reversa e Reengenharia Baseada em Padrões. Dissertação (Mestrado em Ciência da Computação). Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de São Carlos – São Carlos/SP. Junho 2002

(RECCHIA, 2002) RECCHIA, E. L.; PENTEADO, R. A. D. FaPRE/OO: Uma Família de Padrões para Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais. SugarloafPLoP2002 – The Second Latin American Conference on Pattern Languages of Programming. Itaipava, Rio de Janeiro. Agosto, 2002.

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

seu Feedback

sob

re esta edição

Page 51: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 51

Ricardo S. Ferreira [email protected]

Profissional com amplo conhecimento em diversos domínios de negócio, em especial na área de telecomunicações e conteúdo digital. Possui mais de 13 anos de experiência, onde durante estes anos já atuou em dezenas de projetos envolvendo complexos cenários de integração corporativa, e na definição, imple-mentação e implantação de projetos que se utilizam de arquiteturas orientadas a servi-ços. Possui mais de 10 anos de experiência na plataforma Java EE, tendo ajudado diversas organizações na implementação de sistemas críticos usando servidores de aplicação como JBoss, WebLogic e Websphere. Atualmente trabalha na área de soluções da Progress Software, ajudando organizações da américa latina a adquirem maior responsividade ope-racional por meio de produtos de BPM, CEP, SOA e gestão semântica de dados. Antes de atuar na Progress Software, foi arquiteto de soluções na JBoss, a divisão de middleware da Red Hat. Possui as certificações SCEA, SCBCD, SCWCD, SCJP, Oracle SOA Architect Certified Expert, IBM Certified SOA Solution Designer, IBM Certified RUP v7.0 Solution Designer, Borland JBuilder Product Certified Developer, Borland Delphi Product Certified Developer e de Borland Certified Instructor. Já palestrou em diversos eventos de tecnologia do Brasil como Just Java, The Developers Conference, Sun Tech Days, COMDEX, JBoss in Bossa, Fu-turecom e CIAB.

De que se trata o artigo?Este artigo irá mostrar os detalhes e problemas re-lacionados a processos de negócio dentro de uma organização, além de explicar, passo a passo, como conduzir uma iniciativa de otimização de um proces-so de negócio, com o intuito de torná-lo mais eficaz e mais eficiente.

Para que serve?Organizações de diferentes segmentos precisam mais do que nunca ter um bom diferencial e servir com cada vez mais eficiência e agilidade aos seus clientes, a fim de sobreviver em um mercado onde a decisão de ir para a concorrência está a apenas um clique de distância ou com o custo de apenas uma ligação. A oti-

mização constante de processos de negócio em uma organização pode fazê-la obter esse diferencial e essa agilidade, além de prover um nível de satisfação e ex-celência superior aos seus clientes, fornecedores e fun-cionários, por meio da simplificação destes processos.

Em que situação o tema é útil?Este artigo pode ser uma ferramenta muito va-liosa para gerentes ou líderes de área de organi-zações que estejam engajadas em otimizar seus processos de negócio objetivando obter maior diferencial perante seus clientes, fornecedores e funcionários. Ao final da leitura desta série de artigos, será possível que o caro leitor possa con-duzir uma iniciativa de otimização de processos dentro de qualquer organização.

Otimização de Processos de Negócio usando BPM – Parte 1Transformando organizações “Boas” em organizações “Ótimas”

Engenharia

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

Você sabia que os icebergs mos-tram apenas 10% de sua massa sobre a superfície da água? É

incrível notar como estes fenômenos da natureza podem ser extremamente perigosos para aqueles navios que se aventuram nas águas do oceano, como podemos notar na Figura 1. Um navio pode estar a uma distância “segura” de um iceberg, mas mesmo depois de avis-tar o iceberg, podem, sem mesmo saber como aconteceu, colidir com ele e causar

danos irreparáveis ao navio ou mesmo seu naufrágio. Isso acontece porque, o que se vê sobre a superfície das águas é o que chamamos de percepção, aquilo que nos ressalta aos olhos. Mas aquilo que está abaixo da superfície das águas, é a realidade: aquilo que normalmente não conseguimos enxergar, mas que pode ser a causa de muitas coisas boas ou ruins.

Organizações possuem diversos ice-bergs dentro dela, e estes icebergs são na

Page 52: Www.superdownload.us ES35

52 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM – Parte 1

verdade seus processos de negócio. Normalmente, as pessoas da organização possuem apenas uma vaga percepção destes processos, também conhecida como visão míope. Poucas pes-soas na organização possuem a visão da realidade por debaixo dos processos, dos perigos que eles podem causar bem como as oportunidades que estes podem gerar. É necessário que as organizações possam saber “até onde vai o iceberg” para que esta possa, de forma proativa, corrigir o rumo das suas operações antes que seja tarde demais.

O sucesso de uma organização depende em grande parte sobre como ela compreende 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 po-dem 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 substanciais 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.

Nesta série de artigos, você irá descobrir os elementos princi-pais para a condução de uma iniciativa de otimização de proces-sos 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.

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.

Visão Geral sobre Processos de NegócioSendo um gerente ou um líder de uma área, você provavel-

mente já deve ter ouvido extensivas discussões sobre “otimi-zação de processos de negócio”, “redesenho de processos” e sobre “reengenharia de processos de negócio”. Você deve se perguntar constantemente sobre o que isso tudo realmente significa. A primeira coisa que iremos fazer é entender um pouco mais sobre processos de negócio para na sequência, entender exatamente o que é (e o que implica) otimização de processos de negócio.

Figura 1. Exemplo de um iceberg e sua porção de massa sobre a água

Tecnicamente, um processo de negócio nada mais é do que um conjunto de etapas que uma área de negócio desempenha para criar valor aos seus clientes e também à própria organi-zação. Um processo de negócio é composto de três elementos básicos:• Entradas: Elas iniciam o processo. Por exemplo, se você está produzindo uma bicicleta, as entradas para esse processo serão os pneus, as rodas, as porcas, parafusos, correntes, etc.• Atividades: Elas transformam as entradas em saídas. No exemplo da bicicleta, atividades incluem a montagem do pedal, a inserção das rodas e o ajuste das engrenagens. Um conjunto de atividades dentro de um processo também é conhecido como fluxo do processo.• Saídas: Também conhecidos como resultados ou entregáveis. Uma saída é o produto final gerado pela execução de todas as atividades do processo. Neste exemplo, a bicicleta concluída.

Processos são simples de entender quando você considera coisas físicas como bicicletas. Mas processos existem em to-das as organizações, não somente naquelas que criam coisas físicas. Por exemplo, numa companhia que provê consultoria em gestão de recursos humanos, existirão entradas (tal como o conhecimento do consultor), atividades (por exemplo, a con-dução de uma pesquisa de satisfação dos funcionários para avaliação da organização do cliente) e saídas (tal como o plano de iniciativa de mudança cultural no cliente).

Em resumo, processos de negócio são constituídos de todas as atividades que a sua organização está engajada com o intuito de cumprir os objetivos de negócio traçados por ela. Processos determinam a eficácia e a eficiência das operações da sua organização, a qualidade que os seus clientes experi-mentam, e também, o sucesso financeiro da sua organização. Toda organização contém um grande número de processos de negócio. Alguns destes processos são realizados num único departamento, como a entrada de um pedido de compra de um cliente no computador. Outros são processos mais complexos implementados em toda a organização, extrapolando várias fronteiras departamentais, como por exemplo, o desenvolvi-mento de um produto de sucesso no mercado.

Page 53: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 53

MELhoRIA DE PRoCESSo

Processos podem também variar de acordo com seu nível de formalidade. Eis um exemplo de processo informal: um cliente seu de longa data lhe pede um desconto para que ele possa comprar o dobro da quantidade do produto que ele está acostumado a comprar. Não existe nenhuma regra que diga que você não possa dar esse desconto, nem mesmo um conjunto de regras que determine a natureza e as condições para se conceder descontos. Logo, você dá esse desconto ao seu cliente. Você neste momento acabou de criar um processo informal. A organização não possui esse processo documenta-do e formalizado. Até este ponto, esse processo existe apenas em sua cabeça.

Agora vamos a um exemplo de processo formal: você ge-rencia uma área de atendimento a clientes que provê formas de resolver os problemas gerados pelos serviços e produtos vendidos através do telefone ou da internet. Você e o seu time criaram rigorosos procedimentos para responder as dúvidas dos seus clientes, bem como regras de encaminhamentos padrões de acordo com cada natureza do problema. Todos os novos funcionários da área de atendimento ao cliente devem estudar esses procedimentos assim que são admitidos, bem como receber um treinamento formal destes procedimentos por um funcionário mais sênior. Os conjuntos de procedimen-tos para atendimento aos clientes criados pela área formam um processo formal na organização.

Alguns processos começam informais e depois se tornam formais. É papel de um gerente ou líder de área, revisar cuidado-samente esses “incidentes” que ocorrem no dia a dia das organi-zações e transformá-los em processos formais caso sejam julgados como de importância para o negócio. Por exemplo, suponha que foi criado um processo informal em que os funcionários existentes possam recomendar novos funcionários com base em sua árvore de relacionamentos. Observando que todos os novos funcionários admitidos satisfizeram todas as exigências e começaram a dar ex-celentes resultados à organização, viu-se que o processo realmente traz valor e pode então, ser transformado num processo formal da organização. O processo pode ser até levemente modificado, para acrescentar bonificações aos funcionários que realizam as recomendações, na forma de uma recompensa financeira no salário, e com base num conjunto de regras pré-definidas como, por exemplo, de que o novo funcionário deva permanecer na organização por pelo menos três meses.

Todo mundo na sua organização, você, seu chefe, parceiros, gerentes imediatos, seus clientes e fornecedores, são respon-sáveis por diferentes processos de negócio diariamente. Mas porque esses processos de negócio são invisíveis, muitas destas pessoas não se preocupam com eles e sobre como eles podem impactar o desempenho da organização. Gerentes desprendem muitos recursos e um considerável capital consertando falhas e substituindo recursos operacionais (porventura pessoas) do processo até que o problema real seja evidenciado. E para o mal geral da organização, esses problemas são recorrentes e sempre ocorrem nas mesmas condições e nas mesmas etapas.

O maior dos problemas com processos de negócio é a falta de ciência desses processos por parte dos envolvidos. Cada

envolvido, direto ou indireto do processo precisa saber exata-mente o que está fazendo, e o quê o resultado do seu trabalho irá causar a organização, bem como quais são os resultados esperados. Sem isso, sem a falta de compromisso com os ob-jetivos da organização, processos irão continuamente falhar, mesmo que você troque os recursos ou implemente-o sob uma nova tecnologia. Através da compreensão das falhas do processo e da conscientização dos envolvidos da importância deles, você e o seu time podem corrigir estas falhas e garantir os resultados esperados pela sua organização. A geração de valor com processos de negócio começa quando estes estão formalmente documentados e quando os envolvidos sabem exatamente do valor destes processos para a organização. Podemos dizer que, estas são as pré-condições para qualquer iniciativa de otimização de um processo de negócio. Muitos engenheiros de processo e consultores de negócio falham em otimizar alguns processos por ignorarem estes elementos que são básicos e simples. De nada adiante aplicar técnicas avan-çadas de melhoria de processos (como as que iremos estudar nesta série de artigos) se a formalização e o comprometimento com os processos não existe.

Além do problema da formalização e o comprometimento com os processos, existem duas síndromes que normalmente são razões pelas quais processos de negócio tendem a falhar. A primeira é conhecida como síndrome da caixa preta, onde os gerentes de uma organização enxergam os processos como uma grande caixa preta. Eles não conhecem bem os detalhes destes processos, mas sabem que, bem ou mal, eles estão pro-duzindo o resultado esperado, não na mesma eficiência que se gostaria, nem mesmo na mesma eficácia que se espera. Os gerentes sentem receio de otimizar tais processos, pois acham que a otimização deles pode fragilizá-los ou mesmo quebrar o que já está funcionando. Com isso, são feitas apenas iniciativas básicas de automação de partes destes processos, usando pra isso, tecnologia da informação.

A outra síndrome é conhecida como visão apenas das arestas. Quando as organizações tratam esses processos que desco-nhecem por completo como caixas pretas e até mesmo como objetos sagrados, elas ficam constantemente relutando em tentar otimizar esses processos e focam apenas na automa-ção das atividades destes processos. Eles acham que, com a introdução da tecnologia, a eficiência irá aparecer como num passe de mágica, e ignoram a tentativa de otimizar o processo em si. Esta atitude os isenta totalmente da responsabilidade de fracasso dos processos, pois se algo der errado... “foi culpa da tecnologia”. Bill Gates possui um ditado bem interessante para esse tipo de problema: “A primeira regra de qualquer tecnologia é que a automação aplicada numa operação que já é eficiente irá aumentar sua eficiência. A segunda regra é que, a automação de uma operação que é ineficiente irá aumentar sua ineficiência.”.

Otimização de Processos de NegócioAgora que você entendeu um pouco mais sobre o que são

processos de negócio, é hora de dar uma boa olhada nas

Page 54: Www.superdownload.us ES35

54 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM – Parte 1

várias dimensões e facetas de uma iniciativa de otimização de processos de negócio.

Por definição, a otimização de um processo de negócio ou simplesmente BPI (do inglês, Business Process Improvement) com-preende o conjunto de abordagens e ferramentas estruturadas que gerentes ou líderes de área utilizam para melhorar o de-sempenho de uma organização otimizando os seus processos de negócio. Como o próprio nome sugere, foca-se na mudança e no aperfeiçoamento dos processos de negócio para alcançar maior eficiência e maior eficácia. Em organizações que usam BPI, é comum observar que:• Gerentes e funcionários conhecem bem seus processos de negócio e os têm muito bem documentados na forma de mapas ou diagramas visuais, manuais de procedimentos ou simplesmente, um acordo formal entre os envolvidos sobre “o jeito certo de fazer as coisas”.• Gerentes avaliam constantemente o desempenho dos pro-cessos por meio de métricas e indicadores que possam aferir a qualidade das entradas e saídas dos processos e medir também a eficácia das atividades em andamento.• A alta diretoria investe sistematicamente nestes processos. Em alguns casos, estes investimentos têm como objetivos melhorar as operações em andamento, como por exemplo, melhorando a eficiência em que pedidos de compra são processados. Em outros casos, estes investimentos têm como objetivo melhorar a competitividade da organização perante a concorrência, como por exemplo, reforçando o desenvolvi-mento de produtos ou a estratégia de formulação da matéria prima destes produtos.

BPI é uma ferramenta que pode ser usada em todos os níveis de uma organização, seja por um gerente ou líder de área responsável pela observação das operações e transações de negócio em andamento ou pela alta diretoria e grupos execu-tivos interessados nas iniciativas globais da organização (que também são processos de negócio) que visam estruturá-la de acordo com as novas diretrizes estabelecidas pelo conselho.

Neste artigo veremos algumas das técnicas usadas para otimizar processos de negócio em nível departamental ou de grupos departamentais. Entretanto, a sua organização pode

estar envolvida num conjunto de programas de otimizações de processos mais gerais, que envolvam toda a estrutura da orga-nização, fazendo com que gerentes e líderes de todas as áreas (incluindo a sua) participem. Neste caso, é importante que você se familiarize com estes programas. A Tabela 1 mostra alguns dos programas de BPI mais conhecidos mundialmente.

Uma iniciativa de BPI pode ser disparada por diferentes tipos de eventos. Estes incluem ineficiências ou desempenhos pro-blemáticos. Por exemplo, Kely, uma gerente de um escritório regional de vendas de uma grande distribuidora de produtos, chega à conclusão que os resultados da regional estão 5% abaixo das demais regionais. O seu time de vendas trabalha duro, mas mesmo assim eles não estão conseguindo atingir as metas. Kely decide então examinar os processos de venda, tais como a forma como a equipe dela qualifica as oportunidades de vendas e as distribui para o time, para ver se alguns desses processos podem ser alterados para que o cenário de vendas mude positivamente.

Outras mudanças no cenário corporativo podem também dis-parar iniciativas de BPI. Mudanças no negócio podem assumir diferentes formas, incluindo a aquisição de novas tecnologias, a aquisição de uma nova empresa ou a criação de uma subsi-diária, alterações nas preferências dos clientes e a imersão de novos concorrentes. Por exemplo, Marcos, um gerente de um departamento de recursos humanos, está intrigado com as possibilidades que a internet traz. Ele descobre que criando um sistema web que possibilite que os funcionários possam solicitar a mudança dos seus benefícios anuais online, reduzirá drasticamente os custos da sua área de recursos humanos. An-tes deste sistema ser implantado, funcionários que necessitam alterar seus benefícios anuais tinham que agendar uma visita com um consultor de recursos humanos da empresa, processo este extremamente custoso e dispendioso.

Uma iniciativa de BPI bem conduzida possibilita que você gere importantes resultados para sua organização. Por exem-plo, BPI pode ajudar você a entender o quão eficaz seu time está atendendo as expectativas dos seus clientes e aos outros departamentos da organização. Pode inclusive poupar tempo e dinheiro da organização através da simplificação de proces-sos complexos e cansativos. Pode ainda fazer com que você

Nome do Método Descrição

Six Sigma Metodologia disciplinada e dirigida a evidências para a eliminação de defeitos em qualquer processo, criado para garantir maior desempenho, confiabilidade e

satisfação dos clientes. A Motorola desenvolveu o Six Sigma em 1980 depois de reconhecer que mesmo produtos com poucos defeitos falham à medida que são

utilizados pelos clientes. A letra grega sigma significa: variação do padrão estabelecido.

Total Quality Management (TQM) Estratégia de gerenciamento que prima pela assertividade quanto à qualidade em todos os processos organizacionais, a motivação constante dos funcionários,

a garantia de maior satisfação aos clientes com os produtos produzidos bem como a redução constante dos custos com recursos. TQM foi popularizado no Japão

depois da segunda guerra mundial pelo estatístico norte americano e professor de faculdade W. Edwards Deming.

ISO 9000 Família de padrões para gerenciamento da qualidade de sistemas criado pela organização mundial de padrões. Estes padrões não garantem necessariamente

a qualidade final dos produtos, ao invés disso, eles garantem que a organização esteja aplicando seus processos de negócio de forma consistente e correta. Os

padrões da ISO 9000 são implantados e avaliados por órgãos de certificação afiliados à organização mundial de padrões.

Business Process Reengineering (BPR) Abordagem de gerenciamento de processos que promove o redesenho radical dos fluxos de trabalho e processos de negócio dentro e entre as organizações, a

fim de conseguir um aumento significativo do desempenho. BPR teve seu ápice no mercado em meados de 1990, quando Michael Hammer e James Champy

publicaram o livro Reengineering the Corporation.

tabela 1. Metodologias e padrões formais de otimização de processos de negócio

Page 55: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 55

MELhoRIA DE PRoCESSo

descubra processos inteiramente novos que a organização jamais pensou ser necessário ter.

Fases de uma Iniciativa de BPIComo visto anteriormente, BPI pode trazer resultados signi-

ficativos a sua organização. Mas para gerar estes resultados, você precisa utilizar uma abordagem estruturada para sua iniciativa de otimização de processos. Nesta série de artigos, iremos discorrer passo a passo as seis principais fases de uma iniciativa de BPI, fases estas recomendadas pelos mais importantes consultores e especialistas de BPM do mundo. São elas:• Planejamento: Fase em que é feito a seleção de um ou mais processos de negócios existentes que se queira ou precisa-se melhorar. É feita a definição do escopo do projeto de BPI, re-sultados esperados e também qual será o grupo de trabalho usado na iniciativa.• Análise: Examinam-se cuidadosamente os processos de negócios que foram elencados para otimização, realizando o mapeamento destes processos, a identificação dos problemas que eles geram bem como a análise sobre o histórico desses processos dentro e fora da organização.• Redesenho: Os processos de negócio elencados na fase de planejamento são revisitados e melhorados, de forma que uma nova versão destes processos é criada, endereçando os prin-cipais problemas e entregando os resultados esperados. Fase onde é feita a análise sobre as implicações do uso desta nova versão do processo para geração de gaps de implantação.• Recursos: Obtenção de todos os recursos que serão neces-sários para a implementação do novo processo de negócio, recursos estes que podem ser equipamentos, sistemas, pessoas ou outros processos.• Implementação: Fase onde as mudanças elencadas na fase de redesenho são efetivamente postas em prática, ao mesmo tempo em que se cuida do processo de aposentadoria contro-lada da versão anterior do processo.• Otimização: Fase onde se revisita constantemente os resul-tados entregues pelo processo e cogitam-se novas iniciativas de BPI para obtenção de novos resultados, mais eficientes e mais eficazes.

É claro, quando você precisar fazer otimizações simples em processos de um único departamento, você não precisará necessariamente desprender tempo em todas estas seis fases explicitamente. Ao invés disso, você irá passar por algumas destas fases rapidamente e outras irá simplesmente ignorar por não fazer sentido em virtude da simplicidade do processo,

departamento ou dos resultados da otimização. Por exemplo, suponha que você precise que o processo de tomada de de-cisão do seu time se torne mais eficiente. Atualmente, você coleta feedback de cada envolvido durante uma semana, onde esses recursos e você ficam parados por conta desse processo. Claramente, com adição de mais envolvidos no time, este pro-cesso irá ser demasiadamente demorado e inviável até mesmo financeiramente, devido à parada de todos os recursos do time. Uma iniciativa simples de BPI poderia ser de implementar a prática onde todos os envolvidos façam pelo menos uma vez por semana uma reunião para discussão dos pontos chaves, em reuniões menores e mais direcionadas. Num dado dia do mês, você apenas consolida as decisões discutidas pelo seu time. A Figura 2 sintetiza as fases clássicas de uma iniciativa de BPI.

Fase 1: Planejamento de uma Otimização de ProcessoA fase de planejamento de uma iniciativa de BPI sem dúvida

é a mais importante de todas as fases. Através das atividades desta fase, iremos delinear todo o trabalho que será realizado, as pessoas que serão envolvidas, e os possíveis resultados (po-sitivos e negativos) que serão gerados. A sua importância se dá porque é o momento de criar e comprometer expectativas. Excesso de expectativas pode ser o grande vilão de qualquer projeto numa organização. Por isso, você deve executar essa fase com muito cuidado e cautela, além de, claro, garantir que todos os envolvidos estejam corretamente preparados para o que está por vir. Para realizar o planejamento de uma otimização de processo de negócio, você deverá executar as seguintes etapas:• Identificar áreas da organização que estejam com falhas;• Selecionar o processo de negócio que será otimizado;• Definir o escopo da iniciat iva de BPI, objet ivos e cronograma;• Montagem de um grupo de trabalho para a iniciativa de BPI;• Posicionar todos sobre a iniciativa deixá-los a par de tudo.

Identificando Áreas da Organização que estejam com Falhas

Como primeira tarefa da fase de planejamento de uma iniciativa de BPI, é necessário que você decida qual área da organização precisa de otimização. Felizmente, existem per-guntas simples que podem ser feitas para ter essa percepção. Se houver pelo menos uma resposta “Sim” para algumas das perguntas abaixo, é um sintoma de que algumas áreas preci-sam de otimização:• Os clientes estão comentando ultimamente sobre a qualidade inferior dos produtos criados pela organização? A concorrência está ganhando cada vez mais espaço com seus produtos devido a este tipo de problema?• Alguns procedimentos para tarefas da organização parecem ser bastante complicados e com isso geram bastante retrabalho e inconsistências?• Um determinado procedimento da organização tem seu tempo de execução diferente para cada pessoa que o realiza. Figura 2. Fases de uma iniciativa de BPI

Page 56: Www.superdownload.us ES35

56 Engenharia de Software Magazine - Otimização de Processos de Negócio usando BPM – Parte 1

Não há garantia de que duas pessoas irão executar tal proce-dimento no mesmo tempo médio?• As tarefas não são feitas da forma correta logo de primeira? São necessárias várias realizações de uma atividade até que o produto final esperado desta atividade seja alcançado?• O desempenho da sua equipe como um todo está declinando? Ou a equipe está demorando demais até que sejam alcançados os objetivos comuns?• Funcionários estão expressando frustração sobre os processos de negócio altamente confusos e complexos? Isso está causan-do desmotivação e gargalos nas equipes dificultando que os objetivos da organização sejam cumpridos?

Selecionando um Processo de Negócio para Otimização

Se você é como a maioria dos gerentes, você deve enxergar diversos sintomas de processos problemáticos ocorrendo simultaneamente. Isso sugere que mais de um dos processos de negócio precisam de otimização. Por exemplo, João, que gerencia o escritório regional de um grande banco espanhol, tem percebido que os clientes estão reclamando de ter que repassar os mesmos dados pessoais todas as vezes que vão solicitar um empréstimo. Além disso, ele tem percebido que a regional em que trabalha está com um número de contas aber-tas por trimestre menor do que as demais regionais, indo então contra os objetivos definidos pela matriz do banco, mesmo com a experiência e conhecimento que seu time possui.

A impressão que dá é que todos os processos que estão sendo observados precisam de otimização, mas por qual deles começar? Essa é uma pergunta realmente difícil de responder, e muitos gerentes param suas iniciativas de BPI por aí. Para contornar esse problema, você precisa criar uma planilha de critérios de seleção em que cada processo observado e candidato para otimização será avaliado quanto a uma série de critérios. Você deve fazer um rateio de cada processo problemático numa escala de um a cinco, sendo cinco o maior score e um o menor score. A Tabela 2 mostra um exemplo deste tipo de tabela aplicado ao cenário de exemplo do João.

Assim que você tiver feito a avaliação de cada processo, você deverá avaliar quem teve os maiores scores. Aquele(s) de maior(es) score(s) será(ão) elencado(s) para otimização. No caso particular do estudo de caso de João, o processo de abertura de contas deveria ser o processo priorizado para otimização. Durante a criação da planilha de critérios de seleção, você pode colocar quantas colunas quiser cujos significados deve-rão refletir, em sua grande parte, os objetivos estratégicos da

Nome do ProcessoPotencial de Redução

de Custos

Fonte de Problemas com

os Clientes

Geração de Receita

Superior

Facilidade de

Mudança

Fonte de Frustração dos

FuncionáriosScore Total

Abertura de Contas 5 5 2 2 4 18

Avaliação do Histórico de Crédito 4 2 4 3 4 17

Aprovação de Pedidos de

Empréstimo4 1 3 2 4 14

tabela 2. Planilha de critérios de seleção para o estudo de caso de João

organização. Uma boa prática é perguntar aos envolvidos dos processos sobre seus pontos de vista, e que necessidades para eles são mais urgentes. Estes serão os insumos básicos para definição das colunas.

É importante também priorizar aqueles processos que te-nham maior impacto direto aos clientes. Sem dúvida, estes deverão ser os processos mais importantes e os primeiros can-didatos à otimização, uma vez que deve ser objetivo primário de qualquer organização aumentar a retenção de seus clientes. Processos que geram receita direta para a organização (Ex: abertura de contas, ativação de linhas telefônicas, venda de produtos) também devem ser considerados como prioritários. Da mesma forma, aqueles processos que não geram receita, mas geram despesas em potencial, também devem ser dados como prioritários. De nada adianta otimizar aqueles processos que geram bastante receita para a organização, quando aqueles que estão gerando “sangramento” no fluxo de caixa ainda estão precários. O peso correto aplicado a esta balança dependerá diretamente do valor montante final que cada processo de negócio gera. Desta forma, avaliando a equação “O que eu ganho é maior do que o que eu perco?” deverá ser suficiente para tomar a decisão.

Definição do Escopo da Iniciativa de BPI, Objetivos e Cronograma

Você deve definir o escopo, objetivos e cronograma da sua iniciativa de BPI. O escopo define o que será e o que não será incluído na iniciativa. Por exemplo, para otimizar a forma como sua regional abre novas contas bancárias, João deci-de criar uma campanha com empresas do ramo de varejo para abertura de contas em massa para seus funcionários. É necessário também especificar como a iniciativa de BPI irá sustentar os objetivos estratégicos da organização. Esclareça exatamente como este novo processo irá se relacionar com os demais processos, bem como todos os demais interessados, tais como clientes, funcionários e fornecedores. Finalmente, é importante expressar a otimização em termos financeiros. João por exemplo, determina que a otimização do processo de abertura de contas irá ajudar a organização a atingir sua meta de dois milhões de euros até o final do seu ano fiscal.

Para definir o cronograma, estabeleça exatamente quais serão os marcos necessários para atingir os objetivos estabelecidos, bem como o tempo aproximado para se chegar a cada marco. Por exemplo, os marcos definidos por João incluem mapear o novo processo de abertura de contas em dois meses e de conduzir uma execução de aprendizado e amostragem até o final do segundo trimestre.

Page 57: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 57

MELhoRIA DE PRoCESSo

Montagem do Grupo de Trabalho para a Iniciativa de BPI

É necessário definir quem serão os responsáveis por sua iniciativa de BPI. Para a montagem de um grupo de trabalho, considere incluir os seguintes papéis:• Gerente de Projetos: Escolha alguém para ser o gerente de projetos da iniciativa, que pode ser você mesmo ou outra pessoa. Este gerente de projetos deve possuir experiência tra-balhando com várias pessoas, designando tarefas e cobrando resultados, garantir que executem suas tarefas no prazo e cumpram os objetivos definidos pela iniciativa.• Responsável pelo Processo: O responsável pelo processo é aquela pessoa que é atualmente responsável pela execução daquele processo na organização e que, após o redesenho do processo, será responsável por fazer com que a nova versão tenha sucesso e cumpra os objetivos definidos. Novamente, esta pessoa pode ser você, mas desde que você ou outra pessoa tenham os conhecimentos em nível de detalhes suficientes sobre o processo, tenha bastante influência com os demais interessados no processo e com quem está patrocinando a iniciativa, bem como ser responsável por todas as métricas e indicadores de medição porventura criados para avaliar o progresso do novo processo.• Usuários do Processo: Estes incluem todos os indivíduos que trabalham diretamente no processo de negócio. Não fique tentado a escolher as pessoas que melhor desempenham no processo. Tente escolher pelo menos uma pessoa que tenha dificuldades ou desempenho inferior no processo, pois esta será sua fonte de inspiração para descoberta das falhas do processo.• Céticos: Pode parecer estranho, mas é de suma importância que você reúna também um grupo de pessoas céticas (pessoas que duvidam ou não acreditam em sua iniciativa) no grupo de trabalho. Elas ajudarão a criticar bastante as decisões e fazer aparecer condições e problemas que você e sua equipe não estavam prevendo, por serem demasiadamente otimistas. É claro, é papel do gerente de projetos garantir que estas reuniões e discussões sejam sempre sadias e focadas.• Especialista em Tecnologia: A tecnologia desempenha um papel crucial em qualquer iniciativa de BPI. Ter alguém que tenha os conhecimentos de tecnologia apropriados no grupo de trabalho pode ajudá-los a definir o que é ou não é possível fazer, bem como ponderar sobre decisões mais realistas sobre as implicações na TI do uso do novo processo. Esta pessoa pode ser um funcionário do seu departamento de tecnologia da informação, um consultor de uma empresa de tecnologia ou um profissional de arquitetura de soluções do seu fabricante de tecnologias preferido.

Posicionar todos sobre a Iniciativa e deixá-los a par de Tudo

Estabeleça regras claras sobre como todos os participantes do grupo de trabalho irão interagir. Para isso, é importante talvez criar um plano de comunicação. Por exemplo, estabeleça regras que mostrem com qual periodicidade o grupo de trabalho

irá se reunir para discutir e endereçar os problemas? Quem será responsável por fazer com que determinada atividade do projeto seja concluída? Como os envolvidos irão resolver conflitos e adquirir os recursos necessários para a completude de suas atividades?

Se necessário, consiga o comprometimento do seu próprio gerente ou superior direto criando um documento de estudo de caso que demonstre o valor da iniciativa de BPI. Finalmente, decida com o seu gerente quando e como seu grupo de trabalho irá mantê-los atualizados sobre o progresso da iniciativa e dos resultados obtidos em cada marco definido.

ConclusõesNesta primeira parte da série de artigos sobre otimização de

processos de negócio, vimos o que são processos de negócio e o que iniciativas de BPI podem fazer pela sua organização. Explicamos os conceitos básicos sobre BPI e apresentamos quais são as fases clássicas de uma iniciativa de BPI. Na pró-xima edição da revista, iremos dar continuidade a esta série explorando os detalhes sobre a fase de análise dos processos de negócio, entendendo principalmente as abordagens usadas para compreensão dos processos e as técnicas usadas para a modelagem destes processos, usando notações padrões como BPMN e ferramentas de mercado como o Progress Savvion BPM®. Até a próxima!

Blog “O BPM que faço hoje... é realmente BPM?”

http://bit.ly/hwUCXo

Progress Savvion BPM

http://web.progress.com/en/savvion/savvion-businessmanager.html

Link para Download do Progress Savvion Modeler

http://bit.ly/fNMsdc

Links

Livro “Good to Great: Why some companies make the leap... and others don’t” -

ISSBN 9780066620992

Livro “Business Process Management: Practical guidelines to successful

implementations” – ISSBN 9780750686563

Livros

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

seu Feedback

sob

re esta edição

Page 58: Www.superdownload.us ES35

58 Engenharia de Software Magazine - Implantando a gerência de configuração de software em empresas de médio porte

Jorge Marcos [email protected]

Mestrado Executivo em Computação Aplica-da pela UFRJ. MBA Executivo em Tecnologia da Informação Empresarial pela UFRJ. MBA em Gerência de Projetos de Software pela PUC. MBA em Engenharia de Software pela UFRJ. MBA em Gestão Estratégica da In-formação pela UFRJ. MBA em Gerência de Projetos pela FGV.

De que se trata o artigo?Este artigo apresenta uma estratégia para a implan-tação da Gerência de Configuração de Software (GCS), adaptada à realidade das empresas de médio porte e apoiada em ferramentas automatizadas para contro-le de versões. A falta da GCS propicia um total desco-nhecimento do produto de software a ser desenvol-vido. Aliado a isso, a falta da gerência de mudanças leva a perda de controle na produção de artefatos de software durante o processo de desenvolvimento ou manutenção de sistemas de informação. Este artigo descreve os trabalhos de pesquisa referentes à Dis-sertação de Mestrado, do programa de Mestrado Profissional da Universidade Estadual do Ceará (MP-COMP), sob orientação do professor Edilberto Strauss, Ph.D. (UECE/POLI/UFRJ).

Para que serve?A estratégia apresentada pode servir como fonte de consulta, ou até mesmo, como base para planeja-mento por futuros interessados em implantar a GCS em suas organizações. Além disso, também con-tribui para a melhoria da qualidade dos projetos de software e, conseqüentemente, para o sucesso das empresas de software frente ao mercado, facilitando a aplicação deste processo.

Em que situação o tema é útil?Este tema interessa, principalmente, aos geren-tes de projetos de software, merecendo sua total atenção, uma vez que a implantação da GCS é um fator de melhoria da qualidade nos projetos de desenvolvimento de software.

Implantando a gerência de configuração de software em empresas de médio porte

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

Para ter acesso à esse artigo na íntegra acesse o leitor digital:

www.devmedia.com.br/esmag

Page 59: Www.superdownload.us ES35

Edição 35 - Engenharia de Software Magazine 59

GERêNCIA DE CoNFIGUR Ação