www.portalbpm.com.

br

Da Orientao para Objetos at o SOA

chegando ao BPM

Glauco Reis (gsrt@terra.com.br) Consultor em Java e metodologias OO, e especializado em plataforma IBM. Tm o ttulo de SCJP 1.1 e 1.4,
SCJWCD 1.4, e IBM CSE e IBM Websphere Application Server Certified. Escreve h mais de 8 anos sobre o tema Java e trabalha na rea de
informtica h mais de 20 anos, participando tambm como palestrante COMDEX e FENASOFT. especialista em WebServices e est envolvido
com a tecnologia BPMS, como arquiteto principal na criao de uma soluo BPMS nacional.

A orientao para objetos existe h um longo tempo. Smaltalk j existia como linguagem operacional ao
final da dcada de 60. Entretanto, mesmo aps estes mais de 40 anos, continuamos tendo dificuldades na
sua adoo. Os graus de complexidade ainda so altos, e h um grande GAP entre o resultado esperado
pelo usurio e o processo de desenvolvimento em si. A industria vm promovendo alternativas, que vo da
componentizao at mtodos geis de desenvolvimento, na tentativa de suplantar as dificuldades.
Algumas tiveram sucesso de alguma forma, outras so mero hype promovido pela indstria, e acabam
desaparecendo no mercado. A nova sopa de letrinhas mais comentada no mercado o SOA (Service
Oriented Architecture). Ela se prope a resolver a panacia do desenvolvimento, e parece ser o foco os
CIOs no momento. Vamos falar um pouco sobre a tecnologia, mas iniciando desde os primrdios da OO at
os dias atuais.
Existem duas constantes presentes na lista de preocupaes de qualquer metodologia, linguagem ou
tcnica de programao que j existiu, e provavelmente nas que iro aparecer nos prximos anos. As
funes (rotinas, mtodos, procedimentos ou funes) e os dados (atributos, campos, colunas).
Ao longo do tempo, duas grandes disciplinas apareceram para resolver os problemas de desenvolvimento
: a programao estruturada e a engenharia da informao. O foco central de atuao de cada uma delas
eram respectivamente as funes e os dados.
Na programao estruturada a idia a diviso do sistema em problemas cada vez menores, at que
chegamos a uma descrio to simples que o problema pode ser resolvido facilmente atravs de uma
rotina. Um mdulo separado em submdulos, que por sua vez separado em unidades funcionais e
outras subdivises menores ainda, at que chegamos uma rotina (procedure, funo, mtodo ou qualquer
outro nome que deseje atribuir). atribudo a Dijkstra esta idia de diviso e conquista, mas parece que o
conceito ainda mais antigo, j que Sun Tsu, em a arte da guerra, j propunha que a melhor forma de
destruir um exercito inimigo era forar a diviso em grupos menores, desviando sua ateno, e derrotar
estes grupos menores, um a um.
Esta idia utilizada at hoje, mas dois fatores pesam contra esta abordagem: em primeiro lugar, as
rotinas so muito volteis, e em segundo impossvel dissociar dados de funes. A primeira afirmao
significa dizer que dentro de um sistema qualquer, porcentualmente as rotinas alteram-se com uma
frequncia muito maior do que os dados. Pare para pensar nos sistemas que voc j desenvolveu at hoje.
Provavelmente muitas alteraes ocorreram na forma como os dados eram manipulados (funes) e
poucas alteraes nos dados em si, como mudana de tipo e reajuste do nmero de colunas. Fixar o foco
da metodologia em um elemento voltil mais ou menos como construir um prdio sobre areia movedia.
A segunda abordagem, surgida mais ou menos nos anos 80, foi a engenharia da informao. O foco do
estudo foram os dados, e tcnicas para estruturar e dividir como a informao seria armazenada. Neste
caso, Ganne e Yourdon deram grande foco informao, e como armazen-la de forma eficiente.
Novamente, lidar com dados sem se preocupar com a manipulao deles tambm utopia. No meio do

www.portalbpm.com.br
caminho, surgiu uma tcnica que propunha utilizar elementos da programao estruturada com elementos
da engenharia da informao, que a anlise essencial.

Figura 1. Algumas metodologias de desenvolvimento.

O aprendizado adquirido durante os anos nos mostra que uma das idias importantes que a Orientao a
Objetos (OO) nos trouxe a idia de que dados no podem ser dissociados das rotinas que os manipulam,
no importa a tcnica que voc utilize para desenvolver. Este conceito to importante que um dos
pilares da OO, chamado de encapsulamento. O encapsulamento faz com que os dados e as rotinas que os
manipulam fiquem prximos, e isto facilita na criao e manuteno dos cdigos. Este conceito tambm
no est preso a nenhuma linguagem orientada para objetos. Com boas prticas de programao voc
pode restringir o acesso aos dados a partir de um conjunto de rotinas, em virtualmente qualquer linguagem
de programao existente. A unio de dados e rotinas em grupos de funcionalidade nos traz o conceito de
classe. O que chamamos de Objeto uma instncia de uma classe. Um comparativo interessante o
seguinte: o molde que gera um boneco de gesso uma classe, e cada boneco de gesso criado a partir do
molde um Objeto. Podemos modificar a cor do chapu e da roupa, para um boneco criado (ou uma
instncia). Mas no podemos modificar a forma do objeto, pois isto est preso ao molde (classe).

www.portalbpm.com.br
Figura 2. Representao comum de Objeto (DONUT)

Aps esta breve introduo, chegamos ao objeto, que consenso em todas as prticas de programao
atualmente existentes. Ainda h divergncias na forma como os objetos se relacionam. Imagine que
tracemos uma linha horizontal, indo desde objetos sem relacionamento algum at objetos com
relacionamento complexo.
Se voc tiver um fraco acoplamento entre os objetos, estar em um extremo prximo da linha de algo
chamado componentizao. Na componentizao, a idia que poucos relacionamentos existam entre os
objetos, facilitando a reutilizao. No extremo oposto temos o framework, onde h um agrupamento de
objetos relacionados, normalmente com forte acoplamento entre eles. Veja por exemplo o Struts ou
Hibernate, que so exemplos de framework. Voc no consegue utilizar a classe Action ou ActionForm fora
do struts, pois h interdependncia entre o que voc cria e o prprio framework. Tambm no d para
utilizar o Struts sem utilizar um servidor de aplicaes, que outro exemplo de framework. J veja o caso
de um componente JavaBean, por exemplo. Voc pode utilizar um componente JavaBean em qualquer
ferramenta de desenvolvimento. Pode ser o NetBeans, VisualAge ou qualquer outra ferramenta visual.
Pode-se igualmente utilizar um JavaBean em um projeto J2EE ou desktop. Uma das razes que h fraca
dependncia entre o cdigo criado e outras tecnologias. Infelizmente no h um marco divisor entre os
componentes e os frameworks. Voc vai gradualmente migrando das particularidades de um at chegar ao
outro. como ir da cor branca para a preta. Existem infinitos tons de cinza entre as duas cores. Por
exemplo, a tecnologia EJB considerada um tipo de componentizao, mas que executa sobre um
framework.
Normalmente um framework consegue gerar resultados satisfatrios somente quando o conhecemos na
totalidade. A Componentizao mais fcil de ser utilizada, pois como os componentes so blocos isolados
e com uma interface bem definida, mais fcil criar cdigos que interfaceiem com ele, sem conhecer o
todo. Por outro lado, geramos resultados mais rpidos a partir do zero utilizando Componentes do que
Frameworks. Quando criamos um Servlet ou um EJB, estamos merc das regras e APIs disponveis no
servidor de aplicaes, para gerenciar o pedao de cdigo. Raramente em um framework temos a viso do
todo, ficando restritos s partes. O ciclo de aprendizado na utilizao de um framework normalmente mais
longo, se comparado ao componente. Mas, como disse anteriormente, a linha que delineia os dois
contnua, e frequentemente os frameworks comeam a ser construdos a partir de componentes.

Figura 3. Comparativo em relao ao acoplamento entre os objetos

A OO tradicional fica em um meio termo entre a componentizao e o framework, tentando definir

relacionamentos que so importantes, nem ficando em um extremo de isolar cada pea, como a
componentizao, nem se especializando e criando corpo, como o framework. A especializao se faz em
funo do sistema que est sendo desenvolvido. Esta tarefa de criar apenas os relacionamentos
necessrios, propostos pela OO, uma atividade no trivial e demanda um conhecimento profundo sobre a
tecnologia.
Houve um aprendizado na criao e evoluo da arquitetura J2EE, em relao aos frameworks
tradicionais, pois apesar de vrios componentes relacionados, de alguma forma ele foi componentizado,
para facilitar a assimilao da tecnologia. As APIs de servlet, por exemplo, so totalmente independentes
das APIs de EJB. Pode-se aprender a utilizar uma delas, e somente depois avanar o conhecimento para
outra. Isto ajuda na adoo.

www.portalbpm.com.br
A idia de componentes se popularizou muito alguns anos atrs, com o advento das ferramentas RAD
(Rapid Application Development). Este tipo de ferramental gerava (e ainda gera) cdigos de forma muito
rpida e no exige conhecimento profundo da tecnologia, pois os componentes so normalmente
conectados de forma visual. Uma enxurrada de tecnologias surgiram com base neste paradigma, como
VBX, ActiveX, OCX, JavaBean, VCL e mais um monte de outras.
Perceba que a receptividade de uma tecnologia componentizada mais fcil por parte do desenvolvedor,
pois ele pode tratar o componente como uma caixa preta, ligando-o de forma visual, sem se preocupar
como foi criado, ou como o relacionamento est acontecendo. Para voc, que entende de orientao para
objetos, significa esquecer os tipos de relacionamentos (agregao, composio e associao),
direcionalidade e algumas outras preocupaes normais. O sucesso do VB e Delphi, por exemplo, so
advindos desta abordagem. O problema que a conexo visual dos componentes deixa a critrio do
fabricante da ferramenta a forma como eles so conectados. Como o desenvolvedor no se preocupa em
como o cdigo final, pois o processo visual e rpido, o resultado tende a ser de pior qualidade do que se
adotarmos uma abordagem de desenvolvimento tradicional. Se voc tiver a curiosidade de gerar um
diagrama de classes para um projeto criado visualmente a partir de uma ferramenta RAD, ver que o
diagrama de classes se aproxima de algo como na figura 4.

Figura 4. Cdigo componentizado, criado visualmente a partir de uma ferramenta RAD

Costumo dizer o seguinte : se algum dia voc ouvir frases do tipo voc chegar rpido ao mercado, com
qualidade, desconfie. Rapidez e qualidade so palavras que no combinam em informtica, ao menos no
estgio atual.
Por outro lado, a idia de componentizao existe muito viva at hoje, e ainda recebeu um novo escopo.
Um conceito muito difundido como qualidade dos servidores web que se pode dividir o processamento
entre vrias mquinas (WLM WorkLoad Management). Criar componentes distribudos foi o caminho
natural para a arquitetura J2EE, o que foi feito com os EJBS. Na verdade, a tecnologia CORBA surgiu bem
antes dos servidores de aplicao explorarem a idia de cdigos distribudos, mas foi com a adoo dos
EJBs que a idia se firmou. Com o surgimento dos EJBs a idia de componentes distribudos recebeu uma
nova roupagem e algum estmulo do mercado. Algo semelhante foi sendo evoludo na plataforma Microsoft,
com os componentes DCOM (Distributed Component Object Model).
Embora os componentes sejam mais fceis de utilizar (criar outra estria),a arquitetura J2EE se
popularizou, principalmente por causa da Web e aplicativos Web Based, onde cada um dos grandes
fabricantes criou sua implementao de J2EE, como WebLogic (BEA), Websphere (IBM),JBoss (JBoss
Inc),e outros. inegvel o sucesso. Aplicativos baseados em Web so dominantes hoje no mercado, e no
h nenhum cenrio futuro que pretenda mudar isto nos prximos anos. Muito pelo contrrio.

www.portalbpm.com.br
Neste ponto da histria empresas tinham componentes criados em CORBA, alguns em RMI, outros em
DCOM, alguns sistemas utilizando diretamente TCP/IP, e outros ainda utilizando outros mecanismos de
comunicao distribudos, no orientados para objetos, como mecanismos de envio de mensagens (MQ e
Sonic, entre outros), mecanismos transacionais (CICs, entre outros), e com poucas possibilidades de
comunicao entre eles. E alis, em qualquer empresa que tenha utilizado informtica ao longo do tempo
deve haver diversidade (a menos que tenha migrado para um ERP). impossvel que a cada revoluo
tecnolgica todo o legado seja jogado fora, e o mais provvel que novos desenvolvimentos tenham sido
criados utilizando novas tecnologias. importante que todo este legado se integre, e ainda por cima
execute em um ambiente Web Based, como proposto pelos servidores de aplicao.
Algo ainda pior acontece nas empresas, pois os novos sistemas tm uma alta propenso a se integrar
com o legado (sistemas no so ilhas). Na tentativa de resolver estes problemas, bem como outros de
interoperabilidade, a Microsoft iniciou um movimento que culminou com a criao do SOAP 1.0. Isto
mesmo, um dos primeiros players a baterem na idia de SOAP foi a Microsoft. Inclusive, eu me recordo que
a Sun se posicionou contrria idia durante um longo tempo, mas com a unio da IBM com a Microsoft
para evoluo da tecnologia, a Sun teve que silenciosamente absorver a tecnologia.

Figura 5. Linha cronolgica de algumas tecnologias discutidas

A idia do SOAP parece bem interessante, quando olhada de um nvel mais alto. Utiliza um protocolo
HTTP, simples de ser utilizado, onde trafegam arquivos XML, facilmente criados a partir de qualquer que
seja a tecnologia, e portanto favorecendo ambientes heterogneos. Na prtica se mostrou um protocolo
frgil, no que se refere segurana, e muito perdulrio em termos de redundncia no envio da informao,
ou seja, lento e ineficiente. Eu me lembro que na Comdex e Fenasoft de 2003 todos os consultores
estavam fazendo apresentaes sobre as virtudes e como SOAP iria revolucionar o mundo da informtica.
A verdade que, em dezembro de 2002 foi feita uma pesquisa com uma massa de desenvolvedores
brasileiros, e se detectou que 21% estavam utilizando SOAP. A mesma pesquisa, com a mesma massa de
usurios, feita em abril de 2003 mostrou que o nmero havia diminudo para 19%. claro que o que os
fabricantes estavam vendendo como um milagre na verdade se mostrou efetivo em um montante menor do
que se previa ou se vendia.
SOAP, que o mecanismo de transmisso da informao, se uniu ao WSDL (Web Service Description
Language) que descreve como o servio deve operar e tambm ao UDDI (Universal Description and
Discovery Interface) que permite listar um grupo de servios, para criar o termo que conhecemos como
Web Service (para evidenciar que um servio disponvel na Web), e mais recentemente recebeu o nome
SOA (Service Oriented Architecture) para indicar que o conceito de servios foi agrupado para se tornar
uma arquitetura para criao de programas, e no mais apenas servios isolados que devem ser
publicados em casos especficos.
Uma das particularidades interessantes do SOAP, que ele na verdade no apropriado para
comunicao entre objetos remotos (e veja que SOAP a sigla para Simple Object Access Protocol). Ele
mais indicado para prover servios, utilizando-se de passagem de parmetros e recepo em um formato
hierrquico (XML). Uma das razes para isto que no houve uma grande preocupao em fazer com que
o cliente tivesse a sensao de que o que ele estava acessando do seu lado fosse um objeto real. Isto at

www.portalbpm.com.br
que fcil de entender, pois SOAP pode ser acessado inclusive por tecnologias no orientadas para
Objeto.
Por exemplo, uma tarefa trivial em orientao para objetos, que acessar um objeto Cliente remoto, e
navegar pelos Produtos que ele comprou em uma loja pode ser uma tarefa um tanto quanto complexa
para SOAP. J para CORBA, isto natural, e como se voc estivesse acessando o objeto normal (pois os
objetos remotos so apresentados como proxies). Como SOAP permite comunicao entre mundos de
Objetos e mundos de no objetos, se resolveu que seria interessante desvincular a idia de Objeto da
tecnologia SOAP.
A informao continua sendo fornecida por Objetos, caso a linguagem seja OO, ou no, para abrir o leque
de possibilidades, pois SOAP pode ser utilizado em linguagens no OO. J o acesso se faz atravs de
servios. Aumentou-se o escopo e se aplicou algum marketing sobre a tecnologia, para tentar vender o
mesmo conceito com outro nome, que foi denominado de Web Service e posteriormente SOA (Service
Oriented Architecture).
Este trabalho de marketing ao longo dos anos mudou o foco de comunicao entre objetos SOAP para
disponibilizao de servios SOA. Hoje, se aceita que a idia de Web Service prover um servio, como
obter o valor de uma cotao, efetuar uma compra, entrar dados no sistema. Se o que se encontra na outra
ponta um objeto ou no, no relevante. Francamente, este novo cenrio de Web Services fica melhor a
algo corporativo, do que o SOAP, que o protocolo de mais baixo nvel e especfico para comunicao.
Mas SOAP resolve apenas parte dos problemas, j que o protocolo de comunicao que trafega na
rede. Ainda temos dois outros protocolos que no so fundamentais, mas foram agregados como parte do
processo de definio do SOA, que so o WSDL e UDDI.

Figura 6. Trade de tecnologias que compe os Web Services

A idia do WSDL fornecer um descritivo para o servio, como endereo do servidor e porta de
comunicao, parmetros a serem passados e por a vai. Algumas vezes encontramos a definio de
WSDL como o currculo do servio. A idia seguiu os mesmos princpios do SOAP, com arquivos XML
simples para representao da informao. Veja exemplo na listagem 1.
Listagem 1: Exemplo de WSDL

<?xml version="1.0" encoding="UTF-8"?>

<message name="somaRequest">
parmetros
<part name="valor1" type="xsd:double"/>
<part name="valor2" type="xsd:double"/>
</message>
<message name="somaResponse">
retorno
<part name="result" type="xsd:double"/>
</message>
<portType name="Calculadora">
<operation name="soma" parameterOrder="valor1 valor2">

www.portalbpm.com.br
<input message="tns:somaRequest" name="somaRequest"/>
<output message="tns:somaResponse" name="somaResponse"/>

mtodo sendo

chamado
</operation>
</portType>
</definitions>

A idia do UDDI prover uma lista de servios disponveis, como uma lista telefnica de WSDLs.
Em conjunto a idia que a trade de protocolos funcionem da seguinte forma :
a) o cliente lista os servios disponveis a partir de um servidor (UDDI)
b) Escolhido um servio, pede-se uma descrio do servio atravs de seu currculo (WSDL)
c) A chamada ao servio acontece, passando parmetros e recebendo valores (SOAP)
Mas o que SOA, afinal ? H muita propaganda sobre o termo, mas basicamente a idia modularizar a
empresa em termos de servios que podem ser reaproveitados, e at mesmo publicados para outras
empresas.
As idias principais do SOA so modularizar e disponibilizar. Da mesma forma que a componentizao
tornou mais fcil a adoo da OO, a SOA expandiu o conceito para que todos os servios sejam
modularizados ou componentizados.
Como o mecanismo padro de disponibilizao o SOAP, que pode ser implementado por virtualmente
qualquer linguagem ou tecnologia, reduzimos as restries sobre o que pode ser feito em termos de legado.
Desta forma, criamos uma camada uniforme sobre as informaes advindas de sistemas antigos, bem
como dos novos sistemas criados a partir da orientao para objetos.
Na figura 7, cada ON pode ser um servio em CORBA, Cobol, Java, .NET ou qualquer outra tecnologia.
Neste mundo de servios, se uniformizou a forma como eles so disponibilizados.

Figura 7. Objetos de negcios disponibilizados como Servios

Agora j temos os servios do legado e novos servios componentizados, mas qual ser a prxima
onda ?
Um conceito at antigo (aproximandamente 10 anos), mas que vm ganhando fora no mercado a idia
de gerenciamento da empresa por processos.

www.portalbpm.com.br
Se a empresa consegue desenhar e definir os papis e processos de forma bem definida, chegaremos ao
momento em que o processo ser gerenciado (o termo correto orquestrado) atravs de ferramentas que
utilizam uma tcnica chamada BPM (Business Process Modeling).
A idia do BPM permitir que os processos da empresa sejam modelados por fluxo de informao, ao
invs de modelados por sistema.
Isto por s s j uma quebra de paradigma. Imagine o seguinte : em um desenvolvimento tradicional,
so desenvolvidos ou implantados cada um dos mdulos da empresa. Por exemplo, se cria o mdulo de
controle de estoque, financeiro, compras, recursos humanos, etc. E procura-se fazer com que os mdulos
integrem criando portas de comunicao entre eles. Estas portas de comunicao podem ir desde a troca
de arquivos TXT at tcnicas mais sofisticadas, como comunicao via TCP/IP ou CORBA. Ou seja, os
sistemas so construdos por reas de atuao.
Na idia da modelagem por processos, os sistemas so construdos ignorando-se a rea onde o sistema
ser executado, mas levando-se em considerao cada fase de sua execuo.
Neste caso, pensamos no que acontece desde o incio at o final da cadeia produtiva.
Como exemplo, uma empresa pode solicitar ao fabricante o envio de um pedido. Este pedido, ao chegar
na empresa entrar para o estoque, atravs da recepo de materiais. O nmero de tens em estoque ser
ajustado e disponibilizado para o departamento de vendas. Ser solicitado ao departamento financeiro que
a fatura do cliente seja paga, e por a vai.
O conceito de sistema e mdulo no desaparece, ao menos em um primeiro momento, pois no final cada
pequena atividade (pagamento de fatura, por exemplo) ser uma das funcionalidades do mdulo.
Mas pensamos no fluxo de comunicao da empresa como um todo, e no de forma isolada, o que
mais realista.
Normalmente dentro de uma empresa um fluxo caminha entre departamentos, transferindo
responsabilidades entre os participantes, ao invs de ficar preso a um sistema especfico.

www.portalbpm.com.br

Figura 8. Modelo de fluxograma de uma modelagem por processo

No desenho da figura 8, podemos observar algumas coisas : Ele muito parecido com um diagrama de
atividades da UML, e inclusive pode ser desenhado atravs de uma ferramenta UML. Em modelagem de
processos o nome do artefato workflow. Cada etapa at a concluso ser desenhada. Cada quadrado da
atividade pode e ser expandida em diagramas mais detalhados, at que chegamos a um quadrado para
cada interao com usurio ou funo a ser executada.
Mas o que a modelagem de processos tm a ver com o SOA?
Os dois se integram de forma magnfica. Nos prximos anos o que os grandes fornecedores de
tecnologia vendero como a prxima onda. Se voc quiser estar sintonizado com o futuro, procure
entender tcnicas de modelagem por processo.
Se cada atividade do diagrama acima estiver no grau de detalhamento menor, ou seja, for um passo para
a execuo do problema, isto significa que cada desenho azul pode ser resolvido por um Web Service. Se
voc tiver uma ferramenta que permita atachar um Web service a cada desenho azul, na figura 8, estar
orquestrando os Web Services da empresa a interagirem para a gerao do resultado final, que todo o
processo desenhado.
O fato que existem programas que permitem que esta orquestrao seja feita de forma visual, ou seja,
o desenho criado e colocado em execuo em um engine Run time, e passa a funcionar imediatamente.
Ou seja, sem desenvolvimento. Este tipo de ferramenta recebe o nome de BPMS (Business Process
Modeling System).
Se voc quiser experimentar, veja em JBOSS group o jBPM, que uma verso open source de um
engine de orquestrao. Praticamente todos os grandes players esto se mobilizando para ter ou adquirir
empresas que atuam no segmento de BPM. Existem empresas que se especializaram neste segmento,
fornecendo ferramentais muito avanados para este tipo de atividade.

www.portalbpm.com.br
O benefcio desta abordagem que, mais fcil para a empresa realinhar as atividades no negcio. Se a
ligao entre os Web Services feita atravs de um desenho, mudanas no desenho permitem alteraes
nas regras do negcio. Ou seja, pode-se mudar a forma como a empresa opera apenas mudando a ordem
em que os Web Services so chamados.
Caso no seja necessrio criar um novo Web-Service, mudanas acontecem muito rapidamente nos
sistemas. Estas ferramentas permitem tambm a retirada de mtricas para cada atividade de um processo.
Porque meu processo no eficiente? Em qual parte do processo posso efetuar melhorias? Estas so
perguntas frequentemente feitas pela rea gerencial e dificilmente respondidas em abordagens tradicionais,
pois como o desenvolvimento foi divido em sistemas, fica difcil saber onde exatamente uma atividade
demorou.
Como entender todas estas mudanas de paradigma ?
Eu entendo as tcnicas de BPM como um forma de levar a componentizao at o nvel do sistema,
fazendo com que cada servio vire o que chamvamos de componente, e a orquestrao o que
colocvamos no diagrama de sequncias como a ordem de chamada dos componentes. A diferena que
os artefatos esto mais prximos do usurio final do que do desenvolvedor, tendo mais chances de
sucesso. O desenho do processo tende a ser feito junto com o usurio final, diminuindo a distncia entre o
levantamento e o resultado apresentado.
Na verdade, as tcnicas de modelagem por processos foram criadas sem o objetivo de gerar cdigo, mas
com o propsito de fornecer entendimento sobre como a empresa opera. Hoje, a evoluo da modelagem
de processos e a criao dos BPMs corre em paralelo com o desenvolvimento orientado para objetos, com
um pequeno contato na tecnologia SOA, mas o caminho que parece natural o encontro entre as
tecnologias de forma mais forte, em um futuro prximo.
Links e livros
www.jboss.org/jbpm
www.bpmn.org
www.wfmf.org
www.w3c.org