2009 MSC NunoSantos

UniversidadedoMinho EscoladeEngenharia
ImplementaodeProcessosde NegcioemSoftwareUtilizando TransformaesdeModelos

NunoAntniodeLiraFernandesFariadosSantos
DissertaosubmetidaUniversidadedoMinho paraobtenodograudeMestreemEngenhariaeGestode SistemasdeInformao,elaboradasobaorientaocientficado ProfessorRicardoJorgeSilvriodeMagalhesMachado
UniversidadedoMinho EscoladeEngenharia DepartamentodeSistemasdeInformao Guimares,Outubrode2009
Agradecimentos
Agradecimentos
Agradeo ao Professor Doutor Ricardo Machado pela sua excelente tarefa de orientao de todo o processo da dissertao, pela transmisso do seu vasto conhecimento cientfico, aconselhamento formal e informal, pelo seu empenho em garantir que o trabalho no sofresse desvios de ndole temtica, pela motivao dada para que os prazos estipulados fossem cumpridos e, por fim, pela indicao e fornecimentodealgumabibliografiaimportantequesereveloufundamental. Agradeo Bosch Car Multimedia Portugal, Lda., em Braga, empresa onde elaborei o caso de estudo desta dissertao, a oportunidade concedida. Agradeo tambm aos meus colegas do Departamento de Informtica da empresa, todos sem excepo, por me proporcionarem uma integrao fcil e rpida. Tenho de agradecer especialmente ao Eng. Francisco Duarte, meu chefe, pela transmisso de conhecimentosobrealgunstemasabordados,pelatotaldisponibilidadeparadiscusso sobre vrias vertentes da dissertao e pelo aconselhamento do ponto de vista profissional e acadmico. No posso deixar de deixarum agradecimento ao Carlos Ribeiro, Marco Couto e Jos Pedro Arajo, com quem interagi mais durante o tempo em que estive na empresa, pela ajuda por eles fornecida durante a aprendizagem de certas tecnologias em que eu no dominava por completo e pela entreajuda aquando docontactocomtecnologiasutilizadasqueaindaerampoucodominadas. Agradeoaosmeuscolegaseamigosdalicenciaturaetambmposteriormente do mestrado, no s pela convivncia proporcionada ao longo de cinco anos pois alguma descompresso tambm necessria mas tambm pela troca de experincias e conhecimentos da elaborao das suas prprias dissertaes, que tambmconstituramcontributosparaestadissertao. Agradeo aos meus amigos pela compreenso da dedicao que a realizao deste tipo de trabalhos requer, dado que nem era sempre possvel a convivncia com eles. Por fim, mas no menos importante, agradeo minha famlia. Desde o facto de me proporcionarem condies durante todo o perodo estudantil at ao seu apoio totalnaalturaemquedeciditirarumapsgraduao.
iii
Sumrio
Dado que as organizaes se regem por processos de negcio, emergente a necessidade de o desenvolvimento do sistema de informao de uma organizao seja direccionado para suportar esses processos. Durante um processo de desenvolvimento de sistemas de informao so conhecidas vrias abordagens e metodologias com o objectivo de este seja obtido com cada vez maior acrscimo de qualidade. Essa qualidade devese reflectir na definio dos processos do sistema de informao e deve requerer uma metodologia que possua tarefas bem definidas e automatizadas. Uma metodologia possvel, a Business Implementation Methodology (BIM), prope transformaes dos processos de negcio de forma automatizada para que a implementao dos processos em software consuma menor esforo e menores custos. As quatro fases da metodologia so percorridas desde a definio inicialdosprocessosdenegcioataosistemadeinformaofinal. O que distingue nesta fase das outras metodologias a proposta de utilizar modelos
de referncia de processos. Dado o contexto, sugerese a utilizao de linguagens de modelaodeprocessospararepresentaogrficadosprocessosdenegcio. Para obteno do sistema de informao na ltima fase da metodologia seguida, proposta a utilizao do ModelDriven Architecture (MDA). A transformao de um modelo de processos de negcio que seja um Platform Independent Model (PIM) para um modelo que seja um Platform Specific Model (PSM) permitir a obteno da implementao do modelo de processos em software. O resultado da transformao ser um modelo composto pelo processode negcioemBPELepela devidaintegraodeaplicaesrealizadasatravsdouso deumEnterpriseServiceBus(ESB). Palavraschave: BusinessImplementationMethodology;linguagensdemodelaode processos;modelosderefernciadeprocessos;MDA;PIM;PSM;ESB
Sumario
vi
Abstract
Abstract
Duethefactthatorganisationsruletheirbusinessbybusinessprocesses,itisemerging the need that development of the information system should be oriented to support those processes. During the process of an information system development many approaches are known so it can be achieved with an increase of quality. This quality must be reflected in the definition of the information systems business processes and it requires a methodology that has well defined and automated tasks. A possible methodology, the Business Implementation Methodology (BIM), proposes transformations of business processes in an automated way so software implementation of the processes are less effort consuming. The four methodology phases are executed since the initial definition of the business process to the final information system. What distinguishes this methodology from other business implementation
methodologies in these initial phases is the use of process reference models proposal. In the context, it is suggested the use of business process modelling languages for visual representationofbusinessprocesses. For obtaining the information system in the last phase of the methodology, it is
proposedtheuseofOMGsModelDrivenArchitecture(MDA).Thetransformationofaprocess frameworkthatisaPlatformIndependentModel(PIM)toaPlatformSpecificModel(PSM)will allow obtaining software implementation. The result of the transformation will be a model composed by the business process in BPEL and the integration of applications through the use ofanEnterpriseServiceBus(ESB. Keywords: BusinessImplementationMethodology;businessprocessmodellinglanguages; processreferencemodels;MDA;PIM;PSM;ESB.
vii
Abstract
viii
ndices
ndice
Agradecimentos................................................................................................................ iii Sumrio.............................................................................................................................. v Abstract........................................................................................................................... vii ndice................................................................................................................................ix ndicedeFiguras............................................................................................................... xi ndicedeTabelas............................................................................................................ xiii Acrnimos....................................................................................................................... xiv 1. Introduo................................................................................................................ 1 1.1 1.2 1.3 1.4 2. ObjectivoseContributos.................................................................................. 2 AbordagemdaInvestigao.............................................................................4 TrabalhoRelacionado....................................................................................... 5 EstruturadoDocumento.................................................................................. 7
ExecuodeProcessoseTransformaesdeModelos.........................................11 2.1 2.2 2.3 2.4 2.5 2.6 Introduo...................................................................................................... 11 LinguagensdeRepresentaodeProcessosdeNegcio...............................12 ImplementaodosProcessos.......................................................................18 ModelDrivenDevelopment...........................................................................26 TransformaodosModelos..........................................................................31 Concluses...................................................................................................... 35
3.
ProcessosdeNegcioemModeloPIM..................................................................37 3.1 3.2 3.3 3.4 Introduo...................................................................................................... 37 AsLinguagensExistentes................................................................................38 ModelaodeProcessosdeNegcioemPIM...............................................52 Concluses...................................................................................................... 58
4.
TransformaoAutomatizadadosProcessos........................................................61 4.1 4.2 4.3 4.4 Introduo...................................................................................................... 61 TransformaodosProcessosPIM .................................................................62 ModelodeProcessosemPSM.......................................................................70 Concluses...................................................................................................... 82 ix
ndices 5.
Concluso................................................................................................................ 85 5.1 TrabalhoFuturo.............................................................................................. 88
Bibliografia...................................................................................................................... 91 AnexoAArtigoCientficoRelacionadocomaDissertao.......................................101 AnexoBDefiniesdosPadresdeWorkflow.........................................................113 AnexoCQuestionrio................................................................................................ 117 AnexoDTabeladerespostas.................................................................................... 123 AnexoECdigodoProcessoemRunnable...............................................................125 AnexoFCdigodosComponentesdoProcessoemSoftwareImplemented...........134
ndices
ndicedeFiguras
Figura1.IlustraodeumProcessoBPEL......................................................................15 Figura2.ArquitecturaYAWL.......................................................................................... 16 Figura3.ExemplodeumaRededePetri.......................................................................17 Figura4.As4FasesdaBIM............................................................................................ 19 Figura5.ExemplodeIntegraoUtilizandoumESB ......................................................23 Figura6.FrameworkdoApacheServiceMix..................................................................24 Figura7.TrocadeMensagensemAmbienteJBI...........................................................25 Figura8.ComposiodoServiceAssembly....................................................................26 Figura9.OMGModelDrivenArchitecture.....................................................................27 Figura10.TransformaodeumPIMparaPSM............................................................29 Figura11.As4camadasMDAeasRelaesdeInstncia,LingusticaeOntolgica.....29 Figura12.TransformaodosModelos.........................................................................32 Figura13.TechnologicalSpaceseRelaesEntreEles..................................................33 Figura14.TransformaodeCdigoJavaemC#...........................................................33 Figura15.RelaesentreMetamodelosQVT................................................................35 Figura16.ExemplodeCdigoBPELReferenteaNamespaces......................................48 Figura17.ExemplodeCdigoBPELReferenteaosPartnerlinks...................................48 Figura18.ExemplodeCdigoBPELReferentesVariveis..........................................49 Figura19.ExemplodeCdigoBPELReferenteSequnciadeActividades.................49 Figura20.ExemplodeCdigoWSDLReferenteaosNamespaces.................................49 Figura21.ExemplodeCdigoWSDLReferenteaosTiposdeElementos.....................50 Figura22.ExemplodeCdigoWSDLReferenteaosTiposdeMensagens....................50 Figura23.ExemplodeCdigoWSDLReferentesPortaseOperaes........................50 Figura24.ExemplodeCdigoWSDLReferentesFefiniesdoPartnerlink...............51 Figura25.ExemplodeumProcessoBPEL......................................................................51 Figura26.EstadosdosPFsnaBIMeTransformaodeumPIMparaPSM.................53 Figura27.EsquemadeTransformaoAdoptado.........................................................53 Figura28.FasedaTransformaoemqueseEncontraomodeloPIM.........................56 Figura29.ExcertodeProcessoBPEL"Produo"..........................................................57 Figura30.GenericPFRegistoProdutos.......................................................................58 xi
ndices
Figura31.FasedaTransformaoemqueseEncontramosRequisitos.......................63 Figura32.OperaesPropostaspeloCliente................................................................64 Figura33.ProcessodeBPELdeRegistarProdutoeActividadesdeCustomizao...65 Figura34.InstantiatedPFLanamentodeQuantidades............................................65 Figura35.RepresentaodasRelaesdosSoftwaresqueExecutamoProcesso.......66 Figura36.RunnablePFdeLanamentodeQuantidades...........................................67 Figura37.ExcertodoCdigoBPELFinal........................................................................68 Figura38.RepresentaodoWDSLdeLanamentodeQuantidades.......................68 Figura39.FasedaTransformaoemqueseEncontraaTransformaodoModelo ..71 Figura40.TransformaodosModelos.........................................................................71 Figura41.ComponentesdaPlataformaCriadosParaExecutaroProcesso..................72 Figura42.MapeamentoEntreosComponentesPIMePSM.........................................75 Figura43.FasedaTransformaoemqueseEncontraoPSM.....................................76 Figura44.FicheirodeServioWSDLCriadoaPartirdaClasseJava..............................78 Figura45.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutaroProcesso..............79 Figura46.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutarnoSAP....................79 Figura47.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutarnaBD......................79 Figura48.ProcessoBPELFinal....................................................................................... 80 Figura49.ExcertodoCdigoBPELFinal........................................................................80 Figura50.SAdosSU'scriados........................................................................................ 81 Figura51.BCeSEdepoisdoDeploydoSA....................................................................82 Figura52.ServiceMixdoModeloPSMFinal..................................................................82
xii
ndices
ndicedeTabelas
Tabela1.ComparaodaslinguagensbaseadanospadresWorkflow.......................40 Tabela2.Respostasqueapontamparalinguagens.......................................................42 Tabela3.Pontuaodosinquiridosacadalinguagem..................................................42 Tabela4.Comparaonombitodeumaorganizao.................................................45 Tabela5.Resultadosfinaisdaslinguagens....................................................................46 Tabela6.ActividadesBsicasBPEL................................................................................47 Tabela7.EstruturasAlgortmicasBPEL..........................................................................48 Tabela8.RelaesdoMapeamentoPIMPSM..............................................................73 Tabela9.ElementosparaMarcao..............................................................................74
xiii
Acrnimos
Acrnimos
4SRS ARIS ATL B2B B4P BC 4StepRuleSet ARchitectureforintegratedInformationSystems AtlasTransformationLanguage Businesstobusiness BPEL4People BindingComponent BusinessProcessDiagram BusinessImplementationMethodology BusinessProcessExecutionLanguage BusinessProcessExecutionLanguageforWebServices BusinessProcessManagement BusinessProcessManagementInitiative BusinessProcessModelingLanguage BusinessProcessModelingNotation BusinessProcessManagementSystem BusinessProcessQueryLanguage Conditioneventnets ComputerIndependentModel CarMultimedia CapabilityMaturityModel CompleteMOF CommonObjectRequestBrokerArchitecture Commercialofftheshelf ColoredPetriNets CustomerRelaionshipManagement CommonWarehouseMetamodel DARPAAgentMarkupLanguageforServices DatabaseManagementSystems DeliveryChannel DesignChainOperationsReference DesignDecisions DiscreteEventSystems
BPD BIM
BPEL BPEL4WS BPM BPMI BPML BPMN BPMS BPQL CEnets CIM CM
CMM CMOF CORBA COTS CPN CRM
CWM DAMLS DBMS DC
DCOR DD DES
xiv

DSL EAI DomainSpecificLanguages
EnterpriseIntegrationIntegration EuropeanFoundationforQualityManagement EnterpriseJavaBeans EssentialMOF EventdrivenProcessChain EnterpriseResourcePlanning EnterpriseServiceBus enhancedTelecomOperationsMap HighLevelPetrinets InternationalBusinessMachinesCorporation InternationalOrganizationforStandardization InformationTechnologyInfrastructureLibrary Java2Platform,EnterpriseEdition JavaBusinessIntegration JavaConnector JavaDatabaseConnectivity JavaMessageService ModeldrivenArchitecture ModeldrivenDevelopment ModeldrivenEngineering MessageExchangePattern ModelintegratedComputing MetaObjectFacility Nonfunctionalrequirements NormalizedMessageRouter OrchestratedBusinessObjects ObjectConstraintLanguage OrchestrationDirectorEngine ObjectManagementGroup WebOntologyLanguageforServices Process4 ProcessFramework PlatformIndependentModel PlainOldJavaObjects
Acrnimos
EFQM EJB
EMOF EPC ERP ESB
eTOM HLnet IBM ISO ITIL
J2EE JBI JCo
JDBC JMS
MDA MDD MDE MEP MIC
MOF NFR
NMR OBO OCL ODE
OMG OWLS P4 PF PIM
POJO
xv
Acrnimos
POM PrTnet PSM PSP ProjectObjectModel Predicate/TransitionNet PlatformSpecificModel PersonalSoftwareProcess Placetransitionnet Query/Views/Transformations RegularExpressionLanguage ServiceAssembly
PTnet QVT REL SA
SAPR/3
Systeme,AnwendungenundProdukteinderDatenverarbeitungRealtime SystemVersion3
SCOR SE SOA
SupplyChainOperationsReference ServiceEngine ServiceOrientedArchitecture SimpleObjectAccessProtocol SoftwareProcessEngineeringMetamodel ServiceUnit SoftwareEngineeringBookofKnowledge TecnologiasdeInformao TechnologicalSpaces TeamSoftwareProcess UnternehmensbereichKraftfahrzeugausrstung UnternehmensbereichKraftfahrzeugausrstungReferenceModel UnifiedModelingLanguage UMLActivityDiagrams WorkflowManagementCoalition WorkflowProcessDefinitionLanguage WebServices WebServiceChoreographyInterface WebServiceDescriptionLanguage WebServicesFlowLanguage WebServicesBusinessProcessExecutionLanguage XMLLANGuage XMLSchema XMLMetadataInterchange
SOAP SPEM SU
SWEBoK TI TS TSP UBK
UBKRM UML UMLAD WfMC WPDL WS
WSCI WSDL WSFL WSBPEL XLANG XSD XMI
xvi

XML XPDL YAWL yEPC eXtensibleMarkupLanguage
XMLProcessDefinitionLanguage YetAnotherWorkflowLanguage YAWLEventdrivenProcessChain
Acrnimos
xvii
Acrnimos
xviii
1. Introduo
Este captulo pretende apresentar o problema relacionado com a temtica do desenvolvimento de sistemas de informao em organizaes que se regem por processos de negcio. Dada a motivao do trabalho, so enunciados os objectivos a que este trabalho se props a alcanar. De seguida apresentada a abordagem de investigao seguida pelo autor do trabalho. O trabalho relacionado pretende apresentar algum trabalho semelhante j realizadoporoutrosautoresbemcomoaapresentaodaestruturadodocumento. O conceito de Business Process Management (BPM) [Smith e Fingar 2002] j um conceito largamente implementado pelas empresas, onde tambm o termo Enterprise Resource Planning (ERP) [Sandoe, Corbitt et al. 2001] se encontra inserido no ambiente organizacional, sendo este o sistema normalmente utilizado como suporte aos processos. Dado que as organizaes dos clientes j possuem sistemas de informao direccionados para BPM, os requisitos pedidos pelos prprios clientes j tm por base os processos de negcio, pelo que os modelos a utilizar no desenvolvimento de software que cumpram esses requisitos jtmdeserdireccionadosparaprocessosdenegcio. O desenvolvimento de software deve ento ter por base processos de negcio. Isto prendese com o facto de, em organizaes que se regem por processos (processoriented organizations) [Duarte, Fernandes et al. 2006], as actividades destas organizaes serem focadas na satisfao das necessidades dos clientes. Logo, para suportar estas actividades, tambm os sistemas de software desenvolvidos devem ser capazes de suportar processos e no apenas uma funo especfica de um departamento. O crescimento da quantidade de solues de Business Process Management Systems (BPMS) [Smith e Fingar 2002] que surgem nomercadoaconstataodessefacto. A metodologia utilizada neste trabalho para implementao dos processos, a Business Implementation Methodology (BIM) [Duarte, Machado et al. 2009], tem como caracterstica principal a de utilizar modelos de referncia de processos que forneam as melhores prticas organizacionais do sector e finalizar a implementao de um sistema de software no sistema deinformaodaorganizaoquegarantaasatisfaodosrequisitosdosprocessosdocliente. Aprincipalmotivaodestetrabalhoprendesecomaltimaparte.Naimplementao do processo em software, tal como nas restantes fases, no existem restries no que toca a notaes e a marcas e instituies, sendo totalmente independente. Para implementar o modelo de processos de negcio em software, uma abordagem modeldriven pode ser vantajosa, em termos de tempo e de complexidade. A ModelDriven Architecture (MDA) [OMG 2003] j mundialmente reconhecida na sua eficincia no desenvolvimento de
1.Introduo
software. A utilizao da MDA sugere a concepo de dois modelos. O Platform Independent Model(PIM)representaomodelodosprocessosdenegcio,eoPlatformSpecificModel(PSM) a execuo em software do modelo anterior [Duarte, Machado et al. 2007]. Resta ento saber se, aps o modelo de processos estar devidamente definido, a obteno de software a partir dosconceitosdeMDAefectuadacomumnveldeautomatizaodastarefaselevado. Maximizando o nvel de automatizao da implementao dos processos de negcio garantidaumaimplementaoseguraeeficiente,originandoumaquantidademnimadeerros durante todas as fases de um projecto de implementao, o que por sua vez resulta numa reduodotempoedosrecursosparaaempresa. No entanto, o desenvolvimento de um sistema de informao para a organizao continua a ser uma tarefa complicada, devido a implicar a integrao de vrias tecnologias. A integrao de sistemas informticos numa organizao alargase a toda a organizao e j passa as fronteiras da organizao, passando por integrar com as aplicaes de clientes e fornecedores. A integrao inclui cada vez mais aplicaes heterogneas entre si, dado que presentemente o ERP necessita estar integrado com sistemas de gesto de bases de dados, Customer Relationship Management (CRM) [Sandoe, Corbitt et al. 2001], datawarehouses, aplicaes de Business Intelligence, de apoio a decises, de escritrio e tambm de suporte a funes especficas. Como norma em ambientes organizacionais, o tempo dispendido tem que ser cada vez menor, bem como os custos associados. Integrar aplicaes da organizao e nos,empoucotempoecombaixoscustos,pode,devidoaheterogeneidadedasaplicaes, no ser tarefa fcil. com esse objectivo que esto sempre a surgir novas normas e abordagensdeintegrao,comoWebServices(WS)eServiceOrientedArchitecture(SOA).
1.1
ObjectivoseContributos
Este trabalho consiste em apresentar uma perspectiva de obteno de software no
desenvolvimentodesistemasdeinformaoparaorganizaesqueseregemporprocessosde negcio. A abordagem ao modeldriven development [Atkinson e Khne 2003] j provou ser apropriada para desenvolver software. Tal como o prprio titulo deste documento sugere, o principal objectivo deste trabalho de investigao o de utilizar transformaode modelos na actividade de desenvolvimento de um sistema de informao de uma organizao. Para tal, testada a tcnica de transformar processos utilizando os conceitos de Platform Independent Model(PIM)ePlatformSpecificModel(PSM)[OMG2003],doMDA.comosconceitosdePIM e PSM e utilizando transformao de modelos que se pretende obter um sistema de software
que execute os processos de negcio do sistema de informao. O principal contributo da investigao ento o de sugerir uma abordagem a modelos na fase em que se pretenda transformarumprocessodenegcioemsoftware.AutilizaodemodelosPIMePSMpermite que se obtenha software de uma forma perfeitamente automatizada. A metodologia de implementao dos processos seguida pela investigao, a BIM, um bom suporte para desenvolvimento de software para as organizaes que se regem por processos. O trabalho resultante desta investigao pretende ser um exemplo de suporte utilizao de uma metodologiacomoaBIM. A tarefa inicial ficou definida como identificar a linguagem de representao de processos de negcio que mais se adequa Bosch Car Multimedia Portugal, Lda. Esta tarefa prendese com o facto de a empresa no ter definida a utilizao de qualquer linguagem de modelao de processos, nem conhecimentos profundos das linguagens existentes no mercado. A definio de uma linguagem de representao dos processos de negcio deve ser a tarefa inicial executada antes de se percorrer as fases de uma qualquer metodologia de implementao dos processos, dado que a linguagem escolhida para definir os processos a utilizada ao longo de todo o desenvolvimento do sistema de informao. Alm de ser tido em conta aspectos das caractersticas e do funcionamento em termos tecnolgicos das prprias linguagens, tambm so analisados conceitos acerca de aspectos relacionados com os colaboradores da empresa e com o negcio em que esta est inserida. A utilizao destes dois aspectos adicionais na comparao das linguagens ser tambm uma das contribuies do trabalho. Este trabalho tambm pretende demonstrar a importncia do uso de modelos de referncia de processos pois, utilizando uma metodologia como a BIM, assegura que os processos reflictam boas prticas organizacionais. A utilizao de boas prticas resulta em processos de negcio que trazem maior valor acrescentado para a empresa onde estes funcionam.Osprocessosdomodeloderefernciaservemdebaseparaposteriormenteserem concebidos processos customizados que j respondam aos requisitos especficos do cliente. A utilizaodosmodelosderefernciacomobasejustificasetendoemcontaqueoclientepode no conhecer boasprticas interorganizacionais, ou ento no ter a capacidade de zelar correctamente pelo bem da sua organizao [Duarte, Machado et al. 2009]. Sendo que os processos no s usam boas prticas, mas tambm representam a lgica do negcio da organizao do cliente, assegurado que o processo est definido da melhor forma possvel emtermosdoseufuncionamento.Esteaspectoessencialnasuatransformaoemsoftware, pois a execuo automtica de um processo s traz vantagens se este realmente estiver bem definido.
1.Introduo
1.2
AbordagemdaInvestigao
O trabalho de investigao realizado segue as abordagens habituais para um
documento deste gnero. O trabalho dividese em duas partes: a parte terica e a parte prtica. A teoria apresentada primeiro, pois necessrio possuir um conhecimento de base dos conceitos apresentados para melhor se compreender o trabalho prtico seguinte. A parte prtica engloba a aplicao dos conceitos tericos em casos reais, num ambiente organizacional. Para a investigao, foi efectuada uma reviso de literatura no sentido de contextualizar dos conceitos tericos acerca de linguagens de modelao de processos de negcio, implementao de processos, modeldriven development e transformao de modelos, de modo a realizar uma anlise ao estado da arte destes temas. Pretendese nesta fase atingir o conhecimento terico necessrio para melhor estruturar a aplicao deste trabalho numa organizao que vai servir de caso de demonstrao. Todos os conceitos revistos iro servir de base no desenvolvimento da transformao automatizada dos modelos de processos, para se obter processos implementados em sistemas de software. A pesquisa bibliogrfica inicialmente feita para identificao dos principais conceitos associados a cada tema. Ao identificar os conceitos, tornase necessrio tambm identificar quais os autores mais influentes na rea, bem como as instituies que possuam especificaes standard do tema abordado. Um determinado conceito sempre descrito conforme a especificao oficial da instituio correspondente, sendo que citaes de autores so necessrias para apresentao e discusso dos seus pontos de vista. Ser realizada tambm pesquisa de citaes que apresentem perspectivas alternativas. Para melhor fundamentar um ponto de vista, os autores citados por autores identificados na bibliografia tambm ir ser tido em conta. Para testar e demonstrar a validade da automatizao do desenvolvimento de sistemas, realizouse um caso de demonstrao, utilizando para o efeito recursos e processos de negcio de uma organizao, neste caso a Bosch Car Multimedia (CM) Portugal, Lda., em Braga. nesta fase que so feitas as experincias para se chegar soluo final e identificar alternativas.Almdeutilizarmodelosdereferncia paraosprocessosdenegcio,estesforam posteriormente aplicados a processos de negcio efectivamente executados na Bosch CM, criandoconjuntosdeprocessosquesejampossveisdesertransformados.
Para alm dos processos de negcio, tambm um grupo de colaboradores pertencentesaodepartamentodeinformticadaBoschCMparticipaactivamentenotrabalho. Este grupo de colaboradores respondeu a um questionrio sobre linguagens de modelao de processos,inseridonaactividadedecomparaoeescolhadalinguagemmaisapropriadapara modelar os processos de negcio da empresa. O questionrio era composto por um conjunto de perguntas de escolha mltipla, tanto perguntas em que se pretende apenas uma resposta bem como perguntas com respostas mltiplas. As respostas ao questionrio eram annimas, pois a identidade dos colaboradores no era relevante. Aps a recolha das respostas, um estudoestatsticoanalisaosresultados.
1.3
TrabalhoRelacionado
A realizao de transformaes em linguagens de processos utilizando o MDA j
temadetrabalhosanteriores.[Zhao,Hauseretal.2006]transformaprocessosemmodeloPIM em Diagramas de Actividade UML2 num modelo PSM em BPEL atravs do mtodo REL (Regular Expression Language), tal como [Bzivin, Hammoudi et al. 2004] que realiza a mesma transformaoutilizandoalinguagemdetransformaoATL(ATLASTransformationLanguage) [Bzivin, Dup et al. 2003], ou ento [Koehler, Hauser et al. 2005] que transforma o modelo utilizando regras OCL (Object Constraint Language) [OMG 2006]. Outro tipo de abordagem realizado por [Bauer, Muller et al. 2004] e [Lezoche, Missikoff et al. 2008], que comeam por conceber um modelo de processos CIM em EPC [Nttgens, Feld et al. 1998], transformando o CIM num modelo de processosPIM em BPMN [White 2004] e finalmente obter um modelo de processos PSM em BPEL. Uma abordagem diferente
possuem
[Rodriguez, FernandezMedina et al. 2007] e [Rungworawut e Senivongse 2006] que realizam transformao de um modelo CIM em BPMN em modelos PIM em UML [OMG 2009], em Diagramasdecasosdeusoeemdiagramasdeclasses,respectivamente. Uma metodologia para implementao do negcio a mLEARN [Coelho 2005]. A metodologia mLEARN, conhecida pela metodologia das competncias organizacionais, fornece tcnicas para representao dos processos de negcio organizacionais, devidamente alinhados com os objectivos estratgicos e tambm clarifica as responsabilidades na organizao. AmLEARNassentanumaabordagemintegradaesistmicadaorganizao,numa orientao a objectos organizacionais, apoiado em tcnicas interactivas e com a preocupao dagestodoconhecimentoorganizacionaledamudana. A mLEARN apenas define tarefas no sentido de se definir uma arquitectura de processos de negcio. No sentido de adicionar implementao de software aos processos, podem ser utilizadas tcnicas como o 4Step Rule Set (4SRS) [Machado, Fernandes et al. 2005]
1.Introduo
ou o standard MOF Query/View/Transformation (QVT) [OMG 2005] da OMG. O 4SRS uma tcnica para transformar requisitos dos utilizadores em modelos arquitecturais que representam os requisitos do sistema. Associa, para cada objecto encontrado durante a fase da anlise, uma determinada categoria: interface, dados e controlo. O objectivo do QVT obter uma domain specific language (DSL) [Deursen, Klint et al. 2000] para realizar queries, views e transformaes em modelos. O QVT permite efectuar relaes de correspondncia entre modelos, nas quais um cdigo de um modelo posteriormente transformado e obtm seumcdigodeumoutromodelo. O conceito de Process Reference Models (modelo de referncia de processos) um
conceito com o objectivo de fornecer boasprticas que possam ser utilizadas entre organizaes. Integram conceitos de Business Process Reengineering, benchmarking e anlise de boasprticas [SCC 2008]. Actualmente, existem Process Reference Models disponveis para as organizaes, como SupplyChain Operations Reference model (SCOR) [SCC 2008], DesignChain Operations Reference model (DCOR) [SCC 2006], Information Technology Infrastructure Library (ITIL) [ifSMF 2007] ou o Enhanced Telecommunications Operations Map (eTOM)[TMForum]. A arquitectura Spring [Johnson, Hoeller et al. 2005] fornece uma plataforma para executarprocessosdenegcio.constitudaportrscamadas:manipulaodeinterfacescom utilizador (por exemplo, Web browsers ou EJB), implementao de regras de entidades e de negcio (por exemplo, um Application Server), e persistncia de dados (por exemplo, um servidordebasesdedados). No mbito de integrao de aplicaes empresariais, [Hohpe e Woolf 2004] define um conjunto de padres de integrao em organizaes (Enterprise Integration Patterns), onde so definidos requisitos que a integrao de aplicaes deve obedecer num ambiente organizacional,bemcomoalgumastcnicasesolues. Para implementar a integrao de aplicaes existem alguns open Enterprise Service Bus (open ESBs). Os open ESBs so vantajosos no sentido em que so open source e utilizam open standards. Alguns exemplos das ferramentas mais conhecidas so o Mule, o Apache ServiceMix, o OpenESB, o Apache Synapse, o JBoss ESB, o Apache Tuscany, o Fuse ESB, o OW2 PEtALSeoOpenAdapter[RademakerseDirksen2008]. Atingindose uma determinada quantidade de processos de negcio
devidamente modelados, pode ser necessrio um sistema de gesto dos processos, que funcione como um repositrio. O BPEL Repository [Vanhatalo 2006] armazena ficheiros BPEL bemcomooutrosficheirosXML,WSDLouXSD.Orepositriotambmpermiteconsultasfceis
repositrio.
aos dados utilizando a Object Constraint Language para executar queries dentro do
De referir ainda algum trabalho j existente na avaliao de linguagens de modelao de processos. Os padres de workflow [Aalst, Hofstede et al. 2003] foram compilados a partir de uma anlise s linguagens de workflow e capturam dependncias encontradas na modelao do controlo do fluxo. A abordagem dos vinte padres de workflow traz vantagens na medida em que analisa exemplos de controlo de fluxo que podem ocorrer durante um processo e possvel verificar se possvel na modelao do processo numa determinada linguagem. Nestetrabalhotambmoscolaboradoresdaorganizao(nestecaso,comfunesem
projectossesistemasdeinformao,softwareesuporteaprocessosdenegcio)soavaliados no seu conhecimento das linguagens. Para avaliar competncias de programadores no que toca a desenvolvimento de sistemas de software h a possibilidade de recorrer anlise nas reas de conhecimento do SWEBoK [Abran, Bourque et al. 2004], ou ainda analisar segundo nveis de maturidade da empresa (CMM) [CMMI 2006], do indivduo (PSP) [PomeroyHuff,Mullaney etal.2005], oudaequipa(TSP)[Humphrey1999],talcomosugereo SEI. O Personal Software Process (PSP) pretende classificar o indivduo, no tanto quanto aos conhecimentos que possui de desenvolvimento de software, mas sim quanto ao processo de desenvolvimento do software. possvel ento dizer que o PSP classifica o indivduo quanto metodologiautilizadanodesenvolvimentodesoftware.
1.4
EstruturadoDocumento
Este documento foi definido atendendo a uma estrutura normalmente adoptada de
umadissertao,seguindoosmesmospassospropostospor[Berndtsson,Hanssonetal.2007]. Para alm deste captulo onde o problema introduzido e a contribuio e os objectivos da investigao so estabelecidos, o documento constitudo por um captulo que descreve o estudo do estado da arte de um conjunto de conceitos identificados com relevncia para o trabalho de investigao. Os captulos seguintes contm a descrio da proposta, onde so exemplificadas todas as abordagens, bem como a validao e a experimentao dos cenrios. nestes captulos que feita a discusso de resultados obtidos. Para finalizar o documento, existeumcaptulode conclusesonde efectuadoumbalanodotrabalhorealizado,quaisas contribuies da investigao e tambm so apresentadas futuras investigaes relacionadas comosconceitosabordados.
1.Introduo
No captulo 2 esto apresentados os conceitos tericos necessrios para a realizao do trabalho posterior. Primeiramente, feita uma anlise s principais linguagens de modelao de processos de negcio, qual se segue uma comparao destas com o objectivo de verificar qual delas se adequa melhor para se utilizar na execuo dos processos. Se, para cadalinguagemrealizadaumaanlisessuasprincipaiscaractersticaseaosaspectosqueas diferenciam. Tambm apresentada uma primeira abordagem metodologia de implementao dos processos (BIM), modelos de referncia de processos e a plataforma para executar ao nvel de software os processos de negcio (ESB). De seguida, apresentado o mtodo de desenvolvimento de software baseado em modelos (MDD)
[Atkinson e Khne 2003], onde se analisa as principais caractersticas, alguns standards (da OMG) e os principais conceitos (como o CIM, PIM e PSM). Por fim, abordado o tema da transformao de modelos, onde so apresentados conceitos e tcnicas de automatizao de transposiodemodelosparaumsistemadesoftware. No captulo 3 dado incio ao caso de demonstrao. O trabalho tem como caso de demonstrao uma empresa do sector industrial, a Bosch Car Multimedia Portugal, Lda. Dado que a empresa no tinha ainda adoptado uma linguagem de modelao de processos, procedeuse escolha da linguagem mais apropriada. A comparao foi efectuada no s ao nvel tecnolgico de cada linguagem, mas tambm ao nvel intrnseco dos futuros utilizadores da linguagem e ao nvel do prprio negcio em que a empresa est inserida. Acerca da comparao entre as linguagens, no anexo B encontramse descritos os vinte padres de workflowdefinidospor[Aalst,Hofstedeet al.2003],paramelhorseperceber comoaprimeira comparao foi realizada. Ainda relativamente comparao, no anexo C est reproduzido o questionrio realizado aos colaboradores do Departamento de Informtica da Bosch Car MultimediaPortugal,Lda.nombitodaescolhadalinguagemsegundooperfildosutilizadores e, no anexo D, a tabela de respostas do questionrio que relata as respostas obtidas ao referido questionrio. Escolhida a linguagem, feita uma apresentao mais detalhada, com as especificaes que so necessrias para ter conhecimento na sua utilizao. Alm do tema das linguagens, neste captulo tambm abordada a forma como os processos modelados na linguagem sero implementados. Para tal, descrita a metodologia a ser seguida, a Business Implementation Methodology (BIM), bem como uma descrio da forma como esta vai ser seguida ao longo do restante trabalho. Para finalizar a primeira parte da demonstrao, um conjuntodeprocessosdenegciogenricos,talcomopropostonaBIM,juntocomadiscusso daadopodemodelosdereferncia,somodelados.
Durante o captulo 4 so seguidas as restantes fases da metodologia adoptada, bem como includa a proposta de investigao relativa transio para a ltima das fases, a utilizao do MDA para obter uma transformao em software. Numa primeira parte, discutido como os processos genricos podem ser utilizados para posterior modelao de processos denegcio medida do negcio do cliente, bem como uma abordagem em que o processo de negcio anteriormente modelado medida resulta num processo de negcio que seja executvel no sistema de informao da organizao. O referido processo de negcio executvel descrito na linguagem BPEL, pelo que o correspondente cdigo BPEL e WSDL reproduzido no anexo E. Posteriormente, discutida uma forma de utilizar os conceitos de PIM e PSM da MDA para se atingir a ltima fase da BIM, a Implementao. Para demonstrar o resultado, o processo de negcio implementado numa plataforma de execuo dos processos, o Enterprise Service Bus (ESB). Todos os componentes do ESB necessrios para obter um modelo PSM so descritos e o respectivo cdigo de todos os componentes descritos soreproduzidosnoanexoF. O captulo 5 pretende apresentar a importncia da investigao realizada. realizado um balano dos objectivos previamente estabelecidos que foram efectivamente cumpridos, bem como apresentar as contribuies cientficas fornecidas pelo documento. Como no existe documento ou investigao perfeita, apresentado um conjunto de conceitos que podemseralvodeinvestigaofutura. No anexo A reproduzido integralmente uma verso draft do artigo cientfico que ir ser, posteriormente, submetido em conferncias cujo tema referente dissertao, intitulado MDA Transformations in Order to Obtain Information Systems. O artigo foi desenvolvido em conjunto com o Eng. Francisco Duarte, do Departamento de Sistemas de Informao da Universidade do Minho, em Guimares, e responsvel pela seco de Sistemas de Informao do Departamento de Informtica da Bosch Car Multimedia Portugal, Lda., e comoProf.Dr.RicardoMachado,igualmentedoDepartamentodeSistemasdeInformaoda UniversidadedoMinhoeorientadordadissertaodemestrado.
1.Introduo
10
2. ExecuodeProcessoseTransformaesdeModelos
O objectivo deste captulo fornecer um contexto terico acerca dos temas abrangidos. O primeiro tema abordado neste captulo o das linguagens de modelao de processos de negcio, onde feita uma breve descrio das principais caractersticas das principais linguagens. Conceitos de implementao dos processos de negcio tambm so apresentados. A metodologia de implementao dos processos apresentada, bem como as suas fases que a constituem e os principais conceitos a reter. De seguida, apresentado o mtodo de desenvolvimento de software baseado em modelos, alguns standards e os principais conceitos (como o Computation Independent Model CIM, Platform Independent Model PIM e Platform Specific Model PSM) [OMG 2003]. Por fim, abordado o tema da transformaodemodelos.
2.1
Introduo
Este documento baseado em trs conceitos principais, nomeadamente o
ModelDriven Development (MDD) [Atkinson e Khne 2003], a transformao de modelos do MDD, e estes aplicados no desenvolvimento de software em organizaes orientadas a processos de negcio. O tema dos processos de negcio encontrase dividido nas linguagens demodelaoexistentesenaimplementaodosprocessosnumsistemadeinformao. A Engenharia de Software preocupase actualmente em explicar o qu que a mquina deve fazer, ao invs de especificar como o ir fazer. neste mbito que surge o desenvolvimentodesistemasdesoftwarebaseadoemmodelos.Ummodeloumconjuntode elementosquedescrevemalgoqueirserdesenvolvido.Deverserabstracto,compreensvel, preciso, previsvel e com menores custos [Gasevic, Djuric et al. 2006]. O MDD surge como abordagem vantajosa no desenvolvimento de software e com base nessa abordagem que ser modelado o sistema de informao. O ModelDriven Architecture (MDA) [OMG 2003] uma iniciativa que surge para que seja possvel utilizar os principais standards da Object Management Group (OMG) [OMG.org], como por exemplo Meta Object Facility (MOF) [OMG2005]eoQuery/Views/Tranformations(QVT)[OMG2005],descritosnestedocumento. No Computation Independent Model (CIM) [OMG 2003], so especificados o ambiente e os requisitos do sistema, sendo que os detalhes da estrutura do sistema so ocultados. O Platform Independent Model (PIM) [OMG 2003] um modelo que a sua especificao no se altera de uma plataforma para outra. Possui um grau de independncia da plataforma de forma a que o modelo possa ser executado em vrias plataformas de diferentes tipos. O PlatformSpecificModel (PSM)[OMG2003]resultadoprocessodetransformaodoPIMpara queasespecificaesdoPIMsejamiguaissespecificaesdaplataformaespecfica.
11
2.ExecuodeProcessoseTransformaodeModelos
Para passarmos do PIM para o PSM necessrio um processo de transformao do modelo. Normalmente, o processo de transformao de modelos realizado seguindo os conceitosdemapeamentoetransformao. As linguagens de representao de negcio permitem modelar os processos, normalmente utilizando para especificar as tarefas e decises a tomar em relao aos dados. Permitem tambm verificar o estado do processo, dado estarem relacionados a Web Services. A descrio do relacionamento dos processos com os Web Services envolventes inclui especificarcomoumprocessodenegcioutilizaosWebServicesparaalcanarseusobjectivos [Maldaner e Pasqual 2006]. A linguagem de programao que estas linguagens normalmente utilizamoXML. Para implementao dos processos de negcio descritos segundo uma qualquer linguagem,umapossvelsoluoautilizaodeumEnterpriseServiceBus(ESB).Noentanto, ainda na fase inicial de construo do processo, proposta a utilizao de modelos de refernciadeprocessos,demodoautilizarnormasdeboasprticasorganizacionais.
2.2
LinguagensdeRepresentaodeProcessosdeNegcio
A escolha de uma linguagem de modelao de processos de negcio mais adequada
para a Bosch Car Multimedia Portugal, Lda. o primeiro objectivo proposto. Para tal, foi realizado um levantamento e anlise s principais linguagens, como BPML (Business Process Modeling Language) [BPMI 2001], BPEL (Business Process Execution Language) [OASIS 2007] XPDL (XML Process Definition Language) [WfMC 2008], YAWL (Yet Another Workflow Language) [Aalst e Hofstede 2002] e CPN (Colored Petri Nets) [Jensen 1992]. Para melhor compreenso, feita tambm uma descrio da tcnica EPC (Eventdriven Process Chain) [Nttgens, Feld et al. 1998], que uma tcnica de descrio utilizada na modelao das linguagens e inclusivamente um tcnica j conhecida da organizao onde se vai realizar o casodedemonstrao,eanotaoBPMN(BusinessProcessModelingNotation)[White2004], poisoBPML,BPELeXPDLsobaseadosnestanotao.
EventdrivenProcessChain(EPC)
O mtodo Eventdriven Process Chain (EPC) permite modelar processos de negcio
com o propsito de implementao num ERP. suportado pelo ARIS (ARchitecture for integrated Infomation Systems) e pelo SAP R/3 [Nttgens, Feld et al. 1998]. A abordagem ARIS
12
foi desenvolvida na universidade de Saarbrucken, Alemanha, em 1992 com o objectivo principaldepermitiradescrioedesenvolvimentodesistemasdeinformaoqueestivessem integrados estrutura da organizao atravs de seus processos de negcio [Jnior, Almeida et al. 2008]. O EPC obteve um crescimento quanto sua utilizao como linguagemdemodelaodevidoaosucessodestesdoisprodutos. No EPC,os processosso sequncias de eventos que desencadeiam (triggers) funes,
representando as dependncias lgicas e temporais das actividades de um processo. Ao introduzir operadores booleanos (AND, OR e XOR), a estrutura EPC podese expandir para um complexo workflow que ilustra as principais decises de negcio. A ilustrao de fluxos de dados,deunidadesorganizacionaisedeutilizaodesistemasTIrepresentaumaexpansodo EPCparadescriodoscomponentessemntica.
BPMN(BusinessProcessModelingNotation)
BPMN [White 2004] a especificao standard da Business Process Management Iniciative (BPMI) [BPMI.org] para, tal como o prprio nome indica, notaes de modelao de processos denegcio. O BPMN a linguagem para definio de processos denegcios na fase de anlise e est incorporada em linguagens como o BPML, BPEL e XPDL [Junior 2005]. De referenciar que, no caso das linguagens BPEL e XPDL, a incorporao do BPMN apenas possvelgraasutilizaodemetamodelosdeprocessosdenegcio[Harmon2004]. BPMN tem como principal objectivo o de fornecer uma notao facilmente compreensvel por todos os utilizadores empresariais, analistas de negcio que tenham criado osprimeirosrascunhosdosprocessos,tcnicosresponsveispelodesenvolvimentoeaplicao da tecnologia que iro realizar os processos e, finalmente, empresrios que vo gerir e acompanhar os processos. O BPMN , ento, um mecanismo simples que permite o desenvolvimento dos modelos processos de negcio e garante a complexidade inerente aos processos. O BPMN define um Business Process Diagram (BPD) [Aalst, Dumas et al. 2006], que
uma espcie de fluxograma constitudo por um conjunto de elementos grficos. Estes elementos permitem o fcil desenvolvimento de diagramas simples que parecem familiares para a maioria dos analistas de negcio incorporando construes adaptadas modelao de processos de negcio, tais como ANDsplit, ANDjoin, XORsplit, XORjoin
[Aalst,Dumasetal.2006].
13
BPML(BusinessProcessModelingLanguage)
O Business Process Modeling Language (BPML) uma metalinguagem da BPMI [BPMI.org] para modelao de processos de negcio, suportada por empresas como a SAP, Intalio, Sun e Versata. A especificao BPML suporta XML 1.0, XMLNamespaces, XMLSchema 1.0eXPath1.0[Arkin2002]. BPML fornece um modelo abstracto para processos de negcio colaborativos e transaccionais que abrangem vrias aplicaes, departamentos e parceiros de negcio. Como abrange vrias dimenses da gesto de processos de negcio, o BPML consegue unir as infra estruturas de TI herdadas com os protocolos B2B (Businesstobusiness) emergentes, tais comoebXML,RosettaNeteBizTalk[BPMI2001]. A modelao de BPML constituda por: actividades (simples ou complexas), processos, contextos, propriedades e sinais. As actividades so componentes de desempenho de funes especficas. Um processo uma actividade complexa que pode ser invocada por outros processos. Um contexto define um ambiente para a execuo das actividades relacionadas, pode ser utilizado para trocar informaes e coordenar execues. Propriedades so utilizadas para troca de informaes e s existe num contexto. Os sinais so usados para coordenaraexecuodasactividades.
BPEL(BusinessProcessExecutionLanguage)
Business Process Execution Language (BPEL), ou formalmente Web Services Business Process Execution Language (WSBPEL) [Oasis 2007], uma linguagem de especificao de Web Services (WS) [Couloris, Dollimore et al. 2001] que surge como juno das linguagens WSFL da IBM e XLANG da Microsoft e foi inicialmente denominada de BPEL4WS, passando a ser BPEL por uma questo de simplicidade. Esta convergncia incorporou as especificaes WSCoordination, WSTransaction e WSSecurity [Martins 2005] em resposta especificao BPML(daBPMI)[BPMI.org]maisabrangente. AnormaBPELforneceumalinguagemquecapazdeespecificarprocessosdenegcio e o estado dos seus processos, atravs da relao destes com os Web Services. A descrio do relacionamento dos processos com os Web Services envolventes inclui especificar como um processo de negcio utiliza os Web Services para alcanar seus objectivos [Maldaner e Pasqual 2006]. Os processos de negcio especificados em BPEL (Figura 1) so executveis em qualquer ferramenta BPEL, que especifica qual o servio que o Web Service prestaaoprocessoBPEL.
14
Figura1.IlustraodeumProcessoBPEL[MaldanerePasqual2006]
OProcessoBPELconstitudopor2tiposdearquivos: Um arquivo WSDL [W3C 2007], que contm toda a especificao do tipo de ligao entre as interfaces, propriedades, tipo de portas e operaes, mensagens e parte de interesse do processo, incluindo servios implementadoseinvocadospeloprocesso;
Um arquivo BPEL, que codifica o processo em XML, incluindo todas as actividades e principais variveis envolvidas. Por herdar as caractersticas da Microsoft XLANG e da IBM WSFL, o BPEL utiliza tanto oconceitodoclculodepi[Milner,Parrowetal.1989]comodasredesde Petri[Petri1962],aproveitandoascaractersticasevantagensdeambos.
XPDL(XMLProcessDefinitionLanguage)
O XML Process Definition Language (XPDL) [WfMC 2008] foi standardizado pelo
Workflow Management Coalition (WfMC) [WfMC.org] com o objectivo de desenvolver uma linguagemquesuportasseatrocadedefiniesdosworkflowsdosprocessosdenegcio. Em 2008, lanada a verso final para a verso 2.1 do XPDL [WfMC 2008]. Na sua
definio, podemos ver que no se deu apenas a transformao do WPDL numa linguagem baseada em XML, mas tambm foram adicionados e modificados alguns conceitos em relao aoWPDL.Oprincipalfocodestalinguagemadefiniodadistribuiodetrabalhoatravsde
15
sua estrutura baseada em grafos [Junior 2005]. O XPDL tem como principais elementos: Package, Application, WorkflowProcess, Activity, Transition, Participant, DataField, e DataType[Aalst2003].
YAWL(YetAnotherWorkflowLanguage)
YAWL [Aalst e Hofstede 2002] foi proposta baseada numa rigorosa anlise de sistemas de gesto de workflow e linguagens de workflow existentes. O YAWL baseado na teoria de redes de Petri, suportando alguns smbolos diferenciados de outras linguagens. As linguagens baseadas em redes de Petri so melhor executadas quando seguem os padres de workflow baseadosemestados[MaldanerePasqual2006].Contudo,algunspadresnosofacilmente mapeados em redes de Petri (de alto nvel). com essa inteno que ento se revela necessrio odesenvolvimento de uma nova linguagem, tendo como ponto de partida as redes de Petri e adicionando mecanismos que permitissem um suporte mais directo e intuitivo aos padresjidentificados.dessanecessidadequesurgeoYAWL. Entre todas as linguagens YAWL a nica que segue os 20 padres impostos pelo P4 (Process 4 um grupo constitudo por van der Aalst, ter Hofstede, Kiepuszewski e o Barriosa Group), pois a prpria linguagem foi proposta justamente por esse grupo. YAWL utiliza uma arquitectura orientada a servios (Figura 2), que controla os fluxos atravs de servios (YAWL Services),nosquaisasentidadesexternasoferecemserviosourequeremservios.
Figura2.ArquitecturaYAWL[Aalst,Aldredetal.2004]
RedesdePetriColoridas(CPN)
Redes de Petri (Petri Nets) so uma classe de grafos generalizados, criados por Carl
AdamPetri, nombitodasuatesede doutoramento[Petri1962],paraenfrentarconcorrncia
16
em sistemas. Porque possuem uma descrio matemtica associada representao grfica, as redes Petri so uma ferramenta que est bem adaptada, no s para modelao, mas tambm para a anlise e estudo de eventos discretos de sistemas (DES), especialmente aqueles nos quais eventos podem ocorrer simultaneamente. Em outras palavras, utilizando redes de Petri para modelar um sistema conduz a uma descrio matemtica desse sistema, quepermite oestudoanalticodasuaestruturaepropriedades,inclusiveaquelesassociadosa ocorrnciasimultneadeeventosdosistema. A representao de uma rede de Petri um grafo direccionado bipartido.
Matematicamente, uma Rede de Petri R=(P, T, I, O) definida formalmente por: [Oliveira2006] Na sua modelao, um lugar representado por um crculo, uma transio por uma barra(ourectngulo)eumamarca(outoken)porumpontonolugar(Figura3).Asligaesso efectuadas por arcos, que tero um determinado peso (a no ser que o peso seja de valor zero). UmconjuntofinitoPdelugares(places); UmconjuntofinitoTdetransies; UmafunodeentradaI:TP(P) UmafunodesadaO:TP(P)
Figura3.ExemplodeumaRededePetri[Oliveira2006]
A marca, ou token, utilizada para descrever o estado do sistema no lugar onde se
encontra, sendo que a normal utilizao das redes de Petri atravs de condies do estado
17
dos lugares, isto , se o lugar est marcado ou no. Da que uma posterior denominao das redesdePetrioriginaissejaconditioneventnets(CEnets). Posteriormente surgem as redes LugarTransio (Placetransition net PTnet), onde
os lugares podem ter mais de uma marca e os arcos so ponderados, indicando quantas marcasseroretiradase/ouinseridascomodisparodatransioqualoarcoincidente. O primeiro metamodelo de redes de Petri de alto nvel surgem em 1981, as
Predicate/Transition Nets (PrTnets). Estas redes so basicamente a juno das PTnets e as CEnets,peloquepossuemosmesmosconceitosdestasduasredes. sPrTnetsseguiramseastimePetrinets,coloredPetrinets,objectorientedPetrinets
eupgradedPetrinets[Oliveira2006]. As primeiras redes de Petri coloridas (CPN) surgem no intuito de resolver limitaes das PrTnets [Jensen 1992]. So directamente inspiradas nas PrTnets, mas utilizam funes associadas aos arcos, em detrimento de expresses. Em alguns artigos, as CPN podem aparecer denominadas HighLevel Petrinets (HLnets). As CPnets permitem manipular tipos de dados complexos, pois cada token tem associado um valor, que ser a cor do token, que pode ser analisada e modificada pela transio que estiver a ocorrer. Com CPnets possvel obter um modelo largo utilizando combinaes de pequenos submodelos, as interfaces so bemdefinidas, bem como a semntica, e os submodelos podem ser reutilizados [Jensen1992].
2.3
ImplementaodosProcessos
O desenvolvimento de processos de negcio uma tarefa que vai muito alm da sua
representao.Adefiniodosprocessosdeveserconstitudaporumconjuntodetarefas,que vo desde os requisitos, modelao ou implementao. Tal como h que ter em conta conceitos como notaes, ferramentas (de representao e de execuo), arquitecturas, sistema de informao. nesse sentido que se torna necessria a utilizao de uma metodologia para a implementao dos processos. A metodologia apresentada de seguida constituda por quatro fases de transies entre processos. A metodologia iniciase com processospreviamentedefinidosque servirocomobase,utilizandomodelosderefernciade processos.Ametodologiafinalizadacomimplementaoemsoftwaredosprocessos,ondeo usodeumEnterpriseServiceBusproposto.
18
BusinessImplementationMethodology(BIM)
A BIM [Duarte, Machado et al. 2009] uma metodologia de implementao em
software de processos de negcio de uma organizao. Esta metodologia prope o uso de boasprcticas do domnio do negcio, e permite a customizao do processo de modo a que as necessidades da organizao sejam atendidas pelo processo em causa. uma metodologia flexvel,quepermitevriastecnologiasindependentesumasdasoutras,bemcomoautilizao deprodutosdevriosvendedores. O objectivo da BIM o de servir como um guia para a implementao de sistemas de
software para organizaes que funcionam orientadas a processos. Permite tambm o uso de diferentes notaes em cada uma das suas fases, pois a transformao dos modelos em cada fase independente de notaes. Tambm permite a utilizao de tecnologias de diversos vendedores, de modo a suportar processos de negcio de um modo real. A BIM utiliza conceitos tais como processos de negcio genricos, aspectos organizacionais que esto presentes nos processos, a arquitectura do processo e a implementao em software das entidadesdonegcio. A BIM constituda por quatro fases: seleco (Selection) dos processos de negcio
genricos adequados; definio (Definition) dos processos a utilizar; a concretizao (Concretisation) do processo no sistema de informao da organizao onde vai funcionar; e a implementao em software (Implementation) das vrias entidades que compe o processo (Figura4).
Figura4.As4FasesdaBIM[Duarte,Machadoetal.2009]
A particularidade que define qual a fase da metodologia em que o processo se
encontra o estado, no sentido em que responda a determinados requisitos da metodologia, da arquitectura dos processos. Definidos os requisitos necessrios para finalizar cada fase, atribuda arquitectura do processo um estado. Os estados definidos pela metodologia so genricos (Generic), instanciados (Instantiated), executveis (Runnable) e implementados em software (Software Implemented). A cada estado da arquitectura dos processos (Process FrameworkPF)correspondeentocadaumadasfasesdaBIM.
19
Na fase de Seleco, o analista do processo escolhe um modelo de referncia de
processosadequadoparaonegcio.Oanalistavaitambm,emconjuntocomocliente,definir um conjunto de aspectos organizacionais a incluir no modelo de processos genrico. Esta fase terminaquandoomodelogenricoestescolhido. Na fase de Definio, o modelo de processos genrico deve passar a ser instanciado.
Paratal,oclienteeoarquitectodoprocessodevemdefinirquaisasnecessidadesdoprocesso. De referir que o modelo genrico deve ser sempre o modelo utilizado como base para a instanciao, de modo a que o modelo resultante utilize devidamente um modelo de refernciaentreorganizaes[Duarte,Machadoetal.2007]. A fase de Concretizao j pressupe que o modelo de processos se encontra na sua
representao final, de modo a definir claramente a sua funo no sistema de informao da organizao.Anveldedefiniodoprocesso,estenosofremaisalteraes.nestafaseque se decide quais os processos que iro ser implementados em software e quais so puramente manuais. Tambm devem ser apresentados processos de negcio alternativos que igualmente possamserconcretizadosnosistemadeinformaonoimediato. Na fase de Implementao em Software acontece a obteno do cdigofonte do
respectivo processo. Nesta fase apenas so tratados os processos que necessitam suporte em software, conforme decidido na fase anterior. A obteno do cdigo pode ser feita mapeando directamente a partir do modelo Runnable. A implementao do processo feita a partir de um determinado modelo ou utilizando j cdigo desenvolvido anteriormente e posteriormentecustomizadodeformaapossuirascaractersticasdesejadas.
ModelosdeRefernciadeProcessos
O conceito de Process Reference Models (modelos de referncia de processos) um
conceito com o objectivo de fornecer boasprticas que possam ser utilizadas entre organizaes. Este conceito surge com o objectivo de as organizaes partilharem boasprticas entre si. Estes modelos podem servir como base para as organizaes conceberem os seus prprios processos. Os process reference models tambm podem ser levados em conta num processo de redefinio dos processos de negcio de uma empresa. Alis, os process reference models integram conceitos de Business Process Reengineering, benchmarking e anlise de boasprticas [SCC 2008]. Eles devem permitir que se derive o estado futuro dos processos (tobe) a partir do seu estado presente (asis), definir metas internas a atingir tendo em conta resultados operacionais de organizaes similares e
20
seusconcorrentes.
caracterizar praticas de gesto e solues que resultem em performances melhores que os
Um bem conhecido process reference model o SupplyChain Operations Reference
model (SCOR) [SCC 2008] e um modelo de referncia para empresas de produo. O modelo sugere que estas organizaes devem operar baseadas em cinco processos de negcio: Planear(Plan),Procurar(Source),Produzir(Make),Entregar(Deliver)eRetorno(Return). O DesignChain Operations Reference model (DCOR) [SCC 2006] um modelo de
referncia para os processos de desenho dos produtos. Este modelo sugere cinco processos: Planear (Plan), Desenho (Design), Investigar (Research), Integrar (Integrate) e Melhorar (Amend). OInformationTechnologyInfrastructureLibrary(ITIL)[ifSMF2007]possuiumconjunto
de boas prticas para empresas de Tecnologias de Informao. Focase em cinco estados para o servio prestado pela organizao: Estratgia (Service Strategy), Desenho (Service Design), Transio (Service Transition), Operao (Service Operation) e Melhoria Continua (Continual ServiceImprovement)doServio. O Enhanced Telecommunications Operations Map (eTOM) [TMForum] muito
semelhante ao ITIL, sendo mais aplicvel no ramo das telecomunicaes. Fornece um framework que descreve como a empresa deve organizar os seus departamentos e quais os processos executados por eles. Divide a empresa em trs grandes grupos de processos: Gesto Empresarial (Enterprise Management), Operaes (Operations) e Estratgia, InfraestruturaseProduto(Strategy,Infrastructure&Product). O grupo Bosch tambm tem definido para a sua subdiviso Car Multimedia um grupo
de processos transversais s diversas empresas espalhadas por diversos pases, o UBK (UnternehmensbereichKraftfahrzeugausrstungDivisodeTecnologiaAutomvel).Descreve um grupo de processos de referncia que podem depois ser redefinidos tendo em conta aspectosespecficos,comoporexemplodaprpriaorganizaooudopasondelabora.
IntegraodeAplicaesAtravsdeEnterpriseServiceBus(ESB)
O conceito de integrao de aplicaes empresariais (Enterprise Application
Integration EAI) [Lee, Siau et al. 2003] surge a partir da necessidade de integrao de sistemas com menores custos e menor programao. EAI engloba planos, mtodos e ferramentas com o objectivo de modernizar, consolidar e coordenar todas as funcionalidades computacionais de uma empresa. Por norma, uma empresa possui aplicaes de legado e bases de dados, e pretende continuar a utilizlas enquanto adiciona ou executa migraes
21
para um conjunto de novas aplicaes. Um projecto de EAI pode envolver uma mudana total na perspectiva do negcio da empresa e das duas aplicaes, determinar como as aplicaes existentes encaixam nessa nova perspectiva e delinear a uma forma de reutilizar eficientementeoquejexisteenquantonovasaplicaesenovosdadossoadicionados. Anteriormente,aintegraodediferentessistemasrequeriareescreveroscdigosdos sistemas de origem e de destino, o que representava grandes gastos de tempo e de dinheiro. O EAI utiliza um middleware que serve como uma ponte entre diferentes aplicaes na integrao de sistemas. Todas as aplicaes podem comunicar livremente com outras atravs deumacamadadeinterfacecomumemvezdeatravsdeintegraopontoaponto,peloque nonecessrioumaprogramaoextensa. Um tipo de tecnologia middleware de EAI o Enterprise Service Bus (ESB). A utilizao
dehubsebrokersnocasodosEAIdlugarutilizaodebarramentosnocasodosESB(Figura 5). No primeiro caso a arquitectura centralizada pois o hub ou o broker processa todas as trocas de mensagens. No segundo caso a arquitectura distribuda dado que o ESB permite a implementao de vrias funes fisicamente separadas. Na generalidade os produtos EAI so baseados em produtos proprietrios (e.g. WebSphere Message Broker usa WebSphere MQ), enquanto que os ESB geralmente so baseados open standards, como Java Message Service (JMS)[Hapner,Burridgeetal.2002],XMLouWebServices. Primeiramente deve ser considerado pela organizao se realmente necessrio para
o seu negcio a integrao das suas aplicaes. Se no existe essa necessidade, ento implementar uma soluo ESB tornase desnecessria. Mas a realidade que em muitas organizaesexistemesmoessanecessidade,poisassoluestecnolgicasdevemsercapazes defacilitaraquenovosprodutospossamserlanadosnomercadoemmenortempo.Tambm a utilizao de diferentes protocolos de comunicao, como JMS, SOAP, entre outros, dificulta a implementao da integrao das aplicaes, o que sugere a utilizao de um ESB. Um produto ESB tambm permite a reduo dos custos, dado que um ESB funciona como uma soluocomumparatodaaintegrao,facilitandoagestoeamanuteno. Uma das principais funcionalidades de um ESB a transparncia da localizao, pois fornece uma plataforma central que permite a comunicao com qualquer aplicao sem que tenha que as mensagens enviadas s mensagens recebidas. Tal como j foi referido anteriormente, um ESB permite integrar aplicaes que utilizem diferentes protocolos, como JMS e SOAP. O ESB tem a capacidade de transformar as mensagens que estejam num determinado formato para um formato open standard, por exemplo o XPath. O ESB possui tambm funcionalidades de encaminhar mensagens, segurana e monitorizao [RademakerseDirksen2008].
22
Figura5.ExemplodeIntegraoUtilizandoumESB[RademakerseDirksen2008]
ApacheServiceMixESB
O ServiceMix uma soluo ESB aceite e utilizada por entidades respeitveis no
mercado de desenvolvimento de software, mas tambm open source e baseado em open standards, o que traz benefcios na sua implementao, como baixos custos mas tambm assegura qualidade. O seu funcionamento tem como fundo o Java Business Integration (JBI) [TenHove e Walker 2005]. O JBI define uma arquitectura que permite integrao de sistemas a partir de componentes que so adicionados e operam uns com os outros atravs do mtodo detrocademensagensmediadas.Estemtododetrocademensagensmediadasfoiadoptado a partir da especificao do WSDL 2.0 de Message Exchange Patterns (MEPs) [TenHove e Walker 2005]. Os MEPs definem um conjunto de tipos de troca de mensagens, podendo estas serem de apenas um sentido (InOnly), um sentido com confiana (Robust InOnly), pedidoresposta (InOut) e de resposta opcional (In OptionalOut). O ServiceMix define dois tipos de componentes JBI: Service Engines (SE) e Binding Components (BC), tal comorepresentadonaFigura6.UmSE fornecelgicadenegcioedeprocessamento,i.e., o componente que processa um tipo de conjunto de dados de modo a executar um servio Um BC fornece comunicao para o exterior, funcionando como uma ponte entre a entrada e sadadedadosdo(ouparao)ESBparao(ouparao)exterior.
23
Figura6.FrameworkdoApacheServiceMix[ServiceMix]
O Apache ServiceMix possui integrao com uma srie de outros projectos Apache. O Apache ActiveMQ a base de troca de mensagens. E h tambm a integrao com Apache CXF, Apache ODE, Apache Camel e Apache Geronimo. Uma grande srie de componentes JBI foidesenvolvidaparaoServiceMixquefornecemumconjuntodefuncionalidadesimportantes j referidas anteriormente, como componentes JBI para suporte a protocolos como JMS e SOAP, e tambm componentes para implementar Enterprise Integration Patterns [HohpeeWoolf2004]. Na Figura 7 est representado o funcionamento do ServiceMix no que toca troca de
mensagens, dando uso s caractersticas JBI presentes neste ESB. Antes de mais, de referir que os SEs e os BCs podem ter o papel de consumidores de servios (service consumers), fornecedores de servios (service providers) ou ambos. Estes papis referemse ao tipo de tratamento a que o servio sujeito, sendo que o fornecedor do servio o componente que envia uma mensagem de pedido de execuo de um servio, e o consumidor do servio o que executar o pedido e envia uma mensagem de resposta. A troca de mensagens entre o fornecedor e o consumidor tem que obedecer a normas prprias, que so baseadas em WSDL e XML. A mensagem deve estar num formato normalizado antes de entrar no barramento, sendo que volta ao seu formato de origem quando so enviadas para o exterior pelos BCs. As mensagens so normalizadas de modo a serem constitudas por trs partes: Payload, Message Properties e Message Attachments. Estando num formato normalizado, todos os
24
componentes so capazes de interpretar as mensagens. Entre um SE e um BC, as mensagens so enviadas para um Normalized Message Router (NMR) [TenHove e Walker 2005]. O NMR recebe e troca mensagens com os componentes JBI e reencaminha a mensagem para o componente pretendido para processamento, pelo que funcionam sempre como intermedirios na troca das mensagens, pois os componentes no comunicam directamente entre eles. Para finalizar no que toca a mensagens, falta apenas referir os Delivery Channels (DC). Os DCs so os canais que fazem a comunicao do NMR com os SEs e BCs, por onde as mensagens (de pedido ou de resposta) circulam. O funcionamento dos DCs similar ao funcionamentodeumsocket[Genender2007].
Figura7.TrocadeMensagensemAmbienteJBI[Genender2007]
Para implantar um componente no ServiceMix recorrese utilizao de um Service
Unit (SU) [Rademakers e Dirksen 2008] que ir fornecer instanciaes do componente. O SU um conjunto de ficheiros XML neste caso , cujo contedo transmitido ao componente. A cada instanciao de um SE ou de um BC ir existir um SU que ir possuir as definies do componente instanciado. ParaumSUpoderserutilizadonoESB,necessrioousodeService Assemblies (SA) [Rademakers e Dirksen 2008]. Um SA uma coleco de SUs. Os componentes JBI so incapazes de interpretar SUs sem que estes estejam contidos num SA. UmSAconstitudoporpelomenosumSU(Figura8).
25
Figura8.ComposiodoServiceAssembly[RademakerseDirksen2008]
No exemplo da Figura 8, retirado de [Rademakers e Dirksen 2008], o SA constitudo
por dois SUs, um JMS SU e um Bean SU. O SA pode conter SUs que sero implantados como instanciaes de diferentes componentes, i.e., o mesmo SA pode conter SUs que iro dar origem a instanciaes de BCs e a SEs. Assim que o SA implantado no ServiceMix, so criadas instanciaes de componentes dentro do ServiceMix (ServiceMix Container). O JMS SU implantadonoServiceMixcomoumJMSBC,enquantoqueoBeanSUimplantadocomoum BeanSE.
2.4
ModelDrivenDevelopment
Desde que a Engenharia de Software se preocupa em explicar o qu que a mquina
deve fazer, ao invs de especificar como o ir fazer, que esta tenta aumentar o nvel de abstraco da actividade que se pretende realizar. neste mbito que surge o desenvolvimento de sistemas de software baseado em modelos (Modeldriven Development MDD) [Atkinson e Khne 2003]. Esta abordagem tem como caracterstica o facto de recorrer a modelos para o desenvolvimento de sistemas de software, o que faz com que se eleve o nvel de abstraco em relao ao desenvolvimento baseado na codificao. A utilizao de modelos permite tambm que sistemas de software sejam desenvolvidos independentementedaplataformaemqueestesiroserimplementados. Ummodeloumconjuntodeelementosquedescrevemalgoqueirserdesenvolvido. Dever ser abstracto, compreensvel, preciso, previsvel e com menores custos
26
[Gasevic, Djuric et al. 2006]. Alm do aumento do nvel de abstraco, o MDD tem outra motivao que o aumento da automao das tarefas a realizar. Isto conseguido atravs da transformaodemodelosegeraoautomticadecdigo.
OMGsModeldrivenArchitecture(MDA)
Falando em ModelDriven Development (MDD), comum associlo iniciativa desenvolvida pelo Object Management Group (OMG) [OMG], o Modeldriven Architecture (MDA) [OMG 2003]. Esta iniciativa surge de modo a que seja possvel utilizar os principais standards da OMG (The Unified Modeling Language UML: linguagem de modelao standard,umainstnciadalinguagemMOF;MetaObjectFacilityMOF:linguagemdemeta modelao; XML Metadata Interchange XMI: intercmbio de metadados; Common Warehouse Metamodel CWM: linguagem de modelao para aplicaes Data warehouse; Object Constraint Language OCL: linguagem de expresses que estende o UML e o MOF neste aspecto; Query/Views/Tranformations QVT: linguagem de definio de transformaes, tambm utilizada para queries e views de modelos; e Software Process Engineering Metamodel SPEM: perfil de metamodelos e UML para descrever um processo de desenvolvimento de software concreto) [OMG] em qualquer plataforma, seja ela qual for, comoporexemploWebServices,.NET,CORBA,J2EE,entreoutras(Figura9).
Figura9.OMGModelDrivenArchitecture[OMG]
A arquitectura define trs nveis de abstraco para anlise dos sistemas. Dados os nveis de abstraco, podem ento ser definidos modelos para esse sistema. definido o
27
Computer Independent Model (CIM), que foca no ambiente e nos requisitos do sistema; o Platform Independent Model (PIM), que foca nas operaes do sistema; e o Platform Specific Model (PSM), que combina o PIM com os detalhes especficos daplataforma que o sistema ir utilizar.
OsModelosCIM,PIMePSM
OpontodepartidadoMDAodaseparaoentreasespecificaesdasoperaesdo sistema e os detalhes da forma como o sistema ir utilizar as capacidades da plataforma. Permitir assim que: seja especificado o ambiente do sistema e os seus requisitos (CIM), o sistema seja especificado independentemente da plataforma que o suporta (PIM), sejam especificadas plataformas, seja escolhida uma plataforma para o sistema e transformar as especificaes do sistema para especificaes de uma determinada plataforma (PSM). Os trs principais objectivos do MDA sero a portabilidade, interoperabilidade e reutilizao em arquitecturasseparadas[OMG2003]. No CIM so especificados o ambiente e os requisitos do sistema, sendo que os detalhes da estrutura do sistema so ocultados, ou mesmo indeterminados. Por estas razes, pode tambm ser chamado de domain model. O utilizador do CIM no conhece os modelos utilizados para perceber a funcionalidade na qual os requisitos so articulados. O CIM serve ento como uma importante ponte entre os especialistas do domnio e os seus requisitos e os especialistasemdesigneconstruo[OMG2003]. O PIM um modelo que a sua especificao no se altera de uma plataforma para
outra. Possui um grau de independncia da plataforma de forma a que o modelo possa ser executado em vrias plataformas de diferentes tipos. O modelo deve ser desenvolvido respeitando as classes das diferentes plataformas onde o modelo poder ser implementado. Uma tcnica muito comum o de implementar uma mquina virtual livre de tecnologia em vrias e diferentes plataformas. A mquina virtual ser utilizada como plataforma. O modelo dever ser desenvolvido de modo a que especifique a plataforma. Mas, como a mquina virtual foi desenvolvida para ser implementada em diferentes plataformas, o modelo no ir especificarumaplataformaespecfica,garantindoaindependnciadeplataformas. O PSM resulta do processo de transformao do PIM para que as especificaes do
PIM sejam iguais s especificaes da plataforma especfica. O processo de transformao efectuado combinando o PIM com os detalhes especficos da plataforma do sistema (Figura 10).
28
Figura10.TransformaodeumPIMparaPSM[OMG2003]
As4camadas
O MDA baseado numa arquitectura de quatro camadas de metamodelos,
complementada pelos standards MetaObject Facility (MOF), Unified Modeling Language (UML) e o XML Metadata Interchange (XMI). Os elementos pertencentes a uma camada so instanciadosporelementosdacamadaabaixo(Figura11).
Figura11.As4camadasMDAeasRelaesdeInstncia,LingusticaeOntolgica[OMG2006]
29
A camada M3 representa o nvel mais elevado de abstraco, o metametamodel, isto
, o MOF. O MOF, por si s, garante a abstraco e a definio da linguagem e o framework paraespecificar,construiregerirtecnologicamentemetamodelosindependentes. Todos os metamodelos userdefined definidos no MOF esto situados na camada M2.
UmdessesmetamodelosoUML. Os modelos do mundo real que estejam representados por conceitos pertencentes a
ummetamodelosituadonacamadaM2situamsenacamadaM1. NacamadaM0encontramseelementosdomundoreal,queseencontrammodelados
na camada M1. Os elementos podem ser coisas concretas do mundo real (como por exemplo, umainstnciadaclassePessoaouAnimal),bemcomoobjectosdelinguagensdeprogramao. Metamodelos so um modelo de especificao para uma classe de sistemas em
estudo, onde cada sistema do conjunto ele prprio um modelo vlido expresso numa qualquer linguagem de modelao [Gasevic, Djuric et al. 2006]. Os metamodelos ditam o que pode ser expresso para um modelo numa certa linguagem de modelao de modo a que o modelo seja considerado vlido. Os metamodelos so eles prprios modelos, logo tambm podem ser representados em linguagens de modelao. No caso do MDA, os metamodelos esto situados na camada metametamodeling (M3), e a linguagem de modelao dos metamodelosoMOF. O MOF um conjunto mnimo de conceitos que podem definir outra linguagem de
modelao. Fornece um framework para gesto de metadados e um conjunto de servios de metadados para possibilitar o desenvolvimento de modelos e de sistemas baseados em metadados (como ferramentas de modelao e desenvolvimento, sistemas de data warehouse, repositrios de metadados, etc.). Na verso 2.0 [OMG 2005], existem dois tipos demetametamodelos,oEssentialMOF(EMOF)eoCompleteMOF(CMOF).OEMOFfavorece a simplicidade de implementao ao invs da expressividade enquanto que o CMOF mais expressivo,masmaisdifcildeimplementar[Gasevic,Djuricetal.2006].
ModeldrivenEngineering(MDE)
AabordagemdoMDAestlongedeserumaabordagemdeengenharia.[Bzivin2004]
constata que o Modeldriven Engineering (MDE) possui uma viso mais alargada do que o MDA, porque combina a arquitectura com os processos e a anlise. A abordagem de engenharia do MDE o foco nos modelos, ao invs do foco em objectos [Bzivin 2004]. As ideiasbsicasdoMDEsosimilaresaoutrasabordagens,comoaprogramaogerada,domain specific languages (DSL) [Deursen, Klint et al. 2000], computao com integrao de modelos
30
standardsdaOMG(UML,MOF,etc).
(MIC),etc.O quesepassanoMDAqueestesprincpiosdeMDE sorealizadoscombasenos
O MDE uma abordagem mais aberta e integrada, pois permite a utilizao de vrios
conceitos de tecnologias, como linguagens de programao, ontologias, linguagens XMLbased,sistemasdegestodebasesdedados(DBMS),MDA,etc. Os conceitos de MDD descritos at agora so os conceitosbase para o
desenvolvimento de software. No entanto, o foco deste trabalho sobre uma rea que abrange um tema que vai para alm destes conceitosbase. Tal como o nome indica, estes sero a base do desenvolvimento do sistema, mas, para a demonstrao da investigao, o principal tema ainda no foi desenvolvido, que a transformao dos modelos, que se vo aplicarlinguagemdeprocessosdenegcioqueforescolhida.
2.5
TransformaodosModelos
J vimos anteriormente que para passarmos do PIM para o PSM necessrio um
processodetransformaodomodelo.SeaprincipalmotivaodoMDD/MDAodepermitir desenvolver software a um nvel de abstraco mais elevado, no deixa de ser verdade que o principal desafio imposto o de transformar o modelo que est no nvel de abstraco mais alto num modelo a um nvel de abstraco mais baixo, pois s possvel gerar o cdigo automaticamente neste nvel devido a j estar descrito para a plataforma especfica em que vaiserimplementado(PSM). Esta transformao comummente chamada de Instanciao, pois estamos a descer um nvel de abstraco (M2 para M1, por exemplo). A transformao de modelos tambm utilizada quando queremos transformar um modelo num metamodelo, subindo um nvel de abstraco (M2 para M3, por exemplo), que pode ser chamada de Promoo [BraganaeMachado2008]. Pararealizaroprocessodetransformaonecessrioseguirumaestratgiademodo
a assegurar que esta no feita de qualquer maneira. Normalmente, o processo de transformao de modelos realizado seguindo conceitos de mapeamento e transformao [Pastor e Molina 2007]. A OMG tambm sugere a utilizao da tcnica de marcao [OMG 2003], tal como representado na Figura 12. A marcao feita indicando quais os elementosnoPIMqueserotransformadosemPSM.
31
Figura12.TransformaodosModelos[OMG2003]
No mapeamento so efectuadas relaes entre os elementos do PIM e do PSM. Por exemplo, possvel criar um mapeamento que relacione uma classe do modelo a uma classe em Java [Armstrong, Ball et al. 2004]. Os mapeamentos devem ser baseados nos requisitos necessrios linguagem de programao ou ao modelo. possvel que existam relaes entre um elemento do PIM e vrios elementos do PSM, bem como um elemento do PSM pode se relacionarcomvrioselementosdoPIM. Efectuadoo mapeamento,oprocessodetransformaorealizarageraodecdigo,
tendo por base o PIM, o PSM e o mapeamento efectuado, pois j ter toda a informao necessriaparatraduziromodeloparacdigo.Paraserpossvelestepasso,precisoquecada elemento do PSM possua informao necessria que possa ser traduzida em cdigo. exactamente para assegurar que essa informao se encontra no modelo que continuam a surgirnovasabordagensparaatransformao. Para melhor compreender o processo de transformao de modelos, necessrio
primeiramente introduzir o conceito de Technological Spaces (TS) [Bzivin, Dup et al. 2003], que usado para fins de anlise e comparao. Um TS um contexto de trabalho que possui um conjunto de conceitos associados, conhecimento, ferramentas, capacidades requeridas, entre outros No contexto modeldriven, so identificados os seguintes TS: sintaxes concretas e abstractas de linguagens de programao (Syntax TS), ontologias (Ontology TS), linguagens e ferramentas XMLbased (XML TS), sistemas de gesto de bases de dados (DBMS TS) e ModeldrivenArchitecture(MDATS).EstesestorepresentadosnaFigura13.
32
Figura13.TechnologicalSpaceseRelaesEntreEles[Bzivin,Dupetal.2003]
Tambm podemos notar na Figura que nenhuma das tecnologias uma ilha, todas
estorelacionadascommaisalguma(s)TS. NaFigura14podemosverumexemplodetransformaoquepodeserentreomesmo
TS ou ento entre TS diferentes. A migrao de cdigo Java para C# pode ser efectuada sem ter de sair do TS (Syntax TS, neste caso), tal como representado na operao D, pois existem ferramentas que efectuam a transformao automtica de cdigo. Alternativamente, podemos efectuar a mesma transformao utilizando TS diferentes, como passar do cdigo Java (Syntax TS) para a correspondente modelao especfica de
UML
(MDA TS) operao R esta ser transformada em modelao especfica para C# e depois se geradoocdigocorrespondente(SyntaxTS)operaoF[Bzivin,Dupetal.2003].
Figura14.TransformaodeCdigoJavaemC#[Bzivin,Dupetal.2003]
33
4StepRuleSet(4SRS)
O 4Step Rule Set (4SRS) uma tcnica proposta para transformar requisitos dos utilizadores em modelos arquitecturais que representam os requisitos do sistema. Associa, para cada objecto encontrado durante a fase da anlise, uma determinada categoria: interface, dados e controlo. Cada uma destas categorias est relacionada a uma das trs dimenses ortogonais em que a anlise pode ser dividida (informao, comportamento e apresentao) [Machado, Fernandes et al. 2006]. O 4SRS constitudo por quatro passos: (i) criao de objectos; (ii) eliminao de objectos; (iii) empacotamento e agregao dos objectos e(iv)associaodeobjectos.Osegundopassodivididoemsetemicropassos. A transformao baseada no mapeamento de diagramas UML de casos de uso em diagramas UML de objectos. Outros esquemas podem ser usados, por exemplo diagramas UMLdesequncia,actividadesedeestado[Machado,Fernandesetal.2005].Apsaexecuo do 4SRS, obtemos a arquitectura lgica para o sistema que capta todos os seus requisitos funcionais e no funcionais. Adicionalmente, o 4SRS tambm pode ser utilizado para transformar um diagrama de objectos para que este mostre os servios que o sistema necessita para o seu funcionamento. Isto conseguido gerando um diagrama de objectos de servios que corresponde arquitectura lgica do servio a ser especificado [Fernandes,Machadoetal.2006].
Query/View/Transformations(QVT)
O MOF Query/View/Transformation (QVT) [OMG 2005] um standard da OMG para linguagens de transformaes de modelos para o MDA. O objectivo do QVT obter uma domain specific language (DSL) [Deursen, Klint et al. 2000] para realizar queries, views e transformaes em modelos. O QVT opera ao nvel dos modelos MOF (camada M3 do MDA), pelo que utilizado num nvel de abstraco maior e pretendese diminuir esse nvel de abstraco. Atravs do QVT possvel a transformao entre diferentes techological spaces (TS), MDA TS, Syntax TS, DBMS TS, etc. Para tal, j existem ferramentas especficas, como por exemplo o ATL [Bzivin, Dup et al. 2003]. Outra das caractersticas que as queries so expressesOCL,quepodemretornarvalores,elementosdemodelos,etc. O QVT tem na sua especificao uma parte declarativa e uma parte imperativa, sendo
que a parte declarativa est dividida em duas camadas (Relations e Core) que formam o framework para a execuo ao nvel da semntica da parte imperativa (Operational Mappings eBlackBox),comoseencontrarepresentadonaFigura15.
34
Figura15.RelaesentreMetamodelosQVT[OMG2005]
A QVT Relations [OMG 2005] uma linguagem que ir especificar as relaes entre os modelos MOF. A QVT Relations consegue suportar padres de correspondncia complexos de objectos, criando implicitamente classes de rastreio e instncias que iro guardar todas as ocorrnciasduranteatransformao. A QVT Core [OMG 2005] uma linguagem/modelo que especifica os padres de
correspondncia segundo um conjunto de variveis avaliando as condies dessas variveis num conjunto de modelos. Esta linguagem trata todos os elementos do modelofonte, modelofinal e modelo de rastreio por igual. to poderosa como a Relations, mas a sua semnticamaissimples,apesardesermaisdescritiva A QVT Operational Mappings [OMG 2005] permite a realizao de transformaes utilizando uma abordagem imperativa (transformao operacional), ou complementa as relaesutilizandooperaesimperativasimplementandoasrelaes(transformaohbrida). Fornece extenses OCL [OMG 2006] que permitem uma abordagem procedimental e baseada em sintaxes imperativas. A Operational serve tambm para ajudar a implementar relaes, quesejammuitocomplicadasdeexecutarapenasdeformadeclarativa.
2.6
Concluses
Foram apresentadas caractersticas de algumas das principais linguagens de
representao de processos de negcio (BPML, BPEL, XPDL, YAWL, EPC, CPN). Para desenvolverosoftwareiremosutilizaraabordagemdeMDD.OsstandardsMDAapresentados so largamente reconhecidos para a obteno de software. Neste documento foram descritas os conceitos relevantes no desenvolvimento da investigao. Para a transformao do PIM paraoPSM,seroutilizadastcnicasdemapeamento,marcaoeposteriortransformao.
35
Feita a reviso bibliogrfica necessria, todos os conceitos sero absorvidos para a realizao de casos de demonstrao de modo a validar a investigao. Este trabalho vai ser realizado utilizando como caso de demonstrao processos de negcio da empresa Bosch Car Multimedia Portugal, Lda. Visto que a empresa no utiliza uma linguagem de modelao de processosparaosdefinir,temqueseprocederescolhadamaisapropriada. O prximo passo ir ser modelar vrios processos modelados na linguagem escolhida anteriormente. Estes processos vo ser modelados de forma a corresponderem ao PIM. Os processos modelados tero um modelo de referncia como base, sendo que depois sero demonstrados exemplos de processos para suportar o caso de demonstrao. Ir ser criado um repositrio de diversos PIMs que depois podero ser implementados num Enterprise ServiceBus.
36
3. ProcessosdeNegcioemModeloPIM
Este captulo pretende mostrar a primeira parte do trabalho no que toca a utilizar modelos(MDA)naconstruode processosdenegcio.Oquese pretende demonstraruma primeira modelao dos processos considerando a utilizao de normas de boasprticas, tal como sugerido pela metodologia que apresentada, e qual o valor acrescentado para a empresa que esta abordagem fornece. No entanto, existe um conjunto de trabalho de base que ainda necessita de ser realizado. A linguagem para modelar os processos ainda no est definida, pelo que ainda necessrio se proceder a uma escolha. A linguagem no pode ser escolhida de uma maneira egosta, dado que a anlise prope a toda uma organizao a utilizaofuturadalinguagem.
3.1
Introduo
nestecaptuloquesedinicioaocasodedemonstrao.Paratal,aempresaemque
foram realizadas as demonstraes foi a Bosch Car Multimedia Portugal, Lda. A criao da Bosch Car Multimedia Portugal, Lda. esteve, desde o incio, orientada por slidos valores no mbito da Qualidade, Inovao e Desenvolvimento. As suas prticas sempre se pautaram pela Melhoria Contnua ao nvel dos processos e pelo posicionamento de vendas no ranking mundial. A Bosch Car Multimedia Portugal, Lda. a maior fbrica de produo de autordios daEuropa.LideraasvendasnoMercadoEuropeu e contribuiactivamente paraaeconomiado pas, encontrandose entre os 10 maiores exportadores nacionais. O valor das compras ascende a 33 Milhes de Euros. O impacto a nvel regional substancial, empregando actualmentecercade2000colaboradores.EntreestesencontraseumgrupodeEngenheirose Tcnicos (cujo nmero quadruplicou desde 1999) que desenvolvem novos produtos e sistemas, bem como mtodos de produo inovadores. O seu trabalho dirigido tambm ao melhoramentocontnuodeprodutosjexistentes. Este captulo documenta as bases que tiveram de ser feitas na execuo do caso de demonstrao. A primeira tarefa a ser realizada prendese com um dos objectivos propostos para este trabalho, que o de escolher uma linguagem de representao de processos de negcio mais adequada para a empresa. Visto a investigao estar inserida num ambiente organizacional, a linguagem de execuo de processos de negcio deve ser cuidadosamente escolhida, pois a escolha deve ser devidamente fundamentada para que as pessoas da organizao se sintam convencidas de que devem passar a utilizar a linguagem nos seus projectos. A estratgia organizacional passa por trs aspectos: estratgia de negcio, estratgia organizacional e estratgia de sistemas de informao [Pearlson e Saunders 2004]. Os padres de workflow definidos por [Aalst, Hofstede et al. 2003] so largamente aceites na
37
3.ProcessosdeNegcioemModeloPIM
comparao entre linguagens. Mas, no entanto, no ambiente organizacional, apenas uma das estratgias est a ser tida em conta (estratgia de sistemas de informao). Realizar uma anlise no mbito do negcio e no mbito da prpria organizao torna portanto a comparao mais completa. Neste captulo so comparadas as cinco linguagens de execuo deprocessosdenegcioapresentadasnocaptuloanteriorsegundoostrstiposdeestratgia, sendo escolhida a linguagem mais apropriada segundo os trs aspectos. Ao nvel tecnolgico, aslinguagensforamalvodecomparaoquantosuacapacidadedemodelaodeprocessos, utilizandocomobasepadresdefluxodedados.Aonveldaspessoas,foramtidasemcontaas caractersticasdecadacolaboradordaempresa.Aonveldaorganizao,foramtidasemconta factores importantes para qualquer empresa que lide com Tecnologias de Informao e tambm factores especficos da Bosch Car Multimedia Portugal, Lda. A linguagem escolhida depois apresentada, atravs de uma descrio dos conceitos necessrios para modelar e executarosprocessos. Na segunda parte do captulo apresentada uma metodologia de implementao de
processos numa arquitectura organizacional, a Business Implementation Methodology (BIM) [Duarte,Machadoetal.2009],queapresentaumapropostadetransformaodeprocessosde negcio em sistemas de software e que a metodologia seguida no desenvolvimento do trabalho. A metodologia prope um conjunto de fases para obter software com base em processosdenegcioesugerequeumapossvelformadeobterosoftwareserautilizaodo ModelDriven Development (MDD) [Atkinson e Khne 2003], atravs da transformao de modelos PIM em modelos PSM [OMG 2003]. A descrio da metodologia efectuada neste captulo pretende servir como base para o primeiro modelo de processos descrito no captulo, bem como guia para o trabalho efectuado no captulo seguinte. O modelo de processos inicial representa processos genricos e devem reflectir utilizao de normas de boasprticas, atravsdousodemodelosderefernciadeprocessos.
3.2
AsLinguagensExistentes
O trabalho de investigao no pode comear logo com modelao de processos.
Nesta seco apresentado o trabalho de base necessrio para se proceder modelao dos processos de negcio. Um estudo das linguagens de execuo de processos de negcio existentes deve ser a primeira das tarefas do trabalho. Propese que a escolha seja baseada emtrsmbitos:tecnolgico,organizacionaledenegcio. Para a comparao das linguagens apenas realizada uma anlise das caractersticas
de cada uma. No entanto, escolhida a linguagem, logicamente o conhecimento destas
38
insuficiente para representar os processos, pelo que antes de modelar os processos apresentadaaestruturadeumprocessomodeladonalinguagemescolhida.
EscolhadaLinguagem
Na seco 2.2 esto descritas as principais caractersticas sobre o funcionamento das principais linguagens de representao de processos de negcio, assim como o que as diferencia umas das outras. No sentido de escolher a linguagem mais adequada para modelar os processos de negcio na organizao, as linguagens foram objecto de uma anlise das vantagens de cada uma ao nvel da sua utilizao, do tipo de utilizadores e de aspectos inerentessuaimplementaoeaestetrabalho. Para analisaras linguagens quanto sua utilizao, o objectivo passa por verificar qual a linguagem que melhor facilita a modelao dos processos. O que se verifica que as linguagens no so iguais quanto a certos aspectos na sua modelao. Na modelao dos processos, nem todo o tipo de operaes possvel de executar. A linguagem que mais operaes permitir modelar , portanto, a linguagem que traz mais vantagens quanto sua modelao. A linguagem mais apropriada para o tipo de utilizadores da Bosch Car Multimedia Portugal, Lda. tambm tida em conta na escolha, pois estes sero os usufruidores da linguagem que for escolhida. Apesar de os utilizadores no serem todos iguais, possvel descreverperfisdosutilizadorestendoemcontaosconhecimentoseapetnciasquepossuem. A linguagem que melhor se encaixar nesses perfis tambm vantajosa na sua implementao naorganizao,poisalinguagemimagemdosutilizadores. Porfim,existemaindaoutrosaspectosinerentesslinguagensquesotidosemconta, nomeadamente aspectos referentes implementao da linguagem na organizao, pois a linguagem pode ser boa do ponto de vista funcional e agradar aos utilizadores, mas no fim decontasomaisimportanteaorganizao,enelaquesedevecentrar.
ComparaocomBasenosPadresdeWorkflow
Para se determinar a linguagem mais completa no aspecto da sua funcionalidade, recorreuse comparao das linguagens analisando vinte padres de controlo de fluxo, definidasporvanderAalst,Hofstede,KiepuszewskieBarrosem[Aalst,Hofstedeetal.2003].A abordagemdosvintepadresdeworkflowtrazvantagensnamedidaemqueanalisaexemplos de controlo de fluxo que podem ocorrer durante um processo e possvel verificar se possvel na modelao do processo numa determinada linguagem. Esta abordagem citada
39
em vrios trabalhos tanto dos mesmos autores desta, como [Aalst, Dumas et al. 2002], [Aalst e Hofstede 2002] e [Aalst 2003], bem como em trabalhos de outros autores como [Mendling, Moser et al. 2006], [Mulyar 2005] e [Takecian 2008]. As definies referentes aos vinte padres encontramse em anexo (Anexo B) devido sua extensibilidade e dado que o importante a quantidade de padres suportados pela linguagem e no os padres em si, peloqueasdefiniessoconsideradasleituraadicional. A Tabela 1 foi preenchida com base em estudos j referidos anteriormente, nomeadamente [Aalst, Dumas et al. 2002], [Aalst e Hofstede 2002] e [Aalst 2003] e [Mendling, Moser et al. 2006]. Se a linguagem suporta directamente o padro est designado comum+,sesuportaindirectamenteestdesignadocomum+/,esenosuportaopadro estdesignadocomum.
Tabela1.ComparaodaslinguagensbaseadanospadresWorkflow
N 1 2 3 4 5 6 7 8 9 Sequncia Divisoparalela Sincronizao Escolhaexclusiva Junosimples Escolhamltipla Junosincronizada Junomltipla Discriminador PadresdeControlodeFluxo BPML + + + + + +/ + + + + + + BPEL + + + + + + + + + + + +/ + + XPDL + + + + + + + + + + + YAWL + + + + + + + + + + + + + + + + + + + CPN + + + + + + + + + + + + + +/
10 Cicloarbitrrio 11 Terminaoimplcita 12 MltiplaInstnciasemsincronizao 13 MltiplaInstnciacomconhecimentoprvioprojecto 14 MltiplaInstnciacomconhecimentoprvioexecuo 15 MltiplaInstnciasemconhecimentoprvioexecuo 16 EscolhaemDiferido 17 Roteamentoparaleloentrelaado 18 Marco 19 Actividadecancelvel 20 Casocancelvel
Ao visualizar a tabela, existem logo alguns dos dados que saltam vista. O YAWL , de longe, a linguagem que maior nmero de padres suporta directamente, pelo que apenas no suporta directamente o padro 11. As CPN e o BPEL no suportam ambos seis padres. TambmsaltavistaqueBPELeBPMLsomuitosemelhantes,comoBPMLasuportarmenor
40
padres.
nmero de padres. O XPDL surge como a linguagem que menos suporta, apenas onze
possvel ento dizer que o YAWL a linguagem mais adequada do ponto de vista funcional. No entanto, este foi apenas o primeiro de trs pontos de comparao das linguagens.
Comparaocombasenosconhecimentosdosutilizadores
Este ponto de comparao justificado com o facto de os utilizadores, neste caso os colaboradores do Departamento de Informtica da Bosch Car Multimedia Portugal, Lda. responsveis por desenvolvimento de sistemas de informao, serem as pessoas que iro utilizar e modelar os processos de negcio, sendo ento necessrio efectuar um estudo para concluir qual a linguagem de representao de processos que melhor se identifica com as caractersticasecompetnciasdestes. A forma encontrada para se chegar a tal concluso foi a de os utilizadores responderem a um questionrio (Anexo C). O questionrio foi estruturado de forma a que os inquiridos respondessem a questes sobre caractersticas presentes nas linguagens em comparao,comoconhecimentosacercadeWebServices,linguagemXML,SOA,entreoutros, e tambm conhecimentos de BPM de modo a analisar a sua maturidade em compreender processos de negcio e como estes devem ser modelados. A anlise ao questionrio permite tambm relacionar uma das linguagens de entre as estudadas com o nvel de maturidade atribudoaosinquiridos. Ao longo do questionrio, algumas perguntas esto directamente relacionadas com uma linguagem de processos em particular. Existem tambm perguntas cujas respostas direccionam indirectamente para uma ou mais linguagens. As relaes entre as respostas e as linguagensestorepresentadasna Tabela 2. atravs das respostas dadas que se vai determinar a linguagem mais adequada. A tabela de respostas recebidas dos nove questionrios est reproduzida no anexo D. Todas as respostas foram recolhidas e efectuouse o clculo da pontuao que cada um dos nove inquiridos deu a cada linguagem, apresentada na Tabela 3. A pontuao obtida por cada linguagem dada por um valor relativo que tem em conta o nmero de respostas dadas pelos inquiridos, mas tambm a quantidade de respostas possveis para cada linguagem. Isto justificase com o facto de, em algumas perguntas com respostas que se associam
41
indirectamente com a linguagem, a quantidade destas no ser equilibrada para todas as linguagens,peloqueesteclculomaisjustodoqueumasimplessomadapontuao.
Tabela2.Respostasqueapontamparalinguagens
Pergunta 7Sim 8b,c,d,e 9Sim 10c,d 11UMLb,c,d,e 11BPMNb,c,d,e 11EPCb,c,d,e 12a,c,d,e,f,h,i,o,p,q 12a,b,d,g,l,r,s 12d,l,m,n,t 12k,u 12j 13Sim 14c,d,e 15c,d,e 16a,b,c,d,e,f,g,j,l,m,n,o,p BPML x x x x x x x BPEL x x x x x x x x x x x XPDL x x x x x x YAWL x x x x x x x x x CPN x x x x x x x
Tabela3.Pontuaodosinquiridosacadalinguagem
Linguagem BPML BPEL XPDL YAWL CPN #1 0.76 0.76 0.76 0.65 0.84 #2 0.70 0.80 0.79 0.94 0.99 #3 0.64 0.74 0.79 0.83 0.78 #4 0.59 0.60 0.79 0.57 0.59 #5 0.62 0.72 0.79 0.70 0.76 #6 0.67 0.88 0.87 0.90 0.95 #7 0.15 0.38 0.35 0.34 0.30 #8 0.34 0.53 0.59 0.49 0.48 #9 0.78 0.79 0.92 0.69 0.75 Total 5.26 6.20 6.65 6.11 6.43
Comparaosegundoconceitosrelevantesparaaorganizao
Finalmente, foi realizado um levantamento de outros aspectos de comparao das linguagens relacionados com determinadas caractersticas relevantes para a implementao e utilizao na organizao e posterior anlise e discusso com o objectivo de melhor fundamentar a escolha. Algumas das caractersticas definidas foram baseadas em caractersticas que so definidas para comparao de ferramentas das linguagens [Helki, Seppl et al. 2006]. As restantes so da responsabilidade do autor, baseado em conceitos gerais de interesses das organizaes de tecnologias (por exemplo, a maturidade), em conceitos relevantes para o problema em questo (a traduo e transformao das linguagens), bem como at sugestes de pessoas na empresa (por exemplo, o custo da implementao) ou conhecimentos do autor acerca do funcionamento da empresa (por exemplo,aintegraodalinguagemnoSAP).
42
A anlise quanto maturidade da linguagem tem em conta o tempo em que a linguagem surge, as diferentes verses e actualizaes e a data da ltima verso. O BPML tem como nica verso a 1.0, que surge no ano de 2002 [Arkin 2002]. A primeira verso do BPEL surge em 2005 [Curbera, Goland et al. 2005] e a ltima verso, a 2.0, em 2007 [Oasis 2007]. BPML e BPEL possuem, portanto, um nvel grande de maturidade. O XPDL e o YAWL surgem em2002eassuasversesmaisrecentes,a2.1nocasodoXPDL[WfMC2008],ea2.0BETAno caso do YAWL [YAWL System], so publicadas em 2008, pelo que possuem um nvel de maturidademenordoqueaslinguagensanteriores.AsCPNsurgemem1981[Jensen1992]ea ferramentaprincipal,oCPNTools[CPNGroup],surgeem2001eaversomaisrecentedatade 2006.Esta,semdvida,alinguagemmaismadura. A anlise quanto usabilidade refere a facilidade na modelao das linguagens. Neste
caso, as linguagens baseadas em fluxogramas, BPML, BPEL e XPDL, possuem maior grau de usabilidade em relao s linguagens baseadas em grafos, YAWL e CPN, pois um fluxograma permitemelhorcompreensonaleituraeescritadosprocessos. No que respeita anlise da quantidade de ferramentas existentes, obviamente que no possvel poder dizer com certezas absolutas aquantidade de ferramentas que suportam cadalinguagem,peloquefoirealizadaumaanlisequantidadesuficienteparapoderdizerse uma linguagem suportada por mais ou menos ferramentas do que outra. O mesmo se passa naanlisedaquantidadedetutoriaisonlinedecadalinguagem. Para se comparar a capacidade de traduo da linguagem, foi tido em conta se a linguagem pode ou no ser traduzida em qualquer uma das outras linguagens, i.e., migrao delinguagemutilizandoomesmoTechnologicalSpace(seco2.5,exemplodaFigura14). O esforo de aprendizagem referese ao esforo necessrio (horas necessrias, por exemplo) para domnio da linguagem. Novamente, mais fcil e requerem menos esforos as linguagensbaseadasemfluxogramas,BPML,BPELeXPDL. A capacidade da linguagem se transformar a caracterstica mais relevante para este trabalho. Referese capacidade de transformar a linguagem em cdigo orientado a objectos, pois esse o paradigma utilizado no desenvolvimento de software. Para esta anlise, serviu como vlida a utilizao de diferentes Technological Spaces na transformao em cdigo. Este ponto o mais importante no mbito deste trabalho, dado que o temachave para a concretizao de um dos objectivos propostos. O BPEL a linguagem cujas caractersticas melhor permite a transformao para cdigo orientado a objectos, pois possvel relacionar os construtores BPEL com os artefactos Java [Kloppmann, Knig et al. 2004], e j existem efectivamenteferramentasparaatransformao(BPEL2JAVA)[BPEL2Java].tambmpossvel a transformao do BPEL em Diagramas de Actividade UML 2 (UMLAD)
43
[Reiter, Kapsammer et al. 2006], que podem posteriormente ser transformados em cdigo usando o MOF QVT [OMG 2005]. O XPDL tambm tem relaes com o UML2AD [GuelfieMammar2006],mascomospossvelatransformaodeUML2ADemXPDLeno o contrrio, possvel estabelecer relaes entre eles, mas mais limitada, pois analisando os padresdeworkflowsuportadosentreUMLeXPDL[Aalst2003]concluisequeexistemmuitos padres que um suporta e o outro no. Quanto s linguagens BPML, YAWL e CPN, possvel transformlas em UML atravs de ferramentas como o ATL [Bzivin, Dup et al. 2003], mas esteumprocessoaindamaislimitadodoquenocasodoXPDL. Como caracterstica relevante para uma organizao, impossvel no realizar uma anlise quanto a custos. Felizmente, a maior parte das ferramentas que suportam as linguagens so de livre acesso, logo no acarretam custos para a empresa. Existem ferramentas livres para todas as linguagens, mas no entanto a comparao foi feita com base nas ferramentas mais cotadas. Neste contexto, as principais ferramentas para BPML, BPEL e YAWL so todas livres, o CPN Tools (ferramenta de referncia para as CPNs) requer uma licenaantesdeapodemosutilizar,eoEnhydraJaWe(paraoXPDL)umaferramentapaga. O conceito de portabilidade definido como capacidade de pegar num artefacto criado num ambiente de um vendedor e utilizlo num ambiente de outro vendedor [Oasis 2007]. Assim, o YAWL surge em vantagem dado que existe apenas um vendedor, logo a portabilidade sempre assegurada. As CPNs, tal como o BPEL, tambm tm como caracterstica funcionarem de igual forma independentemente da ferramenta onde correm. No caso do BPML, permite exportao de modelos de ficheiros XML vlidos em qualquer ferramenta [Silver 2009]. O XPDL possui 3 Mode Portability Conformance Classes, o Simple, o StandardeoComplete[Silver2009]. O conceito de interoperabilidade definido como capacidade de mltiplos componentes interagirem utilizando mensagens e protocolos bemdefinidos. Inclui combinao de componentes de diferentes vendedores a executarem de forma semelhante [Oasis2007].Nestecaso,oBPML,oBPELeoYAWLasseguramtotalinteroperabilidadeatravs de troca de mensagens entre servios em WSDL. O XPDL assegura interoperabilidade atravs da troca de mensagens XML, mas no totalmente automtico, necessita de configurao. O mesmo se passa nas CPNs, mas neste caso ainda mais limitado, pois a troca de mensagens pode ter de se feita em linguagens diferentes, o que requer uma configurao das invocaes aindamaisdifcil. A segurana outro aspecto que a organizao no pode descurar, pelo que a linguagem escolhida deve garantir uma troca de dados segura e sem perda de informao. O BPMLeoBPELpossuem nassuasespecificaesoWSSecurity, queo protocoloquegarante
44
a segurana na troca de mensagens entre Web Services. O YAWL por sua vez garante a seguranadosdadosatravsdoYAWLManager. A eficincia traduz os aspectos do tempo de execuo de um processo e dos recursos utilizados. O BPEL utiliza o protocolo WSCoordination para orquestrar os Web Services, o YAWL utiliza o YAWL Manager, enquanto que as CPNs, devido s caractersticas de uma Rede de Petri, asseguram a eficincia atravs de frmulas matemticas. O BPML necessita de se relacionar com o WSCI (Web Service Choreography Interface) [Aalst, Dumas et al. 2002] para garantiraeficincia. No que consiste gesto dos dados, importante que os dados, nomeadamente variveis ou os seus valores, estejam sempre perfeitamente identificados quanto sua localizao. Neste aspecto, o XPDL e as CPNs possuem vantagem dado que o XPDL apenas trata dados em XML e nas CPNs os valores dos dados esto sempre guardados nos tokens, enquantoquenoBPML,BPELeYAWL,osdadossotratadosemXMLeWSDL. OaspectodaintegraodalinguagemnofuncionamentodoSAPrelevante,dadoque o ERP utilizado para a organizao gerir os seus processos. As linguagens BPML e BPEL podem ser integradas directamente, enquanto que o YAWL deve primeiramente ser traduzido emyEPC(YAWLEventdrivenProcessChain). NaTabela4estrepresentadaaavaliaodaslinguagenssegundoestescritrios,onde foiutilizadaumanotao de1a5,sendoque1e2 correspondemaumaavaliaonegativa,3 razovel mas j corresponde a avaliao positiva e 4 e 5 avaliao positiva e muito positiva, respectivamente. Somandoaspontuaesobtidaspelascincolinguagens,possvelverificarqueoBPEL
aquemaiornmerode pontosobteve,numtotal de66pontos.OBPELentoalinguagem que melhor serve os interesses do ponto de vista organizativos. Quanto s restantes linguagens,oBPMLobteve59pontos,seguidodasCPNcom55,oYAWLcom53efinalmenteo XPDL,comapenas47pontos.
Tabela4.Comparaonombitodeumaorganizao
N 1 2 3 4 5 6 7 8 9 10 11 Caractersticas Maturidade Usabilidade Ferramentasexistentes Tutoriaisonline Traduzvel EsforoAprendizagem TransformvelemcdigoOO CustosdeImplementao Portabilidade Interoperabilidade Segurana BPML 4 4 4 5 5 4 2 5 3 5 5 BPEL 4 4 5 5 5 4 5 5 5 5 5 XPDL 4 4 3 3 3 4 3 3 3 4 3 YAWL 3 3 2 3 4 3 2 5 5 5 5 CPN 5 3 5 5 4 3 2 4 5 3 3
45
12 13 14 Eficincia GestodosDados IntegraonoERPSAP
4 4 5 5 4 5 2 5 3 5 4 4 5 5 3
Resultadodasanlises
Finalizada ento a anlise s linguagens segundo prismas de funcionalidade, utilizadores e de organizao, tempo ento de realizar um balano. No possvel dizer se alguma das trs anlises efectuadas mais importante na escolha de uma linguagem do que outra, pelo que as trs so consideradas com igual importncia. Na Tabela 5 esto os resultadosobtidospelaslinguagensnastrsanlises,tendoasanlisestodasomesmopesona obtenodoresultadofinal.
Tabela5.Resultadosfinaisdaslinguagens
Anlise Funcionalidade Utilizadores Organizao Final BPML 4 5 2 4 BPEL 2 3 1 1 XPDL 5 1 5 4 YAWL 1 4 4 3 CPN 2 2 3 2
Como se pode ver na tabela, no h grandes dvidas de que o BPEL obteve os
melhores resultados, sendo ento considerada a linguagem de representao de processos de negcio mais adequada para utilizao na Bosch Car Multimedia Portugal, Lda. e na realizao deste trabalho. O BPEL obteve os melhores resultados em relao s restantes linguagens nas anlises, custa de ter obtido a melhor pontuao segundo conceitos relevantes para a organizao,mastambmporterobtidoasegundaeterceiramelhorpontuaonasrestantes comparaes,respectivamente. O facto de ordenar as linguagens por classificao ao invs de apenas mencionar a
linguagem com melhor resultado prendese com a possibilidade de procurar alternativas primeira opo, dado que a comparao efectuada com o objectivo nico de indicar uma linguagem com base num estudo cientfico, no sendo a empresa obrigada a aceitar ou implementaralinguagemescolhida.
BusinessProcessExecutionLanguage(BPEL)
A arquitectura e as principais caractersticas da linguagem BPEL j foram descritas na
seco 2.2. O modo como o BPEL executa os processos modelados foi o ponto de anlise na escolhadaslinguagenspropostasnestedocumento.Agoraquealinguagemjestescolhida,
46
necessrio no entanto efectuar uma descrio do BPEL ao nvel da estrutura e modelao de umprocessoBPELparamelhorsecompreenderaconstruodosprocessos. Um processo BPEL constitudo por uma srie de actividades realizadas
sequencialmente, representando o fluxo dos dados. Como actividades bsicas em BPEL temos invoke, receive, reply, assign, entre outros (Tabela 6). tambm constitudo por estruturas algortmicas no caso de processos um pouco mais complexos, tais como if, while, repeatUntil, flow, entre outros (Tabela 7). As Variables e os PartnerLinks so os elementos tratados nas actividades e nas estruturas algortmicas. Um PartnerLink faz a ligao com o interface de um servio que interage com o processo, que se encontra num ficheiro WSDL (Web Services Description Language) separado. As Variables representam as mensagens que so trocadas durante o processo. Para a definio das estruturas algortmicas que expressam condies e Variables atravs de expresses, podem ser utilizadas expresses XPath 1.0 que esto disponveisem[W3C1999].
Tabela6.ActividadesBsicasBPEL
AtividadeBsica invoke receive reply wait assign throw compensatee compensateScope exit empty rethrow validate extensionActivity
Descrio FazumachamadaaalgumWebServicedisponibilizado Esperaporumamensagemdeumagenteexterno Efectuaarespostareferenteaumarequisiopreviamenteaceite Aguardaporumdeterminadotempo Copiadadosentrevariveisouinsereossegundoexpresses Sinalizaumafalhainternanaexecuo Iniciaacompensaodeactividadesquejforamconcludascom sucesso Finalizaimediatamenteainstnciadoprocesso Nofaznenhumaaco.Podeserusadacomopontode sincronizao Lananovamentefalhasqueforamsinalizadas Asseguraqueosvaloresarmazenadosnasvariveissejamvlidos Definenovasactividades
47
Tabela7.EstruturasAlgortmicasBPEL
Estruturasalgortmicas sequence flow pick
Descrio Contemumaoumaisactividadesexecutadassequencialmente Contemumconjuntodeactividadesexecutadasconcorrentemente Contemumconjuntodeparesdeactividades,executandoa actividadeassociadaaumeventoocorrido Repeteaexecuodeumaactividadeenquantoumacondiofor verdadeira Repeteaexecuodeumaactividadeatqueumacondiode torneverdadeira Agrupaactividadesemblocos Especificaumcomportamentocondicionaldentrodoprocesso Repeteaexecuodeumaactividadeporumdeclaradonmerode vezes Determinaumprazodeesperaparaaexecuodeumaactividade
while
repeatUntil scope if forEach wait
Um ficheiro BPEL constitudo por quatro partes. A primeira parte referese aos
namespacesdosficheirosXMLnecessriosnaexecuodoprocesso.
[1] [2] [3] [4] [5] <process name="main" targetNamespace= ... xmlns:bpel="http://docs.oasisopen.org/wsbpel/2.0/process/executab le" xmlns:tns= ... >
Figura16.ExemplodeCdigoBPELReferenteaNamespaces
AsegundapartereferesedefiniodointerfacedoPartnerLinkdoprocesso,bem
comoalocalizaodorespectivoficheiroWSDL,edequalqueroutroutilizadonoprocesso.
[1] [2] [3] [4] [5] [6] [7] <import location="main.wsdl" namespace= importType="http://schemas.xmlsoap.org/wsdl/" /> <partnerLinks> <partnerLink name="client" partnerLinkType="tns:main" myRole="mainProvider"/> </partnerLinks> Figura17.ExemplodeCdigoBPELReferenteaosPartnerlinks
48
trocadasduranteoprocesso.
[1] [2] [3] [4] [5] <variables> <variable name= messageType= /> </variables>
A terceira parte referese definio das variveis utilizadas, i.e., o tipo de mensagens
... ...
Figura18.ExemplodeCdigoBPELReferentesVariveis
A quarta e ltima parte do ficheiro BPEL referese sequncia de actividades do
processo.
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] <sequence name="main"> <receive name= ... partnerLink="client" portType= ... operation= ... variable="input" createInstance="yes"/> <assign name= ... > <copy> <from ... /> <to ... /> </copy> </assign> <reply name= ... partnerLink="client" portType= ... operation= ... variable="output"/> </sequence> </process> Figura19.ExemplodeCdigoBPELReferenteSequnciadeActividades
A cada processo BPEL existe sempre um ficheiro WSDL correspondente que contm as
definies do interface do processo. Um ficheiro WSDL constitudo por cinco partes. A primeirapartecontmosnamespacesutilizados.
[1] [2] [3] [4] [5] [6] [7] <?xml version="1.0"?> <definitions name= ... targetNamespace= ... xmlns:tns= ... xmlns:plnk="http://docs.oasisopen.org/wsbpel/2.0/plnktype" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> Figura20.ExemplodeCdigoWSDLReferenteaosNamespaces
49
mensagenseXMLSchema(XSD)[W3C].
[1] [2] [3] [4] [5] [6] [7] [8] [9]
A segunda parte do ficheiro WSDL contm a definio do tipo de elementos das
<types> <schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace= ... xmlns="http://www.w3.org/2001/XMLSchema"> <element name= </element> </schema> </types> Figura21.ExemplodeCdigoWSDLReferenteaosTiposdeElementos ...
A terceira parte referese definio do tipo de mensagens e das respectivas partes
existentesnasmensagensdefinidasanteriormentenoschema.
[1] [2] [3] <message name= <part name= ... </message> ... > element=
...
/>
Figura22.ExemplodeCdigoWSDLReferenteaosTiposdeMensagens
A quarta parte referese definio das portas utilizadas e especifica qual(ais) a(s)
operao(es)queocorremnarespectivaportaequalotipodemensageminputeoutput.
[1] [2] [3] [4] [5] [6] <portType name= <operation name= <input message= <output message= </operation> </portType> ... ... ... ... > > /> />
Figura23.ExemplodeCdigoWSDLReferentesPortaseOperaes
A quinta e ltima parte contm a definio do papel (role) do PartnerLink referente a
este interface, bem como as definies Simple Object Access Protocol (SOAP) [W3C 2007] e as respectivasligaes.
50
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]
<plnk:partnerLinkType name= ... <plnk:role name= ... portType= </plnk:partnerLinkType>
> ...
/>
<binding name= ... type= ... > <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name= ... > <soap:operation soapAction= ... /> <input> ... </input> <output> ... </output> </operation> </binding> <service name= ... > <port name= ... binding= ... > <soap:address location= ... /> </port> </service> </definitions> Figura24.ExemplodeCdigoWSDLReferentesFefiniesdoPartnerlink
ExemplodeumprocessoBPEL
Figura25.ExemplodeumProcessoBPEL
51
3.3
ModelaodeProcessosdeNegcioemPIM
A metodologia em que este trabalho baseado prope a utilizao de normas de
boasprticas na definio dos processos de negcio que funcionam numa organizao. A metodologiadetalhadadeseguidadeformaaapresentarosconceitospresenteseparauma melhor compreenso do trabalho que realizado. Tambm a utilizao da abordagem a modelos justificada como base para a transformao dos processos em software, apresentando para j a modelao de processos de negcio em PIM. A modelao inicial dos processos utiliza os modelos de referncia de processos, que garante a utilizao de boasprticasnaempresa.
RelaoentreaMetodologiaBIMeUtilizaodeMDA
ABusinessImplementationMethodology(BIM)[Duarte,Machadoetal.2009]descreve
aformacomosoftwaredeveserimplementadodemodoasuportarprocessosdenegciosem empresas. Esta metodologia permite a implementao de software utilizando um conjunto de actividades faseadas, tendo por base o estado em que os processos de negcio esto definidos. Os estados para definio dos processos so Generic obtidos atravs de uma definio dos processos ao nvel de abstraco mais elevado , Instantiated instanciao dos processos Generic, no qual j se prope uma customizao do processo de modo a este melhor se aplicar na empresa no mbito do negcio , Runnable processos que j se integram na arquitectura de Sistemas de Informao organizacional e o Software Implementedprocessojtotalmente suportadonaempresaporumsistemadesoftware.Tal como j foi referido, as fases da BIM so baseadas nos estados dos processos, i.e., a cada fase da BIM corresponde a um estado dos processos. A BIM constituda pelas fases de Selection, Definition, Concretisation e Implementation. S possvel passar de uma fase para a fase seguinte quando o estado dos processos tambm se altera para o estado correspondente fase seguinte. A cada estado da arquitectura dos processos (Process Framework PF) correspondeentocadaumadasfasesdametodologiaseguida. Analisando as caractersticas desta metodologia, possvel estabelecer algumas
relaes entre a BIM e o Modeldriven Development/Architecture (MDD/MDA). As caractersticas de um processo de negcio que estejam no estado Generic, Instantiated e RunnablesosemelhantesscaractersticasdeummodeloPlatformIndependentModel(PIM) do MDA, dado que nestes estados a representao dos processos no inclui ainda qualquer dependncia em tecnologia (plataforma). Durante as trs primeiras fases (Selection, Definition
52
e Concretisation) o processo no funciona com suporte de qualquer software, pois at ao fim da terceira fase ainda nem se tomou a deciso se o processo vai funcionar em software ou no. Alis, no fim da fase da Concretizao, sugerido que exista um processo que seja posteriormente implementado conforme a fase seguinte da metodologia, mas que sejam propostas alternativas, entre elas pelo menos uma em que o processo no necessite de implementao de software, i.e., que o seu modelo no estado final seja o obtido no estado Runnable. O estado de Software Implemented corresponde ento ao modelo de Platform Specific Model (PSM), dado que o processo j funcionar em software, tendo para isso de obedecersespecificaesdaarquitecturatecnolgicaondevaifuncionar(Figura26).
Figura26.EstadosdosPFsnaBIM[Duarte,Machadoetal.2009]eTransformaodeumPIM paraPSM[OMG2003]
Figura27.EsquemadeTransformaoAdoptado
53
Estabelecidas as relaes entre os processos de negcio na BIM e os modelos MDA, o esquema que descreve as transformaes que os modelos dos processos vo sofrer obtido (Figura 27). Os processos iro ser modelados em BPEL at existirem dados suficientes para a implementao destes processos em software. O modelo CIM no foi considerado para este caso,mas,setivessesido,oprocessoseriadefinidonoestadoGeneric,porexemploatravsda linguagemBPMN,antesdeseobteromesmoprocessonomesmoestadomasemBPEL.
CaractersticasdeumProcessoPIM
Para a modelao dos processos, temse em conta primeiramente as funcionalidades destes, ainda sem qualquer especificao sobre procedimentos de ordem tcnica, apenas do pontodevistadonegcio.EstenveldemodelaocorrespondeaomodeloCIM(Computation Independent Model) do ModelDriven Architecture (MDA) descrito na seco 2.4. Tal como descrito nessa seco, o CIM sofre transformaes de modo a tornarse um PIM. Ao nvel do CIM no se justifica a utilizao do BPEL para modelar o processo, pelo que uma linguagem apenas de notao, como BPMN, EPC ou UML ser suficiente. Em certos casos, pode ser aconselhvel amodelao doprocessoprimeiramenteaonveldoCIMantesdeomodelar em PIM,ficandonoentantoaocritriodoanalistadoprocessoanecessidadeounodemodelaro processo primeiramente em CIM e depois o transformar em PIM, ou modelar o processo directamente em PIM. Aps a transformao para o nvel PIM, o processo modelado j ir conter especificaes da implementao do processo. Mas, devido a ser um modelo de processo de negcio independente de plataforma, ainda no contm qualquer especificao sobreemqueplataformaserimplementado.Essastransformaessotratadasmaisadiante. UmmodelodeprocessosaonveldoPIMmodeladoemBPELdeveterumconjuntode requisitos a que o processo deve obedecer para garantir o fluxo correcto dos dados. Deve conter especificaes computacionais ao nvel da linguagem para execuo dos processos, tal como descreve o MDA aquando a obteno de um PIM a partir de um CIM. Daqui se retira a necessidade de modelar o processo a partir de uma linguagem que permita a execuo do processo, como o BPEL, ao invs de utilizar linguagens que apenas permitem representar o processo utilizando notaes, como BPMN, EPC ou UML. Linguagens como o BPMN devem ser utilizadas ento a um nvel mais abstracto da modelao do processo, quando o designer do processoeoanalistadonegciopretendemapenasdefinirocontrolodofluxodosdados,bem comoespecificarquemsoosparticipantesnoprocessoequaisosartefactosligadosaele.Ao nveldoPIM,omodelodoprocessoemBPELdeverentojdescreveroprocessodenegcio segundo especificaes de servios bem como integrao e ligaes entre diversas aplicaes,
54
de modo a que responda aos requisitos funcionais e nofuncionais do prprio processo e permitamaiornvelpossveldeligaesautomticasentreservios. AmodelaoemprocessosBPELnormalmentefeitatendoporobjectivoaintegrao das vrias aplicaes que uma organizao pode utilizar. Ao nvel do PIM a integrao no o principal objectivo, pelo que dever ser apenas o de definir as ligaes que permitam o fornecimento de um servio qualquer que satisfaa os requisitos do processo. Se, por norma, utilizamosumESB(EnterpriseService Bus) paraqueosvrioscomponentesdaarquitecturado sistema de informao de uma organizao possam trocar mensagens de modo a viabilizar todo e qualquer processo de negcio, no modelo PIM apenas considerado o componente BPEL, como se este se encontrasse sozinho na arquitectura. Isto , o modelo deve definir ligaes entre servios, mas no especificar o modo como a ligao feita. Por exemplo, o modelo de processos pode definir ligaes a um dado ERP, mas no so descritas as especificidadesprpriasqueoERPnecessitaparaseinterligaraoprocesso. Outra caracterstica do processo que este descrito como funciona no tempo presente (asis) e no como funcionar no tempo futuro (tobe), pois necessitaria de ter definidas especificaes do tipo de ligaes que iria ter com os servios e softwares constituintes do processo, bem como tambm necessitaria de ser consideradas especificaes no que respeita o desenvolvimento de sistemas de software que iriam suportar o funcionamentodosprocessos. Como j referido anteriormente, para o nvel do PIM devese considerar apenas o componente BPEL, como se este estivesse sozinho. Ento, o modelo constitudo por um processo que ter as actividades bsicas BPEL (invoke, receive, reply, wait, assign, throw, compensate, compensateScope, exit, empty, rethrow, validate, extensionActivity) e as estruturasalgortmicasquealinguagemBPELsuporta(sequence,flow,pick,while,repeatUntil, scope,if,forEach,wait),nocontendoquaisquerdescriesmaisdetalhadasacercadecomoo processoirserexecutado.
55
Bestpractices
Figura28.FasedaTransformaoemqueseEncontraomodeloPIM
Processosdeboasprcticaspermitemsorganizaesmelhorarosnveisdeeficincia operacional. Deste modo, tornase fundamental que as organizaes possuam um repositrio de processos de boasprcticas, com processos que garantam a eficincia da empresa. Na elaborao das boasprcticas devese ter em conta aspectos variados para alm da eficincia do ponto de vista puro do negcio ou financeiro, como por exemplo, aspectos especficos do pasdefuncionamentodaempresaouquestesdegestoambiental,entreoutros. A utilizao de boas prticas garante tambm organizao a obteno de certificaes de qualidade, como ISSO [ifSMF 2007], EFQM [EFQM 2001], entre outros. Estas certificaes, para alm de garantir que a empresa funciona de um modo eficiente, trazem benefcios em termos de imagem junto de clientes, fornecedores e colaboradores, o que tambmpositivodopontodevistadonegcio. No caso do Grupo Bosch, mais concretamente na subdiviso Car Multimedia (CM), o
modelo de referncia para os seus processos de negcio o UBKRM (Unternehmensbereich Kraftfahrzeugausrstung Reference Model), que representa a Diviso de Tecnologia Automvel. O primeiro nvel dos processos composto por trs categorias de processos de negcio: de gesto, chave e de suporte. Os processos de gesto tm a funo de suportar as tomadas de decises por parte da gesto de alto nvel. Os processoschave so os que descrevem o funcionamento do negcio por parte da organizao. Os processos de suporte no interferem no desenvolvimento do produto, mas so igualmente necessrios, pois, por norma, so eles que tratam da relao da empresa com os seus stakeholders. A este nvel,
56
ainda no possvel estabelecer relaes exactas entre os processos, pelo que a modelao em BPEL no se realiza. A modelao em BPEL s se justifica aquando da representao do processo ao nvel das suas actividades, correspondente ao nvel 3 do UBKRM, que pode tambmsercomparadoaonvel3sugeridopelomLEARN[Coelho2005]eSCOR[SCC2008]. Para a modelao em BPEL do modelo PIM pretendido, o nvel 3 do UBKRM foi transformado em BPEL, obtendose assim um repositrio de processos que representam as boasprcticas. O exemplo dado neste captulo o processo de Produo, pertencente ao processochavedeFulfillment(Figura29).
Figura29.ExcertodeProcessoBPEL"Produo"
Na figura, podese ver um excerto do processo produtivo, que vai desde a preparao
da linha, passando pelo consumo dos materiais, embalamento e no representado na imagem o armazenamento dos produtos. O incio do processo efectuado depois de realizado o planeamento do material. No processo de produo os materiais saem do stock, so consumidos e o produto ou conjunto de produtos enviado para a rea de expedio.
57
Acabadooprocesso,seguemseoscontrolosdequalidadeantesdeirempararaosclientes.Em resumo,oprocessotemumprocessoantecessoredoisprocessossucessores.
GenericPFdeRegistoProdutos
Figura30.GenericPFRegistoProdutos
O RegistaProduto um subprocesso do processo de Produo. Na Figura 30 est o
modelo BPEL correspondente. O chefe de linha regista o produto / conjunto, aps o consumo dos materiais, fabrico, teste e embalagem. Esta actividade resulta na actualizao dos stocks. Visto que apenas necessrio uma actividade para este subprocesso, necessrio ento apenas representar uma actividade invoke no modelo BPEL, neste caso denominado de ActualizarStock.
3.4
Concluses
Neste captulo um dos objectivos propostos j foi cumprido. A linguagem de execuo
de processos de negcio a utilizar na Bosch Car Multimedia Portugal, Lda. foi escolhida tendo em considerao trs tipos de estratgias: organizacionais, de negcio e de sistemas de informao. A anlise de dois aspectos adicionais, ao invs de apenas considerar os vinte
58
padresdeworkflowtornaaescolhamaiscompletaefundamentada,poisassimaescolhano puramente tecnolgica. Visto que a anlise pretende a escolha de uma linguagem para utilizao de uma organizao e no utilizao individual, a anlise linguagem mais apropriada aos colaboradores da empresa, bem como a anlise linguagem mais apropriada ao negcio da organizao, torna a escolha da linguagem mais abrangente e sincronizada com os reais interesses da empresa. Aps muita investigao, ao nvel de vrios estudos dos padres de workflow, percepes das pessoas e adequao ao nvel do negcio, variados autores e variados aspectos relevantes e irrelevantes, distintos e no distintos, no sobraram dvidas de que o WSBPEL mais adequado para a empresa em causa do que as restantes linguagens identificadas. Muitos autores definem o WSBPEL como linguagem standard na execuo de processos de negcio, mas essas afirmaes no foram sequer tidas em conta duranteacomparao,poisoalvodacomparaoapenasesaempresa. ABIMsurgecomoumametodologiainteressanteaestudar,poissugereautilizaode modelos de referncia na definio dos processos, em vez de simplesmente transformar em software os requisitos dos clientes. Neste captulo ainda s a fase de Seleco efectuada. Foram apresentadas quais as caractersticas que os processos de negcio possuem nesta fase, at estarem num estado em que j so executveis. Numa fase inicial, para descrever os processos PIM, apenas considerada a representao grfica dos processos. apresentado um exemplo de um modelo de processos que vai sofrer as transformaes do seu estado ao longodametodologia.Oprocessodeexemplo,dadoquepertenceaummodelodereferncia, servircomobaseparaastransformaesseguintespropostaspelametodologia,atseatingir umatransformaoquepermitaobtersoftware.
59
60
4. TransformaoAutomatizadadosProcessos
Nestecaptulo,osprocessosdenegcioemPIMvosendotransformadosatestarem devidamente prontos para serem transformados para PSM. Seguindo a BIM, os modelos dos processos so instanciados e alterados at se encontrarem executveis, i.e., so descritas as fases 2 e 3. Na segunda parte do captulo, os conceitos da plataforma onde o software executado so descritos. Estes conceitos so importantes na tarefa da transformao e da obteno do PSM. As transformaes so efectuadas seguindo os conceitos propostos pelo MDA, nomeadamente descrio da plataforma, mapeamento e marcao. S aps as trs actividades se pode passar ento transformao em si. Finalmente, apresentado um modelo PSM para demonstrar que a transformao resulta efectivamente numa implementaoemsoftwaredoprocessodenegcio.
4.1
Introduo
Ainda apenas a primeira fase da BIM, a Seleco, foi executada. O ponto de situao
que o processo est em PIM, mas, segundo a BIM, no est ainda pronto para ser transformadoemsoftware. O modelo de processos est no seu estado genrico, pelo que apenas reflecte as
propostas dos modelos de referncia. O cliente pode agora expor a sua viso do negcio, pois tem como objectivo destacarse e distinguirse das organizaes concorrentes. A BIM permite que trs cenrios: que seja o processo pedido pelo cliente a ser tratado na prxima fase, que seja o processo j obtido na fase anterior a ser tratado na prxima fase, no sofrendo instanciao, e por ltimo, que seja um processo baseado no processo genrico mas que responda aos requisitos do cliente a ser tratado na prxima fase. Assim que se assegure que o processo est devidamente definido, passase ento fase de concretizao no Sistema de Informao. A ltima fase da BIM que ainda considera modelos de processos PIM, a de
Concretizao, tambm tratada neste trabalho. necessrio assegurar que o processo est pronto para a transformao no final desta fase. Para tal, o modelo de processos deve estar totalmente concretizado no Sistema de Informao. Deve ser ento definido a forma como o processo se encaixa na arquitectura da organizao. No fim desta fase, o processo j executveleestpreparadoparaserimplementadoemsoftware. A abordagem MDA utilizada na transformao do modelo em software,
considerandoomodelodeprocessosobtidoumPIMeomodelodesoftwareaobterumPSM. Para ter o processo a executar em software, este ser implementado num Enterprise Service Bus (ESB). O Apache ServiceMix [ServiceMix] um ESB baseado em componentes JBI [TenHoveeWalker2005].
61
4.TransformaodosProcessos
AtarefadetransformaoexecutadaseguindoospassospropostospeloMDA.Este
um passo muito importante no trabalho, pois demonstra como um processo de negcio pode ser transformado em software de uma forma automatizada e assim, para alm de resultar num desenvolvimento eficiente devido utilizao da BIM, resulta num desenvolvimento eficaz.
4.2 TransformaodosProcessosPIM
Para se concluir as fases de Definio e de Concretizao da BIM devese assegurar que os modelos dos processos so instanciados do modelo genrico (este passo no obrigatrio, o modelo pode passar para a fase seguinte sem ser instanciado desde que seja comprovado que os processos esto devidamente definidos e prontos a serem tratados na prxima fase) e que so executveis. Estes modelos ainda so PIM e, assim que esto no estadodeexecutveis,estonaltimafaseantesdeseremtransformadosemPSM. Para melhor acompanhar a transformao dos processos, sempre feito um ponto de
situao da transformao tanto no mbito da metodologia como no mbito de MDA, pois os conceitos de MDA sero muito importantes na preparao e na transformao do modelo em sistemas de software, permitindo ao modelo de processos serem implementados em software.
PropostadeCustomizaodocliente
O passo seguinte para transformar os processos efectuar o levantamento dos requisitos do cliente para este processo, para posteriormente efectuar a devida anlise das transformaes que o processo bestpractice (PIM) ir sofrer de modo a satisfazer o cliente. De acordo com a BIM, esta fase corresponde a passar de um modelo Generic para um modelo Instantiated (Fase 1 para Fase 2). Para demonstrar a transformao, o exemplo escolhido foi o subprocesso de Registo do Produto j apresentado no captulo 3. A escolha recaiu neste subprocesso pois no um processo complexo alm de receber e responder ao pedido, apenasrealizaumaactividadeadicionale,comodemonstradomaisadiante,aarquitectura emqueesteseintegradegrandeimportncia.
62
Figura31.FasedaTransformaoemqueseEncontramosRequisitos
Apropostadoclientetemcomoobjectivoacrescentarvaloraoprocesso.Nombitodo
negcio,o clientetem comoproposta noregisto dosprodutos/conjuntosfinais(nestaaltura do processoprodutivo, os materiais j foram consumidos, embalados e testados, pelo que so considerados produtos acabados) que seja adicionada uma entrada nos registos do novo produto/conjuntoacabadoequesejafeitaumaactualizaodaquantidadedemateriaisem armazm para gesto do stock (Figura 32). A proposta tambm sugere que estas operaes devem ser executadas pelo chefe de linha, dado que este o responsvel pelo supervisionamentodoprocessodeproduodoproduto/conjuntoemquesto. A actualizao automtica dos stocks traz valor organizao dado que permite, por exemplo, que a organizao tenha conhecimento, em tempo real, que a quantidade de stock de um determinado material atingiu o seu valor de segurana, pelo que aconselhvel efectuar um pedido de encomenda ao fornecedor desse material. O registo de novo produto permitir organizao que os dados do produto sejam persistentes, i.e., que a informao seja registada e guardada para que possa ser acedida sempre que algum da organizao assimoentender.
63
Figura32.OperaesPropostaspeloCliente
InstantiatedPFLanamentodeQuantidades
A segunda fase da BIM [Duarte, Machado et al. 2009], a Definio, descreve que o
modelo genrico escolhido na fase anterior deve servir de base para se chegar a uma instanciao do modelo de processos. A metodologia descreve tambm que o modelo instanciadodeveincluiravisodoclienteeasuaestratgiaparaonegcio. J foi visto anteriormente que uma proposta para acrescentar valor no registo dos produtos / conjuntos o exemplo escolhido para a demonstrao a de que este processo deve incluir duas actividades, adicionar registo de novo produto e actualizar quantidade do material consumido em stock. Na modelao em BPEL realizada anteriormente, em vez de apenas uma actividade de invocao, propese que o processo deve ter ento duas invocaes(Figura33). O cliente refere que necessita de dar baixa dos materiais no stock, mas tambm de guardar os valores para consulta dos dados no futuro. Facilmente se identifica a necessidade desubstituiraactividadeprovenientedomodelogenricoporduasactividadesquesatisfaam os requisitos pedidos pelo cliente. Justificase uma invocao em paralelo pois os dados que serointroduzidosparacadauma dasinvocaessoosmesmos.Sendoqueasactividades se realizam em paralelo, e no sequencialmente, tambm faz com que o processo s termine se ambas as actividades forem executadas com sucesso o que no aconteceria se fossem sequenciais,oquenecessrioparamelhoraronegciodaorganizao. DereferirqueoprocessodescritoanteriormenteerepresentadonaFigura34tratase de uma proposta, pelo que podem ser desenvolvidas alternativas ao modelo instanciado. A BIM uma metodologia flexvel no que toca quantidade de modelos desenvolvidos, pois
64

independnciadetecnologias.
permite a alterao fcil do modelo definido em qualquer uma das suas fases e tambm a
Figura33.ProcessodeBPELdeRegistarProdutoeActividadesdeCustomizao
Figura34.InstantiatedPFLanamentodeQuantidades
65
RunnablePFLanamentodeQuantidades
necessrioagoraconcretizaromodelonosistemadeinformao.Aprimeiratarefaa
realizar ser analisar que tipos de tecnologias podem ser utilizados para suportar a componente automtica do processo. Uma proposta ser utilizar um sistema ERP, muito utilizado no suporte a processos na larga maioria das empresas, entre as quais tambm se insere a Bosch Car Multimedia Portugal, Lda. Alis, nesta empresa, o ERP mesmo o principal sistema de suporte aos processos de negcio. O sistema de ERP utilizado o sistema da SAP. No entanto, utilizar um sistema de gesto de bases de dados para inserir novos registos directamentenabasededadospodeserumasoluomaisadequada. Logo, alm de actualizar o stock introduzindo os dados num ERP, necessrio guardar os valores numa base de dados. Uma proposta ser ento uma invocao, em paralelo, de um sistema de ERP e outra de um sistema de Base de Dados. Analisando a arquitectura deste, verificase que o processo iniciado a partir de um software instalado num terminal local ou num terminal mvel (PDA). Como sistema de gesto de bases de dados esto em implementados na organizao dois sistemas, Oracle e MySQL, pelo que qualquer um deles podeasseguraroregistodonovoproduto.
Figura35.RepresentaodasRelaesdosSoftwaresqueExecutamoProcesso
NoquetocatransformaodomodeloBPELparaafasedeConcretizao,bastante
simples. Sendo que na fase anterior j se identificaram duas actividades que so executadas emparaleloregistarnovoprodutoedarbaixanostocke,atravsdaanlisearquitectura, j se definiu que sero os sistemas de ERP e de Base de Dados a suportarem as actividades, o modelo BPEL no ir sofrer transformaes significativas de modo a estar no estado de Runnable. As actividades BPEL invoke definidas no modelo anterior so substitudas por
66
actividades invoke que invocam os sistemas de ERP e Base de Dados. De resto, na sua disposio,noexistemmaisquaisqueralteraesnasactividadesdomodeloBPEL(Figura36).
Figura36.RunnablePFdeLanamentodeQuantidades
Para completar a fase de Concretizao da BIM necessrio que o PF esteja devidamente concretizado no Sistema de Informao. Para assegurar que tal acontece, j necessrio descrever devidamente o processo, pelo que a sua representao grfica j no suficiente. De seguida, so especificadas quais as localizaes de cada actividade do processo, bem como o tipo de mensagens que so trocadas. Na Figura 37 est representado parte do cdigo BPEL, nomeadamente a parte das importaes (linhas 1 a 4) e a parte da sequncia da actividade de invocao dos servios externos em paralelo (linhas 5 a 14). A razo de representar estas partes prendese com as ligaes aos servios realizadas, nomeadamente a utilizao dos namespaces, de modo a que o orquestrador consiga identificar a localizao
67
onde o servio est alocado. Estes dados iro ser considerados na tarefa de transformao paraPSM,vistoqueprovvelqueatransformaoabordeestestiposdeelementos.
... [1] [2] [3] [4] <bpel:import namespace="http://Sap" location="SapArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import namespace="http://Bd" location="BdArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> ... [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] <bpel:flow name="Flow"> <bpel:invoke name="SAP" partnerLink="sap" operation="process" inputVariable="sapRequest" outputVariable="sapResponse" portType="ns3:Sap"> </bpel:invoke> <bpel:invoke name="BD" partnerLink="bd" operation="process" inputVariable="bdRequest" outputVariable="bdResponse" portType="ns1:Bd"> </bpel:invoke> </bpel:flow> ...
Figura37.ExcertodoCdigoBPELFinal
Visto que o PF se encontra no estado Runnable, j deve ser considerado para o
processo estar em funcionamento, no apenas o BPEL, mas tambm o WSDL associado ao processo (Figura 38). J foi explicado anteriormente na seco 2.2 e 3.2 que cada processo BPEL composto por um ficheiro BPEL que possui um interface correspondente num ficheiro noformatoWSDL.
Figura38.RepresentaodoWDSLdeLanamentodeQuantidades
O que importa ressalvar do WSDL so os dados referentes ao servio, ligao, tipo de
porta, operaes e elementos de entrada e sada. O processo ficou definido como fornecedor de um servio de lancQuantService, em que as ligaes so efectuadas atravs de um
68
LancQuantPort, localizado em http://0.0.0.0:8080/ode/processes/LancQuantService. O tipo de porta ficou definido como LancQuant, que fornece apenas a operao process. A operao process corresponde neste caso ao processo principal, tal como j tinha sido definido no cdigo BPEL (nas actividades de receive e reply) e tem como elementos de entrada e sada LancQuantRequest e LancQuantResponse, respectivamente. O cdigofontedoprocessoBPELedoseurespectivointerfaceWSDLencontramseemanexoE. Podese pensar que, aps obter o processo no estado executvel e assegura a
concretizao no Sistema de Informao, esta fase est completa. Analisando com mais pormenor a fase de Concretizao, nomeadamente as tarefas definidas para o responsvel pelo processo de negcio, verificase que estas so a de decidir se o processo deve ser implementado ou no em software e de definir processos alternativos a conceber. Esta ltima altamente aconselhvel, no mbito da gesto de risco da organizao. No caso do processo apresentado, o processo vai ser implementado em software (e descrito na prxima seco). Podem ser apresentadas alternativas de processos que avanam para a fase seguinte da BIM mas tambm adequado que sejam apresentadas propostas para processos cujos modelos j se encontram nos seus estados finais, i.e., no avanam para a prxima fase e serem implementadosemsoftware.Seroportantoprocessosdenegciopuramentemanuais. Mais uma vez se reala que este modelo no deve ser o nico desenvolvido nesta fase
da BIM. A convenincia de existir uma alternativa ao modelo de processo implementado em software justificase pelo facto de que qualquer um dos componentes que participam no processo de negcio est sujeito a falhas, pode passar por fases de baixa performance, necessidade de actualizaes ou sobrecarga de tarefas, entre outras possveis razes. Possuir um modelo alternativo diminui os riscos para a organizao, mas no os elimina completamente. Possuindo mais alternativas, possvel afirmar que o risco diminui exponencialmente,mas,comobvio,nuncapossveleliminaroriscoporcompleto. Tal como referido anteriormente, adequado que seja apresentada pelo menos uma
alternativa em que o modelo represente um processo que no seja implementado em software. Nesta fase da BIM, o modelo no estado executvel deve ser obtido a partir do modelo no estado instanciado ou genrico, mesmo que, na elaborao inicial desses modelos, o propsito da elaborao do modelo fosse que este percorresse todas as fases da BIM. A partir do exemplo do modelo instanciado apresentado anteriormente, a proposta para alternativa para um processo executvel e concretizado na organizao ser a de executar as actividades j definidas mas sem recorrer a qualquer tipo de tecnologia, como por exemplo realizarosregistosempapel.Seriamentoefectuadososregistosrelativossadadematerial, bemcomoosregistosdaentradadenovosprodutosacabadosparaazonadeexpedio.
69
4.3 ModelodeProcessosemPSM
O modelo de processos de negcio j percorreu todos os seus estados antes de ser implementado em software. Nesta fase, o modelo deixar de ser PIM para ser transformado em PSM. Os processos sero executados num Enterprise Service Bus pois permite a integrao dasaplicaesdeumaformastandard.Paramelhorseperceberatransformao,osconceitos da arquitectura tecnolgica so apresentados de uma forma generalizada, devido quantidadeecomplexidadedosconceitos,paranosairdosaspectosessenciais. A tarefa de transformao demonstra a forma como os elementos do processo PIM
iro ser inseridos nos componentes da plataforma. No fim de definir os componentes com as transformaes, o processo de negcio est ento implementado em software, tal como definido na BIM. Sendo esta fase completada, o projecto ter ento percorrido toda a metodologiacomsucesso.
TransformaodomodeloemPSM
No final da seco 4.2, oPIM est modelado e os requisitos do cliente para o processo esto levantados. Esto ento reunidos os contedos necessrios para se especificar as transformaes necessrias para a plataforma onde o processo vai ser implementado (Figura 39). nesta fase que todos os detalhes necessrios para a transformao final do modelo PIM para um modelo PSM so definidos. Esta tarefa to ou mais crucial do que as tarefas realizadas anteriormente e a tarefa da prpria obteno do PSM, dado que os detalhes da transformao so toda a base para a obteno do PSM, pelo que os detalhes devem ser analisadosaopormenor. Seguindo o modelo proposto pela OMG para o MDA (Figura 40), para efectuar a fase
detransformaodomodelonecessriodescreveraplataforma,seguindoseomapeamento e a marcao dos elementos que iro ser transformados. Seguindo as especificaes da OMG, a tarefa de transformao feita de forma automatizada e, dado o nvel de detalhe de cada uma das descries efectuadas, o risco de erros na transformao do modelo ento reduzido.Sdepoisquejpossvelrealizarseoprocessodetransformaodomodelo.
70
Figura39.FasedaTransformaoemqueseEncontraaTransformaodoModelo
Figura40.TransformaodosModelos[OMG2003]
Plataforma Os processos suportados por software vo ser executados dentro de um Enterprise

Service Bus (ESB). A partir da arquitectura do Sistema de Informao em que o processo executado,definidonasecoanteriorparasechegaraoestadoexecutvel(Runnable)nafase de Concretizao da BIM, identificado um dos artefactos mais importantes da BIM, os Orchestrated Business Objects (OBO) [Duarte, Machado et al. 2009]. Para a identificao dos OBOs, devese iniciar por identificar quais as tecnologias presentes na arquitectura representada na Figura 35. necessrio tambm ter em ateno as especificidades tecnolgicasqueoESBquevaisuportaroprocesso,oServiceMix.
71
Na arquitectura identificamse quatro tecnologias diferenciadas: o softwarecliente, que d ordem de inicio ao processo atravs da sua invocao; o BPEL, com a funo de orquestrador do processo que define a ordem como os servios sero invocados; o ERP, que executa a actividade de sada de material do stock; e a Base de Dados, que executa a actividade de registo de novo produto para expedio. Analisando as caractersticas do funcionamento do ServiceMix quanto a execues e ligaes externas, possvel identificar a necessidade de trs Binding Components (BCs), de modo a possuir ligaes para o ERP e a BasedeDadoseoutraligaodepedidoerespostaaocliente.UmtipodeBCadequadoparaa tarefa um que interprete Web Services, dado que as caractersticas do protocolo SOAP so das mais apropriadas para enviar pedidos e respostas para um dado cliente. No que toca s ligaes com o ERP e a Base de Dados, esta opo baseiase no facto de ainda no existir um Service Engine (SE), para funes, neste caso, no ERP SAP, e tambm dado que assegura ligaes Java Database Connectivity (JDBC) [Sun]. Para estes dois ltimos, a execuo do Web Service feita atravs de SEs, ou seja, um SAP SE e de um BD SE. Necessita tambm de um BPEL SE (na Apache denominase de Orchestration Director Engine ODE) [ODE], para executaroworkflowdoprocessoeorquestrarosservios. Resumidamente, executar o processo de negcio no ESB necessitar de seis OBOs, correspondentes a seis componentes JBI: um BPEL SE para executar a orquestrao do workflow; dois CXF SEs, um para SAP e outro para a BD, para insero dos dados atravs de Web Services; e trs CXF BCs, dois que efectuaro a ligao dos Web Services definidos nos correspondentes CXF SEs ao sistema externo respectivo, e outro que efectuar a ligao do pedidodoclienteaoprocessoearespostadoprocessoaocliente(Figura41).
Figura41.ComponentesdaPlataformaCriadosParaExecutaroProcesso
72
Mapeamento
Tabela8.RelaesdoMapeamentoPIMPSM
ElementoPIM WSDLTiposdosElementosdotipoRequest ElementoPSM ParmetrosdeentradadaclassedoPOJOdoSU (CXFSEs) NomedoWebServicenoficheiroJAVA pertencenteaoSU(CXFSEs) targetServicedoSU(CXFBCs) NomedoserviodopartnerLinkrespectivonoSU (BPELSEODE) targetInterfacedoSU(CXFBCs) targetEndpointdoSU(CXFBCs) NomedaportadoserviodopartnerLink respectivonoSU(BPELSEODE) namespacesnosficheirosxbean.xmle targetNamespacenoficheiroJAVAdoSU(CXFSEs) namespacesdosficheirosWSDLqueso PartnerLinksnoficheiroBPEL wsdldoSU(CXFBC),geradospeloCXFSE ParmetrosdeentradadoWebServicedocliente TipodeelementoinputdoRequestdoWSDL VarivelinputdoBPEL ActividadeBPELInvokeSAPSE FicheiroWSDLgeradopeloCXFSE ActividadeBPELInvokeBDSE FicheiroWSDLgeradopeloCXFSE ParmetrosderetornodoWebServicedocliente TipodeelementooutputdoResponsedoWSDL VariveloutputdoBPEL
WSDLNomedoServio (LancQuantService,SapServicee BdService) WSDLTipodePortadoServio (LancQuant,SapeBd) WSDLNomedaPortadoServio (LancQuantPort,SapPorteBdPort)

BPELnamespacesdosserviosimportados BPELFicheirosWSDLimportados BPELVarivelinputeWSDLElemento Request BPELActividadeInvokeSAP BPELFicheiroWSDLquePartnerLinkSap BPELActividadeInvokeBD BPELFicheiroWSDLquePartnerLinkBD BPELVariveloutputeWSDLElemento Response

O mapeamento (Tabela 8) que descreve as relaes entre os artefactos dos modelos
de PIM e de PSM reflectem um grupo de regras que a transformao ir seguir. A tarefa de mapeamentonoapresentaumgraudedificuldadeelevado,dadoque,nestecaso,oprocesso modeladoemBPELapresentaapenasseisactividades. As actividades de invoke pretendem que um determinado servio lhes envie uma
resposta a um determinado pedido, pelo que o componente do ESB que corresponde a estas caractersticas o Service Engine. Assim, o mapeamento directo, pelo que as actividades de invokeiroinvocaroOBOrespectivo,i.e.,ainvocaoSAPestrelacionadacomoOBOSAP SE,enquantoqueainvocaoBDestrelacionadacomoOBOBDSE.Asduasactividades deassignnosofremalteraesparaonovomodelo,poissoigualmentenecessriasnonovo modelo e o seu contedo no modificado, pois os valores que este atribui s variveis tambm se mantm inalterados. Os namespaces, bem como os dados do servio do WSDL portType, service e port , correspondem aos dados de identificao dos SUs que vo sercriados.OficheiroWSDL,alis,oficheiroquecirculanoNMR.
73
O ficheiro WSDL o mais importante na transformao, dado que apenas a definio das mensagens (partes e tipos) no so consideradas na transformao, pelo que o programador define conforme entender. No que toca ao ficheiro BPEL, a definio dos PartnerLinks e das Variveis no so abrangidas na transformao, pois a definio do PartnerLinkType fica igual, e o nome e o role no so considerados na transformao e ficam aocritriodoprogramador.
Marcao
Tal como a tarefa de mapeamento, tambm a de marcao simples, dado a baixa complexidadedomodelodeprocessos.Amarcaodoselementosfeitaapartirdasrelaes identificadas no mapeamento. Consultando a coluna dos elementos PIM da tabela 8, esto ento os elementos a serem marcados, respectivamente listados na tabela 9 e representados na Figura 42. A marcao til no sentido em que, tal como pode ser observado na tabela 8, umelementonoPIMpodedarorigemamaisdoqueumelementonoPSM.Paraestescasos,a tcnica da marcao utilizada para que no se corra o risco de algum elemento ficar esquecido na transformao, o que resultaria num modelo PSM incompleto. Em alguns casos, aconselhvel listar cada elemento a marcar, e no generalizar os elementos pelo seu tipo, como nos casos em que a listagem refere o mesmo tipo de elementos, mas aplicveis a SapeaBd. Mais fcil do que consultando ambas as tabelas anteriores, na Figura 42 possvel ver uma representao do mapeamento e da marcao, onde, do lado esquerdo da figura, esto os elementos do PIM mapeados e que vo ser marcados e, do lado direito, est o respectivo elementoPSMresultantedatransformaoaserrealizada.
Tabela9.ElementosparaMarcao
ElementoPIM ActividadeBPELInvokeSAP ActividadeBPELInvokeBD NamespacedoSapServiceimportadonoBPEL NamespacedoBdServiceimportadonoBPEL FicheiroSapArtifacts.wsdlimportadonoBPEL FicheiroBdArtifacts.wsdlimportadonoBPEL PortTypeSapdoservionoWSDL PortTypeBddoservionoWSDL ServiceNameSapServicedoservionoWSDL ServiceNameBdServicedoservionoWSDL PortNameSapPortdoservionoWSDL PortNameBdPortdoservionoWSDL Elementos/VariveldotipoinputnoWSDL/BPEL Elementos/VariveldotipooutputnoWSDL/BPEL
74
Figura42.MapeamentoEntreosComponentesPIMePSM
As tarefas representadas na Figura 40, de modo a definir a transformao, nesta fase j foram efectuadas. As descries sobre a plataforma e dos elementos que vo ser transformados e que vo dar origem a outros elementos para o modelo final permitem que a transformao do modelo PIM do processo de negcio para o modelo PSM seja efectuada de modo automatizado. As tarefas de mapeamento e de marcao podem ser feitas de maneira
75
automticautilizandooMOFQVT[OMG2005].Introduzindoquaisoselementosatransformar eoselementosqueresultamdatransformao,ocdigofinalobtido.Nestecaso,sendoque oprocessopodeserconsideradosimples,ousodoQVTnoessencial,pois,comojfoivisto, as alteraes so poucas, pelo que a utilizao deste standard da OMG fica considerao de cada um. O QVT por norma til nos casos em que os modelos e as transformaes so mais complexos.
ExemplodeProcessoPSM
O processo de transformao a que o MDA se refere constitui o ltimo passo na obteno de um modelo PSM (Figura 43). O modelo PSM obtido representa o processo de negciototalmenteimplementadoemsoftware,comasdevidasespecificidadesdaplataforma tecnolgicaondeoprocessoexecutado.
Figura43.FasedaTransformaoemqueseEncontraoPSM
Tal como j visto anteriormente, as especificaes para a transformao para a
plataforma em causa passam pela descrio da plataforma (Apache ServiceMix), mapeamento dasrelaesemarcaodoselementos.Estastrsdescriesconstituemabaseparaadevida transformaoparaPSM.Apartirdaconsultadadescriodaplataformaverificasequeexiste um conjunto de propriedades que necessrio definir. Revisitando a descrio da plataforma, concluise que o ESB utilizado requer a definio de Service Engines (SE), Binding Components (BC),ServiceAssemblies(SA)eServiceUnits(SU).
76
Seguidamente, ir ser feita uma demonstrao da criao e da definio dos SEs, BCs e SUs (contidos posteriormente no respectivo SA). De modo a dar seguimento ao raciocnio apresentado ao longo deste captulo e do anterior, o processo de negcio a implementar no ESB ServiceMix ser o exemplo de processo que tem vindo a ser demonstrado ao longo da metodologia. A definio dos SUs, tal como os restantes componentes JBI, feita criando um projecto Maven 2 [Maven]. O Maven 2 um software open source para gesto e automatizao de projectos em Java, desenvolvido pela Apache Software Foundation [Apache]. O mtodo baseiase na construo de um Project Object Model (POM), onde se descreve todo o processo de construo de um projecto, ou seja, as suas directorias, dependncias (jars) e a sua sequncia de construo. O Maven 2 fornece uns modelos (archetypes) com cdigo que pode ser reutilizado. Os modelos fornecem todos os dados necessriosparaaposteriorcompilaodosSUs.
ServiceEngines
O primeiro passo definir SUs que, depois de efectuado o deploy no ServiceMix, iro criar SEs. O tipo de SE pretendido do tipo CXF. Mais uma vez se refere que esta opo se baseianofactodeaindanoexistirumSEparafunesnoERPSAP.OfuncionamentodoSU descrito num ficheiro xbean.xml, gerado a partir de um modelo Maven especfico para ServiceMix. A definio do tipo feita logo na primeira linha de cdigo, onde definido o namespace (xmlns:cxfse=), enquanto que o resto do cdigo descreve elementos necessrios para a constituio do SU. Este ficheiro bastante simples pelo facto de que apenas indica onde est localizado a classe do POJO (Plain Old Java Object) [Johnson,Hoelleretal.2005]querelevanteparaoServiceEngine. Nestecaso,classeSapService,queserefereoWebServiceexpostopeloCXFSE.O cdigo que antecede diz respeito localizao definida aquando da definio dos groupId e artifactIdparaidentificaodoficheiroeprojectoreferente.OSUcontmtambmumficheiro Java [Armstrong, Ball et al. 2004], neste caso SapService.java, que o Web Service que executado pelo CXF SE. Este ficheiro Java utiliza o SAP Java Connector (JCo) [Schuessler 2001] para efectuar insero e recepo de dados entre o Web Service e o ERP SAP, obedecendo assim correctamente aos requisitos de uma ligao ao ERP. Aps compilao via Maven 2, a classe Java SapService vai criar um novo ficheiro WSDL (Figura 44), que neste caso foi renomeado para SapArtifacts por uma questo de simplicidade no mapeamento dado ser esse o nome dado pela ferramenta de design de BPEL do Eclipse para os WSDLs. este
77
ficheiroWSDLqueoBPELfinal(aindaadescreverposteriormente)irinvocar.Dentrodesse ficheiro,onamespaceadefinirparaoficheirooqueadvmdomapeamentodoPIM.
Figura44.FicheirodeServioWSDLCriadoaPartirdaClasseJava
TalcomooCXFSEqueexecutaaintroduodosvaloresnoSAP,adefiniodoSUpara o CXF SE para a BD semelhante. A utilizao de um CXF SE prendese com o facto de este suportar ligaes JDBC. A diferena da definio deste SU para o SU anterior apenas a da definio da classe do POJO, que ser referente classe BdService, o Web Service exposto pelo CXF SE. Este ficheiro, BdService.java, conter no seu cdigo a ligao JDBC para assim comunicar com a Base de Dados. Tambm neste caso um WSDL gerado aps compilao via Maven2,talcomonocasoanterior.
BindingComponents
J foi explicado como o SU que dar lugar a um SE depois de efectuado o deploy no ServiceMix deve ser configurado. A tarefa de definir um SU que define um futuro BC semelhante (Figuras 45 e 46). Tal como anteriormente, o tipo de componente definido atravsdaprimeiralinhadecdigo(xmlns:cfxbc=).Nestecaso,Osdadosdoselementosdo quedefinemoBCdevemserpreenchidoscomosdadosdoBPELedoWSDLdomodeloPIMtal como sugere a tabela 8. Tal permitir uma correcta identificao da localizao dos componentes pretendidos pelo ESB, que assim pode direccionar correctamente os dados (linhasdecdigo3a6).Dadoqueopedidodeiniciodoprocessofeitopelainvocaodeum Web Service por parte do cliente, ento necessrio que a comunicao entre o cliente e o processo em BPEL seja feita atravs de um CXF BC e que este seja configurado da forma como estsugeridonaFigura45. No cdigo BPEL est definido que o processo invoca dois processos externos, o que indicaanecessidadedemaisdoiscomponentesadicionais.Otipodecomponentenecessrio umCXFBCquecomunicarosdadosaoCXFSEdefinidonaFigura46,enviandoerecebendoos valoresdeumWebService.
78
... [1] [2] [3] [4] [5] [6] [7]
<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" ... xmlns:lq="http://LancQuant" ... <cxfbc:consumer wsdl="LancQuantArtifacts.wsdl" targetEndpoint="lq:LancQuantPort" targetService="lq:LancQuantService" targetInterface="lq:LancQuant"/> </beans>
Figura45.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutaroProcesso

... <beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" ... xmlns:sap="http://Sap" ... <cxfbc:consumer wsdl="classpath:SapArtifacts.wsdl" targetEndpoint="sap:SapPort" targetService="sap:SapService" targetInterface="sap:Sap"/> </beans> Figura46.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutarnoSAP
Parainserirosdadosnabasededados,atarefaserigualaocasodoERP,i.e.,osvaloresso inseridosatravsdeumWebService.Assim,oBindingComponentparacomunicarcomoESB serigualmentedotipoCXFBC(Figura46).

... <beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" ... xmlns:bd="http://Bd" ... <cxfbc:consumer wsdl="classpath:BdArtifacts.wsdl" targetEndpoint="bd:BdPort" targetService="bd:BdService" targetInterface="bd:Bd"/> </beans> Figura47.Cdigoxbean.xmldoSUdotipoCXFBCparaExecutarnaBD
79
O modelo PSM fica completo com a representao do BPEL. Tal como se pode ver na Figura 48, em termos de notao visual este no sofre alteraes, dado que o mapeamento (SAPparaSAPSEeBDparaBDSE)norequeradioouremoodeactividadesBPEL. NaFigura49tambmpossvelvisualizarpartedocdigoBPEL.
Figura48.ProcessoBPELFinal

... <bpel:import namespace="http://Sap" location="SapArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import namespace="http://Bd" location="BdArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> ... <bpel:flow name="Flow"> <bpel:invoke name="SAP BC" partnerLink="sap" operation="process" inputVariable="sapRequest" outputVariable="sapResponse" portType="ns3:Sap"> </bpel:invoke> <bpel:invoke name="BD BC" partnerLink="bd" operation="process" inputVariable="bdRequest" outputVariable="bdResponse" portType="ns1:Bd"> </bpel:invoke> </bpel:flow> ... Figura49.ExcertodoCdigoBPELFinal
80
O processo em BPEL, de modo a ser interpretado pelo ODE (Service Engine da Apache de execuo de processos BPEL) [ODE], necessita de um ficheiro XML que descreve as ligaes aos PartnerLinks do processo para que o processo possa ser executado depois de realizado o deploy. Ao contrrio do que acontece nos restantes SUs, em que o ficheiro a configurar o xbean.xml, no ODE a descrio do seu funcionamento feita num ficheiro deploy.xml. Aps o ficheiro estar devidamente definido, o SU est criado e pronto a ser implementado na arquitectura. Quando todos os SUs estiverem criados, esto ento prontos para serem agrupadosnumSA,comoestrepresentadomaisadiante. No que toca a SUs, a tarefa est terminada, pois j no existem mais OBOs para
definir. J foi descrito anteriormente que o ServiceMix incapaz de interpretar os SUs, a no ser que estes estejam contidos num SA. Para definir um SA, necessrio definir o(s) SU(s) contido(s). Primeiramente, os SUs devem ser compilados, sendo que cada SU d origem a um ficheiro compilado. A definio dos SUs que o SA vai conter (Figura 50) feita num ficheiro pom.xml Project Object Model. O ficheiro POM, gerado a partir do modelo Maven 2, contem as definies gerais do projecto, como nome e localizao, bem como a identificao dos componentesqueseroutilizadosnoESB.Naparterelativasdependnciasdoprojecto,com base no POM, o Maven 2 fica encarregue de descarregar para a mquina do programador todas as bibliotecas que esto relacionadas entre si, e que se encontram num repositrio central.
Figura50.SAdosSU'scriados
ApsodeploynoServiceMixosSUscontidosnoSAirodarlugaraoscomponentesJBI
(Figura 51). Dadas as definies contidas nos respectivos ficheiros xbean.xml, cada SU resulta num SE ou num BC, consoante o tipo definido. O ServiceMix capaz de identificar, atravs do contedo dos ficheiros XBean, qual o tipo de componente definido no SU. Efectuado o deploy, oODESUtornasenumODESE,osCXFSESUstornamseemCXFSEeosCXFBCSUstornamse emCXFBC.OESBcomosdevidoscomponentesconstituiassimoPSM(Figura52).
81
Figura51.BCeSEdepoisdoDeploydoSA(adaptadode[RademakerseDirksen2008])
Figura52.ServiceMixdoModeloPSMFinal(adaptadode[Genender2007])
4.4 Concluses
Neste captulo o modelo de processos genrico que tinha sido obtido na primeira fase da BIM sofreu as alteraes at ter percorrido todas as fases da metodologia. Numa primeira fase, o modelo de processos foi sendo transformado at estar executvel. As transformaes permitiramobterumprocessodenegcioquereflecteavisodenegciodoclientee garante
82
ousodeboasprticasorganizacionais.NofinaldaterceirafasedaBIM,oprocessodenegcio j est devidamente concretizado na organizao. O modelo de processos, depois de modelado de base durante a primeira fase, foi sofrendo algumas transformaes durante as segundaeterceirafases.Nofinaldecadafase,omodelodeprocessospossuiumdeterminado estado,demodoaassegurarqueafaseestconcluda.Osestadosdosmodelospermitemque os processos sejam transformados de forma segura e eficaz. O processo exemplificado no captulo foi sofrendo transformaes simples e rpidas de efectuar. Assim que finalizada a terceira fase da metodologia, o processo estava no seu estado final PIM antes de ser transformadoemPSM. Para passar ltima fase da BIM, a de implementao em software, propsse utilizar
o ModelDriven Architecture para transformar os modelos de processos em modelos de software.OMDApropequeatransformaoparaummodeloPSMsejaefectuadarealizando tarefas de descrio da plataforma, mapeamento, marcao e transformao. As trs primeirastarefassoabaseparaatarefafinaldetransformaodomodelo.Realizadasastrs tarefas,jsepossuitodososdadosrequeridoseaimplementaoemsoftwaresimplificada. A implementao dos modelos de processos num Enterprise Service Bus surge como
umapropostaquepermiteintegraodoprocessoedasaplicaesdeumaformastandard.O ServiceMixfoioESBescolhidopoisutilizaambienteJBIeassimaintegraoefectuadacomo uso de open standards. Os dados da integrao referentes ao processo j advm dos dadosda transformao, demonstrando assim a utilidade do MDA. Na definio dos Service Engines e Binding Components, bem como dos Service Units e do Service Assembly que os vai conter, necessriosnaexecuodosprocessosdefinidos,osdadossoobtidoseficazmenteapartirda transformao,sendoosdadosreferentesaorestantecdigopartedosrequisitosdadefinio dosprprioscomponentesnoESB. Foi apresentado um exemplo de implementao dos processos num sistema ESB, neste caso no Apache ServiceMix. Este foi um open ESB escolhido por razes mencionadas no incio da seco 4.3, mas em [Rademakers e Dirksen 2008] so disponibilizados outros exemplos de open ESBs e utilizar ESBs corporativos tambm pode ser a opo seleccionada. Tambmdescritocomo configuraro ServiceMix, masexistem onlinetutoriaisgratuitossobre configuraresteESB.
83
84
5. Concluso
Este ltimo captulo apresenta resumidamente todo o trabalho realizado e os resultados alcanados. De uma forma sintetizada, esclarecese se os objectivos inicialmente propostos foram efectivamente atingidos. Para finalizar, so apresentadas algumas propostas parainvestigaofuturarelacionadacomestatemtica. A Business Implementation Methodology (BIM), descrita resumidamente neste documento, surge com o objectivo de auxiliar no desenvolvimento de sistemas de informao que assegurem que os requisitos dos processos de negcio dos clientes sejam satisfeitos. A caracterstica principal da BIM a de, na tentativa de assegurar que os processos descritos acrescentem valor ao cliente, utilizar modelos de referncia de processos que forneam as melhores prticas organizacionais definidas entre as organizaes de referncia do sector, e finalizar a implementao num sistema de software que responda afirmativamente aos requisitosdosprocessosdocliente. Um cliente pretende obviamente que a sua organizao seja nica. Logo, os seus processos de negcio, especialmente os processos crticos, devem ser nicos, o que dificulta o desenvolvimento de software no que toca ao tempo e recursos dispendidos nestes projectos, dadoquetmdificuldadeemcriarbasesdeconhecimentosquepodemserreaproveitadasem projectosfuturos.Nestescasos,aBIMfornecevantagensnosentidoemqueaimplementao baseada em transformaes faseadas e sugere a utilizao de modelos de referncia e de outros aspectos organizacionais como base de todo o trabalho de implementao, o que permiteoreaproveitamentodeconhecimentosadquiridosanteriormente. Primeiramente foi realizado um estudo aprofundado de cinco das mais significativas linguagens de modelao de processos de negcio existentes no mercado. Atravs de trs critrios, foi demonstrada qual a linguagem de descrio de processos de negcio mais adequada ao contexto da Bosch Car Multimedia Portugal, Lda. O WSBPEL (Web Services Business Process Execution Language) demonstrou ser mais adequada na globalidade dos aspectos considerados: tecnolgicos, especficos da organizao e especficos do negcio. A anlise efectuada provou o BPEL como mais vantajosa no suporte aos padres de workflow adoptados para comparao das linguagens de processos; nas respostas dos colaboradores a questessobrecaractersticaspresentesnaslinguagensemcomparao,comoconhecimentos acercadeWebServices,linguagemXML,SOA,entreoutros,etambmconhecimentosdeBPM de modo a analisar a sua maturidade em compreender processos de negcio e como estes
85
5.Concluso
devem ser modelados; e por fim em aspectos relevantes no mbito do negcio, como a maturidade,usabilidade,esforodeaprendizagem,custosdaslicenas,entreoutros. A demonstrao da utilizao dos conceitos de MDA para alcanar a ultima fase da BIM foi conseguida. O modelo PIM foi sendo descrito durante a execuo das trs primeiras fasesdaBIMSeleco,DefinioeConcretizao,peloqueapenasnofimdaterceirafaseo modelo PIM estava pronto a ser transformado. Para obter o modelo de processos implementadoemsoftware,equivalenteltimafasedaBIMImplementao,foiutilizada a tcnica do MDA para obter o modelo PSM. O PSM foi ento obtido automatizadamente utilizandoastcnicasdedescriodaplataforma,mapeamento,marcaoetransformaono novo modelo. O modelo PSM obtido responde aos requisitos pedidos pela metodologia para queaultimafasefossedadacomofinalizada. Segundo a BIM, a seleco e definio do modelo de processos de negcio sempre feita pelo cliente, o que no assegura que os melhores aspectos do ponto de vista da organizao sejam os escolhidos. A BIM prope apenas alguns dos possveis modelos, bem como alguns aspectos que podem estar contidos no modelo, que podem ser implementados para serem concretizados no sistema de informao. No entanto, o modelo de processos definido antes de ser concretizado no SI est sempre dependente da opinio do cliente, que podeterideiasfixasparaonegcioesimplesmenteignorarboasprticassugeridaspelaBIM. Outro ponto relevante da metodologia a utilizao de modelos de referncia de processos. No caso de demonstrao deste documento apresentado e utilizado como modelo genrico o modelo UBKRM. Podiam no entanto ser utilizados como modelo genrico qualqueroutromodeloderefernciacomooSCOR,DCOR,ITILoueTOM. Juntamente com a seleco de aspectos organizacionais que forneam qualidade aos processos, como por exemplo o EFQM, obtido um modelo de processos de negcio que proporcione organizao a execuo de boasprticas que iro trazer valor acrescentado paraoseunegcio. A utilizao destes modelos genricos como base para posteriores transformaes garante que o modelo final, implementado em software ou no, alm de utilizar modelos de referncia, serve como um template, em que no necessrio modelar processos a partir do zero cada vez que se inicia um projecto. Neste documento s foi utilizado um modelo de referncia, mas podese perfeitamente construir um repositrio de modelos de referncia, bem como uma srie de outros aspectos organizacionais, de modo a proporcionar poupana detrabalhonoinciodecadaprojecto.
86
Nas segunda e terceira fases da BIM mostrase uma forma de realizar transformaes pontuaisaomodelodeprocessosgenrico,deformaautomatizada,paraqueestesrespondam aos requisitos da estratgia de sistemas de informao do cliente. Pretendese que os processos de negcio, alm de proporcionar boasprticas organizacionais, reflictam a viso e aestratgiadoclienteparaonegcio. DadoqueaindanoexistiremcomponentesprpriosparatratardadosparaERPs(SAP ououtroqualquer)nemparaBasesdeDados,foipropostoqueasligaesparaessessistemas fossem realizadas atravs de Web Services. Assim, o servio seria executado num CXF Service Engine e a ligao do servio ao sistema externo seria efectuado utilizando um CXF Binding Component. Posteriormente definio de um SE e um BC para tratar os dados para o ERP, e outra definio semelhante para a Base de Dados, propsse que os restantes componentes seriam um BPEL SE para orquestrar o processo e um CXF BC que efectue a ligao do cliente com o ESB. Dada esta arquitectura do ESB e os seis componentes definidos, foi proposto um mapeamento entre um processo definido apenas num nvel abstracto um PIM e um exemplo de um processo concebido base de Web Services o PSM. Tal como representado natabela8,propsseummapeamentoquedescrevearelaoentreumBPELeosSEseBCs propostosparaexecutaroprocessonoESB. A criao dos Service Units e do Service Assembly no representa o aspecto relevante no que toca transformao para o modelo final PSM, tal apenas se aplica aos componentes Service Engines e Binding Component. Como foi demonstrado, aps a anlise plataforma, mapeamento e marcao, a tarefa de transformao praticamente directa. As trs tarefas antecedentes so realmente as mais trabalhosas, pois representam o grosso da actividade globaldetransformaodosmodelos.Noentanto,aformacomoastarefassoautomatizadas permite que a probabilidade de ocorrncia de erros na transformao seja reduzida. A necessidade de criar Service Units e Service Assembly representada no documento como a implementao do modelo PSM num sistema de software ESB, que o passo seguinte para obteromodelocompletoimplementadoemsoftware.Noumadescriopormenorizadada implementao do ESB para no cair no erro de realizar uma descrio muito extensa, complexa e de difcil interpretao. Apenas a maneira como os dados so tratados, desde os quesoprovenientesdomodeloPIM,quepassampelatransformao,atestarememService Engines, Binding Components, Service Units e Service Assemblies, representada no documento.
87
5.Concluso
5.1
TrabalhoFuturo
A linguagem escolhida para modelar os processos neste trabalho foi o BPEL. Foi
representado no BPEL que o processo foi sendo transformado e possua um determinado estado consoante a fase da BIM. Uma limitao encontrada que o BPEL permite apenas modelar processos totalmente automticos, i.e., processos de negcio em que ao nvel computacional que se desenrola toda a actividade. Conhecendo a realidade organizacional, verificase que muitos dos processos, e at alguns dos mais importantes, no so totalmente automticos, no sentido em que necessitam de interveno humana de modo a seguirem o seu fluxo normal. Uma norma recente, e com muito pouco suporte de ferramentas, o BPEL4People (B4P) [Oasis 2007]. O B4P permite representar actividades humanas num processo BPEL juntamente com as actividades j presentes no WSBPEL. Seria interessante verificar se o B4P tambm suporta transformaes em diversos estados da BIM, bem como a implementaodosprocessosnumESB. Durante a escolha das linguagens, foi verificado que existem conceitos para avaliar
competnciasdeprogramadoresnoquetocaadesenvolversoftware,taiscomooPSP,TSPeo SWEBoK. No existem no entanto diferenciaes no que toca a conceber processos de negcio.Seriaumtrabalhointeressante,dadoque nemtodooconhecimentoemBPMigual, poismuitosconceitosdediferentesreassoabrangidos,comotecnologias,gestoesistemas deinformao,eassimalgunsnveisdematuridadepodemserdefinidos. comum num ambiente organizacional que os processos de negcio sejam
automticos ao mximo, com o objectivo de melhorar nveis de eficcia dos seus processos. Foram apresentados neste documento exemplos de processos de negcio cuja execuo baseadanautilizaode WebServices.AintroduodesemnticanosWebServices (Semantic Web Services) [McIlraith, Son et al. 2001] permitiria aumentar a execuo automtica dos processos ao nvel computacional, pois estes seriam interpretveis uns para os outros. Consiste em agregar aos Web Services metadados sobre as propriedades, capacidades, interfaces, prrequisitos e consequncias de uso desses servios, codificados de forma que possam ser interpretados pela mquina. com este objectivo que surge a DARPA Agent Markup Language for Services (DAMLS) [Martin 2002]. A DAMLS baseada em marcaes (markups) que permitiro que uma aplicao Web saiba qual o input necessrio para que posteriormente outra aplicao Web (potencialmente um Web Service) possa fornecer o servio, que informao ser retornada em seguida e como executar e interagir automaticamentecomessainformao.
88
A BIM independente de notaes ou aplicaes, pelo que utilizar notao BPEL ou BPMN em algumas fases, por exemplo, na fase de Implementao, suportado pela metodologia.Noentanto,utilizarconceitosdeDAMLSbemcomodeWebOntologyLanguage for Services (OWLS) [W3C 2004] para descrever processos de negcio implicaria algumas alteraes no comportamento destes, pois DAMLS e OWLS so diferentes de BPEL e WSDL. Utilizando os conceitos de semntica, a arquitectura de Web Services iria sofrer profunda remodelao.JexistemcasosdeimplementaoB2B,emgrelha,ubquose mveis,maseste um conceito cuja implementao em ambientes organizacionais tem ainda um caminho longo a percorrer. Dadas as diferenas no paradigma do BPEL e do DAMLS, difcil depreender se a utilizao do MDA para obter um modelo implementado em software pode ser realizada da mesma forma como foi apresentada neste trabalho. Da que utilizar estes conceitos de Web Services semnticos poder, ou no, originar trabalhos bem diferentes do trabalhoaquiapresentado.
89
5.Concluso
90
Bibliografia
Aalst,W.M.P.v.d.(2003)."PatternsandXPDL:ACriticalEvaluationoftheXMLProcess DefinitionLanguage."QUTTechnicalreportFITTR200306. Aalst,W.M.P.v.d.,L.Aldred,etal.(2004).DesignandimplementationoftheYAWLsystem. 16thInternationalConferenceonAdvancedInformationSystemsEngineering(CAiSE 04),Riga,Latvia,SpringVerlag. Aalst,W.M.P.v.d.,M.Dumas,etal.(2006).FromBPMNProcessModelstoBPELWeb Services.IEEEInternationalConferenceonWebServices(ICWS'06).I.C.Society. Aalst,W.M.P.v.d.,M.Dumas,etal.(2002)."PatternBasedAnalysisofBPML(andWSCI)."FIT TechnicalReportFITTR200205. Aalst,W.M.P.v.d.eA.H.M.t.Hofstede(2002)."YAWL:YetAnotherWorkflowLanguage." QUTTechnicalreport Aalst,W.M.P.v.d.,A.H.M.t.Hofstede,etal.(2003)."WorkflowPatterns"Distributedand ParallelDatabases14. Abran,A.,P.Bourque,etal.(2004).GuidetotheSoftwareEngineeringBodyofKnowledge SWEBOK,IEEEPress. Andrew,K.R.(1987).TheConceptofCorporateStrategy.Irwin,Homewood,IL. Apache."ApacheSoftwareFoundation."fromhttp://www.apache.org/. Arkin,A.(2002)."BusinessProcessModelingLanguage."BPMI.org. Armstrong,E.,J.Ball,etal.(2004).theJ2EE1.4Tutorial,AddisonWesley. Atkinson,C.eT.Khne(2003)."ModelDrivenDevelopment:AMetamodelingFoundation." Software,IEEE.
91
Bibliografia
Bauer,B.,J.P.Muller,etal.(2004).AModelDrivenApproachtoDesigningCrossEnterprise BusinessProcesses. Berndtsson,M.,J.Hansson,etal.(2007).ThesisProjects:AGuideforStudentsinComputer ScienceandInformationSystems,SpringerVerlagNewYork,Inc. Bzivin,J.(2004)."InSearchofaBasicPrincipleforModelDrivenEngineering."UpgradeVol.5 No.2. Bzivin,J.,G.Dup,etal.(2003).FirstexperimentswiththeATLmodeltransformation language:TransformingXSLTintoXQuery.2ndOOPSLAWorkshoponGenerative TechniquesinthecontextofMDA,Anaheim,CA,USA. Bzivin,J.,S.Hammoudi,etal.(2004).ApplyingMDAApproachtoB2BApplications:ARoad Map.WorkshoponModelDrivenDevelopment(WMDD2004)atECOOP2004, SpringerVerlag. BPEL2Java."BPELtoJava(B2J)Subproject."fromhttp://www.eclipse.org/stp/b2j/. BPMI(2001).ReleaseofBPMLSpecificationPavesWayforImplementations.BMPI.org. BPMI.org"BusinessProcessManagementInitiative."http://www.bpmi.org. Bragana,A.eR.J.Machado(2008).TransformationPatternsforMultistagedModelDriven SoftwareDevelopment.12thInternationalSoftwareProductLineConference. CMMI(2006).CMMIforDevelopment,Version1.2,SoftwareEngineeringInstitute(SEI). Coelho,J.S.(2005).ArquitecturadaEmpresaCentradanosProcessos:OFactorDeterminante paraoAlinhamentoEstratgicodosSI.SistemasdeInformaoOrganizacionais.L. Amaral,R.Magalhes,C.C.Morais,A.SerranoeC.Zorrinho,EdiesSlabo. Couloris,G.,J.Dollimore,etal.(2001).DistributedSystems:ConceptsandDesign,Addison Wesley.
92
http://wiki.daimi.au.dk/cpntools/cpntools.wiki.
CPNGroup."CPNTools:ComputerToolforColouredPetriNets."from
Curbera,F.,Y.Goland,etal.(2005).BPEL4WSVersion1.0specification,IBMCorporation. Deursen,A.v.,P.Klint,etal.(2000)."Domainspecificlanguages:anannotatedbibliography." ACMSIGPLANNotices35:2636. Duarte,F.J.,J.M.Fernandes,etal.(2006).BusinessModelinginProcessOriented OrganizationsforRUPbasedSoftwareDevelopment.ReferenceModelingforBusiness SystemsAnalysis Duarte,F.J.,R.J.Machado,etal.(2007).AutomatedInformationSystemsGenerationfor ProcessOrientedOrganizations.QUATIC'07:Proceedingsofthe6thInternational ConferenceonQualityofInformationandCommunicationsTechnology,IEEE ComputerSociety. Duarte,F.J.,R.J.Machado,etal.(2009).AMethodologytoTransformBusinessProcessesinto SoftwareSystems,SubmittedtoPublicationtoInternationalJournalofBusiness ProcessIntegrationandManagement,SpecialissueonDynamicandDeclarative BusinessProcesses. EFQM(2001).EFQMExcellenceModelLargeCompanies,OperationalandBusinessUnits version. Fernandes,J.M.,R.J.Machado,etal.(2006).ADemonstrationCaseontheTransformationof SoftwareArchitecturesforServiceSpecification.Proceedingsofthe5thIFIPWorking ConferenceonDistributedandParallelEmbeddedSystemsDIPES2006,Braga, Portugal. Fernandez,A.(2005)LessentielduTableaudeBord.ditionsdOrganisation.Paris. Gasevic,D.,D.Djuric,etal.(2006).ModelDrivenArchitectureandOntologyDevelopment.
93
Bibliografia
SoftwareSymposium.
Genender,J.(2007).BuildingaServiceOrientedArchitecturewithServiceMixGreaterQuebec
Guelfi,N.eA.Mammar(2006).AformalframeworktogenerateXPDLspecificationsfromUML activitydiagrams.SAC'06:Proceedingsofthe2006ACMsymposiumonApplied computing,ACM. Hammer,M.(1990)"ReengineeringWork:Don'tAutomate,Obliterate"HarvardBusiness Review. Hapner,M.,R.Burridge,etal.(2002).JavaMessageService,SunMicrosystems,Inc. Harmon,P.(2004)."XMLBPLanguages:AnUpdate."BusinessProcessTrendsVolume2, Number4. Helki,P.,A.Seppl,etal.(2006).EvaluationofIntalioBPMToolT86.5161SpecialCoursein InformationSystemIntegration. Hohpe,G.eB.Woolf(2004).EnterpriseIntegrationPatterns:Designing,Building,and DeployingMessagingSolutions,AddisonWesley. Humphrey,W.S.(1994).ThePersonalProcessinSoftwareEngineering.ThirdInternational ConferenceontheSoftwareProcess. Humphrey,W.S.(1999).IntroductiontotheTeamSoftwareProcess,SoftwareEngineering Institute(SEI). ifSMF(2007).AnIntroductoryOverviewofITILV3. Jensen,K.(1992).ColouredPetriNets:BasicConcepts,AnalysisMethodsandPracticalUse, Springer. Jeston,J.eJ.Nelis(2006).BusinessProcessManagement:PracticalGuidelinestoSuccessful Implementations.ElvesierLtd.
94

Framework,WroxPressLtd.
Johnson,R.,J.Hoeller,etal.(2005).ProfessionalJavaDevelopmentwiththeSpring
Junior,P.K.(2005)."Shark:umenginedeworkflowestensvelbaseadonaespecificao WfMC." Jnior,P.S.S.,J.P.A.Almeida,etal.(2008).ConstruodeumMetamodeloparaoARIS Method:Escavao,RefatoraoeAnlise.ThirdWorkshoponOntologiesand MetamodelinginSoftwareandDataEngineeringWOMSDE2008. Kaplan,R.eD.Norton(1996).LinkingtheBalancedScorecardtostrategy. Karjalainen,S.(2004).BusinessProcessModellingLanguageReport.ComputerScience. Helsinki,FacultyofScienceDepartmentofComputerScienceUniversityofHelsinki. Kloppmann,M.,D.Knig,etal.(2004)."BusinessprocesschoreographyinWebSphere."IBM SystemsJournal2. Koehler,J.,R.Hauser,etal.(2005)."Declarativetechniquesformodeldrivenbusinessprocess integration."IBMSystemsJournal44:4765. Lee,J.,K.Siau,etal.(2003)."EnterpriseintegrationwithERPandEAI."Commun.ACM46:54 60. Lezoche,M.,M.Missikoff,etal.(2008).BusinessProcessEvolution:aRulebasedApproach. 9thWorkshoponBusinessProcessModeling,Development,andSupport(BPMDS'08). Machado,R.J.,J.M.Fernandes,etal.(2005).TransformationofUMLModelsforService OrientedSoftwareArchitectures.Proceedingsofthe12thIEEEInternational ConferenceandWorkshopsontheEngineeringofComputerBasedSystems(ECBS05). Machado,R.J.,J.M.Fernandes,etal.(2006).RefinementofSoftwareArchitecturesby RecursiveModelTransformations.PROFES2006:proceedingsoftheInternational ConferenceonProductFocusedSoftwareProcessImprovement.
95
Bibliografia
AUtilizaodeBPELeYAWL."
Maldaner,L.A.eE.S.Pasqual(2006)."UmaAnlisedeLinguagensdeComposiodeServios:
Martin,D.(2002).DAMLS:BringingServicestotheSemanticWeb,DAMLSCoalition. Martins,V.M.M.(2005).Integraodesistemasdeinformao:perspectivas,normase abordagens.EscoladeEngenharia.Guimaraes,UniversidadedoMinho. Maven."ApacheMaven."fromhttp://maven.apache.org. McIlraith,S.A.,T.C.Son,etal.(2001)."SemanticWebServices."IeeeIntelligentSystems16: 4653. Mendling,J.,M.Moser,etal.(2006).TransformationofyEPCbusinessprocessmodelsto YAWL.Proceedingsofthe2006ACMsymposiumonAppliedcomputing,Dijon,France. MichalewiczZ.,M.Schmidt,etal.(2006).AdaptiveBusinessIntelligence.Springer. Milner,R.,J.Parrow,etal.(1989)."ACalculusofMobileProcesses,PartI."IandII.Information andComputation100. Mitre(2004).Guidetothe(Evolving)EnterpriseArchitectureBodyofKnowledge(EABoK). MITRECorporation. Mulyar,N.A.(2005).PatternbasedEvaluationofOracleBPEL(v.10.1.2). Nttgens,M.,T.Feld,etal.(1998).BusinessProcessModelingwithEPCandUML: TransformationorIntegration?TheUnifiedModelingLanguageTechnicalAspects andApplications.Heidelberg. Oasis(2007).WebServicesBusinessProcessExecutionLanguage2.0(WSBPEL). Oasis(2007).WSBPELExtensionforPeople(BPEL4People)Version1.0. ODE."ApacheODE."fromhttp://ode.apache.org.
96
RequirementsValidation.DepartamentodeSistemasdeInformao.Guimares, EscoladeEngenhariaUniversidadedoMinho.DissertaodeMestrado.
Oliveira,S.A.R.d.(2006).ColoredPetriNetsintheAnimationofUMLModelsfor
OMG."TheObjectManagementGroup."fromhttp://www.omg.org/. OMG(2003).MDAGuideVersion1.0.1,ObjectManagementGroup. OMG(2005).MOFQVTFinalAdoptedSpecification,ObjectManagementGroup. OMG(2006)."MetaObjectFacility(MOF)CoreSpecificationVersion2.0."OMG. OMG(2006).ObjectConstraintLanguage(OCL)OMGAvailableSpecificationVersion2.0, ObjectManagementGroup. OMG(2009).OMGUnifiedModelingLanguage(OMGUML),Infrastructureversion2.2,Object ManagementGroup. OMG(2009).OMGUnifiedModelingLanguage(OMGUML),Superstructureversion2.2,Object ManagementGroup. Pastor,O.eJ.C.Molina(2007).ModelDrivenArchitectureinPracticeASoftwareProduction EnvironmentBasedonConceptualModeling. Pearlson,K.E.eC.S.Saunders(2004).ManagingandUsingInformationSystems:AStrategic Approach,JohnWiley&Sons,Inc. Petri,C.A.(1962).KommunikationmitAutomaten.Bonn,InstitutefurInstrumentelle Mathematik.PhDThesis. PomeroyHuff,M.,J.L.Mullaney,etal.(2005).ThePersonalSoftwareProcess(PSP)Bodyof Knowledge,Version1.0.S.R.CMU/SEI2005SR003,SoftwareEngineeringInstitute (SEI).
97
Bibliografia
Competitors.FreePress.
Porter,M.(1980).CompetitiveStrategy:TechniquesforAnalyzingIndustriesand
Rademakers,T.eJ.Dirksen(2008).OpenSourceESBsinAction,ManningPublications. Reiter,T.,E.Kapsammer,etal.(2006)."AGeneratorFrameworkforDomainSpecificModel TransformationLanguages."ICEIS. Rodriguez,A.,E.FernandezMedina,etal.(2007)."TowardsCIMtoPIMTransformation:From SecureBusinessProcessesDefinedinBPMNtoUseCases."BPM. Rungworawut,W.eT.Senivongse(2006).UsingOntologySearchintheDesignofClass DiagramfromBusinessProcessModel.TransactionsonEngineering,Computingand Technology. Sandoe,K.,G.Corbitt,etal.(2001).EnterpriseIntegration,NewYork. Santos,M.Y.eRamos,I.(2009).BusinessIntelligenceTecnologiasdeInformaonaGesto deConhecimento.FCAEditoradeInformtica. SCC(2006).Dcoroverviewdesignchainoperationsreferencemodel1.0,SupplyChain Council SCC(2008).Scoroverviewsupplychainoperationsreferencemodel9.0,SupplyChainCouncil Schuessler,T.(2001).ApplicationsWiththeSapJavaConnector(JCO),AraSoft. ServiceMix."ApacheServiceMix."fromhttp://servicemix.apache.org. SEI.SoftwareEngineeringInstitute|CarnegieMellon.http://www.sei.cmu.edu/ Silver,B.(2009)."ModelPortabilityinBPMN2.0"BPMSWatch:BruceSilversBlogonBusiness ProcessManagementRetrieved23/03/09,from http://www.brsilver.com/wordpress/2009/03/04/modelportabilityinbpmn202/.
98

Press.
Smith,H.eP.Fingar(2002).BusinessProcessManagementTheThirdWave,MeghanKiffer
Sun."JavaDatabaseConnectivity(JDBC)."from http://java.sun.com/javase/technologies/database. Takecian,P.L.(2008).ACPeLOTOS:umestudocomparativobaseadoemconceitosdeBPELe padresdecontroledefluxo.InstitutodeMatemticaeEstatstica.SoPaulo, UniversidadedeSoPaulo.DissertaodeMestrado. TenHove,R.eP.Walker(2005).JavaBusinessIntegration(JBI)1.0,SunMicrosystems,Inc. TMForum."BusinessProcessFrameworkeTOM."from http://www.tmforum.org/BusinessProcessFramework/1647/home.html. Vanhatalo,J.(2006).BPELRepositoryUserGuide,IBMCorporation. W3C."XMLSchema."fromhttp://www.w3.org/XML/Schema. W3C.(1999)."XMLPathLanguage(XPath)Version1.0."fromhttp://www.w3.org/TR/xpath. W3C.(2004)."OWLS:SemanticMarkupforWebServices."from http://www.w3.org/Submission/OWLS. W3C.(2007)."SOAPVersion1.2."fromhttp://www.w3.org/TR/soap12/. W3C.(2007)."WebServicesDescpritionLanguage(WSDL)version2.0."from http://www.w3.org/TR/wsdl20. WfMC(2008).WorkflowManagementCoalition:FinalXPDL2.1Specification.WFMCTC1025 Oct1008A. WfMC.org"WorkflowManagementCoalition."http://www.wfmc.org. White,S.A.(2004)."BusinessProcessModelingNotation(BPMN)Version1.0."
99
Bibliografia
YAWLSystem."YAWLYetAnotherWorkflowLanguage."http://www.yawlsystem.com/
Zhao,W.,R.Hauser,etal.(2006)."Compilingbusinessprocesses:untanglingunstructured loopsinirreducibleflowgraphs."Int.J.WebGridServ.2:6891.
100
AnexoADraftdeumArtigoCientficoRelacionadocoma Dissertao
Transcriodaversodraftdoartigoaserfuturamentesubmetidoaconferncia.
101
Anexos
UsingMDATransformationsinOrdertoObtain InformationSystems
NunoSantos
RicardoMachado1
rmac@dsi.uminho.pt
FranciscoDuarte1,2
francisco.duarte@pt.bosch.com francisco.duarte@dsi.uminho.pt
pg13315@alunos.uminho.pt
1
Dept.deSistemasdeInformao,UniversidadedoMinho,Guimares 2 BoschCarMultimediaPortugal,Lda.,Braga largely implemented by companies. Abstract Since organizations already possess information systems BPMoriented, In the development of an clients requirements are based in Information System, the definition of business processes with maximum level of business processes, therefore the automation allows processoriented modelstouseinsoftwaredevelopment organizations to be able to fulfil clients that fulfil those requirements must be requirements in less time. In order to businessprocessoriented[2][3]. ensure quality in the business processes In organizational environments definition,amethodologywithwelldefined the time spent in the business process tasks should be followed. A proposed definitions in order to fulfilling clients methodology, the Business Implementation requirements must be smaller and Methodology (BIM), defines automated smaller, as well as the associated costs. transformations of business processes in a Integrating enterprise applications and way that software implementation in not just those in short time and costs organizations information system are less effort consuming. Like BIM, this paper isnt an easy task, due to the proposes the use of OMGs ModelDriven heterogeneityoftheapplications. Architecture (MDA) for obtaining the The methodology used in this Information System. The transformation of article, the Business Implementation a process framework that is a Platform Methodology (BIM) [4], has as its core Independent Model (PIM) to a Platform the usage of process reference models Specific Model (PSM) will allow obtaining to provide best practices in the software implementation. This paper business section and the proposes an automated transformation of implementation of software systems a business process model in a software that ensures fulfilment of clients executing model, by suggesting mapping business process requirements. The between a BPEL process and a set of JBI components who will execute in an core motivation of this article arises EnterpriseServiceBus(ESB). from the last one. To implement the business process model in software a Keywords:BPM;InformationSystem; modeldriven approach may be gainful BusinessImplementationMethodology; in terms of time spent and complexity. MDATransformation;PIM;PSM;ESB. Usage of the ModelDriven Architecture (MDA) [5] suggests the 1. Introduction design of two models. The Platform The concept of Business Process Independent Model (PIM) represents Management (BPM) [1] is already 102
the business process model, and the Platform Specific Model (PSM) the execution in software of the previous model[6].Itonlyleftstoknowif,afterthe
business model is defined correctly, softwareobtainingfromMDAconceptswill allowhighlyautomatedtasks. Forthatmanner,itisexperimented the business process transformations using PIM and PSM concepts from MDA. This is an important step in business implementation because it results in an effective development of software, besides the efficiency provided from BIM. To have thebusinessprocessexecutinginsoftware, it will be implemented in an Enterprise Service Bus (ESB), the Apache
Language) method, as in [10] which makes the same transformation using ATL (ATLAS Transformation Language) [11], or else [12] which transforms the model using OCL (Object Constraint Language) [13] rules. Another kind of approach is the one made by [14] e [15], which starts to design a CIM business process model in EPC [16], transforms the CIM in a PIM business process model in BPMN [17] and finally obtains the PSM business process model in BPEL [31]. Another different approach is presented in [18] and [19], which makes transformation of a CIM in BPMN in a PIM in UML, respectively UseCaseandClassDiagrams. One methodology for business implementation is mLEARN [22]. mLEARN is known by organizational competencies methodology, which provides techniques for providing business process representations, straightalignedwiththestrategicgoals. It also clarifies the responsibilities inside the organization. In order to add software implementation to business processes, techniques like 4Step Rule Set (4SRS) [23] or the MOF QVT [24] standard from OMG can be used. 4SRS is a technique for transforming user requirements in architectural models that represent system requirements. QTV allows relations between models, basedintransformationrules. The Spring architecture [25] provides a platform for executing business processes. It is constituted by three layers: handling user interface (e.g. Web Browsers or EJB), implementing business rules and entities (e.g. Application Server), and persistentdata(e.g.DatabaseServer). In the scope of enterprise application integration, [26] defines a set of Enterprise Integration Patterns, where requirements to obey 103
ServiceMix [8]. Maximizing the automated level of the business process implementation ensures a safe andefficientimplementation,providing a minimum amount of errors during all phases of an implementation project, which in turn will result in a reduction oftimeandresourcesforthecompany. Chapter 2 introduces related work to this article. Chapter 3 contains the core concepts which this work was based on, namely BIM, MDA and ESB. In chapter 4 it is established a relation between the 4 states that business processes are defined in BIM and PIM and PSM states defined in MDA. In chapter 5 MDA transformations are applied to the PIM obtained after the third phase of BIM. In chapter 6 the PSM is presented, correctly implemented in an ESB software system. Finally, in chapter 7, conclusions of the realized work are obtained, as well as a proposal for futurework.
2. RelatedWork
[9] transforms PIM business processes in UML2 Activity Diagrams [20] [21] into a PSM in BPEL [31] through REL (Regular Expression
Anexos
application integration are defined, as wellsometechniquesandsolutions. In order to implement application integration there are some open Enterprise Service Bus (open ESBs). Open ESBs bring gains due the facttheyareopensourceanduseopen standards. Some examples of most known tools are Mule, Apache ServiceMix, OpenESB, Apache Synapse, JBoss ESB, Apache Tuscany, Fuse ESB, OW2PEtALSandOpenAdapter[27].
methodology.Once the necessary requirements to complete each phase are defined, it is attributed a state to the process framework PF. The states defined in the methodology are Generic, Instantiated, Runnable and Software Implemented. To each state of the process framework corresponds oneoftheBIMphases. 3.2 PIMandPSM The starting point of MDA is the separation between systems operations specifications and description of how the system will use platform capabilities. So it will allow that: systems environment and requirements are specified (CIM), the system is specified independently from the platform that supports it (PIM), the platform is specified, a platform is chosen for the system and systems specifications are transformed into specificationsofaplatform(PSM). The PIM is a model where its specification doesnt alter from one platform to another. It has a level of platform independency in a way that the model may be executed in various platforms of different types. The model must be developed respecting classes from different platforms where the model may be implemented in the future. PSM results from the PIM transformation process so the PIM specifications are equal to the specifications of the platform. The PIM transformation process is made by combining PIM details with specific detailsoftheplatform(Figure2). Normally, model transformation is executed using mappings and transformations [28]. OMG also proposesmarking[5],asrepresentedin Figure 3. Marking is made by indicating
3. CoreConcepts
3.1 BusinessImplementation Methodology(BIM) BIM [4] is a methodology for implementing business process of an organization in software. This methodology proposes use of best practices in the business domain and allowscustomisationoftheprocessina way that enterprises needs are attended by the process in question. It is a flexible methodology, which allows various technologies independent from each other, as well as vendor independency. BIM is composed by four phases: Selection of adequate generic business processes; Definition of the processes to use; Concretisation of the business process in the organization information system which it will execute in; and Implementation in software of the various entities that composetheprocess(Figure1).
Figure1.The4phasesofBIM[4]
The particularity that defines which phase of the methodology the business process is presently is his framework state, in a way it responds to certain requirements of the 104
PIM elements that will be transformed intoPSM.
necessary information that can be translatedintocode. 3.3 ApacheServiceMix
Figure4.ApacheServiceMix[8]
Figure2.TransformationfromPIMtoPSM[5]
Figure3.ModelTransformation[5]
In mapping, relationship between PIM and PSM elements is made. For example, it is possible to create a mapping that shows relations between models classes and Java classes. Mappings must be based in necessary requirements to the coding language or to the model. It is possible to exist relations between one PIM element and several PSM elements, as well as a PSM element can be related with several PIM elements. Once mapping is done, transformation will resultincodegeneration,basedinPIM, PSMandtherealizedmapping,because it has all the information it needs to transform the model into code. So this last step is possible, it is required that the PSM element possesses the
The implemented ESB is Apache ServiceMix [8]. ServiceMix is an ESB solution accepted and used by respectable entities in the software developmentmarket,butitalsoisopen sourceandopenstandardbased,which brings benefits in its implementation, like low costs but also ensures quality. Its behaviour is based in Java Business Integration (JBI) [29]. JBI defines a framework that allows application integrationbasedinaddedcomponents that interoperate through a method of normalized messages exchange. This method of message exchange was adopted from WSDL 2.0 specifications Message Exchange Patterns (MEPs) [30]. MEPs define a set of message exchangetypes,beingpossibletobeIn Only, Robust InOnly, InOut and In OptionalOut. JBI defines two types of components: Service Engines (SE) and Binding Components (BC), as represented in Figure 4. SE provides business and processing logic, i.e., it is the component that processes a set of data in order to execute a service. BC provides communication with the exterior, working as a bridge between in and out data from (or to) theESBto(orfrom)theexterior.
105
Anexos
In order to deploy a component into ServiceMix, a Service Unit (SU) [27]
process is executed using software, so it needs to obey specifications of the technologicplatform.
that will provide component instantiation is used. The SU is a set of XML files whose content is transmitted to the component. Each SE or BC instantiation requires a SU which has the instantiated component definition. In order to a SU can be executed in the ESB, it is necessary the use of Service Assemblies (SA) [27]. SA is a collection of SUs. JBI components are unable to interpret SUs without these being inside a SA. A SA is constituted by at leastoneSU.
5. Transformationofthe modelintoPSM
4. RelationBetweenBIMand MDA
Analysing the characteristics of this methodology, it is possible to establishrelationshipbetweenBIMand MDA. The characteristics of a business process that are in the Generic, Instantiated and Runnable state are similar to the characteristics of a Platform Independent Model (PIM) from MDA, due to business process representations in these states dont include any platform dependency. During the first three BIM phases (Selection, Definition and Concretisation) the process doesnt require any kind of software, because until the end of the third phase it isnt yet decided if the process will execute insoftwareornot.Infact,BIMsuggests that, in the end of the Concretisation phase, a process is defined to be implemented in the next phase of the methodology, but also existing alternatives, and at least one of them that doesnt require software implementation, i.e., his final process frameworkbeobtainedintheRunnable state. The Software Implemented state corresponds to the Platform Specific Model (PSM), due to the fact that the 106
Figure5.RunnablePFofQuantityInsertion
In order to complete the BIM Concretisation phase it is necessary that the PF is correctly concretised in the Information System. Business process was designed in WSBPEL [31], as represented in Figure 5. This business process is in PIM and already possesses the characteristics described inBIMtobetransformedinPSM. Because the PF is in the Runnable state, it must be considered totheexecutionoftheprocessnotonly the BPEL code, but also its WSDL [30] code(Figure6). What matters to save from the WSDLcodearethedatareferringtothe service, the port, the port type, operations and in and out elements. The process is defined as a service provider as lancQuantService, with a port defined as LancQuantPort. The port type is defined as LancQuant.
The process operation corresponds in thiscasetothemainprocessandhasas in and out elements LancQuantRequest and LancQuantResponse,respectively.
with those functions, in this case, ERP SAP [16], and also due the fact that it ensures Java Database Connectivity (JDBC) [34]. For these last two, the execution of the Web Service is made through SEs, i.e., one SAP SE and one DB SE. it requires also a BPEL SE (in Apache it is called an Orchestration Director Engine ODE) [35], to execute the process workflow and orchestrate theservices(Figure7).
Figure6.WSDLRepresentationofQuantity Insertion
Platform Following the model proposed by OMG for MDA, in order to make the model transformation phase, it is necessary to describe the platform, following the mapping [28] and the marking of the elements that will be transformed. Only after that it is possible to execute the model transformation. In the framework four OBOs [4] can be identified: the clientsoftware, which gives the process initiate order to the process through its invocation; the BPEL, with the process orchestration role, which defines the ordertheserviceswillbeinvocated;the ERP [32], which executes the material consume instock; and a DataBase(DB), which executes the new product registry to shelf. Analysing the characteristics of the ServiceMix behaviour it is possible to identify the need of three Binding Components (BCs), in order to have connections to the ERP, the DB and the request and response to the client. A BC adequate to the task is one that interprets Web Services [33], due the characteristics of the SOAP protocol are more appropriated to send requests and responses to a client. In what concerns the connections to the ERP and the DB, this choice is based on the fact that it doesnt exist yet a Service Engine (SE)
Figura7.PlatformComponentsCreatedto ExecutetheProcess
Mapping The invoke activities pretend that a certain service send them a response to a certain request, therefore the corresponding ESB component with this characteristic is the Service Engine. So, mapping is direct. Invoke activities will invoke the respectiveOBO,i.e.,SAPinvocationis related with the SAP SE OBO, while BD invocation is related with BD SE OBO. Namespaces, as well as the service data from the WSDL code portType, service e port , correspond totheidentificationdataofthecreated SUs. The WSDL is, in fact, the file that circulates in the Normalized Message Router. For better understanding, the relations are shown and described in Table1. 107
Anexos
Table1.RelationsoftheMappingPIMPSM
PIMElements WSDLElementsfrom theRequesttype PSMElements Entryparametersofthe POJOclassoftheSU (CXFSEs) NameoftheWeb Service intheJAVAfilebelonging totheSU(CXFSEs) targetServiceoftheSU (CXFBCs) Nameoftheserviceof therespectivepartnerLink intheSU(BPELSEODE) targetInterfaceoftheSU (CXFBCs) targetEndpoint oftheSU (CXFBCs) Portnameoftheservice oftherespective partnerLinkintheSU (BPELSEODE) namespacesinthe xbean.xmlfilesand targetNamespaceinthe JAVAfileoftheSU (CXFSEs) namespacesoftheWSDL fileswhichare PartnerLinksintheBPEL file wsdloftheSU(CXFBC), generatedbytheCXFSE Entryparametersofthe clientWebService inputelementfromthe RequestoftheWSDL inputvariableofthe BPEL BPELinvokeactivity SAPSE GeneratedWSDLfilefrom theCXFSE BPELinvokeactivity BDSE GeneratedWSDLfilefrom theCXFSE Returnparametersofthe clientWebService outputelementfrom theResponseoftheWSDL outputvariableofthe BPEL
marked and, in the right side, it is the resulting PSM element of the transformation.
WSDLServicename (LancQuantService, SapServicee BdService)
WSDLPorttypeofthe service(LancQuant, SapeBd) WSDLPortnameofthe service(LancQuantPort, SapPorteBdPort)
BPELnamespacesofthe importedservices
BPELImportedWSDL files BPELinputvariable andWSDLRequest element BPELInvokeactivity SAP BPELWSDLfilewhichis SapPartnerLink BPELInvokeactivity BD BPELWSDLfilewhichis BdPartnerLink BPELoutputvariable andWSDLResponse element

Figure8.MappingBetweenthePIMandPSM Components
6. ThePSM
ServiceEngines The first step is to define SUs who, after being deployed in ServiceMix,willcreateSEs.Thewanted SE type is a CXF kind. Its important to refer once again that this choice is based on the fact that there doesnt exist yet a SE to ERP SAP functions. The behaviour of the SU is described in the xbean.xml file, generated from a Maven [36] archetype specific for ServiceMix. The definition of the SU as aSEcomponentismadeinthefirstline of the coding, where the namespace is defined (xmlns:cxfse=), while the rest of the code describes the necessary elements to the body of the SU. This file is quite simple because it
Marking Just as in mapping, marking is also a simple task, due to the low complexity of the process framework. The marking of the elements is made from the relationships identified in the mapping.InFigure8itispossibletosee a representation of the mapping and the marking, where, in the left side of the figure, the PIM elements are 108
just indicates the location of the POJO class (Plain Old Java Object) [25] which isrelevantfortheServiceEngine. In this case, it is the class SapService the CXF SE exposed Web Service refers to. The code part that precedes it refers to the groupId and artifactId. The SU also contains a Java [37] file, in this case SapService.java, which is the Web Service executed by the CXF SE. This Java file uses SAP Java Connector(JCo)[38]todotheinsertion and reception of data between the Web Service and the ERP SAP, obeying correctly the requirements of a connectionto an ERP. After building via Maven 2, the Java class SapService will create a new WSDL file, in this case renamed to SapArtifacts for a question of simplicity in the mapping due to the fact this is the name automatically given by the BPEL Design tool from Eclipse to WSDL files. This WSDL file will be the one who will be invoked in the future by the BPEL final file (described ahead). Inside that file, thechosennamespacewillbethesame asprovidedbythemapping. Just like in the CXF SE with a Web Service that executes the introduction of the values in SAP, the definition of the SU for the CXF for the DB is similar. The usage of a CXF SE is justified with the fact it supports JDBC connections. The main difference of this SU to the previous one is just the definition of the POJO class, which will refer to the BdService class, the Web ServiceexposedbytheCXFSE.Thisfile, BdService.java, will contain the cod for the JDBC connection so it is able communicate with the DataBase. Also in this case the WSDL file is generated afteraMaven2build.
BindingComponents It has already been explained how a SU that will originate one SE after being deployed in ServiceMix must be configured. The task to configure a SU that originates a BC is similar. Just like before, the type of componentisdefinedinthefirstlineof the code (xmlns:cfxbc=). In this case, the component is a CXF BC which will communicate data to the CXF SE, sending and receiving values of a Web Service. The element data that defines the BC must be filled with the data from the PIM BPEL and WSDL files as suggested by Table 1. Such will allow a correct identification of the component endpoints required by the ESB, which thencanroutecorrectlythedata. The PSM is completed with the BPEL representation. As shown in Figure 9, in terms of visual notation, it doesntsuffermodifications,duetothe fact that the mapping (SAP to SAP SE and BD to BD SE) doesnt requireanyadditionorremovalofBPEL activities. The business process in BPEL, so itcanbeinterpretedbyODE,requiresa XML file that describes connections to processPartnerLinkssotheprocesscan be executable after deploy. Contrarily to what happens with the rest of the SUs, in which the xbean.xml file defines its execution, the behaviour of ODE is configured by a deploy.xml file. After being correctly defined, the SU is ready to be implemented in the framework. When all SUs are created, theyarereadytobegroupedinaSA. As in for SUs, the task is completed. It was already described that, in order to ServiceMix being capable to interpret SUs, they must be contained in a SA. First step, SUs must be compiled, which each SU originates a compiled file. The definition of the 109
Anexos
SUs which the SA will contain is made inapom.xmlfileProjectObjectModel.
7. ConclusionsandFuture Work
In order to pass to the last phase of BIM this article proposes the use of ModelDriven Architecture to transformbusinessprocessmodelsinto software. MDA proposes the transformation is made by realizing tasks of platform description, mapping, marking and transforming. The first three are the ground for the final task of transforming the model. After realizing the first three tasks, all required data is collected and the softwareimplementationissimplified. The implementation of business process models in an Enterprise Service Bus arises as a proposal that allows an integration of the process and applications in a standard way. In the definition of the Service Engines and Binding Components the data is obtained effectively from the model transformation. A found limitation is that BPEL only allows designing fully automatic business processes, i.e., business processes where all activity is executed in the computing domain. By knowing enterprise reality, most of business processes, some of them core ones, arent fully automatic, in a way that they need human intervention for following their normal flow. A recent standard, and with very little tool support, is BPEL4People (B4P) [39]. B4P allows representation of human tasks in a BPEL process together with the knownactivitiesofWSBPEL.
Figure9.FinalProcessinBPEL
The POM file, generated by a Maven 2 archetype, contains the general information of the project, like name and location, as well as the identification of the components which will be used in the ESB. After being deployed in ServiceMix, the SUs contained in the SA will give place to JBI components (Figure 10). Given the
respectively xbean.xml file, each SU originates one SE or a BC. ServiceMix is capable of identifying, through the XBean files, what kind of component is definedintheSU. So, after deploy, ODE SU becomes ODE SE, CXFSE SU becomes CXFSEandCXFBCSUbecomesCXFBC.
References
[1] SmithH.andP.Fingar(2002).Business ProcessManagementTheThirdWave. MeghanKifferPress. [2] FernandesJ.M.andF.J.Duarte(2005).A ReferenceFrameworkforProcessOriented SoftwareDevelopmentOrganizations,
Figure10.PSMFinalModelinServiceMix
110

SoftwareandSystemsModeling(SoSyM), SpringerVerlag. [3] FernandesJ.M.andF.J.Duarte(2004). UsingRUPforProcessOriented Organisations.Bomarius,F.,Iida,H.(eds.), 5thInt.Conf.onProductFocusedSoftware ProcessImprovement(PROFES2004), LectureNotesinComputerScience3009, SpringerVerlag. [4] DuarteF.J.,R.J.MachadoandJ.M. Fernandes(2009).AMethodologyto TransformBusinessProcessesinto SoftwareSystems.Submittedto PublicationtoInternationalJournalof BusinessProcessIntegrationand Management,SpecialissueonDynamic andDeclarativeBusinessProcesses. [5] OMG(2003)."MDAGuideVersion1.0.1." ObjectManagementGroup. [6] DuarteF.J.,R.J.MachadoandJ.M. Fernandes(2007).AutomatedInformation SystemsGenerationforProcessOriented Organizations.SixthInternational ConferenceontheQualityofInformation andCommunicationsTechnology. [7] MartinsV.M.M.(2005).Integraode SistemasdeInformao:Perspectivas, normaseabordagens.Departamentode SistemasdeInformao.Guimares,Escola deEngenharia,UniversidadedoMinho. DissertaodeMestrado. [8] ApacheServiceMix. http://servicemix.apache.org/home.html [9] ZhaoW.,R.Hauser,K.Battacharya,B.R. BryantandF.Cao(2006).Compiling businessprocesses:untangling unstructuredloopsinirreducibleflow graphs.Int.J.WebandGridServices, Vol.2,No.1.InderscienceEnterprisesLtd. [10] BezivinJ.,S.Hammoudi,D.LopesandF. Jouault(2004).ApplyingMDAApproach toB2BApplications:ARoadMap. WorkshoponModelDrivenDevelopment (WMDD2004),ECOOP2004,Oslo,Norway. [11] BezivinJ.,G.Dup,F.Jouault,G.Pitette andJ.E.Rougui(2003).Firstexperiments withtheATLmodeltransformation language:TransformingXSLTintoXQuery. 2ndOOPSLAWorkshoponGenerative TechniquesinthecontextofMDA, Anaheim,CA,USA. [12] KoehlerJ.,R.Hauser,S.SendallandM. Wahler(2005).Declarativetechniquesfor modeldrivenbusinessprocess integration.IBMSystemsJournal,Vol.44, No.1.
[13] OMG(2006).ObjectConstraintLanguage. OMGAvailableSpecificationVersion2.0. ObjectMaganementGroup. [14] B.Bauer,J.P.MllerandS.Roser(2004). AModeldrivenApproachtoDesigning CrossEnterpriseBusinessProcesses. MIOSWorkshopinOTMConference, Springer. [15] LezocheM.,M.MissikoffandL.Tininini (2008).BusinessProcessEvolution:a RulebasedApproach.Proceedingsofthe 9thWorkshoponBusinessProcess Modeling,DevelopmentandSupport (BPMDS08),France. [16] Nttgens,M.,T.Feld,etal.(1998). BusinessProcessModelingwithEPCand UML:TransformationorIntegration?.The UnifiedModelingLanguageTechnical AspectsandApplications.Heidelberg. [17] WhiteS.A.(2004).BusinessProcess ModelingNotation(BPMN):Business ProcessManagementInitiative. [18] RodrguezA.,E.FernndezMedinaandM. Piattini(2007).TowardsCIMtoPIM transformation:Fromsecurebusiness processesdefinedinBPMNtousecases. In:G.Alonso,P.Dadam,andM.Rosemann (2007).BusinessProcessManagement. Proceedingsof5thInternational Conference,BPM2007,Brisbane,Australia. LectureNotesinComputerScience. Springer. [19] RungworawutW.andT.Senivongse (2006).UsingOntologySearchinthe DesignofClassDiagramfromBusiness ProcessModel.ProceedingofWorld AcademyofScience,Engineeringand TechnologyVol.12. [20] OMG(2009).OMGUnifiedModeling Language(OMGUML)Infrastructure Version2.2.ObjectManagementGroup. [21] OMG(2009).OMGUnifiedModeling Language(OMGUML)Superstructure Version2.2.ObjectManagementGroup. [22] Coelho,J.(2005).SistemasdeInformao Organizacionais,EdiesSlabo,Lisboa. [23] Machado,R.J.,J.M.Fernandes,P. MonteiroandH.Rodrigues(2005). TransformationofUMLModelsfor ServiceOrientedSoftwareArchitectures. Proceedingsofthe12thIEEEInternational ConferenceandWorkshopsonthe EngineeringofComputerBasedSystems (ECBS05). [24] OMG(2005)."MOFQVTFinalAdopted Specification"OMG.
111
Anexos
[25] JohnsonR.,J.Hoeller,A.Arendsen,T. RisbergandC.Sampaleanu(2005). ProfessionalJavaTMDevelopmentusing theSpringFramework.WileyPublishing. [26] Hohpe,G.andB.Woolf(2004).Enterprise IntegrationPatterns.AddisonWesley. [27] RademakersT.andJ.Dirksen(2008). OpenSourceEBSsinAction.Manning Publication. [28] Pastor,O.andJ.C.Molina(2007).Model DrivenArchitectureinPracticeA SoftwareProductionEnvironmentBased onConceptualModeling.Springer. [29] TenHove,R.andP.Walker(2005),JavaTM BusinessIntegration(JBI)1.0.Sun Microsystems,Inc. http://jcp.org/aboutJava/communityproce ss/final/jsr208/index.html [30] W3C,WebServiceDescriptionLanguage (WSDL).http://www.w3.org/TR/wsdl
[31] OASIS(2007)."WebServicesBusiness ProcessExecutionLanguageVersion2.0". [32] Sandoe,K.,G.CorbittandR.Boykin(2001). EnterpriseIntegration.NewYork. [33] CoulorisG.,J.DollimoreandT.Kindberg (2001)."DistributedSystems:Conceptsand Design".AddisonWesley. [34] Sun,JavaDatabaseConnectivity(JDBC). http://java.sun.com/javase/technologies/d atabase [35] ApacheODE.http://ode.apache.org/ [36] ApacheMaven.http://maven.apache.org/ [37] Bodoff,S.,E.Amstrong,J.Ball,D.B.Carson, I.Evans,D.Green,K.HaaseandE.Jendock (2004).TheJ2EETMTutorial.Second Edition.AddisonWesley. [38] Schuessler,T.(2001).Developing applicationswiththeSAPjavaconnector (JCO).AraSoft.http://ARAsoft.de/ [39] OASIS(2007).WSBPELExtensionfor People(BPEL4People),Version1.0
112
AnexoBDefiniesdosPadresdeWorkflow
[Aalst,Hofstedeetal.2002]
Padresbsicosdecontrolodefluxo Padro1:Sequncia Definio. Srie ordenada de actividades, em que uma actividade habilitada para executar somenteapsaexecuodaactividadeanterior. Padro2:DivisoParalela Definio. Um ponto no processo em que uma linha de execuo nica dividida em duas ou mais linhas de execuo, de forma que duas ou mais actividades possam comear simultaneamente ou em qualquer ordem. Dessa forma, actividades podem ser executadas concorrentemente,emvezdeseriadas. Padro3:Sincronizao Definio.Umpontonoprocessoemquemltiplasactividadesparalelasconvergemparauma nica linha de execuo. Essas actividades so sincronizadas nesse ponto, pois todas elas precisamestarcompletasparaqueoprocessopossacontinuar. Padro4:EscolhaExclusiva Definio.Umpontonoprocessoemque,baseadoemumadecisointernaaosistemaounos dados de controlo do workflow, um de entre os diversos ramos escolhido. Assim, o caminho divideseemalternativasexclusivas. Padro5:JunoSimples Definio. Um ponto no processo em que dois ou mais ramos alternativos se juntam, sem ser necessria a sincronizao. Observao: assumese, nesse padro, que no ocorre execuo emparalelonosdiversoscaminhosalternativos.
113
Anexos
Padresavanadosderamificaoesincronizao Padro6:EscolhaMltipla Definio. Umpontonoprocessoemque,baseado emumadecisoounosdadosdecontrolo do workflow, um ou mais ramos so escolhidos. A diferena para a escolha exclusiva justamente a quantidade de caminhos que, neste padro, se pode escolher na hora da execuo(desdeumattodososcaminhos). Padro7:JunoSincronizada Definio.Umpontonoprocessoemquemltiplosramosconvergemparaumnicoramo.Se mais de um ramo estiver com actividades activas, preciso esperar o trmino de todas elas, sincronizandoas,paracontinuar.Seapenasumramoforescolhido,oprocessodeveconvergir semsincronizao. Padro8:JunoMltipla Definio. Um ponto no processo em que dois ou mais ramos convergem sem sincronizao. Semaisdeumramofoiescolhidoanteriormenteparaexecutar,aactividadeseguintejuno ser iniciada vrias vezes, com a chegada de cada uma das actividades provenientes dos diversosramos. Padro9:Discriminador Definio. Um ponto no processo que espera pelo trmino de um dos seus ramos de entrada antes de habilitar a actividade subsequente. A partir da, ele espera o fim da execuo dos outros ramos activos, ignorandoos. Depois disso, ele se reinicia. importante notar que, ao contrrio da juno mltipla, o nmero de vezes que a actividade subsequente executada nodependedonmeroderamosactivosdeentradadodiscriminador. Padresestruturais Padro10:CicloArbitrrio Definio. Um ponto no processo em que uma ou mais actividades (partes do processo) podem ser executadas repetidamente, formando um lao. Este padro permite laos no estruturados.Assim,olaopodetermaisdeumpontodeentradaoupontodesada.
114

Padro11:TerminaoImplcita
Definio. Uma instncia de um processo (ou subprocesso) deve ser finalizada quando no h maisnadaaserfeito,isto,quandojnohactividadesactivasno(sub)processo. Padresenvolvendomltiplasinstncias Padro12:MltiplasInstnciasSemSincronizao Definio. Ponto do processo em que, dentro do contexto de uma mesma instncia do processo, vrias instncias de uma actividade podem ser criadas por meio de novas linhas de execuo (threads), independentes umas das outras. No existe a necessidade de sincronizar essaslinhasdeexecuo.Acriaodessasinstnciasnodependederegras. Padro13:MltiplasInstnciasComConhecimentoPrvioemTempodeProjecto Definio. Um ponto do processo em que, dentro do contexto de uma mesma instncia do processo, uma actividade habilitada vrias vezes. O nmero de instncias de uma dada actividade em uma dada instncia de um processo previamente conhecido em tempo de projecto do processo. Aps o trmino de todas as instncias da actividade, uma outra actividadeficahabilitadaparaexecuo. Padro14:MltiplasInstnciasComConhecimentoPrvioemTempodeExecuo Definio. Um ponto do processo em que, dentro do contexto de uma mesma instncia do processo, uma actividade habilitada vrias vezes. O nmero de instncias dessa actividade pode variar dependendo da instncia do processo, podendo depender de caractersticas da instncia ou ainda da disponibilidade de recursos. Este nmero conhecido em algum momento em tempo de execuo, antes que as instncias dessa actividade sejam criadas. Aps o trmino de todas as instncias da actividade, uma outra actividade fica habilitada para execuo. Padro15:MltiplasInstnciasSemConhecimentoPrvioemTempodeExecuo Definio. Um ponto do processo em que, dentro do contexto de uma mesma instncia do processo, uma actividade habilitada vrias vezes. O nmero de instncias de uma dada actividadenoconhecidonemduranteoprojectodoprocesso(comonoPadro13)nemem tempo de execuo antes da criao das instncias (como no Padro 14). Mesmo enquanto algumas das instncias da actividade so executadas ou at mesmo depois de completadas,
115
Anexos
outraactividadeficahabilitadaparaexecuo. Padresbaseadosemestados Padro16:EscolhaemDiferido
outras instncias podem ser criadas. Aps o trmino de todas as instncias da actividade, uma
Definio. Um ponto no processo em que um entre vrios ramos escolhido. A escolha no feita baseada em dados existentes ou regras (como ocorre no padro Escolha Exclusiva), mas sim baseada em uma escolha oferecida ao ambiente. Apenas uma alternativa escolhida para execuo. Padro17:RoteamentoParaleloEntrelaado Definio. Conjunto de actividades que executado em uma ordem arbitrria. A ordem definida em tempo de execuo e, para uma mesma instncia de workflow, duas actividades no podem ser executadas no mesmo momento. Todas as actividades do conjunto sero executadas. Padro18:Marco Definio. Um ponto no processo em que a execuo de uma actividade depende de uma instncia de um processo estar em um estado especfico. A actividade habilitada somente se umcertomarcofoiatingido,masaindanotiverexpirado.Estepadroserexemplificadopor meiodedoiscasosdistintos,quereflectemdiferentessituaes. Padresdecancelamento Padro19:ActividadeCancelvel Definio. Ocorre quando uma actividade habilitada cancelada antes do comeo da sua execuo. Quando a actividade cancelada, necessrio remover a linha de execuo que controla a actividade. Caso a execuo da actividade j tenha comeado, ela cancelada e, quandopossvel,ainstnciaemexecuoparalisadaeremovida. Padro20:CasoCancelvel Definio. Ocorre quando uma instncia do processo completamente removida. Esta remoo inclui todas as actividades que esto executando no momento, aquelas que ainda poderiam ser executadas e todos os subprocessos. A instncia do processo armazenada comocompletadademodomalsucedido.
116
AnexoCQuestionrio
O presente questionrio tem como objectivo avaliar os conhecimentos de cada umnareadeBPMedemodelaodeprocessosdenegcio.Pretendoparatalchegar aumaconclusosobrealinguagemdemodelaodeprocessosmaisadequadaparao perfildoscolaboradoresdaempresa. As perguntas iro recair sobretudo no grau de familiarizao acerca de alguns conceitos. Em alguns casos, pretendese saber se est ou no est familiarizado com o conceito. Noutros, pretendese saber ser mais especfico, com o objectivo se estmuitooupoucofamiliarizado. Aidentificaonorelevanteparaainterpretaodosresultados. Obrigado!!!
117
Anexos
I. ConceitosBPM 1. Dos seguintes conceitos da temtica de BPM, indique os que conhece (definio de conhecer: saber o que so, o que fazem, para que servem no requer necessariamente j ter utilizado qualquer ferramenta de implementao dos conceitos). Assinale com um X a seguir ao nome (pode assinalar as opes que entender):
a. b. c. d. e. f. g. BPM(BusinessProcessManagement) BPMS(BusinessProcessManagementSystems) BAM(BusinessActivityMonitoring) EAI(EnterpriseApplicationIntegration) ERP(EnterpriseResourcePlanning) CRM(CustomerRelashionshipManagement) SCM(SupplyChainManagement) ___ ___ ___ ___ ___ ___ ___
2. Na Gesto da Qualidade dos processos de negcio, indique quais as estratgias que conhece. Assinale com um X a seguir ao nome (podeassinalarasopesqueentender):
a. b. c. d. e. TQM(TotalQualityManagement) SixSigma Kaizen(melhoriacontnua) BSC(BalancedScoreCard) Outra(s) Qual? ___ ___ ___ ___ ___
3. JparticipouemalgumprojectoBPM(reestruturao/melhoria, modelaoemonitorizaodosprocessosdenegciodeuma empresa)?AssinalecomumXumaopo: No: Sim:

118
4. Dos seguintes conceitos de projectos BPM, mesmo que tenha escolhidoNoem3.,indiqueosqueconhece(oqueso,paraque servem).AssinalecomumXaseguiraonome(podeassinalaras opesqueentender):
a. ObjectivosOperacionais(CurtoPrazo) b. Critriosdedesempenho c. ArquitecturadeProcessos: i. Processos1nvel(oumacroprocessos) ii. Subprocessos iii. Actividades iv. Tarefas v. Operaes d. Necessidadesdainformao(oqu) e. Requisitosdainformao(como) f. Sistemasaplicacionais ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
II. ConceitosdeLinguagensdeModelaodeProcessosdeNegcio 5. Sabeoquesodiagramasdeworkflow?(AssinalecomumXuma opo)Sim: No: 6. Indiqueoseugraudefamiliaridadeemrelaoaoperaes algbricasAND,OR,NAND,NOR,XOR:(AssinalecomumXuma opo)

a. b. c. d. Nopossuoconhecimentosacercadenenhumaoperao Conheoalgumasoperaes Conheotodasasoperaes Conheotodasasoperaes,massestouvontadeparaaplicar algumasdelas e. Conheotodasasoperaes,eseiperfeitamenteapliclastodas ___ ___ ___ ___ ___
7. Sabeoquesodiagramasemgrafos?(AssinalecomumXuma opo)Sim: No:

119
Anexos
8. Indiqueoseugraudefamiliaridadeemrelaomodelaode RedesdePetri:(AssinalecomumXumaopo)
a. b. c. d. e. Nopossuoconhecimentos Possuoconhecimentosmnimos Possuoconhecimentosmedianos Possuoconhecimentosbons Possuoconhecimentosmuitobons ___ ___ ___ ___ ___
9. ConheceatcnicadoClculode(pi)?(AssinalecomumXuma opo)Sim: No: 10.Indiqueoseugraudefamiliaridadeemrelaolinguagemde programaoXML:(AssinalecomumXumaopo)

a. b. c. d. Nopossuoconhecimentosacercadalinguagem SeiapenasqueumalinguagemdeprogramaoparaaWeb Possuoconhecimentosmedianosacercadasuaprogramao Estouperfeitamentevontadeparaprogramar ___ ___ ___ ___
11.Dasseguinteslinguagensdemodelao,indique,paracadauma,a opocorrectaquereflitaoseuconhecimentoquantomodelao dalinguagem:(AssinalecomumX)

UML2.0 CasosdeUso Actividades Estado BPMN EPC(ARIS) Nosei modelar Seimodelar Seimodelar Seimodelar Seimodelar pouco suficiente bem muitobem
120
12.Das seguintes linguagens (algumas de modelao, outras de coreografia, outras de execuo, etc.), indique as que conhece (o que so, o que fazem, para que servem). Assinale com um X a seguiraonome(podeassinalarasopesqueentender):
a. b. c. d. e. f.
g.
h. i. j. k. l. m. n. o. p. q. r. s. t. u.
BPDM(BusinessProcessDefinitionMetamodel) BPEL(WebServicesBusinessProcessExecutionLanguage) BPML(BusinessProcessModellingLanguage) BPMN(BusinessProcessModellingNotation) BPRI(BusinessProcessRuntimeInterface) BPSM(BusinessProcessSemanticModel) BPSS(BusinessProcessSchemaSpecification) BPQL(BusinessProcessQueryLanguage) BPXL(BusinessProcessExtensionLayer) CPN(ColoredPetriNets) EPC(EventdrivenProcessChain) UML2.0(UnifiedModellingLanguage2.0 WAPI(WorkflowAPI) WfXML(WorkflowXML) WSCDL(WebServicesChoreographyDescriptionLanguage) WSCI(WebServiceChoreographyInterface) WSCL(WebServicesConversationLanguage) WSFL(WebServicesFlowLanguage) XLANG(eXtensibleLanguage) XPDL(XMLProcessDefinitionLanguage) YAWL(YetAnotherWorkflowLanguage)
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
III. ConceitosSOA(ServiceOrientedArchitecture) 13.ConheceanormaSOA(ServiceOrientedArchitecture)?(Assinale No: comumXumaopo)Sim: 14.ClassificaosseusconhecimentosemWebServicescomo:(Assinale comumXumaopo)

a. b. c. d. e. Nopossuoconhecimentos Possuoconhecimentosmnimos Possuoconhecimentosmedianos Possuoconhecimentosbons Possuoconhecimentosmuitobons ___ ___ ___ ___ ___ 121
Anexos
15.Classificaosseusconhecimentosemconcorrncia(threading) como:(AssinalecomumXumaopo)
f. g. h. i. j. Nopossuoconhecimentos Possuoconhecimentosmnimos Possuoconhecimentosmedianos Possuoconhecimentosbons Possuoconhecimentosmuitobons ___ ___ ___ ___ ___
16.DosseguintesconceitosdanormaSOA,mesmoquetenhaescolhido noem14.,indiqueasqueconhece(oqueso,oquefazem,para que servem). Assinale com um X a seguir ao nome (pode assinalarasopesqueentender):
a. b. c. d. e. f.
g.
h. i. j. k. l.
m. n.
o. p.
B2B(BusinesstoBusiness) B2C(BusinesstoConsumer) B2E(BusinesstoEmployee) B2G(BusinesstoGovernment) CORBA(CommonObjectRequestBrokerArchitecture) EDI(ElectronicDataInterchange) ESB(EnterpriseServiceBus) FTP(FileTransferProtocol) HTTP(HiperTextTransferProtocol) RPC(RemoteProcedureCall) SMTP(SimpleMailTransferProtocol) SOAP(SimpleObjectAccessProtocol) SOMF(ServiceOrientedModellingFramework) UDDI(UniversalDescription,DiscoveryandIntegration) WebServices WSDL(WebServicesDescriptionLanguage)
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
Obrigado!
122
AnexoDTabeladerespostas
Questo 1 a. b. c. d. e. f. g. 2 a. b. c. d. e. 3 4 a. b. c. i. ii. iii. iv. v. d. e. f. 5 6 7 8 9 10 11 UMLCU UMLA UMLE BPMN EPC 12 a. b. c. d. e. f. g. h. i. Q1 X X X X X X X X X X X No X X X X X X X X X X Sim e. Sim b. No b. d. d. c. c. c. X X X X Q2 X X X X X X X X X Sim X X X X X X X X X X Sim e. Sim b. No c. e. e. e. a. c. X Q3 X X X X X X X No X X X X X X X No d. Sim b. No c. d. d. d. a. b. Q4 X X No X X X Sim e. Sim a. No d. e. e. e. a. a. Q5 X Sim X Sim e. Sim b. No c. d. d. d. a. a. Q6 X X X X X X X X Sim X X X X X X X Sim e. Sim d. Sim d. d. d. d. a. b. X X Q7 X X X X X No Sim d. Sim b. No c. c. c. c. Q8 X X X X X X No X X X X X X X X X X Sim d. Sim b. No c. c. c. c. a. a. Q9 X X X X X X X Sim X X X X X X Sim d. Sim b. No c. c. c. c. b. a. X X X
123
Anexos
j. k. l. m. n. o. p. q. r. s. t. u. 13 14 15 16 a. b. c. d. e. f. g. h. i. j. k. l. m. n. o. p.
X X X X X X X X X X X X X X X X X X X X Sim Sim Sim Sim Sim Sim No c. c. c. d. d. d. b. b. d. c. d. d. d. b. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Sim Sim b. c. b. c. X X X X X X X X X X X X X X
124
AnexoECdigodoProcessoemRunnable
FicheiroBPEL:
<bpel:process name="LancQuant" targetNamespace="http://LancQuant" suppressJoinFailure="yes" xmlns:tns="http://LancQuant" xmlns:bpel="http://docs.oasisopen.org/wsbpel/2.0/process/executable" xmlns:ns1="http://Bd " xmlns:ns3="http://Sap">  <bpel:import namespace="http://Sap" location="SapArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import namespace="http://Bd" location="BdArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import location="LancQuantArtifacts.wsdl" namespace="http://LancQuant" importType="http://schemas.xmlsoap.org/wsdl/" /> <!-================================================================= -->   <!-================================================================= --> <bpel:partnerLinks>  <bpel:partnerLink name="client" partnerLinkType="tns:LancQuant" myRole="LancQuantProvider" /> <bpel:partnerLink name="bd" partnerLinkType="ns1:Bd" partnerRole="BdProvider"></bpel:partnerLink> <bpel:partnerLink name="sap" partnerLinkType="ns3:Sap" partnerRole="SapProvider"></bpel:partnerLink> </bpel:partnerLinks> <!-================================================================= -->   <!-================================================================= --> <bpel:variables>  <bpel:variable name="input" messageType="tns:LancQuantRequestMessage"/>  <bpel:variable name="output" messageType="tns:LancQuantResponseMessage"/> <bpel:variable name="bdResponse" messageType="ns1:BdResponseMessage"></bpel:variable> <bpel:variable name="bdRequest" messageType="ns1:BdRequestMessage"></bpel:variable>
<bpel:variable name="sapResponse" messageType="ns3:SapResponseMessage"></bpel:variable> <bpel:variable name="sapRequest" messageType="ns3:SapRequestMessage"></bpel:variable> </bpel:variables> <!-================================================================= -->    <!-================================================================= --> <bpel:sequence name="main">  <bpel:receive name="receiveInput" partnerLink="client" portType="tns:LancQuant" operation="process" variable="input" createInstance="yes"/>  <bpel:assign validate="no" name="Assign"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"><tns:SapRequest xmlns:tns="http://Sap" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"> <tns:data></tns:data> <tns:turno></tns:turno> <tns:linha></tns:linha> <tns:id_produto></tns:id_produto> <tns:qtd_produzida></tns:qtd_produzida> <tns:qtd_refugo></tns:qtd_refugo> <tns:qtd_erros_vacuum></tns:qtd_erros_vacuum> <tns:qtd_erros_id></tns:qtd_erros_id> <tns:qtd_placas_mas></tns:qtd_placas_mas> <tns:qtd_maus></tns:qtd_maus> </tns:SapRequest> </bpel:literal> </bpel:from> <bpel:to variable="sapRequest" part="payload"></bpel:to> </bpel:copy> <bpel:copy>
126
<bpel:from> <bpel:literal xml:space="preserve"><tns:BdRequest xmlns:tns="http://Bd" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"> <tns:data></tns:data> <tns:turno></tns:turno> <tns:linha></tns:linha> <tns:id_produto></tns:id_produto> <tns:qtd_produzida></tns:qtd_produzida> <tns:qtd_refugo></tns:qtd_refugo> <tns:qtd_erros_vacuum></tns:qtd_erros_vacuum> <tns:qtd_erros_id></tns:qtd_erros_id> <tns:qtd_placas_mas></tns:qtd_placas_mas> <tns:qtd_maus></tns:qtd_maus> </tns:BdRequest> </bpel:literal> </bpel:from> <bpel:to variable="bdRequest" part="payload"></bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:data]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:data]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:turno]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:turno]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:linha]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:linha]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"> <![CDATA[tns:id_produto]]>
127
Anexos
</bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:id_produto]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_produzida]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_produzida]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_refugo]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_refugo]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_erros_vacuum]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_erros_vacuum]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_placas_mas]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_placas_mas]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_maus]]></bpel:query>
128
</bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_maus]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:data]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:data]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:turno]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:turno]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:linha]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:linha]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:id_produto]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:id_produto]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_produzida]]></bpel:query> </bpel:from>
129
Anexos
<bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_produzida]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_refugo]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_refugo]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_erros_vacuum]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_erros_vacuum]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_erros_id]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_erros_id]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_placas_mas]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_placas_mas]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_maus]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest">
130
<bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:qtd_maus]]></bpel:query> </bpel:to> </bpel:copy> </bpel:assign> <bpel:flow name="Flow"><bpel:invoke name="SAP" partnerLink="sap" operation="process" inputVariable="sapRequest" outputVariable="sapResponse" portType="ns3:Sap"></bpel:invoke><bpel:invoke name="Bd" partnerLink="bd" operation="process" inputVariable="bdRequest" outputVariable="bdResponse" portType="ns1:Bd"></bpel:invoke></bpel:flow> <bpel:assign validate="no" name="Assign1"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"><tns:LancQuantResponse xmlns:tns="http://localhost:8080/LancQuant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tns:sap></tns:sap> <tns:bd></tns:bd> </tns:LancQuantResponse> </bpel:literal> </bpel:from> <bpel:to variable="output" part="payload"></bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="bdResponse"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:result]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="output"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:bd]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="sapResponse"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns3:result]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="output"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:sap]]></bpel:query> </bpel:to> </bpel:copy> </bpel:assign> <bpel:reply name="replyOutput" partnerLink="client" portType="tns:LancQuant" operation="process" variable="output" /> </bpel:sequence> </bpel:process>
131
Anexos
FicheiroWSDL:
<?xml version="1.0"?> <definitions name="LancQuant" targetNamespace="http:/LancQuant" xmlns:tns="http://LancQuant" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TYPE DEFINITION - List of types participating in this BPEL process The BPEL Designer will generate default request and response types but you can define or import any XML Schema type and use them as part of the message types. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <types> <schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://localhost:8080/LancQuant" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="LancQuantRequest"> <complexType> <sequence> <element name="data" type="int"/> <element name="turno" type="string"/> <element name="linha" type="int"/> <element name="id_produto" type="int"/> <element name="qtd_produzida" type="int"/> <element name="qtd_refugo" type="int"/> <element name="qtd_erros_vacuum" type="int"/> <element name="qtd_erros_id" type="int"/> <element name="qtd_placas_mas" type="int"/> <element name="qtd_maus" type="int"/> </sequence> </complexType> </element> <element name="LancQuantResponse"> <complexType> <sequence> <element name="sap" type="boolean"/> <element name="bd" type="boolean"/> </sequence> </complexType> </element> </schema> </types>
<!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type defintions
132
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <message name="LancQuantRequestMessage"> <part name="payload" element="tns:LancQuantRequest"/> </message> <message name="LancQuantResponseMessage"> <part name="payload" element="tns:LancQuantResponse"/> </message> <!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->  <portType name="LancQuant"> <operation name="process"> <input message="tns:LancQuantRequestMessage" /> <output message="tns:LancQuantResponseMessage"/> </operation> </portType> <!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PARTNER LINK TYPE DEFINITION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <plnk:partnerLinkType name="LancQuant"> <plnk:role name="LancQuantProvider" portType="tns:LancQuant"/> </plnk:partnerLinkType> <binding name="LancQuantSoapBinding" type="LancQuant"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="process"> <soap:operation soapAction="http://localhost:8080/LancQuant/process" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="lancQuantService"> <port name="lancQuantPort" binding="LancQuantSoapBinding"> <soap:address location="http://0.0.0.0:8080/ode/processes/LancQuantService" /> </port> </service> </definitions>
133
Anexos
AnexoFCdigodosComponentesdoProcessoemSoftware Implemented
Ficheiroxbean.xmldoCXFSE(paraSAP):
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns:cxfse="http://servicemix.apache.org/cxfse/1.0" xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://servicemix.apache.org/cxfse/1.0 http://servicemix.apache.org/schema/servicemix-cxfse-3.2.3.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <cxfse:endpoint> <cxfse:pojo> <bean class="pt.bosch.com.teste_cxfse_su.SapService" /> </cxfse:pojo> </cxfse:endpoint> </beans>
Ficheiroxbean.xmldoCXFSE(paraBD):
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns:cxfse="http://servicemix.apache.org/cxfse/1.0" xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://servicemix.apache.org/cxfse/1.0 http://servicemix.apache.org/schema/servicemix-cxfse-3.2.3.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <cxfse:endpoint> <cxfse:pojo> <bean class="pt.bosch.com.teste_cxfse_su.BdService" /> </cxfse:pojo> </cxfse:endpoint> </beans>
Ficheiroxbean.xmldoCXFBC(paraSAP):
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" xmlns:xsi="http://http://www.w3.org/2001/XMLSchema-instance" xmlns:sap="http://Sap" xsi:schemaLocation="http://servicemix.apache.org/cxfbc/1.0 http://servicemix.apache.org/schema/servicemix-cxfbc-3.2.3.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
134
<cxfbc:consumer wsdl="classpath:SapArtifacts.wsdl" targetEndpoint="sap:SapPort" targetService="sap:SapService" targetInterface="sap:Sap"/>
</beans>
Ficheiroxbean.xmldoCXFBC(paraBD):
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" xmlns:xsi="http://http://www.w3.org/2001/XMLSchema-instance" xmlns:bd="http://Bd" xsi:schemaLocation="http://servicemix.apache.org/cxfbc/1.0 http://servicemix.apache.org/schema/servicemix-cxfbc-3.2.3.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <cxfbc:consumer wsdl="classpath:BdArtifacts.wsdl" targetEndpoint="bd:BdPort" targetService="bd:BdService" targetInterface="bd:Bd"/> </beans>
FicheiroBPELdoProcesso:
<bpel:process name="LancQuant" targetNamespace="http://LancQuant" suppressJoinFailure="yes" xmlns:tns="http://LancQuant" xmlns:bpel="http://docs.oasisopen.org/wsbpel/2.0/process/executable" xmlns:ns1="http://Bd" xmlns:ns2="http://Sap">  <bpel:import namespace="http://Sap" location="SapArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import namespace="http://Bd" location="BdArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import> <bpel:import location="LancQuantArtifacts.wsdl" namespace="http://LancQuant" importType="http://schemas.xmlsoap.org/wsdl/" /> <!-================================================================= -->   <!-================================================================= --> <bpel:partnerLinks>  <bpel:partnerLink name="client" partnerLinkType="tns:LancQuant"
135
Anexos
myRole="LancQuantProvider" /> <bpel:partnerLink name="bd" partnerLinkType="ns1:Bd" partnerRole="BdProvider"></bpel:partnerLink> <bpel:partnerLink name="sap" partnerLinkType="ns2:Sap" partnerRole="SapProvider"></bpel:partnerLink> </bpel:partnerLinks> <!-================================================================= -->   <!-================================================================= --> <bpel:variables>  <bpel:variable name="input" messageType="tns:LancQuantRequestMessage"/> <!-Reference to the message that will be returned to the requester --> <bpel:variable name="output" messageType="tns:LancQuantResponseMessage"/> <bpel:variable name="sapResponse" messageType="ns2:SapResponseMessage"></bpel:variable> <bpel:variable name="sapRequest" messageType="ns2:SapRequestMessage"></bpel:variable> <bpel:variable name="bdResponse" messageType="ns1:BdResponseMessage"></bpel:variable> <bpel:variable name="bdRequest" messageType="ns1:BdRequestMessage"></bpel:variable> </bpel:variables> <!-================================================================= -->    <!-================================================================= --> <bpel:sequence name="main">  <bpel:receive name="receiveInput" partnerLink="client" portType="tns:LancQuant" operation="process" variable="input" createInstance="yes"/>  <bpel:assign validate="no" name="Assign">
136
<bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"><tns:BdRequest xmlns:tns="http://Bd" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"> <tns:smd></tns:smd> <tns:linha></tns:linha> <tns:qtd_produzida></tns:qtd_produzida> <tns:defeitos></tns:defeitos> <tns:oee></tns:oee> </tns:BdRequest> </bpel:literal> </bpel:from> <bpel:to variable="bdRequest" part="payload"></bpel:to> </bpel:copy> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"><tns:SapRequest xmlns:tns="http://Sap" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"> <tns:data></tns:data> <tns:turno></tns:turno> <tns:linha></tns:linha> <tns:id_produto></tns:id_produto> <tns:qtd_produzida></tns:qtd_produzida> <tns:qtd_refugo></tns:qtd_refugo> <tns:qtd_erros_vacuum></tns:qtd_erros_vacuum> <tns:qtd_erros_id></tns:qtd_erros_id> <tns:qtd_placas_mas></tns:qtd_placas_mas> <tns:qtd_maus></tns:qtd_maus> </tns:SapRequest> </bpel:literal> </bpel:from> <bpel:to variable="sapRequest" part="payload"></bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:data]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:data]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:turno]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:turno]]></bpel:query> </bpel:to> </bpel:copy>
137
Anexos
<bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:linha]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:linha]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:id_produto]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:id_produto]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_produzida]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_produzida]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_refugo]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_refugo]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_erros_vacuum]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_erros_vacuum]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy>
138
<bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_erros_id]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_erros_id]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_placas_mas]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_placas_mas]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_maus]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="sapRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:qtd_maus]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"> <![CDATA[tns:linha]]> </bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:linha]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_produzida]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:qtd_produzida]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy>
139
Anexos
<bpel:from part="payload" variable="input"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:qtd_maus]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="bdRequest"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:defeitos]]></bpel:query> </bpel:to> </bpel:copy> </bpel:assign> <bpel:flow name="Flow"><bpel:invoke name="SAP SE" partnerLink="sap" operation="process" inputVariable="sapRequest" outputVariable="sapResponse"></bpel:invoke><bpel:invoke name="BD SE" partnerLink="bd" operation="process" inputVariable="bdRequest" outputVariable="bdResponse"></bpel:invoke></bpel:flow> <bpel:assign validate="no" name="Assign1"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve"><tns:LancQuantResponse xmlns:tns="http://LancQuant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tns:sap></tns:sap> <tns:bd></tns:bd> </tns:LancQuantResponse> </bpel:literal> </bpel:from> <bpel:to variable="output" part="payload"></bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="bdResponse"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns1:result]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="output"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:bd]]></bpel:query> </bpel:to> </bpel:copy> <bpel:copy> <bpel:from part="payload" variable="sapResponse"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[ns2:result]]></bpel:query> </bpel:from> <bpel:to part="payload" variable="output"> <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDAT A[tns:sap]]></bpel:query> </bpel:to> </bpel:copy> </bpel:assign> <bpel:reply name="replyOutput" partnerLink="client" portType="tns:LancQuant" operation="process"
140

variable="output" /> </bpel:sequence> </bpel:process>
FicheiroWSDLdoProcesso:
<?xml version="1.0"?> <definitions name="LancQuant" targetNamespace="http://LancQuant" xmlns:tns="http://LancQuant" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TYPE DEFINITION - List of types participating in this BPEL process The BPEL Designer will generate default request and response types but you can define or import any XML Schema type and use them as part of the message types. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <types> <schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://LancQuant" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="LancQuantRequest"> <complexType> <sequence> <element name="data" type="int"/> <element name="turno" type="string"/> <element name="linha" type="int"/> <element name="id_produto" type="int"/> <element name="qtd_produzida" type="int"/> <element name="qtd_refugo" type="int"/> <element name="qtd_erros_vacuum" type="int"/> <element name="qtd_erros_id" type="int"/> <element name="qtd_placas_mas" type="int"/> <element name="qtd_maus" type="int"/> </sequence> </complexType> </element> <element name="LancQuantResponse"> <complexType> <sequence> <element name="sap" type="boolean"/> <element name="bd" type="boolean"/>> </sequence> </complexType> </element> </schema> </types>
141
Anexos
<!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type defintions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <message name="LancQuantRequestMessage"> <part name="payload" element="tns:LancQuantRequest"/> </message> <message name="LancQuantResponseMessage"> <part name="payload" element="tns:LancQuantResponse"/> </message> <!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->  <portType name="LancQuant"> <operation name="process"> <input message="tns:LancQuantRequestMessage" /> <output message="tns:LancQuantResponseMessage"/> </operation> </portType>
<!-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PARTNER LINK TYPE DEFINITION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <plnk:partnerLinkType name="LancQuant"> <plnk:role name="LancQuantProvider" portType="tns:LancQuant"/> </plnk:partnerLinkType> <binding name="LancQuantSoapBinding" type="tns:LancQuant"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="process"> <soap:operation soapAction="http://LancQuant/process" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="LancQuantService"> <port name="LancQuantPort" binding="tns:LancQuantSoapBinding"> <soap:address location="http://0.0.0.0:8080/ode/processes/LancQuant" />
142

</port> </service> </definitions>
Ficheirodeploy.xmldoODE:
<?xml version="1.0" encoding="UTF-8"?> <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:Bd="http://Bd" xmlns:LancQuant="http://LancQuant" xmlns:Sap="http://Sap"> <process name="LancQuant:LancQuant"> <process-events generate="all"/> <provide partnerLink="client"> <service name="LancQuant:LancQuantService" port="LancQuantPort"/> </provide> <invoke partnerLink="bd"> <service name="Bd:BdService" port="bdPort"/> </invoke> <invoke partnerLink="sap"> <service name="Sap:SapService" port="SapPort"/> </invoke> </process> </deploy>
Ficheiroxbean.xmldoCXFBC(Client):
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" xmlns:xsi="http://http://www.w3.org/2001/XMLSchema-instance" xmlns:lq="http://LancQuant" xsi:schemaLocation="http://servicemix.apache.org/cxfbc/1.0 http://servicemix.apache.org/schema/servicemix-cxfbc-3.2.3.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <cxfbc:consumer wsdl="classpath:LancQuantArtifacts.wsdl" targetEndpoint="lq:LancQuantPort" targetService="lq:LancQuantService" targetInterface="lq:LancQuant"/> </beans>
143
Anexos
Ficheiropom.xmldoSA:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>psm-lancquant-sa</artifactId> <packaging>jbi-service-assembly</packaging> <version>0.0.1-SNAPSHOT</version> <name>SA for LancQuant</name> <url>http://www.myorganization.org</url> <repositories> <repository> <id>apache</id> <name>Apache Repository</name> <url>http://people.apache.org/repo/m2-ibiblio-rsyncrepository</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> <repository> <id>apache.snapshots</id> <name>Apache Snapshots Repository</name> <url>http://people.apache.org/repo/m2-snapshot-repository</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>false</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>apache</id> <name>Apache Repository</name> <url>http://people.apache.org/repo/m2-ibiblio-rsyncrepository</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </pluginRepository> <pluginRepository> <id>apache.snapshots</id> <name>Apache Snapshots Repository</name> <url>http://people.apache.org/repo/m2-snapshotrepository</url> <snapshots> <enabled>true</enabled> </snapshots>
144
<releases> <enabled>false</enabled> </releases> </pluginRepository> </pluginRepositories> <properties> <servicemix-version>3.2.3</servicemix-version> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>bd-cxfbc-su</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>bd-cxfse-su</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>lancquant-cxfbc.su</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>sap-cxfbc-su</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>sap.cxfse-su</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>fsi12.pt.bosch.com</groupId> <artifactId>teste-ode-su</artifactId> <version>{version}</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.servicemix.tooling</groupId> <artifactId>jbi-maven-plugin</artifactId> <version>${servicemix-version}</version> <extensions>true</extensions> <configuration> <type>service-assembly</type> </configuration> </plugin> </plugins> </build> </project>
145

2009 MSC NunoSantos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2009 MSC NunoSantos

Hochgeladen von

Copyright:

Verfügbare Formate

UniversidadedoMinho EscoladeEngenharia

ImplementaodeProcessosde NegcioemSoftwareUtilizando TransformaesdeModelos

UniversidadedoMinho EscoladeEngenharia DepartamentodeSistemasdeInformao Guimares,Outubrode2009

Concluso................................................................................................................ 85 5.1 TrabalhoFuturo.............................................................................................. 88

CMM CMOF CORBA COTS CPN CRM

CWM DAMLS DBMS DC

EMOF EPC ERP ESB

eTOM HLnet IBM ISO ITIL

J2EE JBI JCo

MDA MDD MDE MEP MIC

NMR OBO OCL ODE

OMG OWLS P4 PF PIM

PTnet QVT REL SA

SWEBoK TI TS TSP UBK

UBKRM UML UMLAD WfMC WPDL WS

WSCI WSDL WSFL WSBPEL XLANG XSD XMI

XMLProcessDefinitionLanguage YetAnotherWorkflowLanguage YAWLEventdrivenProcessChain

AdamPetri, nombitodasuatesede doutoramento[Petri1962],paraenfrentarconcorrncia

A marca, ou token, utilizada para descrever o estado do sistema no lugar onde se

A particularidade que define qual a fase da metodologia em que o processo se

Na fase de Seleco, o analista do processo escolhe um modelo de referncia de

caracterizar praticas de gesto e solues que resultem em performances melhores que os

Um bem conhecido process reference model o SupplyChain Operations Reference

Para implantar um componente no ServiceMix recorrese utilizao de um Service

No exemplo da Figura 8, retirado de [Rademakers e Dirksen 2008], o SA constitudo

A camada M3 representa o nvel mais elevado de abstraco, o metametamodel, isto

(MIC),etc.O quesepassanoMDAqueestesprincpiosdeMDE sorealizadoscombasenos

de cada uma. No entanto, escolhida a linguagem, logicamente o conhecimento destas

12 13 14 Eficincia GestodosDados IntegraonoERPSAP

Como se pode ver na tabela, no h grandes dvidas de que o BPEL obteve os

Estruturasalgortmicas sequence flow pick

repeatUntil scope if forEach wait

A quarta e ltima parte do ficheiro BPEL referese sequncia de actividades do

A segunda parte do ficheiro WSDL contm a definio do tipo de elementos das

A terceira parte referese definio do tipo de mensagens e das respectivas partes

A quinta e ltima parte contm a definio do papel (role) do PartnerLink referente a

<plnk:partnerLinkType name= ... <plnk:role name= ... portType= </plnk:partnerLinkType>

O RegistaProduto um subprocesso do processo de Produo. Na Figura 30 est o

Visto que o PF se encontra no estado Runnable, j deve ser considerado para o

O que importa ressalvar do WSDL so os dados referentes ao servio, ligao, tipo de

Plataforma Os processos suportados por software vo ser executados dentro de um Enterprise

WSDLNomedoServio (LancQuantService,SapServicee BdService) WSDLTipodePortadoServio (LancQuant,SapeBd) WSDLNomedaPortadoServio (LancQuantPort,SapPorteBdPort)

O mapeamento (Tabela 8) que descreve as relaes entre os artefactos dos modelos

Tal como j visto anteriormente, as especificaes para a transformao para a

... [1] [2] [3] [4] [5] [6] [7]

Parainserirosdadosnabasededados,atarefaserigualaocasodoERP,i.e.,osvaloresso inseridosatravsdeumWebService.Assim,oBindingComponentparacomunicarcomoESB serigualmentedotipoCXFBC(Figura46).

PIM elements that will be transformed intoPSM.

necessary information that can be translatedintocode. 3.3 ApacheServiceMix

In order to deploy a component into ServiceMix, a Service Unit (SU) [27]

process is executed using software, so it needs to obey specifications of the technologicplatform.

WSDLServicename (LancQuantService, SapServicee BdService)

WSDLPorttypeofthe service(LancQuant, SapeBd) WSDLPortnameofthe service(LancQuantPort, SapPorteBdPort)

SUs which the SA will contain is made inapom.xmlfileProjectObjectModel.

outraactividadeficahabilitadaparaexecuo. Padresbaseadosemestados Padro16:EscolhaemDiferido

3. JparticipouemalgumprojectoBPM(reestruturao/melhoria, modelaoemonitorizaodosprocessosdenegciodeuma empresa)?AssinalecomumXumaopo: No: Sim:

II. ConceitosdeLinguagensdeModelaodeProcessosdeNegcio 5. Sabeoquesodiagramasdeworkflow?(AssinalecomumXuma opo)Sim: No: 6. Indiqueoseugraudefamiliaridadeemrelaoaoperaes algbricasAND,OR,NAND,NOR,XOR:(AssinalecomumXuma opo)

7. Sabeoquesodiagramasemgrafos?(AssinalecomumXuma opo)Sim: No:

9. ConheceatcnicadoClculode(pi)?(AssinalecomumXuma opo)Sim: No: 10.Indiqueoseugraudefamiliaridadeemrelaolinguagemde programaoXML:(AssinalecomumXumaopo)

11.Dasseguinteslinguagensdemodelao,indique,paracadauma,a opocorrectaquereflitaoseuconhecimentoquantomodelao dalinguagem:(AssinalecomumX)

III. ConceitosSOA(ServiceOrientedArchitecture) 13.ConheceanormaSOA(ServiceOrientedArchitecture)?(Assinale No: comumXumaopo)Sim: 14.ClassificaosseusconhecimentosemWebServicescomo:(Assinale comumXumaopo)

X X X X X X X X X X X X X X X X X X X X Sim Sim Sim Sim Sim Sim No c. c. c. d. d. d. b. b. d. c. d. d. d. b. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Sim Sim b. c. b. c. X X X X X X X X X X X X X X

Reference to the message that will be returned to the

<cxfbc:consumer wsdl="classpath:SapArtifacts.wsdl" targetEndpoint="sap:SapPort" targetService="sap:SapService" targetInterface="sap:Sap"/>