introducción a bpmn
TRANSCRIPT
Sistemas de Información
Introducción a la Notación BPMN
1
´
© 2010, Universidad Central de Venezuela. Sistemas de Información.
2
• Introducción• Eventos (Events)• Gateways (Decisiones)• Actividades (Activities)• Patrones (Patterns)• Conclusiones
Agenda
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Objetivos de Aprendizaje
Al finalizar este capitulo, usted estará en capacidad de:
1. Definir y describir los elementos básicos de la notación BPMN.
3
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos (Events)
Gateways (Decisiones)
Actividades (Activities)
Patrones (Patterns)
4
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
1.Objetos de
Flujo
3.Swinlanes (carriles)
4.Artefactos
2.Objetos de Conexión
Elementos Básicos de BPMN
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Los objetos de flujo son los principales objetos que expresan la semántica de un modelo de proceso
Eventos
Gateways
Actividades
Elementos Básicos: Objetos de Flujo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Los objetos de conexión son usados para describir como interactúan los objetos de flujo.
Flujo de secuencias:
Flujo de Mensaje:
Asociación:
Elementos Básicos: Objetos de Conexión
Sequence Flow
Conditional Flow
Default Flow
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Flujos vs. Procesos
El flujo del proceso define como ocurre una secuencia de actividades desde la perspectiva de un participante.
El flujo de datos define como la información es intercambiada entre participantes
Elementos Básicos: Objetos de Conexión
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Elementos Básicos: Pools (Participantes)
Participantes es Cualquier recurso
involucrado en un proceso
3 tipos de participantesSistema
Humano
Proceso
Representado por un PoolNombrar el Pool como el participante
Dejar un Pool para representar el proceso que se esta documentando
Al menos un Pool para representar un sistema o humano.
Ejecutable vs. No Ejecutable
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Los Artefactos son usados para proveer información adicional acerca del proceso:
Objetos de Datos:
Grupos:
Anotaciones:
Elementos Básicos: Artefactos
Anotaciones de Texto permiten al Modelador agregar información adicional
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos (Events)
Gateways (Decisiones)
Actividades (Activities)
Patrones (Patterns)
11
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Evento es algo que sucede durante la ejecución de un proceso de
negocio el cual afecta la ejecución del flujo
Existen tres tipos de eventos:
Eventos de Inicio
Eventos Intermedios
Eventos de fin
Eventos
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Evento de inicio indica cuando un proceso particular debe comenzar
Un evento de inicio comienza el flujo de un Proceso
Ningún flujo de secuencia puede conectarse a un evento de inicio
Un evento de Inicio es opcional
Si no es usado, las actividades sin flujo de secuencia de entrada serán
consideradas como conectadas con un evento de inicio implícito
Usado para:
Cuando la recepción de un mensaje activa la instancia de un proceso, ej.
Recepción de una Orden
Muestra cuando una instancia debe ser activada:, ej. Fin de Mes
Eventos: Evento de Inicio
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Evento intermedio indica cuando algo sucede durante la ejecución
de un proceso
Un evento intermedio afecta el flujo de un Proceso
Un eventos intermedio puede ser usado para:
Indicar cuando un mensaje puede ser recibido
Mostrar en donde se esperan delays
Interrumpir el flujo normal a través de manejo de excepciones
Eventos: Evento Intermedio
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Evento de fin de flujo de proceso no tendrá ninguna secuencia de
flujo de salida
Un Eventos de fin es opcional
Un Evento de fin puede ser usado para:
Poner fin a un flujo de proceso y enviar un mensaje
Poner fin a un flujo de proceso y generar un error
Poner fin a un flujo de proceso y realizar una solicitud de una compensación
Eventos: Evento de fin
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Mayor semántica, mediante símbolos de eventos específicos
Un evento intermedio tipo “mensaje”, por ejemplo, puede tener dos instancias: enviando o recibiendo. Los eventos que envían se anotan con un icono relleno (negros), mientras que los que reciben con un núcleo claro (blancos)
Cada símbolo hereda el comportamiento externamente y agrega su propio significado
Eventos: Símbolo de eventos en BPMN
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Evento de Inicio vacio. Ilustra que el proceso inicia en ese punto, pero sin ninguna información sobre el tipo de evento
Evento Intermedio VacioIndica un cambio de estado del diagrama
Punto de captura de indicadores de gestión
Evento de Fin VacioIlustra que el proceso culmina
Los procesos pueden tener múltiples puntos de fin
Evento TerminarDetiene el proceso inmediatamente, incluyendo cualquier ruta paralela
Eventos vacios
© 2010, Universidad Central de Venezuela. Sistemas de Información.
En un subproceso se puede usar eventos de inicio y fin.
Los eventos están implícitos.
Su uso mejora la legibilidad del diagrama
Eventos en los Sub Procesos
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Eventos de Inicio
Disparador Descripción Símbolo
Ninguno No se especifica el tipo de evento, también se usa cuando un sub proceso disparado por el proceso padre
Mensaje Llegada/envío de un mensaje y se dispara un proceso
Timer Para procesos que parten en un día/hora específica
Condicional Es cuando un proceso parte con una condición tal como “si se producen diferencias de inventario teórico y físico”
Señal Una señal no es un mensaje con un destino fijo, sino que puede activar muchos procesos distintos
Múltiple Muchos eventos distintos pueden activar el proceso, basta con que uno de ellos se cumpla para que el proceso se dispare
Evento de inicio de mensaje. El proceso inicia cuando se recibe un mensaje desde otro participante
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Eventos Intermedios
Disparador Descripción Símbolo
Ninguno No se muestra el tipo de evento
Mensaje El proceso queda en espera hasta que llegue el mensaje (recepción) o se usa para enviar mensajes (envío), también se usa para desviar excepciones (*)
Timer Dispara el proceso en un día/hora determinados, también se usa para desviar excepciones
Error Se dispara cuando se produce un determinado error. Solo se puede poner en el extremo de una actividad
Cancelar Se puede poner solo en el extremo de un sub proceso. Se dispara cuando recibe un evento “Cancelar”
Compensación Activa eventos que compensan alguna acción, puede afectar a una actividad si esta se especifica o a todas las suceptibles de ser compensadas
Condicional Es el evento que se dispara cuando una condición tiene valor “True”
Link Conecta dos secciones de un proceso, se puede usar –por ejemplo- para crear loops. Puede tener múltiples fuentes pero solo un destino
Señal Envía y recibe señales que se comunican a lo largo de todo un flujo a quien pueda interesar
Múltiple Es cuando un evento tiene múltiples disparadores, ya sea para recepción como para envío
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Ejemplos Eventos Intermedios
Evento intermedio de mensaje.
El proceso espera hasta recibir un mensaje desde otro participante
Evento intermedio con temporizador
El proceso espera un periodo de tiempo antes de continuar.
Evento de fin de mensajeEl proceso termina enviando un mensaje a otro participante
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Exception Handling
Eventos intermedios asociados a la frontera de una actividad que representan triggers que pueden interrumpir la actividad. Todo el trabajo dentro de la actividad será detenido y el flujo procederá del Evento. Temporizador, excepciones, mensajes, etcétera, pueden ser Trigger.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos Intermedio - Ejemplo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Carreras (Races)
Decisión de ruta a ejecutar basada en la primera ocurrencia de un evento externo
Los eventos pueden ser de distintos tipos
Solo una ruta se ejecuta por lo que sincroniza con una bifurcación exclusiva
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Races - Ejemplo
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Interrupción o Rutas Excepcionales
BPMN tiene una forma elegante de manejar rutas excepcionales
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Interrupción o Rutas Excepcionales
Automáticamente escala tareas retrasadas
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Interrupción o Rutas Excepcionales
Múltiples eventos intermedios pueden ser colocados en el borde de un subproceso:
Eventos de error
Eventos de temporizador
Eventos de compensación
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Eventos: Interrupción - Ejemplo
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Actividades (Activities)
Patrones (Patterns)
30
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Los Gateways son puntos de decisión para canalizar el flujo. Son
utilizados para controlar como interactúan los flujos de secuencias a
medida que convergen o divergen en un proceso.
Decisiones, tales como forks, merges y joins en el flujo de proceso son
modelados con Gateways
El comportamiento de cada tipo de Gateways determinará cuantas de
las rutas estarán disponible para la continuación del flujo.
BPMN define cuatro tipos de Gateways:
Gateways: Definición
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Las distintas rutas se ejecutan
cuando se cumplen ciertas
condiciones.
Exclusivo
Solo una ruta se ejecutara
Inclusivo
Al menos una ruta se ejecuta
Puede tomar mas de una ruta
y se comporta como un
paralelo
Sincronizar con el mismo símbolo
que se inicia la bifurcación
Gateways: Condicionales
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Las rutas por defecto se toman
cuando las otras condiciones
no se evaluan como
verdaderas.
Exclusivo
(A o B), sino C
Inclusivo
Si no (A y/o B) entonces C
Gateways: Condicionales
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Condicional Exclusivo - Ejemplo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Condicional Inclusivo - Ejemplo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Condicional Inclusivo - Ejemplo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Paralelo
Los procesos con frecuencia requieren que múltiples eventos y tareas ocurran en paralelo
Un Paralelo sincroniza los flujos que salen de manera paralela. Todas las rutas deben completarse antes de que el proceso continúe
Sincronización explicita: Todas las rutas deben completarse antes de que el proceso continúe.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Paralelo
• Bifurcación Sincronización
Comportamiento:•A es la primera tareas en ejecutarse •B,D y E inician a la vez•F se ejecuta después de que C,D y E hayan todas terminado
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Paralelo
Comportamiento de los subprocesos
Si existen múltiples puntos de inicio en un subproceso, cada ruta se ejecuta en paralelo.
Forma incorrecta:
Forma correcta:
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Exclusive Event-Based Gateways es similar al Data-Based Gateways:
La única diferencia es que, en lugar de evaluar un conjunto de alternativas para
determinar sólo un flujo de salida, el Gateway basado en evento, iniciara una carrera
entre los diferentes eventos que en el proceso se pudiera recibir; el primero en ser
recibido ganará la carrera y determinará el flujo de la secuencia de salida que debe
ser utilizado.
Aquí los flujos se dirigen según si se ha recibido un mensaje, se ha cumplido una
condición o ha pasado cierto tiempo
Gateways: Exclusive Event-Based
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Gateways: Exclusive Event-Based
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
El Complex Gateway fue creado para tratar casos complejos que
requeriría la combinación de varias otros Gateways de enlace. Para
evitar su uso, el comportamiento de este Gateway puede ser
programadas utilizando un lenguaje de expresión. Como un resultado
del gateway complejo, puede ser usado para manejar todos los
situaciones. Sin embargo, la mejor práctica es evitarlo, ya que hace
que los modelos de proceso sean menos legible.
Gateways: Complex
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
43
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Una Actividad es una unidad de trabajo a realizar. Podría ser una
tarea, un proceso o un sub-proceso.
BPMN define dos tipos principales de actividades:
Una Tarea es una actividad atómica que se incluye dentro de un
proceso
Un Sub-proceso es un proceso que se incluye dentro de otro
proceso
Actividades: Definición
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Las marcas son definidas para especificar semánticas adicionales,
tales como loops
Actividades: Marcas en Actividades
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Actividades: Loops Secuenciales
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Actividades: Loops Paralelos
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
48
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
49
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Patrones: WCP-10 Arbitrary Cycles
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Patrones: WCP-18 Milestone
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Patrones: WCP-19 Cancel Activity
http://diveintobpm.org/index.jsp
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Compensation Handling and Transactions
A Transaction is an activity that has a double border. Transactions are supported by a transaction protocol (e.g., WS-Transaction).
Normal Outgoing Sequence Flow represents the path to follow a successful completion.
A Cancel Intermediate Event represents the path to follow a cancelled completion.
An Exception Intermediate Event represents the path to follow a transaction hazard.
Activities used for compensate (with marker) are outside normal flow and are Associated normal activities.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Un Proceso Complejo
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Documentation
Data Object
Task
Multiple Instances
Collapsed Subprocess
Loop
Text Annotation
Group
Ad-hoc Subprocesses
∼Transaction
Plain
Message
Timer
Error
Cancel
Compensation
Conditional
Signal
Multiple
Link
Terminate
Catching Throwing
EndIntermediateStart
Data-based Exclusive Gateway
Inclusive Gateway
Event-based Exclusive Gateway
Paralllel Gateway
Complex Gateway
Gateways
Events
Activities
Sequence Flow
Conditional Flow
Default Flow
Data
Transaction
Data Object
Undirected Association
Directed Association
Bidirected Association
Message Flow
Resumen de los elementos de BPMN
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Metamodelo de BPMN
56
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
Ejercicios
57
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
58
¿Cuál de estos diagramas es el correcto?
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
59
¿Cuál de estos flujos en los eventos están incorrectos?
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
60
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
61
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
62
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
La tarea C debe ejecutarse en paralelo con el subproceso B
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
63
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
La tarea C debe ejecutarse en paralelo con el subproceso B
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
64
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
La tarea C debe ejecutarse en paralelo con el subproceso B
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
Bajo ciertas condiciones en vez de ejecutar C debemos terminar el proceso, incluyendo las actividades del subproceso B.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
65
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
La tarea C debe ejecutarse en paralelo con el subproceso B
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
Bajo ciertas condiciones en vez de ejecutar C debemos terminar el proceso, incluyendo las actividades del subproceso B
Queremos esperar un tiempo entre que termina B1 y el inicio de B2
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
66
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
La tarea C debe ejecutarse en paralelo con el subproceso B
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
Bajo ciertas condiciones en vez de ejecutar C debemos terminar el proceso, incluyendo las actividades del subproceso B
Queremos esperar un tiempo entre que termina B1 y el inicio de B2
La tarea A es realmente la recepción inicial de un mensaje de un participante “Cajero”.
La tarea E es realmente el envío final de un mensaje a un participante “Contabilidad”
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
67
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
68
Modele una secuencia de 5 tareas llamadas A,B,C,D,E
Convierta la tarea B en un subproceso que contenga las tareas B1 y B2
La tarea C debe ejecutarse en paralelo con el subproceso B
Bajo ciertas condiciones, es necesario no ejecutar la tarea C
Bajo ciertas condiciones en vez de ejecutar C debemos terminar el proceso, incluyendo las actividades del subproceso B
Queremos esperar un tiempo entre que termina B1 y el inicio de B2
La tarea A es realmente la recepción inicial de un mensaje de un participante “Cajero”.
La tarea E es realmente el envío final de un mensaje a un participante “Contabilidad”
Si el subproceso B no termina en un tiempo determinado es necesario ejecutar una tarea “escalar”
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicios
69
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
Ejercicios
Mejores Prácticas
70
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Objetivos al modelar en BPMN
71
Ser eficientes capturando la información del proceso
Reducir errores de interpretación
Transferir conocimiento
Hacer los diagramas tan fáciles de leer como sea posible
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
72
Cree los procesos inicialmente usando solo símbolos de tareas. Luego cambie el símbolo para detallar más el comportamiento del proceso
Concéntrese en documentar el proceso
No intente agregar participantes desde las primeras fases de modelado
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
73
Luego de tener un acuerdo sobre el flujo del proceso, agregue participantes e interacciones.
Agregar participantes antes, tiene a mantener el foco en detalles de forma prematura y a causar la necesidad de re-diagramar el proceso.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
74
Utilice el artefacto de anotación para agregar información importante a transferir
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
75
Asígnele nombres a sus tareas considerando la perspectiva del participante que la ejecuta
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
76
Coloque “la pregunta” asociada en cada bifurcación
cada ruta representa una respuesta, asígnele una etiqueta para documentarla en el diagrama
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
77
Coloque “la pregunta” asociada en cada bifurcación
cada ruta representa una respuesta, asígnele una etiqueta para documentarla en el diagrama
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
78
Una bifurcación hace una sola pregunta.
Evite condiciones que no estén relacionadas entre sí.
Utilice condiciones de cascada en ese caso.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
79
Las condiciones pueden ser anidadas
En ese caso, use subprocesos para evitar confusión y mejorar la legibilidad
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Consejos
80
Cada objeto puede tener un color distinto. Use esta opción para hacer sus diagramas más simples de leer. Adopte una convención y apéguese a ella.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Introducción
Eventos
Gateways (Decisiones)
Activities (Actividades)
Patrones (Patterns)
Ejercicios
Mejores Prácticas
Ejercicios
81
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio A
82
Después de un incendio, por un lado se necesita obtener información de nuestra compañía de seguro. Por otro lado, es posible que necesitemos información adicional del departamento de bomberos, pero solo si los bomberos participaron durante el apagado del incendio. Cuando se tenga toda la información, se necesita escribir un informe consolidado
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio A
83
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio B
84
Nuestros productos están listos para ser enviados. Para determinar que compañía de envío utilizar, enviamos 3 mensajes separados a cada una pidiéndole que despachen nuestros productos. La primera compañía que responda que puede hacer el envió es la escogida
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio B
85
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio C
86
1. Un proceso cliente envía una petición para que se realice una solicitud y aprobación de fondos
2. Se solicita y recibe la información de la solicitud de un empleado
3. Se solicita y recibe la aprobación de la solicitud de un gerente
4. Si la solicitud del empleado es rechazada se vuelve al paso #2
5. Si se aprueba la solicitud, se solicita y recibe información contable al director del área
6. Se solicita y recibe la revisión del departamento de finanzas. Este departamento puede:
a. Aprobar
b. Rechazar basados en la información de la solicitud del empleado
c. Rechazar basados en la información contable proporcionada por el director
7. Si el departamento de finanzas rechazó basado en la solicitud del empleado, se debe volver al paso #2
8. Si el departamento de finanza rechazó basado en la información contable, se debe volver al paso #5
9. Si el departamento de finanzas aprobó, el proceso finaliza enviando un mensaje al proceso cliente.
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio C
87
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio C
88
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Ejercicio C
89
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Conclusiones
90
• Hemos realizado un estudio de …..
• Hemos hecho una discusión sobre….
• Se han desarrollado demostraciones de
Conclusiones