Otros Lenguajes para modelar procesos

EPC y UML

Definición sacada de Wikipedia• The EPC method was developed within the framework of ARIS by

Prof. Wilhelm-August Scheer at the Institut für Wirtschaftsinformatik at the Universität des Saarlandes in the early 1990s. It is used by many companies for modeling, analyzing, and redesigning business processes. As such it forms the core technique for modeling in ARIS, which serves to link the different views in the so-called control view, which will be elaborated in section of ARIS Business Process Modeling.

• "An EPC is an ordered graph of events and functions. It provides various connectors that allow alternative and parallel execution of processes. Furthermore it is specified by the usages of logical operators, such as OR, AND, and XOR. A major strength of EPC is claimed to be its simplicity and easy-to-understand notation. This makes EPC a widely acceptable technique to denote business processes."

Diagramas EPC: Event Driven Process Chain

Funciones• Una función es una tarea técnica, un procedimiento

y/o una actividad relaizada sobre un objeto para apoyar uno o más objetivos de la compañía.

• La función involucra tiempos y costos.• Las funciones representan lugares /momentos en el

proceso donde ocurren cambios.• Las funciones se nombran usando verbo objeto

Verbo ObjetoPreparar Reporte de gastosRevisar Reporte de gastosEnviar Cheque de reembolso

otros ejemplos….

Eventos• Un evento describe una ocurrencia en un objeto que es

relevante para el negocio que controla o influencia la continuación del proceso.

• Los Eventos representan un estatado o status en el proceso

• Los Eventos actúan como gatillantes de actividades, pero tamién están basados en las funciones precedentes y por eso describen un evento.

• Los Events se nombran usando Objeto V erbo en pasadoObjeto verbo en pasadoGasto IncurridoReporte de Gastos AprobadoFormulario Completado

Give us your example….

Componentes EPC

PrepareExpense Report

Verbo

Objeto

ExpenseIncurred

Objeto

Verbo pasado

Evento

Función

Flujos• Los Diagramas EPC siguen una estructura

evento-función-evento• Los Diagramas EPC deben comenzar con un

evento

• Ramificaciones lógicas están representadas en el flujo cronológico de un proceso por reglas en la forma de operadores lógicos (AND, OR, XOR)

• Se hacen con 3 tipos de conectores: • AND• OR• XOR (exclusive OR)

Layout básico de un diagrama EPC

ExpenseIncurred

PrepareExpense Report

Expense ReportCompleted

MailExpense Report

Expense ReportReceived

Secuencia de eventos y funcionesintercalados, partiendo y terminandocon un evento

SolicitudReciboreserva

Evento Evento

Chequeosolicitudreserva FunciónFunción

Solicitud Reserva chequeda EventoEvento

Crear reservavuelo FunciónFunción

Reserva de vuelo creada EventoEvento

Ofrecer vueloalternativo

Vuelo alternativocreado

Evento gatilla función Evento gatilla función

Función genera eventoFunción genera evento

Tabla de Conectores

CONECTOR OR

ProcessPayment

SalespersonNotified

Sales ManagerNotified

Conector OR

Conector ANDEnter

Expense Report

Expense ReportRecorded

Hard CopyFiled

CONECTOR AND

Conector XOR

ReviewExpense Report

ApprovedNot

Approved

CONECTOR XOR

TripCompleted

WeekEnds

PrepareExpense Report

Conector OR con dos eventos gatillantes

Combinaciones posibles de conectores y gatillantes

Event

Function

>

Event

Event

Function

>

Event

Event

Function

x

Event

Event

Function

>

Event

Event

Function

>

Event

Event

Function

x

Event

Function

>

Event

Function

Function

>

Event

Function

Function

x

Event

Function

AND

OR

XOR

Event

Function

>

Function

No Permitido

No Permitido

Evento Gatillante Función Gatillante

Unico Multiple Unico Multiple

Separando y consolidando rutas en el proceso

ExpenseIncurred

CheckInternet

Availability

InternetAvailable

InternetNot Available

PrepareOnline Report

PreparePaper Report

ReportSubmitted

ReportMailed

ReviewExpense Report

Se debe usar el mismo conector

para separar y unir la ruta

Combinación de conectores

No se permiten varias conexiones entrantes y salientes de un mismo conector

Resumen de las reglas para modelar en EPC

• Un EPC empieza y termina con un evento• Se debe seguir una secuencia evento-función-evento

(puede ser sólo interrumpido por conectores lógicos) Se pueden omitir eventos triviales en el medio del proceso

• Los conectores se usan para modelar varias rutas en el proceso

• Los conectores tiene o una conexión de entrada y varias de salida o varias de entrada y una de salida

• Para consolidar (unir) varias rutas en una debe usarse el mismo conector que generó la ramificación

• Un conector OR o XOR no puede seguir a un solo evento

Diagramas Event Process Chain Extendidos (eEPC)

• Modelan el proceso con información adicional• Incluyen vistas de datos, información y

organización

Datos en Diagramas eEPC

Datos del Cliente

DatosDatos

Datos del vuelo

DatosDatos

Datos son procesadosen funciones

Datos son procesadosen funciones

SolicitudReciboreserva

Chequeosolicitudreserva

Solicitud Reserva chequeda

Crear reservavuelo

Reserva de vuelo creada

Ofrecer vueloalternativo

Vuelo alternativocreado

Personas en Diagramas eEPC

R. Alvarez

EmpleadoEmpleado

Sr. Gonzalez

EmpleadoEmpleado

S. Urrutia

EmpleadoEmpleado

Personas (Empleados) Reponsables de Funciones

Personas (Empleados) Reponsables de Funciones

Datos del Cliente

DatosDatos

Datos del vuelo

DatosDatos

SolicitudReciboreserva

Chequeosolicitudreserva

Solicitud Reserva chequeda

Crear reservavuelo

Reserva de vuelo creada

Ofrecer vueloalternativo

Vuelo alternativocreado

eEPC Diagrams

Disponibilidad Vuelos

Unidad Organiza-

cional

Unidad Organiza-

cional

Callcenter

Unidad Organizacional

Unidad Organizacional

Disponibilidad vuelos

Unidad Organiza-

cional

Unidad Organiza-

cional

Solicitud dereserva

Chequeo desolicitud

Solicitud de Reserva

chequeada

Sr. Alvarez

Sr. Urrutia Sr. Gonzales

Employees are assigned to organisational units

Employees are assigned to organisational units

Ofreceralternativa

CrearReserva

vuelo

Reserva creada

Alternativaofrecida

Datos de vuelo

Datos cliente

eEPC diagram

Ticketsvuelodocumento

documento

Listadovuelos

alternativos documentodocumento

Solicitudreservadocumento

documento

Formulario reservadocumento

documentoSolicitud reserva

Chequeo solicitudreserva

Solicitud reserva

chequeada

Callcenter

Disponibilidadvuelos

Disponibilidadvuelos

Funciones Generan y procesan documentosFunciones Generan y

procesan documentos

Ofertavuelos

alternativos

Crearreservavuelo

ReservaVuelocreada

Vuelos Alternativos

ofrecidos

Datos vuelo

Datos cliente

Sr. Alvarez

R. Urrutia Sr. Gonzalez

Actividad 4

• Modele su proceso con Ares y EPC

UML(Unified Modeling Language)

UML

UML es un lenguaje para

– Visualizar

– Especificar

– Construir

– Documentar

artefactos de sistemas intensivos de software

DIAGRAMAS UML

Diagramas estáticos

• Diagrama de clases

• Diagrama de objetos

• Diagrama de componentes

• Diagrama de estructura compuesta

• Diagrama de paquetes

• Diagrama de despliegue

Diagrama de clases

Muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones

Diagrama de objetos

Muestra una instantánea de un conjunto de objetos y sus relaciones

Diagrama de componentes

Muestra la organización y

dependencias entre un

conjunto de componentes, la

vista de implementación de

un sistema.

Están relacionados a diagramas

de clases en donde un

componente se corresponde

con una o más clases,interfaces

o colaboraciones.

Diagrama de estructura compuesta(Composite Structural Diagram)

Muestra la estructura

interna (incluyendo

partes y conectores) de

un clasificador o una

colaboración estructurada.

Diagrama de paquetes

Muestra ladescomposición delmodelo en unidades deorganización y susdependencias.

Diagrama de despliegue

Muestra los enlaces decomunicación físicaentre elementos dehardware y las relacionesentre máquinas físicas yprocesos: qué se ejecutay dónde

Diagramas UML

Diagramas de comportamiento• Diagramas de casos de uso• Diagrama de secuencia• Diagrama de colaboración• Diagrama de estados• Diagrama de actividades• Diagrama cronológico • Diagrama general de interacciones

Diagrama de casos de uso

Muestra un conjunto de casos de uso y actores y susrelaciones

Diagrama de secuencia

Es un diagrama deinteracción que muestra losobjetos y actores queparticipan en unacolaboración poniendo elénfasis en el ordenamientoen el tiempo de losmensajes

Diagrama de colaboración

Un diagrama de interacción que pone el énfasis en la organización estructural de los objetos o roles que envían y reciben mensajes.

Diagrama de estados

Muestra un autómata que consiste de estados, transiciones, eventos y actividades

Diagrama de actividadesMuestra la estructura deun proceso u otro cálculocomo el flujo de controly datos paso a paso en elcálculo.

Starting and Stopping

. The solid circle indicates the beginning of the sequence of activities. The circle with an X represents an end of a "flow" but not the end of the entire use case. In other words, some subtask completes, but the entire use case is not yet complete. The "target" indicates that the entire use case is complete.

Subcase (Sub-Activity)

• The "rake" symbol indicates that the "activity" is complex enough to merit its own activity diagram. In use-case analysis, this is a "subcase"---a stand-alone activity that occurs in more than one use case but is not large enough to be a use case in its own right.

Synchronization (Fork/Join)Used either when several activities can go

on in parallel or when the order in which a set of activities execute is immaterial. The heavy bar at the top is a fork. After the fork, all activities can (but are not required to) go on in parallel. Progress cannot continue past the bar on the bottom (the join) until all the activities that feed into the join complete.

You can label the join with a constraint (e.g. {joinspec= (A and B) or C}) to specify the condition that allows progress to continue. If there's no constraint, AND is assumed.

Decision (Branch/Merge).

A decision activity, the guard labels the decision that was made. The diamond with outgoing arrows (the branch) specifies an OR operation, with a condition imposed by the guard. The diamond with incoming arrows (a merge) simply provides an end to the OR operation. A merge can occur without an associated branch if the diagram has multiple start states.

Guards

• This path is used only if the text in the brackets is true.

Signals (Events)

• Generating signals: sent to outside process (Request Payment at left).

• Accepting signals: received from outside process (Payment Received at left).

• Timer signals: received when time elapses or a set time arrives (30 days... at left).

Exceptions.

• Extraordinary errors that you typically don't detect with explicit tests are indicated with a "lightning bolt."

Object FlowIdentifies objects that are created by

activities (box with outgoing arrow) or used by activities (box with incoming arrow). In the example at left, The invoice object is created during the receive-invoice activity and used by the process-invoice activity. The check object is created in the cut-check activity and is used by the send-payment activity. In this second case, you can also put boxes at both ends of the line. You can indicate exactly how the object is used with aconstraint. (e.g. {create}, {store}, etc.)

Swim LanesActivities are arranged into vertical

or horizontal zones delimited with lines. Each zone represents a broad area of responsibility, typically implemented by a set of classes or objects. For example, the swim lane labeled accounting could represent objects of several classes (Bookkeeper, Clerk, MailRoom, Accountant) working in concert to perform the single "cut paycheck" activity.

Diagrama cronológico(Timing Diagram)

Es un diagrama deinteracción que muestratiempos a lo largo dediferentes objetos oroles, y no secuenciasrelativas de mensajes

Diagrama de interacciones general(Interaction Overview Diagram)

Es un híbrido de diagramas de actividady de secuencia.

Las gráficas fueron extraídas de los siguientes textos:

Booch, G., Rumbaugh, J., Jacobson, I. The Unified Modeling Language. User Guide. Addison Wesley. (2005)

Stevens, P. Pooley R. Utilización de UML en Ingeniería del software con objetos y componentes (2002)