Correspondencia Semántica entre los lenguajes BPMN y GRL1

11

Enl@ce: Revista Venezolana de Información, Tecnología y ConocimientoISSN: 1690-7515Depósito legal pp 200402ZU1624 Año 8: No. 1, Enero-Abril 2011, pp. 11-29

1 EstetrabajoesparcialmentefinanciadoporelFONACITdelMinisteriodeCienciayTecnologíadeVenezuela.2 ProfesoraTitulardelLaboratorioMoST(Modelos,SoftwareyTecnologías),EscueladeComputación,FacultaddeCiencias,Uni-versidadCentraldeVenezuela.DoctoraenCienciasdelaComputaciónen1991yDoctorade3er.cicloen1985delaUniversidaddeParis-Sud,ParisXI,Orsay,Francia.FundadoradelaOpcióndePostgradoenIngenieríadeSoftwareydelCentrodeIngenieríadeSoftwareySistemas(ISYS)delaEscueladeComputación,FacultaddeCiencias,UCV,en1992.Sustemasdeinvestigaciónsonenarquitectura,calidad,estándaresyprocesodedesarrollodesoftware.Correoelectrónico:[email protected]

3 Lic.enComputación.ConsultorenTecnologíasdelaInformaciónyComunicación.MasterenGerenciadeTIC.DoctoranteenCienciasdelaComputaciónenlaUniversidadCentraldeVenezuela.Correoelectrònico:[email protected]

4 ProfesorTitulardelaEscueladeComputación,FacultaddeCiencias,UniversidadCentraldeVenezuela.DoctorenCienciasdelaComputacióndelaUniversidadPaulSabatier,Toulouse,Francia.CoordinadordelPostgradoenCienciasdelaComputación,EscueladeComputación,FacultaddeCiencias,UCV.Sustemasdeinvestigaciónson:modelos,arquitecturasymetodologíasparaeldesarrollodesoftware.Correoelectrónico:[email protected]

Recibido: 05-10-10 Aceptado: 22-02-11

Cómocitarelartículo(NormasAPA):Losavio,F.,Guzmán,J.C.yMatteo,A.(2011).Correspondencia

SemánticaentreloslenguajesBPMNyGRL.Enl@ce Revista Venezolana de Información, Tecnología y Conocimiento,8(1),11-29

Correspondencia Semántica entre los lenguajes BPMN y GRL1

Francisca Losavio2

Jean Carlos Guzmán3

Alfredo Matteo4

Resumen

Unmodelodenegocioesunpuntoinicialparalaelaboracióndelsistemadesoftware;esútilparaqueelequipodedesarrolloentiendamejorlaespecificacióndelosrequisitosglobalesqueelfuturosistemadesoftwaredebesatisfa-cer.Sinembargo,cómopasardelmodelodenegocioalmodelodelsistematomandoencuentametasnofuncionalesenlasetapastempranasdelciclodevidadelsoftware,esaúnunproblemaporresolver.Actualmenteexisteuncon-sensoenconsiderarlosaspectosnofuncionalescomoclaveparaconstruirlaarquitecturadelsistemadesoftware,peroestosnosonconsideradosenlosmodelosdenegocio,aunquesusreglaspuedanimplicaraspectosnofuncionales

12

Correspondencia Semántica entre los lenguajes BPMN y GRLFrancisca Losavio, Jean Carlos Guzmán y Alfredo Matteo

como por ejemplo usabilidadyseguridad.Elmodeladodelprocesodenegociosecentraenlarepresentacióngráficadeactividadesmediantelenguajesdemodelado,comoBPMN (Business Process Modeling Notation),enloscualesnosedestacanlasmetasnofuncionales.Porotraparte,lenguajesorientadosametascomoGRL (Goal-oriented Requi-rements Language),describenelsistemadesoftwarecentradostantoenmetasfuncionalescomonofuncionales,ypermitenrepresentartambiénentidadesyelementosdenegocio.Elobjetivodeestetrabajoespresentarunacorres-pondenciasemánticaentreBPMNyGRL,lenguajesconocidosyampliamenteutilizados,ysedescribenreglasprecisasparaestacorrespondencia,resaltandolosaspectosnofuncionales,lacualseráutilizadaparaladerivacióndelmodeloarquitectónicoinicialdelsistema,apartirdelmodelodenegocio,enetapastempranasdelprocesodedesarrollo,ydeestamanerareducirlabrechaentrelosmodelosdenegocioydelsistema.

Palabras clave: BPMN, GRL,modelodelprocesodenegocio,modelodenegocio,metasno funcionales,correspondenciasemántica

Semantic Correspondence between GRL and BPMNLanguages

Abstract

Softwaresystemdevelopmentshouldstartfromabusinessmodelexpressingthebusinesslogic.Itprovidesthedevelopmentteamabetterunderstandingoftherequirementsspecificationthatthefuturesoftwaresystemmustsatisfy.However,howtomovefromabusinessmodeltoasystemmodel,highlightingnon-functionalgoalsatearlystagesof thesoftware lifecycle, isstillanopenproblem.There isageneralagreementtoconsidernon-functionalaspectsascrucialtoconstructthesoftwaresystemarchitecture.Thebusinessprocessmodelingfocusesonthegraphicrepresentationofactivitiesbymodelinglanguages,suchasBPMN (Business Process Modeling Notation).However,theselanguagesdonotfocusonnon-functionalgoals.Ontheotherhand,goal-orientedlanguages,suchasGRL (Goal-oriented Requirements Language),describe the software systems focusingonnon-functionalgoals,allowingalsorepresentingbusinessentitiesandelements.TheaimofthispaperistopresentthesemanticcorrespondencebetweenBPMNandGRL,wellknownandwidelyusedrepresentativeoftheabove-mentionedlanguages.Thiscorrespondence,describedbypreciserulesandfocusedonnon-functionalaspects,willbeusedtoderivetheinitialarchitecturalmodelofthesystemdirectlyfromthebusinessmodel,atearlystagesofthesoftwaredevelopmentprocess,reducingthegapbetweenbusinessandsystemmodels.

Key words: BPMN, GRL, Business Process Model, Business Model, Non-functional goals, SemanticCorrespondence

13

Enl@ce: Revista Venezolana de Información, Tecnología y ConocimientoAño 8: No. 1, Enero-Abril 2011, pp. 11-29

Introducción

Un Modelo de Negocioofreceunavistaabs-tractaysimplificadadelarealidadcomplejaenlaqueseexpresanconceptossobreelfuncionamien-todelnegociodeunaentidad,entérminosdeme-tasyfactoresdeimportanciaquereflejansulógi-ca.Estáconformadoporundiagramaconstituidodeelementosquecontextualizanelnegocio,comoson actores, actividades, entidades, procesos, vín-culos,entreotros(Burlton,2001).UnProceso de Negocio se concibecomounconjuntovinculadoynaturaldeactividadesbasadasenhabilidadesycompetenciasdetrabajo,queincluyeninteraccio-nesentreactores,recursosutilizadosyvínculosdedependencias entre estos. Las actividades en unproceso de negocio son coordinadas por actores, quienes tienen la intención de satisfacer ciertas metas (Crusson, 2006). La especificación de losprocesosdenegociopermitenalequipodedesa-rrollodesoftware,entenderdeunmodoapropia-do lasnecesidades y los requisitos que el futurosistema debe satisfacer. El Modelado del Proceso de Negocioestácentradoprincipalmenteenlare-presentacióngráficadeesosprocesos,usandolen-guajesdemodeladoespecíficostalescomolaNo-tacióndeModeladodeProcesosdeNegociooBu-siness Process Modeling Notation (BPMN) (BP-MIG,2002)yelLenguajedeRequisitosorientadoaMetasoGoal-oriented Requirements Language (GRL) (ITU-T, 2003, ITU-T, 2008). El lenguajeBPMNiniciadoporelBusiness Process Modeling Initiative Group y recientemente admitido por el Object Management Group (OMG, 2009) comoestándar de facto, tiene por objetivo facilitar la

comprensión del proceso de negocio por parte de losparticipantes(ostakeholders).BPMNsoportasolo conceptos de modelado aplicables al negocio desdeunnivelde abstracciónorganizacional in-termedio,permitiendodefinir,documentar,orga-nizaryrediseñarprocesosdesdeunaperspectivaparticular.Notratalasmetasnofuncionalesque,por ejemplo, pueden ser derivadas de las reglasdel negocio: declarar el acceso restringido a cier-ta informaciónparaalgunosusuarios implicaunobjetivodeseguridad,quedebesernecesariamen-te considerado. Por otra parte, el lenguajeGRL, iniciado recientemente por la International Te-lecommunication Union (ITU) comosubconjun-to del estándar z.151denominadoDefinicióndelLenguajede laNotacióndeRequisitosdeUsua-rios o User Requirements Notation (URN)Lan-guage Definition (ITU-T, 2008), tiene suorigenendosamplioslenguajesdemodeladoorientadoa metas, tales como: i* (YuyMylopoulos, 1993)y el NFR Framework (Chung, 1991).GRL esunenfoquedeIngenieríadeMetasparalaespecifica-cióndesistemasdesoftware,quetambiénpermitemodelarprocesosdenegocioflexibles;enlasfasestempranas,tomaencuentalagestiónsistemáticaeintencionaldemetas,tantofuncionalescomonofuncionales,desdeelpuntodevistadelanociónde la intencionalidad distribuida,quehaceénfasisenelcumplimientodemetaspor losactores.Enestecontexto,lostérminos“intencional”e“inten-cionalidad”,serefierenalcumplimientodeobjeti-vosometasdesdeelpuntodevistadelusuariooactor. Por otra parte, BPMNesun lenguajemuyutilizadoenlaprácticadesdeunenfoquedeInge-niería de Procesos de Negocio. Sin embargo, los

14


diagramas derivados de BPMN solo enfatizan los requisitosfuncionalesdelsoftwareynofacilitanladefinicióndeunaarquitecturainicial.Encambio,ellenguajeGRLpermiteexpresarmetasdealtoni-velorganizacional,metasdelsoftwareymetasdelos stakeholders,explicitardependenciasentreac-tores,distinguirentreagentes,posicionesyroles(Amyot,Horkoff, Gross yMussbacher, 2009), yasírazonarsobrecadaactorconrespectoasusre-laciones con otros actores. El objetivo de este tra-bajoesestablecerreglasprecisasparaunacorres-pondenciasemánticaentreloslenguajesBPMN y GRL, la cual será utilizada en etapas tempranasdeldesarrollode software,para laderivacióndeunmodeloarquitectónico inicialdel sistema,di-rectamenteapartirdelmodelodenegocio,redu-ciendoasílabrechaentrelosmodelosdenegocioydelsistemadesoftware.Enlapráctica,muchasorganizacionestienensusprocesosdenegocioes-pecificados en algún lenguaje demodelado, porejemplo BPMN, el cual es uno de los lenguajesmásusadosactualmenteen la industria.ElpasodeundiagramadelprocesodenegociodeBPMNaunmodelodenegocioenGRLayudaráatomarencuentaenlasetapastempranaslasmetasnofun-cionales,quesepuedenderivardelas metas orga-nizacionales del modelo de negocio y así facilitar la construccióndelmodeloarquitecturaldelsistema.Definimoseltérminocorrespondencia semántica comolasimetríaosimilitudexistenteentredosomáselementosconceptualespertenecientesadoso más lenguajes de modelado específicos, talescomo BPMN y GRL.

En este trabajo presentamos pasos y reglas decorrespondenciasemánticaentreloslenguajes

BPMNyGRL.SeconsideróellenguajeGRLenlu-gardeI*,porqueesunlenguajeorientadoame-tasmásgeneralqueenglobaa I*,ampliandoasítrabajosanterioresenloscualesseconsiderabalacorrespondenciaentreloslenguajesi*yBPMN,deCysneirosyYu(2004),Koliadis,Vranesevic,Bhui-yan,KrishnayGhose(2007).Asímismo,debemosobservarque losenfoques tradicionalesdedesa-rrollo de software enfatizan los aspectos funcio-nales,obviandolosaspectosnofuncionales,comoporejemplolaseguridad,laconfiabilidadyelren-dimiento, para etapas posteriores del desarrollo. Esto trae como consecuencia la producción desistemasdifícilesdemantenerydereutilizar.Bajoesta línea de ideas, las reglas de correspondencia propuestaspuedenserutilizadasenuncontextode reingeniería de proceso, como en el caso de es-tudioaquí expuestoy comomarcode referenciaparatransformarundiagramadelprocesodene-gocio de BPMNaunmodelodeGRL y viceversa. UtilizamoscomocasodeestudioundiagramadelprocesodelaGestióndeTrámitesdeSolicitudes(GTS)tomadodeláreaindustrialyadelantadoporlaDireccióndelTalentoHumano,queinvolucraalasUnidadesMedulares delCentro Nacional de Tecnologías de Información(CNTI),enCaracas,Venezuela, como una primera validación de lapropuesta.

Elpresentetrabajoestáestructuradodelasiguientemanera,ademásdeestaintroducción,elagradecimientoylasconclusiones.Enlasección2se presentan concepto y terminología del modela-dodeprocesosdenegocioyellenguajeBPMN. En lasección3sedescribeellenguajeGRL.Luegoenla sección 4, se presentan los pasos y reglas para

15


lacorrespondenciasemánticaaplicablesaloslen-guajesBPMN y GRL.Enlasección5sediscutenlos principales trabajos relacionados con el tema. Finalmenteenlasección6,seaplicanlasreglasdecorrespondenciaauncasodeestudio.

Modelado del proceso de negocio y BPMN

HammeryChampy(1993)definenunpro-ceso como una colección de actividades que to-manunaovariasclasesdeentradasygeneranunasalidadevalorparaelcliente.Desdeelpuntodevista del negocio, los procesos son ortogonales a lasunidadesgerencialesdeunaorganización.UnProceso de Negocio(PN)seconsideraunconjun-tovinculadoynaturaldeactividadesbasadasenhabilidadesycompetenciasdetrabajo,queseini-ciandesdelosrequisitosdelclientehastalaentre-gatotaldeproductososervicios(Chung,GrossyYu,1999).UnPN esmásqueunameraconexiónde actividades, ya que incluye elementos talescomo propósitos o intenciones, recursos utiliza-dos, eventos, acciones, actividades, desencade-namiento de tareas y vínculos (Hepp y Roman,2007). Las actividades de unPN son ejecutadasdeacuerdoareglaspreestablecidasparasatisfacerciertasmetas,lascualessonlogradasatravésdeunaomás tareas interrelacionadas,permitiendoobtener uno o más artefactos para una entidadconcreta. White (2004) plantea que unModelo del Proceso de Negocio(MPN)sedefinecomounareddeobjetosgráficos,queincluyenactividadesycontrolesdeflujosquedescribenelfuncionamien-

todeunaorganización.LosMPNsondiseñadosatravésdelenguajesespecíficos,loscualesdifie-ren en su naturaleza, característica y objetivos.Bajoestapremisa,elBusiness Modeling Process Initiative Group (BPMIG, 2002) estandarizó unconjuntodenotacionesdemodeladodelnegociollamado Notación de Modelado de Procesos deNegocio o Business Process Modeling Notation (BPMN),unificandoconceptosypuntosdevistasdiferentes, aceptados recientemente por el Object Management Group(OMG,2009).Consistetan-todeunanotacióngráficaasícomotambiéndelasemánticasubyacente.

ElobjetivoprincipaldellenguajeBPMNesofrecerunanotaciónentendible a todos lospar-ticipantes del proceso de negocio (OMG, 2009).BPMN se basa en técnicas de flowcharting o diagramade flujo y considera cuatro categorías:Objetos de Flujo, Objetos de Conexión, Carrileso Swimlane,loscualesseespecializanenPools y Lanes,Artefactosydoselementosdemodulariza-ción: Procesos y Diagramas del Proceso de Nego-cio(DPN)oBusiness Process Diagram,loscualesmanejanlacomplejidadinherenteaunprocesoenparticular.

En el Gráfico 1, presentamosunmodeloconceptualdeBPMNtomadodelaOMG(2009),elcualseutilizacomomarcodereferenciaparalaelaboración y aplicación de los pasos y reglas para lacorrespondenciasemánticaquepresentaremosenlasección4,conlafinalidaddederivarmodelosdeGRLdesdediagramasdeprocesosdenegociodeBPMNyviceversa.

16


Lenguaje de requisitos orientado a metas (GRL)

EnelcontextodelaIngenieríadeRequisitosdenominadoorientaciónametas (goal-oeriented approach), el Lenguaje de Requisitos Orientado

Gráfico 1

Modelo conceptual de BPMN. OMG(2009)

aMetasoGoal-oriented Requirements Language (GRL)esunsubconjuntodelaNotacióndeRequi-sitosdeUsuariosoUser Requirements Notation (URN)(ITU-T,2003;ITU-T,2008),lacualadmitelaelicitación,elanálisis,laespecificaciónylavali-daciónderequisitos,permitiendodescubriryespe-

<<enumeration>>SubprocessKind

+None+Reference+Reusable

Subprocess+name: String+kind: SubprocessKind+type: SubprocessType+cycle: CycleType

Task+name: String+kind: TaskKind

Gateway+type: GatewayType

Event+kind: EventKind+type: EventTypes

<<enumeration>>GatewayType

+Xor+Or+Complex+Paralel Fork+Paralel Join

DirectionFlow+Source+Target

Pool+role: String+orientation: PoolOrientation

Sequence Flow+type: SequenceFlowType

1..*

0..*

0..* 0..1

Lane+role: String

Message Flow Association

Object Flow

Business ProcessDiagram

Supporting ElementBPMN Element

Graphical Element

Activity

Process

Data Object

Swimlane

Group

Artefact

Annotation

Connecting Object+direction: DirectionFlow

<<enumeration>>PoolOrientation+Vertical+Horizontal

<<enumeration>>SequenceFlowType+Default+Normal+Conditional+Exection+Uncontrolled

<<enumeration>>TaskKind

+User+Send+Receive+Reference+Script+Service

<<enumeration>>EventKind

+None+Cancel+Message+Error+Timer+Compensation+Rule+Link+Multiple

<<enumeration>>EventTypes

+Start+Intermediate+End

<<enumeration>>SubprocessType

+None+Transaction+Ad-hoc

<<enumeration>>CycleType

+None+Standard+InstanceMultiples

17


El NFR (Non Functional Requirements Framework) o Framework para Requisitos NoFuncionales,iniciadoporChung(1991),esunen-foqueorientadoametaselcualtratalosrequisitosnofuncionalescomosoftgoalsu“objetivosblan-dos”,queseexpresanenelSoftgoal Interdepence Graphic (SIG) o Diagrama de Interdependencia de Softgoal. El SIG solo considera lasmetas nofuncionalesosoftgoals en contraposición con los hardgoalsu“objetivosduros”,quecorrespondenametas funcionales.Lossoftgoals corresponden aobjetivosno funcionalesapartirde los cuales,a través de operacionalizaciones (soluciones), se permiten derivar componentes arquitectónicos(Chung,NixonyYu,1995;ChungyYu,1998).Unaoperacionalizacióncorrespondeaunmecanismoocomponentearquitectónicoque“satisface”oesuna solución para el cumplimiento del softgoal (Chung,1991;Chung,Nixon,yYu,1995).

GRL,alintegrarloscitadoslenguajesyen-foquesorientadosametas,facilitaladeteccióndeaquellosrequisitosqueseoriginanenelcontextodelnegocioydebensertrasladadosalsoftwareylaresolucióndeconflictosatravésdeopcionesalter-nativasdemetasencompetencia,facilitandounasolucióndediseñoquesatisfagalasmetasuobje-tivosdecalidadrequeridosaniveldenegocio.EnGRLexistentrescategoríasprincipalesdeconcep-tos,talescomo:a)actores:sonlostitularesdelasintenciones,entidadesactivasdelsistemaodesuentorno(p.e., losstakeholdersuotrossistemas)que tienen intenciones y efectúan acciones parasatisfacermetasfuncionalesonoyrealizartareasutilizandosuknow-howylosrecursosqueseen-cuentrandisponibles.b)elementos intencionales:

cificarrequisitosdeunsistemadesoftware.GRL es unlenguajeorientadoametasycentradoenelra-zonamientoacercadelosrequisitos,especialmentesobre losrequisitosnofuncionalesy losrelativosatributosdecalidadquemidenestosrequisitosnofuncionales.Proporcionaconstruccionesparaex-presar los diferentes conceptos de la Ingeniería de Requisitos.GRL tienesusraícesendosenfoquesde modelado orientado a metas, i*(YuyMylopou-los,1993)yelNFR Framework(Chung,1991).

Ellenguajei*, iniciadoporYuyMylopou-los (1993), se centra en procesos de negocio, elcual admite la gestión sistemática e intencionaldemetasfuncionalesynofuncionales,partiendodelmodeladodeprocesosdenegocio,hastallegara los componentes arquitectónicos (ChungyYu,1998)(Chung,GrossyYu,1999).Estásoportadoporunlenguajeconunanotaciónysemánticadi-námica,fundamentadaenlanocióndeintencióndelosactores,quienesactúandemaneraautóno-ma,enelcumplimientodemetas(Yu,1997).Adi-ferencia de otras técnicas de modelado orientadas a metas, por ejemplo KAOS, (Van Lamsweerde,2001), en las cuales las metas se descomponendurante el proceso de diseño en unmodelo delproceso de negocio, en i*lasmetasseencuentranintegradasenlosactores(Yu,1997).Elenfoquei* tieneporobjetolaidentificación,representación,organización,análisisyjustificacióndemetastan-tofuncionalescomonofuncionales,bajolanociónde relaciones intencionales entre actores de unsistema(Yu,StrohmaieryDeng,2006).Tambiénfacilitaelanálisisdeldominioyelmodeladodelambienterepresentadoporlosactoresysusrela-ciones(Lapouchnian,2005).

18


en GRLestánintegradospormetas,softgoals, ta-reas,recursosycreencias,yc)vínculos:sonusa-dos para conectar elementos aislados del modelo derequisitos.Losdiferentestiposdevínculosre-presentan lasdistintas relaciones estructurales eintencionales(incluyendodescomposiciones,con-tribucionesydependencias).

Por otra parte, GRLsoportaanálisisdees-trategiasqueayudanaresolverdemaneraadecua-

Gráfico 2

Modelo conceptual de GRL. ITU-T(2003)

dalosconflictos(tradeoffs)subyacentesentrelasmetas de los stakeholders. Una estrategia consis-teenunconjuntodeelementosintencionalesqueson de valor para la satisfacción inicial de la meta. Estosvaloresdesatisfaccióncapturansituacionescontextualesofuturas,asícomotambiénpermiteelegir entre medios alternativos para alcanzar las referidas metas.

IntentionalElement

+type: IntentionalElementType+decompositionType: DecompositionType = AND+importance: ImportanceType = NONE+importanceQuantitative: Integer = 0

<<enumeration>>ImportanceType

+High+Medium+Low+None

<<enumeration>>IntentionalElementType

+Softgoal+Goal+Task+Resource+Belief

<<enumeration>>ContributionType

+Make+Help+Some++Unknown+Some-+Hurt+Break

<<enumeration>>DescompositionType

+AND+XOR+IOR

Contribution

+contribution: ContributionType = Unknown+quantitativeContribution: Integer = 0+correlation: Boolean = false

Decomposition

Actor

GRLspec

Dependency

ElementLink

GRLmodelElement

GRLLinkableElement

+grlspec

+grlspec

+dest

+src

+grlspec +actors+actor

+elems

+linkDest

+linksSrc

+links 0..*0..*

0..*

0..*

0..*

0..1

0..*+intElements

19

N° Regla

Lenguaje BPMN Lenguaje GRL Regla para la

Correspondencia Término DefiniciónNotación Gráfica

Término DefiniciónNotación Gráfica

1Process o Proceso

Actividad realizada dentro o a través de empresasuorganizaciones (OMG,2009).

Texto

Hardgoal o MetaFuncional

Condición o estado deunasuntoquea los stakeholders lesgustaríalograr(ITU-T,2008).

Un ProcesodeBPMNrepresentaunaMeta FuncionalenGRL.

2Subprocess o Subproceso

Agregación de actividadesquesonincluidasdentrodeunProceso(OMG,2009).

Un SubprocesodeBPMNrepresentaunaMeta FuncionalquehasidodescompuestaenGRLenotras metas de nivel inferior


En el Gráfico 2,presentamosunmodeloconceptualdeGRLdelITU-T(2008)elcualseuti-liza como marco de referencia para la correspon-denciasemánticapresentadaen lasiguientesec-ción,enlacualsederivandiagramasdeprocesosde negocio de BPMN en modelos de GRL.

Pasos y reglas para la correspondencia entre los lenguajes BPMN y GRL

EnCysneirosyYu(2004)yKoliadisyotros(2007) se plantean algunas reglas de derivaciónpara pasar de unmodelo de i* a unmodelo deBPMNenuncontextodereingeniería,esdecirapartirdeI*sereconstruyenlosprocesosdenego-cios.Ennuestrotrabajo,tomamoslaregla“Identi-ficacióndeActorescomoPools”deCysneirosyYu(2004)y la regla“Cualquieractorenunmodelo

i*esunparticipante(Pools o Lines)enBPMNyviceversa”yelpaso“Identificarlosactoresinter-nosyexternoseneldiagramadei*yviceversa”deKoliadisyotros(2007).ParaincorporaraBPMNelconceptodemetanofuncional,lacualpuedeserexigidaporunprocesoconmetafuncional,consi-deramosquelastareasenunprocesoosubproce-sodenegocio,tienenasociadasmetasfuncionalesy/onofuncionalesenGRL.Identificamosladife-renciaentretareasfuncionalesynofuncionalesenBPMNcolocandounaetiqueta<<MNF>>sobreelvínculo de asociaciónentrelastareasqueposeenmetas no funcionales (softgoals en GRL). Debeobservarsequeaunsubproceso,quesecomponede tareas, también podemos aplicar la asociación etiquetadasiimplicaunametanofuncional.EnelCuadro1sepresentandiezreglasparalacorres-pondenciasemánticaentreBPMN yGRL.

Cuadro 1

Reglas de correspondencia semántica aplicables entre los lenguajes GRL y BPMN

20

3Pool

Participantes (entidadeso roles de negocio)(OMG,2009).

Actor

Entidades activas quellevanacabociertas acciones para lograr metas (ITU-T,2008).

Un PooldeBPMNrepresentaun Actor en GRL.

4Lane o Carril

Organizanycategorizan actividades de unPool (OMG,2009).

Role o Papel

Caracterización abstracta del comportamiento deunactor(Amyotyotros,2009).

Un CarrildeBPMNesdescrito como el PapeldeunActorconcretoenGRL.

5 Task o Tarea

Esunaactividad atómica(OMG,2009).

Task o Tarea

Esunamaneraparticulardehaceralgo(ITU-T,2008).

Una TareadeBPMNrepresentaunaTarea particularenGRL.

6

LabeledAssociation oAsociaciónEtiquetada

Muestralaasociación entreunatareaosubprocesofuncionalyunaMetaNofuncional,«MNF»

SoftgoaloMetaNoFuncional

Esunacondicióno estado de unasuntodelmundoquealosstakeholders les gustaríalograr(ITU-T,2008).

UnaAsociaciónEtiquetada deBPMN relacionaunatareafuncionalosubprocesodeBPMNcon un Softgoal enGRL.

7Data Object uObjetodeDatos

Artefactoquesuministrainformación a las actividades a ser realizadas (OMG,2009).

Resource o Recurso

Entidad física o informacional queexpresanecesidades (ITU-T,2008).

Un Objeto de Datos en BPMNrepresentaunRecursodeGRL.

8Gateway o Compuerta

Controlan la interacción, convergencia o divergencia dentrodeunproceso(OMG,2009).

Task descompo-sition link o Vínculodedescomposición de tarea

Tipodevínculoquedescomponeunatareaenunhardgoal, subtask, resource o softgoal (ITU-T,2008).

Una CompuertaenBPMNrepresentaunVínculo de descomposición de tareas (And/Xor/Ior)deGRL.

9

Sequence Flow o FlujodeSecuencia

Muestralasecuenciadeactividadesqueson realizadas enunproceso(OMG,2009).

Means-Ends linkoVínculosMedio-Fin

Relación binaria entreunfinyel medio para lograrlos. El “medio”representaunatareayel“fin”unameta(ITU-T,2008).

Un Flujo de Secuencia enBPMNrepresentaunVínculo Medio-FinenGRL.

10Message FlowoFlujodeMensaje

Muestraelflujodemensaje entre dos entidades (OMG,2009).

Dependency linkoVinculodedependencia

Relación intencional entre dosactores(ITU-T,2008).

Un Flujo de Mensaje en BPMN representaunVínculo de Dependencia entredosactoresenGRL.


Tarea 1

.................«MNF»

Actor

Actor <<Role>>

21


A continuación se presentan cuatro pasosprincipalesaseguirparalograrlareferidacorres-pondencia.

Pasos para la correspondencia entre BPMN y GRL

Paso 1. En base al Diagrama del Proceso de Ne-gocio (DPN) de BPMN, definir la Meta Funcional Medular (objetivo principal del proceso designa-da por los stakeholders) y posibles vínculos de de-pendencias del modelo de negocio en GRL Aplica la Regla 1.

Paso 2. En base a los Pools y los Lanes del DPN de BPMN, definir los Actores y Roles en GRL. Aplican las Reglas 3 y 4.

Paso 3. Identificar Pools, Lanes, Subprocesos, Tareas y asociaciones, Objetos de datos y Com-puertas en el DPN de BPMN y hacerlas corres-ponder con Metas Funcionales, Metas No Fun-cionales y Tareas en el modelo de negocio de GRL:

Paso 3.1. Detectar Metas No Funcionales que estén asociadas a aspectos no funcionale del negocios (como por ejemplo algunas reglas del negocio, restricciones de plataforma) en BPMN y asociarlas con las Metas No Funcionales o soft-goals de GRL. Aplica la Regla 6. Debe observarse queenBPMNnoexisteunanotaciónexplícitaparaexpresarposiblesrestriccionesometasnofuncio-nalesrelacionadasconunprocesoosubprocesodenegocio;porlotantoconsideramosquelastareas pueden ser utilizadas con este fin: las tareas no

funcionales,sedistinguendelasfuncionalesporelvínculodeasociaciónetiquetadopor<<MNF>>.Aunsubprocesotambiénpuedeaplicarselaaso-ciaciónetiquetada.Enparticularunaregladelne-gociopuedeserunsoftgoal potencial, por ejemplo exigircontroldeaccesoparaciertotipodeusua-rios,esunsoftgoalrelacionadocontenerseguri-dadparaelaccesodeusuarios.

• Paso 3.2. Asociar Tareas, Objetos de datos y Compuertas expresados en BPMN con Tareas, Recursos y Vínculos de Descomposición de Tareas en GRL. Aplican las Reglas 5, 7 y 8.

• Paso 3.3. Los subprocesos expresados de BPMN se definen como una descomposición de una Meta Funcional en GRL y los elementos subyacentes son representados de acuerdo a las reglas y pasos que tengan lugar. Aplica la Regla 2ynuevamentelaRegla 6, de ser el caso.

Paso 4. En base a los diferentes elementos que se encuentran presentes en los Pools y los Lanes del DPN de BPMN, establecer vínculos en GRL:

• Paso 4.1. Definir Vínculos de Dependen-cia entre los diferentes elementos de GRL. Aplica la Regla 10.

• Paso. 4.2. Generar vínculos medio-fin en GRL a partir de flujos de secuencias explicita-dos en BPMN. Aplica la Regla 9ylaexperienciadelIngenierodeRequisitos.

• Paso. 4.3. Identificar los Vínculos de Correlación entre Metas No Funcionales en GRL.

• Paso. 4.4. Establecer las Contribucio-nes entre las Metas Funcionales o No Funcionales en GRL.

22


Trabajos relacionados

Cysneiro y Yu (2004) muestran cómo i* puedeserusadocomofront-end a las tecnologías de modelado del proceso de negocio para incorpo-rarautonomíaenlosactoresydisminuirlabrechaentreestosyloslenguajesdemodeladodelprocesode negocio, tales como BPMN:unavezestablecidoel proceso en i*, éste se deriva a BPMN.Koliadisyotros(2007)planteanqueelmanejodecambiosenelciclodevidadeunprocesodenegociopuedeser soportado efectivamente combinando diferen-tes notaciones. El trabajo intenta representar los cambiosrealizadosdeunmodeloi*aunmodelode BPMN.EnKoliadisyGhose(2007)seproponeun enfoquemetodológicopara vincularmodelosbasados en BPMN ametas de alto nivel usandoKAOS(Knowledge Acquisition in autOmated Spe-cification)(VanLamsweerde,2001),peronocon-sideran a i*.Envistadequelosrequisitosnofun-cionalesnosonexplícitamentetratadosenBPMN, PavloskyyZou(2008)proponenunaclasificaciónderequisitosnofuncionalesasociadosalprocesode negocio, en operacionales (rendimiento, con-fiabilidad,seguridad,tiempoderespuesta,calidaddelservicioydisponibilidad,sinespecificarlasde-finicionesdeestosrequisitos)yno operacionales queincluyenconsideracionesrelativasalatecno-logía; proponen dos conceptos, la condición de operación y el caso de control, respectivamente, paracapturarestosrequisitosdealtonivelduran-teelmodeladodelprocesodelnegocio.DiFran-cescomarino y Tonela (2008) proponen el usode Semantic Annotations oAnotacionesSemán-ticascomomecanismosparatratarlosrequisitosnofuncionalesasociadosa lasactividadesdonde

tales restricciones son aplicadas.Nuestro aporterespectoalosenfoquescitadosconsisteenhaberutilizadoGRLenlugardeI*,lenguajemásgeneralqueenglobaaI*,yproponerelusodetareasylasasociacionesetiquetadascomomecanismosparatratar losaspectosno funcionales.Enestesenti-do,ampliamoslosreferidosenfoquesparaelesta-blecimiento de los pasos y reglas necesarias para establecerlacorrespondenciasemánticaentreloslenguajesBPMN y GRL,demaneradereducirlabrechaexistenteentrelasmetasorganizacionalesy sus sistemas de software, destacando aspectosno funcionalesen lasetapas tempranasdel ciclodevidadeldesarrollodesoftware.Estacorrespon-denciapuedeserutilizadaenuncontextoderein-genieríaeingenieríademodelos,particularmentepara la derivación de un modelo arquitectónicodelsistemaapartirdeunmodelodenegocio.

Caso de estudio

SeconsideraunDPNdelprocesodeGes-tión de Trámites de Solicitudes (GTS) de laDi-reccióndelTalentoHumano,queinvolucraalasUnidadesMedularesdelCentroNacionaldeTec-nologíasdeInformación(CNTI).ElprocesoGTSpermiteelestablecimientodeflujosdetrabajooworkflows, según la estructura organizativa ensusnivelesgerencialesconelpropósitodeauto-matizar los procesos de solicitudes de: Viáticos(asignación financiera paramanutención) y Pa-sajes,Vacaciones,Permisos,Préstamos (implicael requisitono funcionalprecisión), entreotras.Lametafuncionalmedular,dealtonivelorgani-zacional,estácentradaenGestionarTrámitesdeSolicitudespormedioderedesseguras(implicael

23

«MNF»

«MNF»

«MNF»

sultar Cadera de Aprobación


requisitono funcional seguridad) con el propó-sitodegarantizarlasatisfaccióndelusuariofinal(implica el requisito no funcional usabilidad) ydisminuir los tiemposde respuestas de las soli-citudes a lo sumo tresdías (implica el requisitonofuncionaleficiencia).Seaplicaránlasreglasypasos descritos en la sección anterior para derivar elmodeloGRLdeunsistemaautomatizadoparaGTS,apartirdeldiagramadelprocesodenegociodeGTSexpresadoenBPMN.

En la Figura 1, se observa el DPN GTSexpresadoenBPMNmediantelaherramientaBi-zAgi Process Modeler(BizAgiLtd,2008).Acon-tinuaciónseaplicanlasreglasdecorrespondenciasemánticadelcuadro1alcitadocasodeestudio,paraderivarunModeloenGRLexplicitadoenlaFigura2,utilizandocomoherramientajUCMNav (Mussbacher,2010),dondeutilizamoslanotaciónBPMNde laOMG(2009)y lanotaciónGRL del ITU-T(2008):

Figura 1

Modelo de negocio GTS expresado en BPMN

≡

NotificarRechazo de

Solicitud

EnviarSolicitud

EnviarAprobación de

Solicitud

RechazarSolicitud

Precisión

Seguridad

Usabilidad Eficiencia

Revisar Solicitudes Control de Acceso

Viáticos yPasajes

Vacaciones

Permisos

AprobarSolicitud

Asignar Estatusa la Solicitud

Supe

rvis

orEm

plea

do

Usu

ario

Realizar Solicitud Control de Acceso

«MNF» «MNF»«MNF»

«MNF»

«MNF»

«MNF»

Asignar Estatus a la Solicitud Aprobado

Asignar Estatus a la Solicitud

Estatus?

En proceso

NotificarAprobación de

Solicitud

24


Aplicación de las reglas de correspondencia semántica al proceso de negocio de GTS

Paso 1. En base al Diagrama del Proceso de Ne-gocio (DPN) de BPMN, definir la Meta Funcional Medular (objetivo principal del proceso designa-da por los stakeholders) y posibles vínculos de dependencias del modelo de negocio en GRL. Ba-sándonosenlaRegla 1,definimoslametaprin-cipal del proceso de negocio GTS, denominadoGestionar Trámites de Solicitudes y el nombre del modelodeprocesodenegocioenGRL,denomina-do Modelo de Negocio de Gestión de Trámites de Solicitudes.

Paso 2. En base a los Pools y los Lanes del DPN de BPMN, definir los Actores y Roles en GRL. Losactores derivados de la Regla 3,son:Usua-rio, IngenierodeSistemas,GestordeSolicitudesy Administrador. De la aplicación de la Regla 4, definimosdosroles en el actorUsuarioyaqueestejuegalosrolesdeEmpleadoydeSupervisor(verFigura 2).

Paso 3. Identificar Pools, Lanes, Subprocesos, Tareas y asociaciones, Objetos de datos y Com-puertas en el DPN de BPMN y hacerlas corres-ponder con Metas Funcionales, Metas No Funcio-nales y Tareas en el Modelo de Negocio de GRL:

Paso 3.1. Detectar tareas funcionales y que estén asociadas a tareas no funciona-les en BPMN y colocar la asociación etiquetada <<MNF>> y asociarlas luego con las Metas No Funcionales o softgoals de GRL. AcontinuaciónsedescribenloselementosquesubyacenalasMe-

tasNoFuncionales delprocesodeGTS,derivadosde la aplicación de la Regla 6:

Lane Usuario-empleado: tareas funciona-les: Viático y pasaje, Vacaciones y Permisos,quetienen asociada la tarea no funcional precisión; Enviar solicitud

Lane Usuario-supervisor: tarea funciona-les: Aprobar, Rechazar, Asignar estatus;

Los Lanes Usuario-Administrador, Usua-rio-Gestor de Solicitudes, y Usuario-Ingeniero de Sistemasnosemuestranaquíparanorecargarla presentación, sin embargo se repite el proceso descrito para todos estos elementos.

Paso 3.2. Asociar Tareas, Objetos de da-tos y Compuertas expresados en BPMN con Ta-reas, Recursos y Vínculos de Descomposición de Tareas en GRL. A continuación se describenlos elementos derivados de la aplicación de las Reglas 5, 7 y 8:

Usuario-empleado: Tareas:ViáticosyPa-sajes; Vacaciones; Permisos y Enviar solicitud.Vínculos de descomposición de tareas: Tipo de solicitudyEstatus.

Usuario-supervisor: Tareas: Aprobar Soli-citud,RechazarSolicitud,NotificarAprobacióndeSolicitud,EnviarAprobacióndeSolicitud,AsignarEstatusalaSolicitud,NotificarRechazodeSolici-tud.Vínculos de descomposición de tareas: Apro-baciónyEstatus.

Paso 3.3. Los subprocesos expresados de BPMN se definen como Metas Funcionales en GRL. Siinvolucrantareasnofuncionales,seaplicanuevamentelaRegla 6.

25


ElsubprocesoRealizar Solicitud tiene aso-ciadolastareasnofuncionales:Usabilidad, Preci-sión, Eficiencia y Seguridad.

El subproceso Revisar Solicitud tambiéntieneasociadolastareasnofuncionales:Usabili-dad, Eficiencia y Seguridad.

AcontinuaciónsedescribenlasMetas Fun-cionales en GRLresultantesdelaaplicacióndelaRegla 2alprocesodenegociodeGTS,presentadoen la Figura 2.

Usuario-empleado: Metas Funcionales: Realizar Solicitud, Control de Acceso y AsignarEstatusalaSolicitud.

Figura 2

Modelo de negocio de la gestión de trámites de solicitudes expresado en GRL

Control de AccesoControl de AccesoUsabilidad

Enviar Solicitud

Rechazar Solicitud

Notificar Rechazode la Solicitud

Enviar Aprobaciónde la Solicitud

Notificar Aprobación de la

Solicitud

Viáticos y Pasajes

Empleado <<Role>> Supervisor <<Role>>

Or

Or

Or

Or

Or

And

And

And

Aprobar Solicitud

Permisos

Vacaciones

GestionarTrámites deSolicitudes

Consultar Cadenade Aprobación

Asignar Estatus ala Solicitud

Asignar Estatus ala Solicitud

Realizar Solicitudes Revisar Solicitudes

7575

-100

-100-100

-100

Cadena deAprobación

Estatus

Precisión Seguridad

Eficiencia

Usabilidad

26

Usuario-supervisor: Metas Funcionales: Revisar Solicitudes, Control de Acceso, AsignarEstatusalaSolicitudyConsultarCadenadeApro-bación.

Los subprocesos presentados a continua-ción no son desarrollados en este trabajo para no recargar la presentación, pero siguen el mismoproceso descrito anteriormente.

Gestor de Solicitudes: Metas Funcionales: MonitorearSolicitudes.

Administrador: Metas Funcionales: Ges-tionarUsuarios,ControldeAccesoyAsignarPer-misosalUsuario.

Ingeniero de Sistemas: Metas Funcionales: GestionarWorkflow,ControldeAcceso,Configu-rar Workflow.

Paso 4. En base a los diferentes elementos que se encuentran presentes en los Pools y los Lanes del DPN de BPMN, establecer vínculos en GRL:

Paso 4.1. Definir Vínculos de Depen- dencia entre los diferentes elementos de GRL. Se definieron los Vínculos de Dependencia im-plícitos entre las tareas, recursos,metas funcio-nalesynofuncionalesenbasealaRegla 10(verFigura 2).

Paso. 4.2. Generar vínculos medio-fin en GRL a partir de flujos de secuencias explicitados en BPMN. En el actorAdministradorsedefinióunVínculoMedio-Finque tienecomomedioCrear,ModificaryEliminarCuentaycomofinGestionarUsuario,enbasealaRegla 9.

Paso. 4.3. Identificar los Vínculos de Co-rrelación entre Metas No Funcionales en GRL. SedefinieronlosvínculosdecorrelaciónentrelasmetasnofuncionalesUsabilidad,Eficiencia,Pre-cisiónySeguridad(verFigura 2).

Paso. 4.4. Establecer las Contribuciones entre las Metas Funcionales o No Funcionales en GRL. Se definieron las contribuciones entre lasmetas funcionalesyno funcionalesespecificadasenlospasosanteriores.EnlaFigura2semuestranlasmetassatisfechas(),pocosatisfechas(.),enconflictos (), poco denegadas (.), denegadas()ydesconocidas(?).

Conclusiones

El lenguajeBPMN, centrado en eventos y dirigido a aspectos esencialmente funcionales,facilita la comprensión del dominio del problema para plantear soluciones funcionales desde unaperspectivaclásicadelaIngenieríadeNegocio.Esmuyutilizadoen laprácticaen la industriaparaespecificarprocesosdenegocio.Sinembargo,ca-rece de una notación explícita para representaraspectos no funcionales, los cuales son impres-cindibles para derivar el modelo arquitecturalinicial del sistema de software que correspondealprocesodenegocioquesequiereautomatizar.Asímismo,esahoradecomúnaceptaciónquelosaspectos no funcionales deben ser consideradostemprano en el proceso de desarrollo, para evitar dificultades posteriores de mantenimiento. Porotraparte,el lenguajeGRLdenaturaleza lógica,dirigidoporobjetivosyorientadoalcumplimientodemetas por actores, explícita las dependencias


27

entre actores y el razonamiento asociado y desta-catambiénaspectosnofuncionales,loscualesnosoncontempladosenBPMN.Parapoderexpresaraspectosnofuncionalesenetapastempranasdelciclodelsoftware,enparticulardesdelaperspecti-vadelnegocioquerequiereelsistema,sepresentaunacorrespondenciasemánticaentreloslengua-jes BPMN y GRL,lacualpuedeserutilizadaparacubrirladeficienciadeBPMNencuantoaltrata-mientodemetasnofuncionales,ayudandoaredu-cirlabrechaentrelasmetasorganizacionalesysussistemasdesoftware.Utilizamoslanocióndeta-reasnofuncionales(asociadasametasnofuncio-nales)comomecanismosparatratarlossoftgoals de GRL en BPMN. Diferenciamos entre tareas funcionalesynofuncionales,locualestásupedi-tadoaltipodevínculoutilizadoenlatarea:pararepresentar las tareas no funcionales utilizamoslosvínculosdeasociación.Asímismo,esbozamosquelasreglasdecorrespondenciaaquípropuestaspuedenserutilizadasenuncontextodereingenie-ríadeprocesostalcomoenelcasodeestudiopre-sentado en este trabajo y como marco de referen-ciaparalageneracióndetransformacionesdeundiagrama del proceso de negocio de BPMNaunmodelo de GRL y viceversa. En referencia al caso deestudio,utilizamosunprocesodenegociodelmundorealcorrespondientealaGestióndeTrá-mitesdeSolicitudesdelCNTI.Entrabajosfuturosproponemosextenderlospasosyreglasparalaco-rrespondenciasemánticaaquípropuestaparare-finarytratarmetasnofuncionalesexpresadasenGRLcomoincumbenciastransversalescandidatasaaspectosparallegaraunmodelodearquitecturainicial, considerandounenfoqueorientadoaas-pectos.

Agradecimiento

QueremosagradeceralPhD.DanielAmyot,miembro activo del Sector de Estandarización de lasTelecomunicacionesdelaorganizaciónInter-national Telecommunication Union(ITU)porha-bernossuministradocopiadelosestándaresz.150(2003)yz.151(2008)deesaprestigiosainstitu-ción. Así mismo agradecemos a los earbitros por la cudadosalecturayelesfuerzohechoparamejorarla calidad de este trabajo.

Bibliografía

Amyot, D., Horkoff, J., Gross, D. y Mussbacher, G.(2009).A Lightweight GRL Profile for i* Mode-ling.Heidelberg,Berlin:Springer.

BizAgiLtd.(2008).BPM BizAgi. Disponible en: http://www.bizagi.com/.[Recuperado:24deMarzode2010].

BPMIG.(2002).Business Process Modeling Language. GLiNTECH,pp.1-45.

Burlton,R.(2001).Effective Business Change through Process Management:StrategiesandArchitec-tures for Integrated Change. Process RenewalGroup.

Chung, L. (1991). Representation and Utilization of Non_Functional Requirements for Information System Design. CAiSE 91, 3rd Int. Conf.Advanced Information Systems Eng.(pp.5-30).Norway,Berlin:Springer-Verlag.

Chung, L. y Yu, E. (1998). Achieving System-Wide Architectural Qualities.Proc.ofOMG-DARPA:MCC Workshop on Compositional SoftwareArchitectures. Monterey,California, USA:CiteSeerX.


28

Chung, L., Gross, D., y Yu, E. (1999). Architectural design to meet stakeholder requirements. In Donohue Software architecture (pp. 545-564).Texas,USA:KluwerAcademicPublishers.

Chung, L., Nixon, B., y Yu, E. (1995). Using Non-Functional Requirements to Systematically Select Among Alternatives in Architectural Design. Proc. of 1st Int. Workshop onarchitectures for Software System (pp. 31-32).Seattle,Washington:CiteSeerX.

Crusson, T. (2006). Business Process ManagementEssentials. Glintech.

Cysneiros, L., y Yu, E. (2004). Addressing Agent Autonomy in Business Process Management - with Case Studies on the Patient Discharge Process. Proc. of the Information ResourcesManagement Association Conference. NewOrleans,USA:ACM.

Di Francescomarino, C., y Tonella, P. (2008).Supporting Documentation and Evolution of Crosscutting Concerns in Business Processes. Proc. ICSOCPhDSymposium2008 collocatedwith 6th International Conference on ServiceOriented Computing (ICSOC). Sydney, Australia:CiteSeerX.

Hammer,M.,yChampy,J.(1993).Reengineering the Corporation.NewYork,US:HarperCollins.

Hepp,M.,yRoman,D.(2007).An Ontology Framework for Semantic Business Process Management. Proc. of the 8th international conferenceWirtschaftsinformatik (pp. 1-18). Karlsruhe:Springer.

ITU-T. (2008).User Requirements Notation (URN)-Language Definition: Recommendation ITU-T Z.151. ITU, pp. 1-206.

ITU-T. (2003).User Requirements Notation (URN)-Language requirements and framework: Recommendation ITU-T Z.150. ITU, pp. 1-29.

Koliadis, G., y Ghose, A. (2007). Relating Business Process Models to Goal-Oriented Requirements Models in KAOS. Proc. of the Pacific-RimKnowledge Acquisition Workshop. Australia:TheBerkeleyElectronicPress.

Koliadis,G.,Vranesevic,A.,Bhuiyan,M.,Krishna,A.,yGhose,A. (2007).A combined approach for supporting the business process model lifecycle. Proc.ofAsia-PacificConferenceonIS(pp.1-13).Wollongong:ComputingScience.

Lapouchnian,A.(2005).Goal-Oriented Requirements Engineering: An Overview of the Current Research. Toronto: University of Toronto.

Mussbacher, G. (2010). jUCMNav. Disponible en: http://jucmnav.softwareengineering.ca/ ucm/bin/view/ProjetSEG/WebHome . [Recuperado:15deOctubrede2010].

OMG. (2009). Business Process Modeling Notation Specification,Ver.1.2.OMG,pp.1-294.

Pavlovski, C. y Zou, J. (2008). Non-FunctionalRequirements in Business Process Modeling.In Proc. Fifth Asia-Pacific Conference onConceptual Modelling (APCCM 2008),Wollongong,NSW,Australia.CRPIT,79.Hinze,A.andKirchberg,M.,Eds.ACS.103-112.

Van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour.Proc.ofRE’01-InternationalJointConferenceon Requirements Engineering (pp. 249–263).Toronto: IEEE.

White,S.(2004).Business Process Modeling Notation (BPMN), Version 1.0. Business ProcessManagementInitiative(BPMI.org).1.0edn.


29

Yu, E. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering.Proc.of the3rd IEEEInt.Symp.on Requirements Engineering (pp. 226-235).IEEEComputerSocietyWashington,DC,USA:IEEE.

Yu, E. (1997). Why Agent-Oriented Requirements Engineering. Proc. 3rd Int. Workshop onRequirements Engineering: Foundations ofSoftware Quality REFSQ’97, (pp. 171-183).Barcelona,Catalonia,Spain.

Yu,E.,yMylopoulos,J.(1993).An Actor Dependency Model of Organization Work-With Application to Business Process Reengineering. Proc. Conf. onOrganizationalComputingSystems(COOCS‘93)(pp.258-268).California:IEEE.

Yu,E., Strohmaier,M., yDeng,X. (2006).Exploring Intentional Modeling and Analysis for Enterprise Architecture. Proc.of the EDOC2006 Conference Workshop on Trends inEnterpriseArchitecture Research. Hong Kong:IEEEComputerSociety.


Correspondencia Semántica entre los lenguajes BPMN y GRL1

Documents

Transcript of Correspondencia Semántica entre los lenguajes BPMN y GRL1