Modelado de Procesos Inter-Organizacionales

6.
DISEÑO Y MODELADO DE PROCESOS

INTER-ORGANIZACIONALES
Curso: Gestión de Procesos de Negocio: Herramientas de software y sistemas

Docente: Dr. Pablo D. Villarreal
Bibliografía
 Villarreal, P., Salomone, E, Chiotti, O. Modeling and Specification of Collaborative Business Processes with
a MDA Approach and a UML Profile. Enterprise Modeling and Computing with UML, Editor: P. Rittgen,
Idea Group, Inc., 2007
 Capítulo 2 (Online en: http://books.google.com.ar/ )
 Villarreal, P, Lazarte, I., Roa, J., Chiotti, O. Modeling Approach for Collaborative Business Processes based
on the UP-ColBPIP Language. Lecture Notes in Business Information Processing (LNBIP), vol. 43, pp. 318-
329, Springer-Verlag Berlin, 2010.
(https://sites.google.com/site/pablodavidvillarreal/publications/download-papers/CBP2009-Villarrealetal-FinalVersion.pdf?attredirects=0)
 Villarreal, P.D.: Método para el Modelado y Especificación de Procesos de Negocio Colaborativos. Tesis
Doctoral. UTN-Facultad Regional Santa Fe, 2005.
 Capítulo 3 y 4 (https://sites.google.com/site/pablodavidvillarreal/phd-thesis/download-
theses/TesisVillarreal.pdf?attredirects=0)
 Lazzarte, I., Villarreal, P., Chiotti, O., Thom, L., Iochpe, C. An MDA-Based Method for Designing
Integration Process Models in B2B Collaborations. 13th International Conference on Enterprise
Information Systems (ICEIS 2011), Beijin, China. SciTePress, 2011
 Lazarte, Ivanna: Diseño y Gestión de Modelos de Procesos de Negocio en Colaboraciones Inter-
organizacionales. Tesis Doctoral. UTN-Facultad Regional Santa Fe, 2013
Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 2

Colaboraciones Inter-organizacionales
Una colaboración inter-
organizacional implica llevar a
cabo un conjunto de acciones
cooperativas o colaborativas
entre organizaciones para un
período de tiempo dado, con el
propósito de alcanzar metas
comunes, coordinar sus
actividades e intercambiar
información, a través de la
ejecución de procesos inter-
organizacionales
Procesos de negocio de las organizaciones son integrados a

través de los procesos de negocio inter-organizacionales

Colaboraciones Inter-organizacionales
Dominios:
 Supply Chain Management
 e-Healthcare services
 e-Government
 e-Telecomunications
 En estos dominios, las cadenas de valor involucran varias

organizaciones
 Se utilizan modelos de referencia del dominio que
establecen reglas generales y los procesos inter-
organizacionales a ser llevados a cabo
Procesos de Negocio en Colaboraciones Inter-organizacionales
5
Proceso Colaborativo
 Define la vista global y pública del comportamiento de una
colaboración inter-organizacional, en términos de las interacciones
entre los participantes (organizaciones)
 Representa “El contrato” entre las partes respecto a cómo será el
comportamiento de la colaboración.
 Describe:
 Las organizaciones involucradas y los roles que desempeñan las mismas en el
proceso
 Un único flujo de control de las interacciones entre las organizaciones
 El intercambio de información y coordinación entre los participantes
 Alcanza una meta de negocio común acordada entre las partes

Proceso Colaborativo como Proceso Abstracto:

 Un proceso abstracto no contiene instancias
 El mismo es ejecutado a través de la través de los procesos de
negocio de cada participante, que contienen las tareas (públicas y
privadas) que soportan el rol que el participante desempeña en el
proceso colaborativo
 Los procesos de negocio de cada participante son instanciados y
gobernados por los SIOP de cada organización para llevar adelante
el “contrato” definido en el proceso colaborativo correspondiente
Modelado de Procesos Colaborativos
Un modelo de proceso colaborativo debería representar:
 Interacciones entre los participantes (organizaciones)
 Interacciones indican el intercambio de mensajes entre dos

participantes
 Vista Global de las interacciones entre los roles de los participantes
 Representación de las dependencias del flujo de control de las interacciones
 Autonomía de los participantes
 Actividades internas que procesan o consumen información intercambiada no
deben ser expresadas
 Representación de Negociaciones
 Colaboraciones inter-organizacionales implican definición de compromisos y
acuerdos mediante el intercambio de mensajes para tomar decisiones en
forma conjunta
 Perspectivas: Flujo de Control, de Datos, Recursos, Operacional

Modelado de procesos colaborativos con BPMN
 Object Management Group, Business Process Modeling Notation

(BPMN) 2.0.2, January, Dec 2013
http://www.omg.org/spec/BPMN/2.0.2/
 Versión 2 incorporó notaciones para procesos colaborativos

 Coreografía para representar procesos colaborativos
 Modelos de Coreografías son expresados en Diagramas de
Coreografía
 Actividades de Interacción para representar las interacciones en una
coreografía
 En una Coreografía, las actividades son interacciones que
representan a un conjunto de mensajes (uno o más) que involucran
dos o más participantes (organizaciones)
 Principales elementos de BPMN para coreografías

Actividades de Interacción
 Involucran solo dos partes: Un
Iniciador (remitente) y un Receptor)
 One-way: un mensaje es
intercambiado del remitente al
receptor
 Two-way: dos mensajes son
intercambiados, el mensaje enviado
por el remitente es seguido por uno
de retorno desde el receptor

Comportamiento de Coreografías
 Puede ser comenzada por varios eventos de inicio y tener varios eventos de fin
 Los eventos no pueden ser de tipo “message”. Sólo eventos de Timer, Error o Signal
pueden ser expresados
 Una secuencia (o relación de precedencia) entre dos tareas de interacción
requiere que el iniciador de la segunda interacción esté involucrado en la
precedente (como iniciador o receptor)
 Interacciones sin dependencias se indican con un Gateway AND-split

Comportamiento de Coreografías
 Exclusive Gateway (data-based XOR-Split)
 Es la decisión interna de una de las parte  el dato a evaluar debe estar disponible
previamente a ambas partes mediante un mensaje enviado en interacción previa
 Event-based Gateway (event-based XOR-Split)

 Todas las interacciones alternativas deben tener el mismo remitente y receptor
 No se modelan eventos de mensajes. Timers pueden ser definidos
 Se ejecutará la interacción para la cual el receptor haya recibido el mensaje enviado
por el remitente. Las restantes serán ignoradas

 Ejemplo de Coreografía

Modelado de procesos colaborativos con UP-ColBPIP
UP-ColBPIP language (UML Profile for Collaborative

Business Processes based on Interaction Protocols)
Orientado a:
 Dar soporte al desarrollo dirigido por modelos de SIOPs que gestionen procesos
colaborativos
 Provee constructores para representar negociaciones, compromisos y obligaciones.
 Foco en la perspectiva de comunicación, no solo las perspectiva de actividades y datos
 Satisface los patrones de flujo de control para definir modelos de procesos colaborativos
 Soportado por cualquier herramienta case para UML
Villarreal, P, Lazarte, I., Roa, J., Chiotti, O. Modeling Approach for Collaborative Business Processes based on the UP-ColBPIP
Language. 3rd International Workshop on Collaborative Business Processes (CBP 2009), BPM 2009. LNBIP, vol. 43, pp. 318-
329, Springer-Verlag, 2010
Villarreal, P., Salomone, E, Chiotti, O. Modeling and Specification of Collaborative Business Processes with a MDA Approach
and a UML Profile. Enterprise Modeling and Computing with UML, Editor: P. Rittgen, Idea Group, Inc., 2007, pp 13-45, ISBN 1-
59904-174-X
Villarreal, P., Salomone, E, Chiotti, O. Transforming Collaborative Business Process Models into Web Services Choreography
Specifications. Lecture Notes in Computer Science, Vol. 4055 (2006) 50-65, Springer, Berlin / Heidelberg.

Enfoque top-down de modelado

• Desde los requerimientos de
negocio a los procesos
• Permite describir diferentes
vistas o perspectivas de una
colaboración inter-
organizacional

Colaboración Inter-organizacional
UP-ColBPIP model
1 (Cross-organizational
«B2BCollaboration»
VMI-based Collaborativ e Replenishment
«CollaborativeAgreement»
VMI-based Collaborative
Replenishment
Collaboration View)
Pincelap S.A. : Tractores Puma S.A.
«B2BRelationship» :Customer
Supplier
InterfaceWithCustomer InterfaceWithSupplier
UP-ColBPIP model
2 (Collaborative Process View
& Business Document View )
Jerarquía de Metas de
Negocio comunes
«BusinessGoal» «CollaborativeAgreement»
Decrease Inv entory Av erage Lev els :Quantitativ eGoal VMI-based Collaborativ e Replenishment
UP-ColBPIP model updateFrecuency = Two months + startDate: date = 01/05/2004
3
computationMethod = Sum I(p,t)/N, t=1..N, p=producto + endDate: date = 31/04/2005
unitOfMeasurement = Product Units + productList: string = [P11, P12]
targetValue = 1500
(Interaction Protocol View )

+ productPrices: float = [115, 210]
currentValue = 2500 + currecyType: string = USD
+ leadTime: String = LT for P11: 4 d...
tags + minIntentoryLevels: String = 1000 for P11; 1...
goalDescription = The main objective of a VMI model is decrease the customer's inventory + maxInventoryLevels: String = 2500 for P11; 3...
+ acceptableToleranceForChangeInPlans: int = 20
«BusinessGoal» «BusinessGoal»
Accurate Demand Forecast :Quantitativ eGoal Reliable Consumption Schedule :Quantitativ eGoal
UP-ColBPIP model
4 «BusinessGoal» «BusinessGoal»
(Business Interface View ) Reliable Replenishment Schedule :Quantitativ eGoal Effectiv e Replenishment :Quantitativ eGoal
 Define los participantes, los roles de los mismos y las metas de negocio ha ser
alcanzadas en una colaboración inter-organizacional
 Extiende la semántica de las Colaboraciones y las Clases de UML2

Vista de Procesos Colaborativos y Documentos de Negocio
UP-ColBPIP model
1 (Collaboration View)
Identificación de los Procesos
Colaborativos y Documentos de
«BusinessGoal»
Accurate Demand Forecast
Negocio «BusinessGoal»
Effectiv e Replenishment :
UP-ColBPIP model :Quantitativ eGoal
(from Agreement and Business Goals)

«BusinessGoal»
Decrease Inv entory Av erage Lev els :
Quantitativ eGoal
2 (Collaborative Process View

«Achieve»
«Collaborativ eBusinessProcess»
Quantitativ eGoal

«Achieve»
Release Agains Blanket Purchase
& Business Document View ) Blanket Purchase Order

«Achieve»
Order
«Subprocess» «Subprocess»
Forecast-based VMI
«Subprocess» «Subprocess»
Tractores Puma S.A. :
Pincelap S.A. :Supplier
Customer
«Collaborativ eBusinessProcess» «Collaborativ eBusinessProcess»

Consumption Schedule Condition: {Acceptable tolerance for Replenishment Schedule
UP-ColBPIP model Puntos de Extensión:

change was violated}
Puntos de Extensión:
3
exception point: T oleranceVerification Inv entoryVerification
ToleranceVerification
(Interaction Protocol View ) «Achieve»

Condition:
{InventoryLimitsWereNon-Fulfilled}
extension point: InventoryVerification
«Achieve»
«Exception»
«Exception»
«BusinessGoal» «BusinessGoal»
Reliable Consumption Schedule : Reliable Replenishment
Quantitativ eGoal «ExceptionProcess» Schedule :Quantitativ eGoal
«ExceptionProcess»
Forecast Exception Replenishment Exception
(from Agreement and Business Goals) (from Agreement and Business Goals)
UP-ColBPIP model
4
(Business Interface View )
 Define los procesos de negocio colaborativos requeridos para alcanzar las metas
de negocio definidas en la colaboración inter-organizacional
 Extiende la semántica de los Casos de Uso de UML2

Vista de Protocolos de Interacción
UP-ColBPIP model
Protocolos de Interacción
UP-ColBPIP model
2 (Collaborative Process View sd <<protocol>> Nombre del Protocolo
& Business Document View ) Partner X :Role A Partner Y :Role B

Request (DemandForecast)
{t=now}
Xor
[Condition-1]
agree (ForecastResponse)
UP-ColBPIP model {t..t+2d}
3 (Interaction Protocol View ) [Condition-2]
refuse (ForecastResponse)
{t..t+2d}
[Success]
UP-ColBPIP model REF

4 Subprotocol X
 Define los protocolos de interacción que describen el comportamiento formal

de los procesos colaborativos
 Extiende la semántica de las Interacciones de UML2

Modeling Collaborative Business Processes: UP-ColBPIP Language
UP-ColBPIP model
UP-ColBPIP model
2 (Collaborative Process View Business Interfaces of the
Partners
& Business Document View )
«PartnerRole»
VMI-based Collaborativ e Replenishment::
Supplier
SupplierInterfaceToCustomer
CustomerInterfaceToSupplier «PartnerRole»
VMI-based Collaborativ e Replenishment::
InterfaceWithCustomer
Customer
UP-ColBPIP model CustomerInterfaceToSupplier
3
SupplierInterfaceToCustomer
InterfaceWithSupplier
(Interaction Protocol View )

«BusinessInterface» «BusinessInterface»
SupplierInterfaceToCustomer CustomerInterfaceToSupplier
+ «BusinessService» propose(BlanketPurchaseOrder) : void + «BusinessService» propose(BPOChange) : void

+ «BusinessService» accept-proposal(BPOChangeResponse) : void + «BusinessService» accept-proposal(BPOResponse) : void
+ «BusinessService» reject-proposal(BPOChangeResponse) : void + «BusinessService» inform(ShipNotice) : void
+ «BusinessService» propose(BPOChange) : void + «BusinessService» inform(ReplenishmentSchedule) : void
+ «BusinessService» inform(ConsumptionSchedule) : void + «BusinessService» request(ResponseToConsumptionSchedule) : void
+ «BusinessService» agree(ResponseToConsumptionSchedule) : void + «BusinessService» agree(ResponseToReplenishmentSchedule) : void
UP-ColBPIP model + «BusinessService» refuse(ResponseToConsumptionSchedule) : void + «BusinessService» refuse(ResponseToReplenishmentSchedule) : void
4 +
+
«BusinessService»
«BusinessService»
failure(ConsumptionSchedule) : void
request(ResponseToReplenishmentSchedule) : void
+ «BusinessService» failure(ReplenishmentSchedule) : void
 Define las interfaces de negocio requeridas y provistas de los roles, con sus
servicios
 Extiende la semántica de las Interfaces y Estructuras Compuestas de UML2

Fundamentos Teóricos
 Enfoques tradicionales de modelado de procesos basados en grafos de
actividades presentan limitaciones:
 Se restringen a la representación del intercambio de información entre las
actividades  no proveen abstracciones para definir compromisos y negociaciones
 Ambigüedad en la definición de actividades: dos analistas pueden tener diferentes
interpretaciones de sus significados
 Capturan el “qué” de un proceso  Qué actividades se deben realizar
 Interacciones inter-organizacionales deben enfocarse en los aspectos de
comunicación entre las partes, no sólo en el intercambio de información
 Representación de compromisos y negociaciones
 Se debe capturar el “por qué” de un proceso  toda acción conlleva una intención
por parte de quien la realiza con el objetivo de:
 Asumir un compromiso
 Romper un compromiso
 Solicitar la creación de un compromiso
 Informar un hecho

Interaction Protocol (Protocolo de Interacción)

 Describe un patrón de comunicación de alto nivel a través de una coreografía de
mensajes entre dos o más roles desempeñados por los participantes
 Define las interacciones entre los roles desde una perspectiva global
 Representa la comunicación de acciones entre los participantes
 interacciones expresadas por mensajes basados en Actos de Comunicación
(Speech Acts)
 La semántica de comportamiento está dada por la secuencia ordenada de
elementos: mensajes de negocio, segmentos de flujo de control, caminos de
interacción, subprotocolos y terminaciones.
 Permite definir modelos estructurados

Elementos de UP-ColBPIP para protocolos de interacción

Interaction Protocol (Protocolo de Interacción)

 Notación:
Protocolo de
sd <<protocol>> Nombre del Protocolo
Interacción
Empresa X Empresa Y
Socio de :Rol A :Rol B
Negocio msg1(doc1)
Rol Xor
Lifeline [Var1=True]
msg2(doc2)
[Var2=True]
msg3(doc3)
Business Message (Mensaje de Negocio)

 Define una interacción o comunicación entre dos roles, el que envía el mensaje
(remitente) y el que lo recibe (receptor)
 Representa una comunicación asincrónica y en un solo sentido
 Su semántica está dada por la semántica del acto de comunicación asociado
 El contenido que transporta es indicado por el documento de negocio asociado
Expresa que el rol remitente realizó una acción que ha generado el envío
de un acto de comunicación, el cual representa su intención en la
interacción, e implica la expectativa del remitente de que el receptor
reaccione de acuerdo a la semántica del acto de comunicación

Speech Act (Acto de Comunicación)
 Representa la actitud o intención (tales como aceptar, proponer, rechazar,
informar, etc.) que un rol tiene con respecto a la información que es trasportada
en un mensaje de negocio, e implica la expectativa del remitente de que el
receptor reaccione de acuerdo a la semántica del acto de comunicación
 La intención del remitente del mensaje es comunicada al receptor
 Es independiente del mensaje  Puede estar asociado a varios mensajes
 Ejemplo:
 El acto propose representa una propuesta con el compromiso del remitente de realizar
una determinada acción, la cual, para que posteriormente se haga efectiva deberá ser
aceptada por el receptor.
:Emisor Acto de Comunicación :Receptor

Mensaje de
Negocio
request(DocumentoSolicitud)
Documento de
Negocio
Librería de Speech Acts:
 propose: representa la acción de enviar una propuesta para realizar una cierta acción
 accept-proposal : representa la acción de aceptar una propuesta para realizar una
acción
 reject-proposal : representa la acción de rechazar una propuesta previamente
presentada
 request: representa la acción de un rol de solicitarle a otro que realice una acción
 agree : representa la acción de acordar ejecutar alguna acción en el futuro. Expresa un
acuerdo a una solicitud previa para ejecutar una acción
 refuse: representa la acción de negarse a realizar una solicitud de acción previamente
presentada
 cancel: expresa la cancelación de un compromiso (realizar una acción) previamente
asumidos entre las partes
 call-for-proposal: representa la acción de un rol solicitando a otro rol que realice una
propuesta
 inform: representa la acción de un rol informando o comunicando a otro rol una
determinada información

Protocol Reference (Referencia de Protocolo o Subprotocolo)

 Indica una llamada a otro protocolo de interacción, denominado el subprotocolo o
protocolo anidado
 Representa la inserción del comportamiento del subprotocolo dentro de un
protocolo
 Cuando el subprotocolo es ejecutado, el protocolo que lo invoca queda esperando
hasta que el subprotocolo finalice
 Los roles del subprotocolo deben ser los mismos del protocolo de interacción que
lo invoca, o bien se debe establecer una correspondencia (correlación) entre los
mismos
 Es posible establecer una correlación entre los documentos de negocio utilizados
en el protocolo y su subprotocolo
 Correlación indica que en un subprotocolo, la instancia de un documento debe ser
la misma instancia del documento del protocolo que lo invoca
Protocol Reference (Referencia de Protocolo)

 Notación
<<Correlations>>
Solicitud = SolicitudPronosticoVentas
Pronostico = PronosticoVentas
ref
Pronóstico Ventas Colaborativo

Control Flow Segment (Segmento de Flujo de Control)

 Representa una secuencia de mensajes compleja
 Está compuesto de uno o varios caminos de interacción
 Su semántica está dada por el operador de flujo de control utilizado
 Operadores: AND, OR, XOR, LOOP, EXCEPTION, TRANSACTION, STOP, CANCEL
Interaction Path (Camino de Interacción)

 Representa un camino posible de ejecución en un segmento de control
 Contiene una secuencia ordenada de elementos de un protocolo de interacción: segmentos
de control, subprotocolos, mensajes, etc.
 Puede tener una condición, la cual debe ser evaluada a True para que el camino se ejecute
Condition (Condición)
 Expresión condicional que restringe un camino de interacción o un mensaje de negocio, es
decir, define cuándo un camino o mensaje puede ser ejecutado
 Puede ser expresada en lenguaje natural o en lenguaje formal

 Notación
Empresa X Empresa Y
Segmento de :Rol A :Rol B
Flujo de Control
msg1(doc1)
Operador de operator
Flujo de Control
[Var1=True]
msg2(doc2)
Camino de
Interacción [Var2=True]
msg3(doc3)



 Operator: AND
 Representa la ejecución en paralelo de diferentes caminos, los cuales pueden

ser ejecutados en forma concurrente o en cualquier orden
[Var1=True]
 La ejecución de los mensajes de los diferentes caminos puede ser intercalada

en cualquier orden mientras se respete el orden de los mensajes en cada
camino
 El fin del segmento representa la sincronización de los caminos  todos
deben ser finalizados para que continúe la ejecución
And
msg2(doc2)
msg3(doc3)
Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas

[Var2=True] 32

[Var1=True]
 Operator: XOR
 Varios caminos alternativos (mutuamente excluyentes) pueden ser ejecutados

y sólo uno de ellos será ejecutado
 El fin del segmento representa la sincronización (merge) de los caminos
alternativos Xor Basado en Eventos
Xor Basado en Datos Xor
Xor
msg2(doc2)
[Var1=True]
msg2(doc2)
msg3(doc3)
[Var2=True]
msg3(doc3)
Basado en la ocurrencia de un evento: a) el
evento de envío del primer mensaje de uno de los
Expresiones condicionales camino; b) o un Timer definido como primer
basadas en datos elemento en algunos de los caminos (condición:
(documentos de negocio) “[Timer = 2d]”)

 Operator: OR
 Doso más caminos alternativos pueden ser ejecutados y al menos uno de ellos
deberá ser ejecutado
 Los caminos a ser ejecutados deben tener su condición evaluada a True
 Un camino por default puede ser definido (Condición: “default”)
Enterprise X Enterprise Y
 Cuatro formas de sincronización: :Role A :Role B
 Synchronizing Merge (<<Sync-Merge>>)
SpeechAct(BusinessDocument)
 Multi-merge (<<Multi-Merge>>)
 Discriminator (<<Disc>>)
Or <<Sync-Merge>>
 N out of M (<<N out of M>>)
[Var1=True]
speechAct(BD)
[Var2=True]
speechAct(BD)


 Operator: IF
 Representa un camino que puede ser ejecutado en el caso que su condición

sea evaluada en True o bien puede que no sea ejecutado nunca debido a que
la evaluación de su condición retorna False
 Es posible agregar un camino con la condición else que represente la negación
del anterior
If If
[Var1=True] [Var1=True]
msg2(doc2) msg2(doc2)
[else]
msg3(doc3)


 Operator: LOOP
 Representa un camino de interacción que puede ser ejecutado varias veces

mientras la condición asociada al loop sea satisfecha
Tipos de Bucles:
 Loop “Until”: el camino debe ser ejecutado al menos una vez
 La condición del camino debe comenzar con la expresión “(1,n)”
 Loop “While”: el camino debe ser ejecutado cero o N veces
 La condición del camino debe comenzar con la expresión “(0,n)”
Loop Loop
[(0,N), Condición] [(1,N), Condición]

msg2(doc2) msg2(doc2)

 Operator: Multiple Instances (MI)
 Representa la ejecución en paralelo de múltiples instancias de un camino de interacción
 Cuatro formas de sincronización de las múltiples instancias
 Múltiple instancias sin sincronización: <<WS>>
 Múltiple instancias con conocimiento en tiempo de diseño: <<DT>>
 Múltiple instancias con conocimiento en tiempo de ejecución: <<RT>>. La variable (documento
de negocio) que contiene el número de instancias debe ser indicada

EnterpriseenXtiempo de ejecución: <<WRTK>>.
Múltiple instancias sin conocimiento Enterprise La
Y expresión
:Role Ade nuevas instancias debe ser
condicional que posibilita la creación :Role B
indicada.
SpeechAct(BusinessDocument)
Multi-Instance <<DT>> MI=n
speechAct(BD)
speechAct(BD)


 Operator: Exception
 Representa el manejo de excepciones a seguir como consecuencia de la

ocurrencia de una excepción (definida en tiempo de diseño) que puede
ocurrir dentro de un alcance (scope) dado del protocolo. Consiste de:
 Un camino que encierra el alcance (scope) de las excepciones
 Uno o mas caminos manejadores de excepciones, uno por cada excepción a ser
capturada y gestionada. Cada uno tiene una condición de excepción a ser evaluada
para manejar la excepcion.
 Después de la ejecución de un camino de manejo de excepción, el protocolo
continúa con su ejecución normal
 Tipos de excepciones a ser manejadas:
 lógicas (basadas en datos)
 De tiempo (eventos de tiempo). Representa el manejo de restricciones de tiempo
definidas en elementos del protocolo

 Operator: Exception
Enterprise X Enterprise Y
:Role A :Role B
speechAct(BD)
Exception
speechAct(BD)
speechAct(BD)
[Exc1=True]
speechAct(BD)
[TimeConstraint]
speechAct(BD)


 Operator: Cancel
 Representa el manejo de excepciones a seguir como consecuencia de la ocurrencia de
una excepción (definida en tiempo de diseño) que puede ocurrir dentro de un alcance
(scope) dado del protocolo. Idem a Exception
 Después de la ejecución de un camino de manejo de excepción, la instancia del
protocolo finaliza Enterprise X Enterprise Y
:Role A :Role B
speechAct(BD)
Cancel
speechAct(BD)
speechAct(BD)
[Exc1=True]
speechAct(BD)
[TimeConstraint]
speechAct(BD)

Time Constraint (Restricción de Tiempo)

 Representa la fecha límite disponible para la ejecución de un elemento del
protocolo
 Para un mensaje indica el tiempo límite a considerar para la recepción del mismo,
a partir del momento de envío del mensaje
 Para un subprotocolo, indica el tiempo límite a considerar para la finalización del
mismo, a partir del momento de inicio del subprotocolo
 Para un segmento de control, indica el tiempo a considerar para la finalización del
segmento, a partir del momento de inicio del segmento
 Puede ser definida con tiempos absolutos o tiempos relativos
 Absoluto: {0..4d}
 Relativo: {t..t+4d}
Duration Constraint (Restricción de Duración)

 Representa la duración máxima de un mensaje del protocolo
 Ej: {2hs}, el mensaje debe ser ejecutado en dos horas
 Time Constraint (Restricción de Tiempo)

Object1 Object2
request(SolicitudPronosticoVentas)
{t=now}
agree(RespuestaSolicitudPronostico)
{t..t+2d}
{2hs}
 Duration Constraint (Restricción de Duración)

Terminaciones Explícitas del Protocolo

 Por defecto, un protocolo tiene una terminación implícita  finaliza
cuando no existen más mensajes a ejecutar
 Es posible definir terminaciones explícitas:
Success:
 Representa la finalización exitosa del protocolo
 El protocolo finaliza en el punto donde se definió el Success
Failure:
 Representa la finalización con una falla del protocolo
 El protocolo finaliza en el punto donde se definió el Failure
 El éxito o falla de un protocolo es sólo una indicación lógica de la

terminación del protocolo
 NO implica un éxito o falla del sistema que gestiona el proceso
Interaction Protocol: An example
sd <<protocol>> Collaborative Demand Forecast
Enterprise A Enterprise B
:Customer :Supplier
request(ForecastRequest) {t=now}
Cancel
XOR
agree(ForecastRequestResponse)
tc1: {t..t+2d}
refuse(ForecastRequestResponse)
tc1: {t..t+2d}
[Failure]
AND
inform(POSForecast)
tc2: {t..t+4d}
inform(PlannedEvents)
tc2: {t..t+4d}
[tc1] cancel(Issues)
[tc2] cancel(Issues)
inform(DemandForecast)


Proceso de Interfaz
 Es definido desde el punto de vista “local” de una organización
 Es abstracto
Describe:
 El comportamiento público del rol que un participante desempeña
en un proceso colaborativo
 El orden en el cual un participante envía y recibe mensajes
En BPMN es llamado Proceso Público

Proceso de Integración
 Es definido desde el punto de vista “local” de una organización
 Soporta el comportamiento de un participante en un proceso
colaborativo
 Está basado en la lógica y actividades públicas de un proceso de
interfaz
 Refinamiento de un proceso de interfaz  Adiciona aspectos
privados (lógica de negocio interna) a un proceso de interfaz
 Incluye las actividades privadas para producir y procesar la
información intercambiada como así también las transformaciones
de datos e invocaciones a sistemas internos
 Es instanciable por un SIOP
En BPMN es llamado Proceso Privado

Generación de modelos de procesos de interfaz/integración
Caso de Estudio
Modelo de Proceso de Integración generados a
partir de un Modelo de Proceso Colaborativo
Lazzarte, I., Villarreal, P., Chiotti, O., Thom, L., Iochpe, C. An MDA-Based Method for
Designing Integration Process Models in B2B Collaborations. 13th International Conference on
Enterprise Information Systems (ICEIS 2011), Beijin, China. SciTePress, 2011
Lazarte, Ivanna: Diseño y Gestión de Modelos de Procesos de Negocio en Colaboraciones
Inter-organizacionales. Tesis Doctoral. UTN-Facultad Regional Santa Fe, 2013

Caso de Estudio
Proceso de Interaz del Supplier

Caso de Estudio
50
 Proceso de Integración del Supplier

Modelado de Procesos Inter-Organizacionales

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modelado de Procesos Inter-Organizacionales

Încărcat de

Drepturi de autor:

Formate disponibile

6.

DISEÑO Y MODELADO DE PROCESOS

Curso: Gestión de Procesos de Negocio: Herramientas de software y sistemas

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 2

Procesos de negocio de las organizaciones son integrados a

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 3

 En estos dominios, las cadenas de valor involucran varias

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 5

Proceso Colaborativo como Proceso Abstracto:

 Interacciones indican el intercambio de mensajes entre dos

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 7

 Object Management Group, Business Process Modeling Notation

 Versión 2 incorporó notaciones para procesos colaborativos

 Principales elementos de BPMN para coreografías

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 9

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 10

 Interacciones sin dependencias se indican con un Gateway AND-split

 Event-based Gateway (event-based XOR-Split)

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 12

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 13

UP-ColBPIP language (UML Profile for Collaborative

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 14

Enfoque top-down de modelado

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 15

UP-ColBPIP model updateFrecuency = Two months + startDate: date = 01/05/2004

(Interaction Protocol View )

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 16

UP-ColBPIP model :Quantitativ eGoal

(from Agreement and Business Goals)

(from Agreement and Business Goals)

2 (Collaborative Process View

(from Agreement and Business Goals)

& Business Document View ) Blanket Purchase Order

«Collaborativ eBusinessProcess» «Collaborativ eBusinessProcess»

UP-ColBPIP model Puntos de Extensión:

(Interaction Protocol View ) «Achieve»

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 17

& Business Document View ) Partner X :Role A Partner Y :Role B

UP-ColBPIP model REF

 Define los protocolos de interacción que describen el comportamiento formal

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 18

UP-ColBPIP model CustomerInterfaceToSupplier

(Interaction Protocol View )

+ «BusinessService» propose(BlanketPurchaseOrder) : void + «BusinessService» propose(BPOChange) : void

UP-ColBPIP model + «BusinessService» refuse(ResponseToConsumptionSchedule) : void + «BusinessService» refuse(ResponseToReplenishmentSchedule) : void

(Business Interface View )

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 19

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 20

Interaction Protocol (Protocolo de Interacción)

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 21

Elementos de UP-ColBPIP para protocolos de interacción

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 22

Interaction Protocol (Protocolo de Interacción)

Business Message (Mensaje de Negocio)

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 24

:Emisor Acto de Comunicación :Receptor

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 26

Protocol Reference (Referencia de Protocolo o Subprotocolo)

Protocol Reference (Referencia de Protocolo)

Escuela RIO 2017 - Gestión de Procesos de Negocio: Herramientas de software y sistemas 28

Control Flow Segment (Segmento de Flujo de Control)

Interaction Path (Camino de Interacción)