Alineamiento de Procesos y Sistemas usando BPMN y UML

REPORTE TECNICO
Metodología para el Alineamiento
de Procesos de Negocio y Sistemas de Información
usando BPMN y UML
Eduardo Jara Goldenberg
Ingeniero Civil Informático. Universidad de Concepción. Chile.
Magister en Matemáticas Aplicadas. Universidad Estatal de Moscú. Federación Rusa.
ejara@craftware.net
Diciembre 2016
Resumen
Los Sistemas de Información deben estar alineados con los Procesos de Negocio, que definen cómo
realizar los productos y servicios en concordancia con los Objetivos Estratégicos de la Empresa. Así
los Sistemas de Información efectivamente apoyan el logro de dichos Objetivos. Puesto que ambos son
trabajados por distintos grupos, con distintos objetivos, metodologías y herramientas, se dificulta la
alineación requerida.
El presente documento presenta una Metodología de Alineamiento cuya aplicación asegura que todas
aquellas partes de los Procesos de Negocio que requieren soporte informático tengan su contraparte
como requerimientos sistémicos expresados como Casos de Uso. Y que, además, todos los Casos de
Uso sean consecuencia de necesidades reales de los Procesos de Negocio.
La Metodología utiliza BPMN (Business Process Model and Notation) para describir los Procesos de
Negocio, y UML (Unified Modeling Language) para la especificación de requerimientos de software
con Casos de Uso.
La Metodología es compatible con cualquier Proceso de Desarrollo de Software, desde Procesos
Ágiles, hasta Procesos altamente formalizados y documentados.

ii
Prefacio
Este Reporte Técnico es el resultado de varios lustros de trabajo del autor en las áreas de Procesos de
Negocio y Desarrollo de Software, con los estándares UML desde 1998 y BPMN desde 2008.
Este Reporte Técnico está dirigido a profesionales que trabajan en el levantamiento, documentación y
automatización de Procesos de Negocio; y profesionales TI que trabajan en el levantamiento y
especificación de Requerimientos de Software.
Los estándares UML y BPMN son especificaciones de OMG (Object Management Group, 2016).
Los diagramas técnicos UML y BPMN mostrados en la figuras de este Reporte fueron desarrollados
con Enterprise Architect (Sparx Systems).
El autor agradece de antemano a los lectores cualquier información sobre ambigüedades,
inconsistencias o inexactitudes, así como opiniones y sugerencias para versiones futuras de este
documento. Por favor enviar correo a ejara@craftware.net o eduardojaragoldenberg@gamil.com.

iii
Contenido
1 Introducción ...................................................................................................................................... 1
2 Arquitectura Empresarial .................................................................................................................. 3
2.1 Matriz de Arquitectura Empresarial........................................................................................... 4
2.2 Alineamiento y Trazabilidad...................................................................................................... 6
3 Modelos y Notación de Procesos de Negocio (BPMN).................................................................. 10
3.1 Ejemplo de BPMN ................................................................................................................... 11
3.2 Elementos de BPMN................................................................................................................ 15
3.2.1 Elementos de Flujos.......................................................................................................... 15
3.2.2 Calles de Responsabilidad (Swimlanes)............................................................................ 19
3.2.3 Elementos de Conexión .................................................................................................... 21
3.2.4 Otros Elementos de BPMN............................................................................................... 24
4 Lenguaje Unificado de Modelado (UML) ...................................................................................... 25
4.1 Estructura de UML................................................................................................................... 25
4.1.1 Tipos de Modelos en UML............................................................................................... 26
4.2 Modelo de Clases ..................................................................................................................... 27
4.3 Modelo de Casos de Uso.......................................................................................................... 31
4.3.1 Descripción de un Caso de Uso ........................................................................................ 34
4.3.2 Requerimientos sólo con Casos de Uso ............................................................................ 35
4.4 Modelo de Actividades............................................................................................................. 37
4.5 Modelado de Procesos de Negocio, ¿UML o BPMN?............................................................. 39
5 Metodología de Alineamiento......................................................................................................... 41
5.1 Principios y Políticas................................................................................................................ 41
5.2 Ambientes................................................................................................................................. 44
5.2.1 Ambiente Interno .............................................................................................................. 45
5.2.2 Ambiente Externo ............................................................................................................. 47
5.2.3 Tareas en Piscinas y Carriles ............................................................................................ 48

iv
5.3 Patrones .................................................................................................................................... 52
5.3.1 Patrones de Interacción ..................................................................................................... 53
5.3.2 Patrones de Mensajes........................................................................................................ 62
5.3.3 Patrones de Servicios ........................................................................................................ 88
6 Ejemplo........................................................................................................................................... 98
6.1 Niveles...................................................................................................................................... 98
6.1.1 Alto Nivel sin Tecnología................................................................................................. 98
6.1.2 Colaboración detallada sin Tecnología............................................................................. 99
6.1.3 Colaboración detallada con Tecnología en Piscinas separadas ...................................... 102
6.2 Aplicación de Patrones........................................................................................................... 105
6.2.1 Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE) ...................................... 105
6.2.2 Mensaje de Sistema Externo hacia Sistema Interno (Msj SE>SI).................................. 107
6.2.3 Mensaje a Rol Interno desde Sistema Interno (Msj RI<SI)............................................ 109
6.2.4 Interacción Rol Interno-Sistema Interno (Int RI < > SI)................................................. 111
6.2.5 Mensaje de Sistema Interno hacia Sistema Externo (Msj SI>SE).................................. 115
6.2.6 Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)........................................ 117
6.3 Refinamiento del Modelo de Casos de Uso ........................................................................... 119
6.3.1 Modelo de Casos de Uso inicial...................................................................................... 119
6.3.2 Inclusiones ...................................................................................................................... 120
6.3.3 Nuevos Casos de Uso...................................................................................................... 122
6.3.4 Generalización de Actores .............................................................................................. 124
6.3.5 Generalización de Casos de Uso..................................................................................... 125
6.4 Mapeo..................................................................................................................................... 126
7 Bibliografía ................................................................................................................................... 128

1
1 Introducción
En última instancia los Sistemas de Información deben apoyar los Objetivos Estratégicos de la
Empresa. Sin embargo, existe un largo camino (temporal, metodológico y organizacional) entre la
definición de los Objetivos y la construcción de los Sistemas de Información.
Por un lado, los Objetivos Estratégicos, que materializan la Misión y Visión de la Empresa, junto con el
Modelo de Negocio desembocan en los Procesos de Negocio que definen, en términos operativos, qué
hace la Empresa, cómo lo hace y quién lo hace.
Por otro lado, los Sistemas de Información, que dan soporte al quehacer de la Empresa, es decir, sus
Procesos de Negocio, nacen de necesidades expresadas como Requerimientos de Software.
La clave para que esta larga cadena, que comienza en los Objetivos Estratégicos y termina en los
Sistemas de Información, se mantenga unida, es que estos dos eslabones: Procesos de Negocio y
Requerimientos de Software, estén alineados. En otras palabras, que cada necesidad de tecnología
informática en los Procesos esté expresada como un Requerimiento, y cada Requerimiento apoye algún
Proceso.
El presente documento presenta una Metodología de Alineamiento de Procesos y Requerimientos
cuya aplicación asegura que de manera sistemática, predecible, repetible y ordenada se deriven los
Requerimientos a partir de los Procesos. La Metodología utiliza BPMN (Business Process Model and
Notation) para describir los Procesos de Negocio, y UML1
(Unified Modeling Language) para la
especificación de requerimientos de software con Casos de Uso.
El objetivo de la Metodología es la identificación de los Requerimientos como Casos de Uso, pero no
se pronuncia sobre cómo documentarlos ni cómo se utilizarán para llegar finalmente al software. Esto
queda a criterio del Proceso de Desarrollo de Software utilizado. Por este motivo, la Metodología de
Alineamiento es compatible con cualquier Proceso de Desarrollo, desde Procesos Ágiles como
SCRUM, pasando por Procesos altamente formalizados y documentados, hasta MDA2
.
Los estándares BPMN y UML son metodológicamente agnósticos3
, es decir, definen la sintaxis y
semántica de los lenguajes gráficos, pero no se pronuncias sobre cómo utilizarlos. En esta línea, la
Metodología de Alineamiento define qué elementos de BPMN usar y cómo utilizarlos. Esto se traduce
en (1) la definición de Ambientes que establecen reglas sobre cómo utilizar BPMN para modelar los
Participantes de Colaboraciones de Procesos de Negocio. (2) La identificación de 15 Patrones que
representan las distintas situaciones de uso de Sistemas de Información en los Procesos de Negocio. (3)
1
BPMN y UML son estándares especificados por (Object Management Group, 2016).
2
Model Driven Architecture.
3
BPMN y UML no son métodos, ni técnicas, ni metodologías. Son lenguajes utilizados por métodos, técnicas y
metodologías.

2
La definición de reglas para inferir los Requerimientos como Casos de Uso para cada Patrón. Y (4) la
definición de un mapeo entre elementos de los Procesos de Negocio y los de los Casos de Uso.
En el Capítulo 0 se presenta la necesidad del Alineamiento en el contexto de la Arquitectura
Empresarial. Se define y explica el uso de la Matriz de la Arquitectura Empresarial para visualizar las
distintas vistas desde las que puede ser analizada una Empresa. Dos de estas vistas son precisamente las
trabajadas en la Metodología de Alineamiento: Procesos de Negocio y Requerimientos de Software.
En los Capítulos 3 y 4 se presentan los estándares BPMN y UML, los que serán usados para describir
los Procesos de Negocio y los Requerimientos en la Metodología de Alineamiento. Para cada uno de
ellos se entrega una introducción a sus elementos más importantes.
La Metodología de Alineamiento es descrita en detalle en el Capítulo 5. Primero se define un conjunto
de principios y políticas que le dan sustento teórico y que delinean sus principales características.
Luego se describen detalladamente sus dos partes estructurales: Ambientes y Patrones.
Por último, en el Capítulo 6 se muestra un ejemplo detallado de la aplicación de los Ambientes y el uso
de Patrones para derivar los Requerimientos de Software como Casos de Uso.

3
2 Arquitectura Empresarial4
Para efectos del presente trabajo entenderemos por Empresa una organización, con o sin fines de lucro,
dedicada a actividades industriales, mercantiles o de prestación de servicios, que se relaciona con su
entorno entregando productos o servicios e interactuando con clientes, proveedores y otros agentes
sociales.
Más allá de sus propósitos específicos, toda Empresa:
 Tienen una Misión o razón de ser.
 Lleva a cabo una Estrategia.
 Involucra a un grupo de Personas.
 Ejecuta Actividades y toma Decisiones.
 Utiliza Recursos.
 Se Relaciona con el mundo.
Todos los aspectos mencionados se relacionan entre sí. Si a esto agregamos el tamaño de las Empresas,
la cantidad de personas que en ellas trabajan, sus diferentes y – a veces – encontrados intereses, y el
cambiante ambiente (legal, comercial, medioambiental) en que deben competir; llegamos a un
escenario altamente complejo para el que las herramientas comunes de administración no están
preparadas.
La forma moderna de administrar esta complejidad es conceptualizar y gestionar las partes de una
Empresa y sus relaciones usando un enfoque arquitectónico, es decir, recurrir a criterios y técnicas
análogos a los usados en la planeación, diseño y construcción de edificios y otras estructuras. Es decir,
trabajando con la Arquitectura Empresarial.
La Arquitectura Empresarial es una técnica que ayuda a dirigir la forma como se construye (organiza y
trabaja) una Empresa, usando un enfoque holístico que conjuga sus diversas partes, para el desarrollo
y ejecución exitosos de la estrategia.
En la práctica la Arquitectura Empresarial consiste en disponer de una representación simplificada de la
realidad de la Empresa para ayudar a tomar decisiones, prever riesgos potenciales, evaluar posibles
cambios, identificar impactos, etc. Esto es análogo a la Arquitectura tradicional, donde los planos y la
maqueta de un edificio son representaciones simplificadas de éste. Lo mismo ocurre con una Empresa,
hay varias formas de verla y representarla, por ejemplo:
 Organigrama – Representa los cargos y quien los ocupa.
 Descripciones de Cargos – Muestran qué hace cada cargo.
 Mapas de Procesos – Representan actividades y decisiones.
 Cuadro de Mando (balance scorecard) – Muestra el estado de salud de la Empresa.
 Diagrama de Redes – Muestra la infraestructura tecnológica y su enlaces.
4
Para mayor información sobre Arquitectura Empresarial consultar (Craftware Consultores, 2016).

4
 Modelo de negocio – Muestra cómo agregar valor a lo que se vende y cuál es la propuesta de
valor.
 otros…
2.1 Matriz de Arquitectura Empresarial
Los diversos puntos de vista desde los que se puede ver la Empresa están identificados en la Matriz de
Arquitectura Empresarial (Craftware Consultores, 2016). Ésta muestra por un lado una jerarquía que va
desde el nivel Estratégico a los niveles Operacional y Tecnológico. Por el otro lado indica distintas
perspectivas de la Empresa: Motivación, Estructura y Funcionamiento.
Figura 2-1. Matriz de Arquitectura Empresarial
En cada celda van modelos específicos para representar esa perspectiva con un nivel dado, por ejemplo:
 En el cruce de Estrategia con Estructura de Datos va el cuadro de mando integral o Balance
Scorecard que dice qué tal está la Empresa.
 En el cruce de Procesos y Funciones y Comportamiento va el Mapa de Procesos de Negocio
 En el cruce de Tecnología con Motivación y Objetivos van los modelos con los requisitos que
deben cumplir las aplicaciones de software.

5
Aquí entendemos por modelo cualquier tipo de representación textual y/ o gráfica, con distintos grados
de formalidad. Es deseable que esta representación, de una parte de la realidad de la Empresa, esté
plasmada en algún documento físico o electrónico, y no sólo en la cabeza de las personas.
Los Modelos en cada celda pueden tener distinto nivel de detalle y usar distintas metodologías y
herramientas.
Figura 2-2. Niveles de detalle de modelos en celda Estrategia - Motivación y Objetivos
Por ejemplo, en la celda Estrategia - Motivación y Objetivos habrá una jerarquía de objetivos que
guían la Empresa desde la Visión y Misión hasta los Objetivos Operacionales. Por otro lado, en la celda
Procesos - Funciones y Comportamiento habrá una jerarquía de Procesos desde los Macro Procesos
hasta las Instrucciones de Trabajo.
Todas las Empresas tendrán esta desagregación en cada celda. En algunos casos los modelos estarán
implícitos, en otros casos estarán formalizados y documentos.

6
Figura 2-3. Niveles de detalle de modelos en celda Procesos – Funciones y Comportamiento
2.2 Alineamiento y Trazabilidad
Los elementos de los modelos dentro de cada celda y entre ellas deben estar alineados, de modo que
ajusten como los elementos de un mecanismo para éste funcione correctamente.
Por ejemplo, en Estrategia - Motivación y Objetivos la Misión de la Empresa debe estar reflejada en
uno o más de los Objetivos Estratégicos. Además, cada uno de éstos debe materializar uno o más
aspectos de la Misión.
Entre Proceso- Funciones y Comportamiento y Tecnología-Motivación y Objetivos debe haber un
alineamiento entre las tareas de los Procesos de Negocio que requieren apoyo TIC5
y los
requerimientos de software expresados, por ejemplo, como Casos de Uso: todos los Casos de Uso
deben tener su origen en tareas de uno o más Procesos, y todas las tareas que requieren TIC deben estar
soportadas por – a lo menos – un Caso de Uso. Esta consistencia entre Procesos y Requerimientos es
esencial pues es el punto de unión el Negocio y los Sistemas de Información, como muestra la Figura
2-4.
5
Tecnología de Información y Comunicación.

7
Figura 2-4. Procesos y Requerimientos - punto de unión entre
Negocio y Sistemas de Información
El alineamiento entre elementos relacionados es esencial para que la Arquitectura Empresarial sea de
calidad. Para asegurar este alineamiento se requiere administrar la trazabilidad entre estos elementos.
Es decir, definir y documentar las relaciones entre ellos y tener la capacidad de consultarlas y
actualizarlas, si es necesario.
Por ejemplo, la Figura 2-5 muestra, en su lado izquierdo, una parte de un Proceso de Negocio en el que
algunas Actividades (enmarcadas en rojo) usan TIC, y en el lado derecho los Casos de Uso que
representan los Requerimientos de Software correspondientes6
.
6
Esto es parte del ejemplo del Capítulo 6. En particular la aplicación del Patrón Interacción Rol Interno-Sistema Interno
(Int RI < > SI).

8
Figura 2-5. Actividades en Proceso de Negocio (izq.)
y Requerimientos que las soportan (der.)
El hecho de saber que ciertos Requerimientos están relacionados con Actividades de los Procesos es
positivo, pero si estas relaciones no están documentadas esta información se puede perder. Por el
contrario, si las relaciones están documentadas y gestionadas con alguna herramienta, se tendrá un
control del alineamiento y serán posibles, por ejemplo, análisis de impacto.
En la Figura 2-6 se muestra, a la izquierda, la documentación explícita de la relación entre Casos de
Uso y Actividades a través de trazas (relación trace). A la derecha se visualizan todas las relaciones del
Caso de Uso Editar Ticket Nivel 1, tanto dentro del Modelo de Requerimientos (con otros Casos de
Uso y con Actores), como hacia los Procesos de Negocio (con las Actividades de los Procesos)7
.
7
Los modelos están hechos con la herramienta Enterprise Architect ( http://www.sparxsystems.com.au ).

9
Figura 2-6. Actividades y Casos de Uso relacionados (izq.)
y visualización de relaciones en Enterprise Architect (der.)
El tema del presente documento versa sobre el alineamiento de las celdas Proceso - Funciones y
Comportamiento y Tecnología-Motivación y Objetivos. La Metodología descrita consiste en
modelar los Procesos de Negocio con BPMN y alinearlos con los Requerimientos de Software
modelados con Casos de Uso de UML. En los siguientes capítulos se realiza una introducción a estos
dos estándares.

10
3 Modelos y Notación de Procesos de Negocio (BPMN)
Los Procesos de Negocio son trabajados con distintos niveles de detalle y formalización, y con
diversos propósitos. Por un lado, los analistas de negocio utilizan algún tipo de flujograma para
representarlos de manera informal o para describir gráficamente los procedimientos administrativos
bajo la norma ISO 90008
.
Figura 3-1.Flujograma (izq.), Diagrama de Actividades UML (der.)
Por otro lado, arquitectos de sistemas e ingenieros de software usan lenguajes formales, como BPEL9
,
para diseñar y ejecutar Procesos en Motores de Procesos BPMS10
.
BPMN (Business Process Model and Notation) es un lenguaje gráfico altamente formalizado cuyo
propósito es cubrir tanto las necesidades de diagramación de los Procesos de Negocio como su diseño
formal para alimentar Motores de Procesos. BPMN provee un mapeo hacia BPEL, y algunos Motores
de Procesos aceptan directamente Procesos diseñados con BPMN.
8
En ISO 9000 un Procedimiento Administrativo es la documentación de un Proceso.
9
Business Process Execution Language.
10
Business Process Management System or Suite. Estos sistemas también se conocen con otros nombres: WfM (Workflow
Management), Motor de Workflow o Process Engine.

11
3.1 Ejemplo de BPMN
En esta sección se muestra un ejemplo simple de BPMN11
, pero que muestra con claridad su uso y sus
elementos más importantes. El ejemplo describe, a un alto nivel, el funcionamiento del Sistema de
Soporte que una Empresa de Software ofrece a sus Clientes para la solución de problemas que éste
tenga con el uso de las aplicaciones provistas.
Informalmente podemos describir el funcionamiento del Sistema de Soporte en los siguientes términos:
El Cliente realiza una consulta a un Administrador de Cuenta, quien le entrega la
respuesta. Si el Administrador de Cuenta puede resolver la consulta la responde de
inmediato, si no deriva el problema a la Mesa de Ayuda Nivel 1. Esta resuelve el
problema y entrega la respuesta al Administrador de Cuenta para que la comunique
al Cliente. La Mesa de Ayuda Nivel 1 puede derivar el problema al Nivel 2 quien
debe obligatoriamente entregar una respuesta al Administrador de Cuenta, si es
necesario consulta al Desarrollador.
A continuación se realiza una descripción del mismo Sistema de Soporte, pero usando la terminología
de BPMN.
El diagrama de la Figura 3-2 muestra una Colaboración en la que interactúan los Procesos de dos
Participantes:
 Cliente
 Empresa de Software
Cada Participante está representado en el Diagrama por una Piscina, dentro de la que se muestra un
Proceso.
 Para el Participante Cliente su Proceso no se muestra en el diagrama (porque no es
relevante para el modelador, o porque – incluso siendo parte del modelo - no es relevante
para el destinatario del diagrama).
 Para el Participante Empresa de Software se muestra el detalle del Proceso.
La Piscina de Empresa de Software está compartimentada en Carriles que, en este caso, representan
unidades de la organización (Soporte, Mesa de Ayuda Nivel 1 y Nivel 2) y roles o cargos cumplidos
por personas (Administrador de Cuenta y Desarrollador).
11
Este ejemplo es una variación del mostrado en (Object Management Group, 2010)

12
Figura 3-2. Sistema de Soporte como Colaboración BPMN
Los Procesos se comunican a través de Flujos de Mensaje que van desde una Piscina a otra. Un Flujo
de Mensaje se inicia en el borde de una Piscina o en un objeto dentro de ella y termina en el borde de
otra Piscina o en un objeto dentro de ella. En el diagrama hay dos Flujos de Mensaje (ver detalle en
Figura 3-3):
 Desde la Piscina de Cliente al Evento Consulta Recibida en la Piscina de Empresa de
Software.
 Desde la Tarea Explicar Solución en la Piscina de Empresa de Software a la Piscina de
Cliente.

13
Figura 3-3. Flujos de Mensaje entre Piscinas
Un Proceso está constituido por un conjunto de Objetos de Flujo (Eventos, Actividades y Compuertas)
conectados por Flujos de Secuencia, los que determinan cómo se va pasando de un objeto a otro
durante la ejecución del Proceso.
La ejecución de un Proceso comienza cuando ocurre un Evento. En el ejemplo, cuando ocurre el
Evento Consulta Recibida, gatillado por el Mensaje desde el Cliente.
Una vez ocurrido el Evento el flujo continúa con la Tarea Manejar la Consulta, la que es realizada por
el Administrador de Cuenta. Durante la ejecución de esta Tarea el Administrador de Cuenta
determina si puede o no solucionar la consulta del Cliente. Una vez terminada la Tarea, el Proceso se
bifurca al llegar a una Compuerta que tiene dos caminos alternativos. Si el Administrador de Cuenta
puede solucionar la consulta el mismo realiza la Tarea Explicar Solución (que, mediante un Flujo de
Mensaje, comunica la solución al Cliente) y el Proceso termina. En caso contrario, la ejecución
continúa en la Tarea Manejar Incidencia de Nivel 1 realizada por la Mesa de Ayuda Nivel 1.
Así el Proceso continúa con la realización de diferentes Tareas y siguiendo el flujo determinado por la
Compuertas.

14
Figura 3-4. Incicio del Proceso al gatillarse el Evento Consulta Recibida
Las Actividades en BPMN son de dos tipos: Tareas y Subprocesos. Las primeras se consideran
atómicas, en el sentido que, a nivel del modelo BPMN, no tienen mayor nivel de detalle. Por otro lado,
los Subprocesos sí tienen mayores detalles (normalmente representados en otro diagrama). En el
ejemplo, todas las Actividades son Tareas, excepto Proveer retroalimentación que es realizada por el
Desarrollador (ver Figura 3-5).
Figura 3-5. Actividades: Tareas o Subprocesos
En la sección siguiente se realiza una descripción de los principales elementos de BPMN, éstos cubren
todo lo necesario para entender los ejemplos de BPMN mostrados en este documento.

15
3.2 Elementos de BPMN
Los elementos de BPMN para describir Procesos y Colaboraciones son:
 Elementos de Flujo.
 Elementos de Conexión
 Calles de Responsabilidad (Swimlanes)
 Artefactos
3.2.1 Elementos de Flujos
Los Elementos de Flujo (Actividades, Eventos y Compuertas) son los principales elementos de BPMN
pues permiten describir lo que pasa en el Proceso.
3.2.1.1 Actividades
El trabajo realizado en un Proceso se representa con Actividades, las que pueden ser Subprocesos o
Tareas.
Un Subproceso es una actividad no atómica, es decir, compuesta por otras actividades. Puede estar
colapsado (no se muestran sus actividades internas) o expandido.
Figura 3-6. Subproceso colapsado
Una Tarea es una actividad atómica, es decir, no se descompone en un mayor nivel de detalle. Son
realizadas por una persona y/o aplicación. La tipificación de las Tareas se muestra en la Tabla 1.

16
Tabla 1. Tipificación de Tareas BPMN
Tarea sin especificación mayor.
Tarea realizada por una persona sin el apoyo de
un Motor de Procesos o cualquier aplicación de
software.
Típica Tarea “workflow” donde una persona
realiza la Tarea con la asistencia de una aplicación
de software.
Usa algún tipo de servicio, el que puede ser un
servicio web o una aplicación automatizada.
Tarea automatizada ejecutada recurrentemente,
puede correr en un Motor de Procesos.
Provee un mecanismo para entregar un input a un
Motor de Reglas de Negocio y obtener el output
desde éste.
3.2.1.2 Eventos
Un Evento modela algo que sucede durante el proceso. Por ejemplo:
 Cambio de estado de un documento.
 Un mensaje que llega o que se envía.
 Un proceso que se inicia o finaliza.
 Se cumple un plazo.

17
Hay tres tipos de Evento:
 Inicial: indica dónde comienza un Proceso. Circulo con línea simple.
 Intermedio: ocurren entre un Evento Inicial y un Evento Final. Círculo con línea doble.
 Final: indica dónde termina el Proceso. Círculo con línea gruesa.
Figura 3-7. Tipos de Eventos
Para cada tipo de Evento existen variantes que indican el motivo por el que éste se gatilla. Las
principales variantes para cada tipo se muestran en las siguientes Tablas.
Tabla 2. Eventos Iniciales más utilizados
El Proceso comienza de inmediato.
El Proceso comienza cuando llega un
Mensaje desde otro Participante.
El Proceso comienza cuando se cumple
una fecha, hora o ciclo (“3 pm”, “1er
viernes del mes”).

18
Tabla 3. Eventos Intermedios más utilizados
Para indicar un cambio de estado en el
Proceso.
Para recibir o enviar un Mensaje desde o
hacia otro Participante.
Cuando se cumple una fecha, hora o ciclo.
Tabla 4. Eventos Finales más utilizados
Indica el fin de un flujo dentro de un
Proceso.
El Flujo termina con el envío
de un Mensaje a otro Participante.
Todas las Actividades del Proceso
terminan.

19
3.2.1.3 Compuertas
Las Compuertas (Gateways) representan bifurcaciones, uniones y acoplamientos de flujos. Se usan
cuando se necesita controlar el camino que seguirá el Proceso de acuerdo a condiciones basadas en
datos o en Eventos. Las compuertas más utilizadas son tres: Exclusiva, Inclusiva y Paralela.
Tabla 5. Compuertas más utilizadas
Se sigue un solo camino dependiendo
del cumplimiento de condiciones.
Se sigue uno o más caminos
dependiendo del cumplimiento de
condiciones.
Se siguen varios caminos paralelos.
3.2.2 Calles de Responsabilidad (Swimlanes)
Las Calles de Responsabilidad permiten organizar los diagramas para resaltar las capacidades
funcionales o responsabilidades de quienes (personas y organizaciones) participan en las
Colaboraciones.
Hay dos tipos de Calles de Responsabilidad: Piscinas (Pools) y Carriles (Lanes).
Los nombres de Piscinas y Carriles recuerdan a roles, cargos y partes de un organigrama. BPMN no
tiene como propósito modelar la estructura de la organización. Sin embargo, en un modelo correcto de
Procesos BPMN todas las Piscinas y Carriles deben estar de una otra manera reflejados en las
estructura de la organización y los roles y cargos que las personas tienen en dichas estructura.

20
3.2.2.1 Piscina
Una Piscina es la representación gráfica de un Participante en una Colaboración. Todo Proceso ocurre
dentro de los límites de una Piscina.
Figura 3-8. Formas de diagramar una Piscina
3.2.2.2 Carril
Un Carril es una sub-partición dentro de una Piscina, normalmente son usados para representar:
 Roles internos
 Sistemas de Información
 Unidades organizacionales como departamentos, gerencias, etc.
Figura 3-9. Carriles dentro de una Piscina

21
3.2.3 Elementos de Conexión
Los Elementos de Conexión unen los Elementos de Flujo, Calles de Responsabilidad y Artefactos entre
sí. Hay tres Elementos de Conexión: Flujo de Secuencia, Flujo de Mensaje y Asociación.
3.2.3.1 Flujo de Secuencia
El Flujo de Secuencia es usado para mostrar el orden en que las actividades son realizadas en un
Proceso. Puesto que un Proceso ocurre dentro de los límites de una Piscina se colige que un Flujo de
Secuencia no puede atravesar los límites de ésta.
Un Flujo de Secuencia uno dos Elementos de Flujo, es decir, Actividades, Eventos y Compuertas.
Figura 3-10. Flujo de Secuencia
Cada Elemento de Flujo puede tener cero o varios Flujos de entrada o de salida. En la Tabla 6 se
muestran las Reglas de Conexión de Flujo de Secuencia.
Tabla 6. Reglas de Conexión de Flujo de Secuencia

22
3.2.3.2 Flujo de Mensaje
El Flujo de Mensaje es usado para mostrar la comunicación entre Participantes en una Colaboración.
Por lo tanto no puede ocurrir dentro de una Piscina, siempre va de una a otra.
Figura 3-11. Flujo de Mensaje
Un Flujo de Mensaje conecta dos Piscinas o Elementos de Flujo dentro de ellas. En la Tabla 7 Tabla
6se muestran las Reglas de Conexión de Flujo de Mensaje.
Tabla 7. Reglas de Conexión de Flujo de Mensaje

23
El Flujo de Mensaje sólo se refiere a una comunicación entre dos Piscinas, no a la tecnología usada
para dicha comunicación. Por ejemplo, dos personas se pueden comunicar cara a cara, o dos Sistemas
de Información lo pueden hacer vía servicios web. A nivel de BPMN lo relevante es dejar establecido
que ambos Participantes se comunican.
El Flujo de Mensaje es asincrónico. Esto significa que después que un Participante envía un Mensaje a
otro Participante (otra Piscina), sigue con la ejecución de su Proceso, es decir, desde la Tarea o Evento
que generó el Mensaje se sigue un Flujo de Secuencia hacia otra Tarea o Evento dentro de la misma
Piscina.
Si una Colaboración requiere que dos Participantes se coordinen, lo normal es que uno de ellos le envíe
un Mensaje a otro y continúe con su Proceso. Más adelante, el que envío el Mensaje se queda
esperando la respuesta del otro, por medio de una Tarea o Evento de Recepción de Mensaje.
Figura 3-12. Coodinación de Participantes a través de Mensajes

24
3.2.4 Otros Elementos de BPMN
Lo elementos descritos de BMPN son los más importantes ya que con ellos es posible realizar la mayor
parte de los modelos de Procesos y Colaboraciones. Sin embargo, existen más variantes de los
elementos descritos y otros tipos de diagramas. A continuación una lista sumaria del contenido de
BPMN:
 Tipos de Tarea: Abstracta, Manual, Usuario, Servicio, Envío, Recepción, Regla de Negocio y
Script.
 Marcas de Actividad: las Tareas y Subprocesos puede ser repetitivas (secuencial o paralelo) y
ad-hoc.
 Transacción: un Subproceso puede ser una transacción, es decir, soportado por un protocolo
especial que asegura que todas las partes involucradas acuerdan que la actividad puede ser o
completada o cancelada.
 Actividad de Llamada: punto en el Proceso donde se (re)utiliza un Proceso Global o una Tarea
Global.
 Subproceso-Evento: no es parte del flujo normal, puede ejecutarse varias veces mientras el
Proceso que lo contiene está activo.
 Tipos de Evento: Nada, Mensaje, Timer, Condicional, Señal, Múltiple, Múltiple Paralelo, Error,
Escalada, Cancelar, Compensación, Enlace, Terminar.
 Eventos adosados a Actividades: los Eventos pueden estar adosados a una Actividad, la que
pueden interrumpir o no.
 Tipos de Compuertas: Exclusivo, Basado en Eventos, Basado en Eventos Paralelo, Inclusivo,
Complejo y Paralelo.
 Conversaciones: Diagramas que muestran una versión simplificada de una Colaboración.
 Coreografías: Diagramas que muestra secuencias ordenadas de intercambio de mensajes entre
dos o más Participantes.
 Artefactos: proveen información adicional al Proceso, pero no influyen en el flujo del Proceso.
 Asociación : usado para conectar información y Artefactos a elementos gráficos de BPMN
Para fuentes más detalladas de BPMN consultar la bibliografía al final del documento.

25
4 Lenguaje Unificado de Modelado (UML)
UML (Unified Modeling Language) es un lenguaje gráfico para describir modelos de software, con
enfoque orientado a objetos. Se usa UML para:
 Visualizar y comunicar modelos e ideas.
 Especificar modelos.
 En ingeniería directa e inversa.
 Documentar.
UML se puede usar en aplicaciones de cualquier dominio: finanzas, ciencia, ingeniería, grandes y
pequeñas empresas, etc.
4.1 Estructura de UML
UML está definido por los Diagramas que permiten visualizar distintas vistas o aspectos de una
determinada realidad; y los Elementos y Relaciones que se muestran en los Diagramas.
Figura 4-1. Contenido de UML
En Modelo de un sistema es una descripción de éste y su entorno con un determinado propósito.
Usualmente un Modelo es una combinación de texto y diagramas.

26
El objetivo es construir Modelos, no sólo Diagramas con UML u otros leguajes similares. Para ello hay
que crear Modelos “enriquecidos”, es decir, complementar lo puramente gráfico con documentación de
los elementos, restricciones formales (invariantes, pre y pos condiciones), estereotipos, valores
etiquetados, etc.
4.1.1 Tipos de Modelos en UML
UML permite construir dos tipos de Modelos: Estáticos o Estructurales, y de Comportamiento o
Dinámicos.
Los Modelos Estructurales destacan la estructura y la organización del sistema:
 Clases
 Objetos
 Componentes
 Paquetes
 Despliegue
 Artefactos
 Estructura Compuesta
Los Modelos Comportamiento destacan los aspectos dinámicos del sistema:
 Casos de Uso
 Secuencia
 Comunicación
 Estados
 Actividades
 Tiempos
 Visión Global de Interacciones
Como se ve, UML contiene una gran variedad de Diagramas que permiten modelar distintas vistas de
los sistemas de software. Sin embargo, algunos son más importantes y, por ende son más utilizados. De
acuerdo a (Grossman, Aronson, & McCarthy, 2005), los más utilizados son, es este orden: Casos de
Uso, Clases, Secuencia, Estados, Actividades, Comunicación, Componentes y Despliegue.
Para la compresión de los ejemplos y discusiones en el resto del documento, en las siguientes secciones
se describen las principales características de los Modelos de Clase, Casos de Uso y Actividades.

27
4.2 Modelo de Clases
Los Modelos de Clase son usados para mostrar la Estructura Estática de un Sistema de Software
Computacional o del Dominio en el que existe dicho Sistema.
En un Dominio donde existen personas que son dueñas de vehículos, podemos – informalmente –
describir este hecho en los siguientes términos:
Una persona tiene vehículos, los que tienen color y marca.
Con mayor formalidad, lo anterior, se puede expresar como:
 Una Persona posee cero o más Vehículos. Un Vehículo es de una Persona que cumple, en esta
relación, el rol de propietario.
 Un Vehículo tiene color, el que puede ser rojo, verde o azul. Un Vehículo tiene una marca, la
que puede ser Ford, Datsun o Volvo.
En UML lo anterior se representa gráficamente con íconos y relaciones mostradas como líneas entre
éstos. Las agrupaciones de entidades (cosas, personas, etc.) se denominan clases y se representan
mediante rectángulos. En el ejemplo hay dos Clases: Persona y Vehículo.
Figura 4-2. Diagrama de Clases UML
Un tipo especial de Clase, denominado, Enumerador se utiliza para representar conjuntos acotados de
elementos simples. En ejemplo hay dos Enumeradores; Color y Marca.
Las relaciones entre Clases en UML se denominan Asociaciones. En el ejemplo, desde la perspectiva
de una Persona, la asociación hacia Vehículo describe el hecho que una Persona posee cero o más
(0..*) vehículos.
Persona
«enumeration»
Color
ROJO
VERDE
AZUL
«enumeration»
Marca
FORD
DATSUN
VOLVO
Vehículo
vehículos
0..*
poseepropietario
1
marca
10..*
color
1
0..*

28
Figura 4-3. Asociación entre Persona y Vehículo vista desde Persona
Desde la perspectiva de un Vehículo, la asociación hacia Persona describe el hecho que un Vehículo
es posesión de una (1) Persona, cumpliendo el rol de propietario.
Figura 4-4. Asociación entre Persona y Vehículo vista desde Vehículo
Los Modelos de Clases permiten modelar relaciones entre conceptos y sus variedades. Por ejemplo,
Vehículo es la base de un conjunto de clases relacionadas por Generalizaciones: Camión, Camioneta
y Automóvil son tipos de Vehículo. Además, Sedán, SUV y Hatchback son tipos de Automóvil.
Figura 4-5. Jerarquía de Clases: Vehíclos y sus variedades
Persona Vehículo
vehículos
0..*
poseepropietario
1
Persona Vehículo
vehículos
0..*
poseepropietario
1
Vehículo
Camión Camioneta Automóvil
Sedán SUV Hatchback

29
Las Clases pueden ser modeladas con mayor detalle agregándoles:
 Atributos: representan características de cada Persona. En ejemplo rut, nombre y direcciones.
 Operaciones: describen lo que pueden hacer una Persona. En el ejemplo comprar y vender.
Una Asociación también puede tener datos, en UML se utiliza una Clase para representarlos y ésta es
unida a la Asociación. En el ejemplo la instancia de la Asociación corresponde a una Compra/Venta
realizada en una determinada fecha y que involucra un cierto monto.
Figura 4-6. Clases con atributos y operaciones. Asociacción con datos
Los Modelos de Clases pueden ser usados para representar el Dominio del problema con un alto grado
de abstracción para que pueda ser entendido tanto por técnicos como por los usuarios del Dominio. En
el otro extremo, con un alto grado de detalle y formalización las Clases se pueden usar para representar
clases en lenguajes de programación orientados a objetos como Java o C#.
Persona
rut: Rut
nombre: Nombre
direcccion comercial: Direccion
direcccion privada: Direccion
comprar(Vehículo)
vender(Vehículo)
«enumeration»
Color
ROJO
VERDE
AZUL
«enumeration»
Marca
FORD
DATSUN
VOLVO
Compra/Venta
fecha: Date
monto: int
Vehículo
patente: string
color
1
0..*
vehículos
0..*
poseepropietario
1
marca
10..*

30
Figura 4-7. Clase detallada (izq.), código Java (der.)
En resumen, los Modelos de Clases pueden ser usados en distintas etapas del desarrollo de Software:
desde la comprensión del problema en el lenguaje del Negocio, hasta la programación, pasando por el
análisis y el diseño.
Los Modelos de Clases contienen más elementos y relaciones que los aquí mostrados: Interfaces,
Agregaciones, Composiciones, Asociaciones Cualificadas, entre otros. Para mayor detalle consultar la
bibliografía.
Comparable
EMail
- localPart: String
- domain: String
- EMail(String, String)
+ getLocalPart(): String
+ getDomain(): String
+ valueOf(String): EMail
+ toString(): String
+ compareTo(EMail): int
public class EMail extends Tipo implements Comparable<EMail> {
private String localPart;
private String domain;
private EMail(String localPart, String domain) { . . . }
public String getLocalPart() {return localPart;}
public String getDomain() {return domain;}
public static EMail valueOf(String stringEmail)throws TipoErroneoException{
if (stringEmail == null || stringEmail.length()== 0){
throw new TipoVacioException("Email vacío");
}
EMail resultado = null;
String regex = "w+@(w+.)+[a-zA-Z]{2,3}";
Pattern pattern = Pattern.compile(regex);
Matcher m = pattern.matcher(stringEmail);
if (m.matches()){// email bien escrito
String[] partes = stringEmail.split("@");
resultado = new EMail(partes[0], partes[1]);
} else { throw new TipoErroneoException("Email mal escrito");
return resultado;
}
@Override
public String toString() {return localPart + "@" + domain;}
@Override
public int compareTo(EMail r) {
return this.toString().compareTo(r.toString());
}
}

31
4.3 Modelo de Casos de Uso
Los Modelos de Casos de Uso son usados para representar los Requerimientos de un Sistema de
Información en términos de la forma en que los usuarios (personas u otros sistemas) lo usan.
En un Sistema de Información que maneja Cuentas Bancarias podemos – informalmente – describir los
requerimientos12
en los siguientes términos:
El titular de una o más Cuentas puede, en un Cajero Automático, hacer retiros o
transferir entre cualquiera de sus Cuentas. Cuando retira o transfiere, el usuario
puede imprimir un comprobante de la transacción, si lo desea. La transferencia
entre cuentas de distinta moneda, que es una variación de la transferencia normal,
es una característica opcional que, dependiendo de los recursos disponibles, será o
no incluida en la siguiente versión del sistema.
Con mayor formalidad, lo anterior, se puede expresar como:
 El Sistema es utilizado por el Actor Cliente Cuentacorrentista.
 El Cuentacorrentista utiliza instancias de los Casos de Uso (CU) Retirar de Cuenta y
Transferir entre Cuentas.
 El CU Imprimir Comprobante es incluido por Retirar de Cuenta y Transferir entre
Cuentas. Es decir, dentro de la ejecución de éstos se incluye (llama o utiliza) a Imprimir
Comprobante. En este sentido, este último CU es obligatorio para que los otros dos puedan
funcionar.
 El CU Transferir entre Cuentas de distinta Moneda es una extensión de Transferir entre
Cuentas, en el sentido que es una variación de este último, y se considera opcional porque
puede o no ser incluido en la siguiente entrega13
.
Un Modelo de Casos de Uso UML consta de Casos de Uso, Actores y relaciones entre ellos: los
Actores utilizan Casos de Uso, los Casos de Uso incluyen, extienden y/o generalizan otros Casos de
Uso.
Como muestra la Figura 4-8, Transferir entre Cuentas de distinta Moneda depende de la existencia
de Transferir entre Cuentas, es una variación de éste (la flecha apunta hacia Transferir entre
Cuentas). Por otro lado, Transferir entre Cuentas depende de la presencia de Imprimir
Comprobante (la flecha apunta hacia Imprimir Comprobante).
El nombre del Caso de Uso refleja lo que el Usuario hace con el Sistema. Por ejemplo, si una tienda
vende sus productos a sus clientes, ¿cuál será el Caso de Uso que representa este hecho?, ¿Vender
Producto o Comprar Producto?
12
Obviamente, un sistema como éste tendrá muchos más requerimientos.
13
Si no es incluido de todos modos el sistema podrá ser utilizado, no estará incompleto.

32
Figura 4-8. Modelo de Casos de Uso
Si el cliente compra por Internet habrá un Caso de Uso Comprar Producto asociado al Actor Cliente,
pues es éste quien interactúa con el Sistema de Información. Por otro lado, si el cliente va a una Tienda
y es un vendedor quien registra lo que el cliente compró, habrá un Caso de Uso Vender Producto
asociado al Actor Vendedor. Lo normal es que existan ambos Casos de Uso y ambos Actores (como
muestra la Figura 4-9). A nivel sistémico los componentes que implementan ambos Casos de Uso serán
los mismos, diferirán sólo en los que implementan la interfaz de usuario mediante la cual los Actores
acceden al mismo Sistema de Información.
Figura 4-9. El Caso de Uso refleja lo que el Actor hace con él
Retirar de Cuenta
Imprimir
Comprobante
Cliente Cuenta-
correntista
Transferiri entre
Cuentas
Transferir entre
Cuentas de distinta
Moneda
«include»
«extend»
«include»
Comprar Producto
Cliente
Vender Producto
Vendedor

33
Los Diagramas de Casos de Uso son sencillos en el sentido que contienen pocos íconos y relaciones.
Esta sencillez se extiende también a su utilización: deben ser simples y fáciles de entender tanto por
técnicos como por usuarios del Dominio.
Los Casos de Uso se utilizan para:
 Comunicarse con el usuario final, el cliente y otros involucrados.
o Proporciona credibilidad en una etapa inicial del desarrollo del Sistema de Información.
o Asegura una comprensión mutua de los requerimientos.
 Identificar
o Quién interactuará con el Sistema de Información.
o Qué interfaz deberá tener el Sistema de Información.
 Validar que los requerimientos estén alineados con las reales necesidades de la organización.
 Verificar
o Que se hayan capturado todos los requerimientos.
o Que los desarrolladores hayan entendido los requerimientos.
 Servir de entrada al desarrollo de la solución de software que cumplirá con los requerimientos
definidos por los Casos de Uso.
 Gestionar el Proyecto
o Planificar y controlar un proyecto de software.
o Estimar la complejidad y tamaño de un Sistema de Información (Puntos de Casos de
Uso).
Como muestra la Figura 4-10, los Casos de Uso no sólo sirven para describir los Requerimientos sino
que también son la base para planificar el Proyecto14
y los demás Modelos15
están relacionados con él.
14
Las Iteraciones se planifican de acuerdo a los Casos de Uso que serán trabajados en ella. Los recursos de distribuyen de
acuerdo a ellos: tal Diseñador diseñará tales Casos de Uso, tal Desarrollador programará y probará tales Casos de Uso en tal
fecha, etc. El avance se mide en términos de ellos: se ha diseñado el 80% de los Casos de Uso, ha pasado a producción el
45% de los Casos de Uso, etc.
15
Los Modelos pueden estar documentados o no, dependiendo del Proceso de Desarrollo utilizado (Ágil, MDA, etc.).

34
Figura 4-10. Desarrollo dirigido por Casos de Uso
4.3.1 Descripción de un Caso de Uso
Los Casos de Uso son un buen ejemplo para ver la diferencia entre Modelos y Diagramas. Los Modelos
de Casos de Uso son para describir los requerimientos, pero no toda la descripción de éstos está en los
Diagramas de Casos de Uso. Por ejemplo, el hecho que el Usuario pueda decidir imprimir o no el
comprobante no está en el Diagrama (el dibujo) sino en la descripción del Caso de Uso.
A diferencia de los Modelos de Clases que contienen variados íconos y relaciones que permiten en el
Diagrama presentan mucha información, los Modelos de Caso de Uso contienen la mayor parte de la
información en la documentación de cada Caso de Uso, la que contiene:
 Nombre del Caso de Uso.
 Descripción breve.
 Precondiciones.
 Postcondiciones.
 Flujos de Eventos.
o Flujo Básico.
o Flujo(s) Alternativo(s).
 Interfaces con Usuarios o con otros Sistemas de Información.
Diferentes técnicas manejan distintos niveles de documentación con distintos grados de formalización.
En un extremo puede bastar el nombre y una descripción como entrada para el desarrollo. En el otro
extremo el Caso de Uso puede ser descrito detallada y formalmente como entrada para un diseño
detallado. Por ejemplo, las pre y postcondiciones pueden ser formalizadas con OCL16
en términos de
16
Object Constraint Language.

35
lógica de predicados, y los Flujos de Eventos pueden ser descritos con, por ejemplo, diagramas UML
de Actividad o de Secuencia.
Los Casos de Uso no deben estar descritos en términos de botones, selecciones y otros elementos
típicos de una pantalla. De este modo un mismo Caso de Uso puede estar asociado a más de una
Interfaz de Usuario en distintas tecnologías17
. Sin embargo, como parte de los requerimientos es
necesario tener definidas las pantallas, mapas de navegación e interfaces con otros Sistemas de
Información, todo esto no sólo hace que los requerimientos estén más completos sino que también
ayudan a definir mejor los Casos de Uso.
Los Diagramas de Casos de Uso contienen más elementos y relaciones que los aquí mostrados: Temas,
Generalizaciones, entre otros. Para mayor detalle consultar la bibliografía.
4.3.2 Requerimientos sólo con Casos de Uso
Distintas metodologías de Desarrollo de SW usan uno o más artefactos para el levantamiento de
Requerimientos: Lista de Características, Modelo de Requerimientos, Modelo de Casos de Uso.
Figura 4-11. Artefactos para captura Requerimientos y su secuencia temporal
Por lo expuesto en las secciones anteriores, tener un Modelo de Requerimientos junto con un Modelo
de Casos de Uso es, por definición, redundante.
Algunas metodologías utilizan los Casos de Uso como una técnica de diseño de las interfaces de
usuario y el paso de una a otro, por lo que el diagrama termina siendo una representación del mapa de
navegación de la aplicación.
17
Un mismo Caso de Uso representa requerimientos funcionales que pueden ser accedidos desde un Smartphone, desde una
típica aplicación web a través de un browser y desde una aplicación cliente servidor. En los tres escenarios las pantallas y la
interacción serán diferentes, pero el Caso de Uso será el mismo.

36
El enfoque presentado en este documento utiliza a los Casos de Uso en su propósito original: captura y
descripción de los requerimientos funcionales y no funcionales. Por lo tanto, no se usará un Modelo de
Requerimientos tradicional. Además, no se usará una Lista de Características puesto que los Casos de
Uso vendrán determinados por los Procesos de Negocio.
Figura 4-12. Requermientos exclusivamente con Casos de Uso

37
4.4 Modelo de Actividades
Los Modelos de Actividad son usados para representar el comportamiento del Sistema de Información
o del Negocio. Muestran actividades y acciones (atómicas), destacando:
 Condiciones y flujos alternativos.
 Tareas y procesos concurrentes.
 Responsabilidades sobre ciertas actividades.
Normalmente son utilizados para:
 Describir Procesos de Negocio.
 Describir Flujos de Eventos en Casos de Uso.
 Describir algoritmos.
En un Dominio donde existen personas que son dueñas de vehículos, podemos – informalmente –
describir este hecho en los siguientes términos:
Si el contrato está en regla, lo firmo. En caso contrario lo analizo y agrego anexos,
y luego lo firmo.
En UML lo anterior se muestra gráficamente con íconos que representan actividades, bifurcaciones y
barras de sincronización, unidos por líneas que indican la secuencia de ejecución.
Figura 4-13. Diagrama de Actividad

38
Los Diagramas de Actividad también pueden contener Carriles (Lanes) que indican los responsables de
las actividades descritas. Si el diagrama representa un Proceso de Negocio, los responsables serán roles
o unidades organizacionales. Si representa el comportamiento del software, los responsables serán
módulos, componentes o sistemas.
Figura 4-14. Diagrama de Actividad con Carriles
Existen semejanzas entre los Diagramas de Actividad UML y los Diagramas de Procesos de BPMN,
pero también muchas diferencias. Según lo indicado en (Object Management Group, 2013) BPMN fue
diseñado considerando la práctica y experiencia con lenguajes y notaciones ya existentes, entre los que
se cuentan los Diagramas de Actividad UML.
Los Diagramas de Actividades contienen más elementos que los aquí mostrados: objetos creados y
recibidos, envío y recepción de señales, entre otros. Para mayor detalle consultar la bibliografía.

39
4.5 Modelado de Procesos de Negocio, ¿UML o BPMN?
Como se explicó en la sección anterior, UML también puede ser usado para el Modelado de Procesos
de Negocio. La manera más directa es por medio de Diagramas de Actividad como se muestra en la
Figura 4-14, donde se representan las actividades para crear el Modelo de Casos de Uso y los Roles que
participan. Los Diagramas de Actividad no difieren mucho de los flujogramas comúnmente utilizados
para describir procedimientos administrativos18
.
Extensiones de UML incluyen Casos de Uso de Negocio y Actores de Negocio, que, usando una
notación análoga a los Casos de Uso, representan los Participantes y los Procesos de Negocio.
Gráficamente los Casos de Uso de Negocio se distinguen porque tiene una línea diagonal en la parte
inferior derecha. Los Actores de Negocio tienen una línea diagonal en la parte inferior derecha de su
cabeza.
Los Casos de Uso de Negocio se pueden detallar con texto estructurado y/o diagramas dinámicos de
UML (Actividades o Secuencia).
Figura 4-15. Casos Uso de Negocio y Actores de Negocio
18
Ver Nota 8 (pág. 11).
Solicitar Ayuda
«business actor»
Administrador de
Cuenta
«business actor»
Desarrollador
Proveer Soporte en
Mesa de Ayuda
Proveer
Retroalimentación
de desarrollo
«business actor»
Cliente
«business actor»
Agente de Mesa de
Ayuda Nivel 1
«business actor»
Agente de Mesa de
Ayuda Nivel 2
«invokes»
«extend»

40
Las extensiones de UML para Procesos de Negocio surgieron por la necesidad del personal de TI de
conocer el negocio para la captura de requerimientos y lo más natural fue reutilizar las notaciones
propias del modelado de Sistemas de Información. Sin embargo, estas notaciones no son utilizadas por
los encargados de la documentación de los Procesos de Negocio.
Se podría argumentar que al trabajar dentro de UML, el alineamiento de los elementos de Procesos de
Negocio y los Requerimientos de Software sería más natural y sencillo. Sin embargo, esto no es así
pues UML es un conjunto de notaciones donde está bien definida la relación entre los elementos de
cada tipo de diagrama, pero no entre ellos. Es responsabilidad de las metodologías y técnicas que usan
UML definir la trazabilidad entre los elementos de los distintos diagramas.
Por lo tanto ya sea que se use UML o BPMN para los Procesos de Negocio, de todas maneras habrá
que definir el mapeo entre elementos de los Procesos de Negocio (en UML o BPMN) a los
requerimientos en Casos de Uso UML.
Además, los diagramas UML se pueden usar en distintas etapas del modelado e implementación de
Sistemas de Información. Por este motivo el estándar UML establece las reglas sintácticas del lenguaje,
pero da espacio a las metodologías y técnicas que lo utilizan para que interpreten la semántica exacta
de los diagramas. Por su parte, BPMN está pensado exclusivamente para Procesos de Negocio y para
ser utilizado por herramientas que automaticen la ejecución de dichos Procesos, por lo tanto tiene una
semántica muy clara y deja menos espacio para interpretaciones.
En resumen, es mejor utilizar BPMN para modelar los Procesos de Negocio en lugar de UML por las
siguientes razones:
 Fue diseñado específicamente para modelar Procesos de Negocio.
 Representa los Procesos de Negocio como flujogramas enriquecidos que pueden ser entendidos
por especialistas de procesos.
 Se está convirtiendo en un estándar de facto en las herramientas BPMS.
 Por su naturaleza procedural son fáciles de entender por el personal técnico TI.

41
5 Metodología de Alineamiento
UML y BPMN son estándares, es decir, establecen las normas sintácticas del lenguaje – cómo realizar
los diagramas - y su semántica – el significado de los elementos de los diagramas.
Tanto BPMN como UML tiene una gran cantidad de elementos y tipos de diagramas. En la mayoría de
los casos no se requiere usarlos todos. Además, ambos estándares presentan diferentes interpretaciones
para algunos de sus elementos, dejando al usuario del lenguaje la decisión de cuál usar.
BPMN y UML no son Metodologías ni Técnicas, sino estándares neutros con respecto a cualquier
Metodología. Cuando una Metodología usa BPMN y/o UML debe indicar qué usará (tipos de
diagramas y elementos) y cómo los usará. Todo uso e interpretación debe ser consistente con la
especificación de los estándares.
En las siguientes secciones se describen los principios y políticas sobre los que se sustenta la
Metodología de Alineamiento. Luego se describen detalladamente sus dos partes estructurales:
Ambientes y Patrones. Donde los Ambientes establecen reglas sobre cómo definir los Participantes de
las Colaboraciones, es decir, cómo aplicar Piscinas y Carriles. Y los Patrones definen las distintas
variantes en que la Tecnología de Información y Comunicación (TIC) puede aparecer en los Procesos
de Negocio, y establecen cómo cada una de éstas se representa como Casos de Uso y Actores.
5.1 Principios y Políticas
La Metodología de Alineamiento se sustenta sobre algunos principios y políticas que se derivan de
ciertos hechos y supuestos.
El Modelado del Negocio y el Modelado de Sistemas de Información son actividades diferentes, con
propósitos diferentes.
I. Los Procesos de Negocio y el Modelo de los Sistemas de Información no
estarán mezclados.
Las Empresas tienen distintos niveles de madurez en cuanto a la documentación de los Procesos de
Negocio y su grado de automatización
II. La Metodología de Alineamiento requiere que los Procesos de Negocio estén
documentados con BPMN.
III. La Metodología de Alineamiento no asume que los Procesos se ejecuten en un
BPMS.
IV. La Metodología de Alineamiento no asume derivación automática de los
Requerimientos.
El Modelado del Negocio tiene precedencia lógica y, normalmente, precedencia temporal respecto al
Modelado del Sistema de Información.

42
V. En los Procesos de Negocio se definirán los elementos donde el uso de TIC se
mapeará al Modelo de los Sistemas de Información.
Todo elemento del Modelo de Sistemas de Información debe satisfacer una necesidad de TIC en los
Procesos de Negocio. Las funcionalidades de los Sistemas de Información se originan como
Requerimientos de Software.
VI. Para asegurar el Alineamiento, ciertos elementos de los Procesos de Negocio
estarán mapeados a Requerimientos de Software en el Modelo de los Sistemas
de Información.
Actualmente, los Negocios no son tecnológicamente neutros. Los detalles tecnológicos no son tema del
Modelo de Negocio.
VII. En los Procesos de Negocio se identificarán explícitamente los puntos en que
se requiere soporte TIC.
VIII. El tipo de TIC a utilizar y la forma en que ésta trabajará son asunto del
Modelo de los Sistemas de Información.
Una vez definidos los Requerimientos de Software es posible, a partir de ellos, construirlo con
diferentes Metodologías.
IX. La Metodología de Alineamiento no asume un Proceso específico de
Desarrollo de Software.
Una aclaración es necesaria respecto a que la Metodología de Alineamiento requiere que los Procesos
de Negocio están documentados con BPMN, y que no está atada a ninguna Metodología de Desarrollo
de Software en particular.
La primera exigencia puede ser fuerte para aquellas organizaciones donde los Procesos de Negocio no
están formalizados, pero no es posible pensar en ningún esfuerzo tendente al alineamiento entre los
Procesos de Negocio y los Sistemas de Información sin que los primeros estén documentados
detalladamente. Para llegar a la formalización de los Procesos de Negocio, la Empresa debe tener
implementado algún tipo de Sistema de Gestión de Calidad (SGC)19
. La exigencia de usar BPMN20
es
necesaria para poder realizar el alineamiento de manera concreta con alguna notación estándar y no
sólo enunciar ideas.
Los únicos elementos del Modelo de los Sistemas de Información que la Metodología considera para el
Alineamiento son los Requerimientos, expresados como Casos de Uso. Por lo tanto las demás partes
19
No necesariamente se debe estar certificado o acreditado bajo alguna norma (ISO 9000, CMMi, acreditaciones
académicas u otros), pero sí los Proceso de Negocio deben ser consistentes con la Misión, Visón y Modelo de Negocio de la
Empresa, y debe haber algún tipo de gestión formal de los Procesos de Negocio
20
Si los Procesos de Negocio están descritos con otra notación es posible adaptar la Metodología de Alineaminto para ellas,
aunque no es parte de este documento.

43
del Modelo del Sistema de Información 21
, formalizados o no: componentes, casos de prueba, código
fuente, etc., no son relevantes para el Alineamiento.
Figura 5-1. Desde Misión a Procesos y desde Casos de Uso a Código
La Figura 5-1 muestra el hecho que los Procesos de Negocio deben estar dentro de un Sistema de
Gestión de Calidad formal o informal, de ahí el apelativo de SGC like. Por otro lado, los Casos de Uso
pueden ser el inicio de un Proceso de Desarrollo altamente documentado como Rational Unified
Process, o la descripción liviana de los requerimientos a desarrollar en un Proceso Ágil, o un modelo
formal de entrada a un desarrollo guiado por modelos que cumpla los criterios de MDA (Model Driven
Architecture).
21
Si el Modelo de Sistemas cuenta con modelos formales, y si las herramientas de desarrollo lo permiten, se pueden
mantener alineados los elementos del desarrollo con los Requerimientos de Software, y así - por transitividad – determinar,
por ejemplo, qué componentes soportan qué Requerimientos, y éstos qué Procesos de Negocio apoyan, etc.

44
5.2 Ambientes
Como está explicado en

45
Modelos y Notación de Procesos de Negocio (BPMN), una Colaboración entre Participantes se
representa con varias Piscinas (una por cada Participante con su propio Proceso de Negocio) con
Flujos de Mensaje entre ellas. Dentro de cada Piscina es posible representar, de manera libre, unidades
organizacionales, roles y cargos como Carriles para identificar quién hace qué dentro de cada Proceso
de Negocio.
En un Proceso de Negocio descrito a muy alto nivel es posible usar una sola Piscina y usar Carriles
dentro de ésta para representar, por ejemplo, Área de Ventas, Sistema de Contabilidad, Contraloría, etc.
Una descripción más detallada de la Colaboración puede requerir el uso de Piscinas separadas para
cada Área, Rol relevante o Sistema de Información. BPMN en cuanto estándar no se pronuncia por una
u otra estrategia sino que lo deja a criterio del modelador.
Como se indicó en Principios y Políticas, la Metodología de Alineamiento establece que en los
Procesos de Negocio se identificarán explícitamente los puntos en que se requiere soporte TIC, y
también saber si ésta es provista por Sistemas de Información de la Empresa o por Participantes
externos. Esto es relevante porque puede o no conducir a Requerimientos de Software que son
responsabilidad de la Empresa.
Lo anterior conduce a que los Sistemas de Información deben ser modelados en sus propias Piscinas, y,
además, se debe distinguir entre Participantes Sistémicos Internos y Externos. Cuando se haga
referencia a un Sistema de Información se usará el término Participante Sistémico, en caso contrario se
usará el término Participante Normal. Para distinguir a los Participantes Externos o Internos,
Sistémicos o Normales, se usarán colores.
5.2.1 Ambiente Interno
Un Participante Normal Interno se muestra mediante una Piscina de color blanco22
. Típicamente
representa la Empresa en su totalidad o un área o rol relevante, por ejemplo: Marketing, Ejecutivo de
Cuentas, Contraloría Interna, entre otros. La Piscina se puede mostrar sin detalles internos (“caja
negra”) o con la descripción del Procesos y Carriles.
22
Código RGB 255, 255, 255.

46
Figura 5-2. Participante Interno "caja negra"
Puesto los Participantes Normales son el centro del modelo, normalmente estarán detallados, aunque
para efectos de simplicidad de los diagramas, en algunos casos aparecerán como “cajas negras”.
Figura 5-3. Participante Normal Interno detallado
Un Participante Sistémico Interno se representa mediante una Piscina de color gris claro23
. Típicamente
representa a la totalidad de los Sistemas de Información de la Empresa o a uno en particular, por
ejemplo: Sistema de Remuneraciones, CRM, entre otros. La Piscina se puede mostrar sin detalles
internos (“caja negra”) o con la descripción del Proceso y Carriles. Normalmente serán “cajas negras” a
no ser que se quiera representar aspectos del Proceso que son orquestados por algún sistema de
workflow especializado o ad-hoc24
.
23
Código RGB 220, 220, 220.
24
Puede ser un sistema especializado para BPM (Business Process Management) como Intalio, Bonita, Oracle BPM Suite; o
software ad-hoc que permite controlar el flujo de documentos y actividades de los usuarios.

47
Figura 5-4. Participante Sistémico Interno “caja negra”
5.2.2 Ambiente Externo
Un Participante Normal Externo se muestra mediante una Piscina de color celeste claro25
. Típicamente
representa una organización o rol con el que interactúa la Empresa, por ejemplo: Cliente, Proveedor,
Ministerio de Salud, entre otros. La Piscina se puede mostrar sin detalles internos (“caja negra”) o con
la descripción del Procesos y Carriles.
Puesto que los Participantes normales Externos no son parte de la Empresa sino que representan el
entorno con el que ésta interactúa, normalmente no estarán detallados. En algunos casos el modelador
podrá mostrar algunos detalles del Participante Normal Externo que sean relevantes para la
comprensión de los Procesos de Negocio de la Empresa.
Figura 5-5. Participante Normal Externo "caja negra"
Un Participante Sistémico Externo se representa mediante una Piscina de color celeste oscuro26
.
Típicamente representa a la totalidad de los Sistemas de Información de una organización externa o a
uno en particular, por ejemplo: Sistema de Servicio de Impuestos, Sistemas de Proveedores y Clientes,
entre otros. La Piscina se puede mostrar sin detalles internos (“caja negra”) o con detalles.
Normalmente serán “cajas negras” a no ser que se quiera representar aspectos del Proceso que son
relevantes para la compresión de los Procesos de Negocio.
25
Código RGB 220, 255, 255.
26
Código RGB 100, 255, 255.

48
Figura 5-6. Participante Sistémico Externo "caja negra"
En el caso de los Participantes Sistémicos Internos es obligatoria una Piscina exclusiva, para los
Participantes Sistémicos Externos esto es opcional, pudiendo estar como un Carril Sistémico dentro de
un Participante Normal Externo (ver Figura 5-7).
Figura 5-7. Participante Normal Externo con Carril Sistémico
5.2.3 Tareas en Piscinas y Carriles
Los elementos centrales en la descripción de los Procesos de Negocio con BPMN son las actividades.
Las cuales pueden ser Subprocesos o Tareas. Los primeros se usan para indicar que la actividad será
detallada aún más a nivel del Negocio. Las Tareas, por su parte, indican que la actividad es terminal a
nivel del Negocio, es decir, se les podrá detallar textualmente, pero no con otro diagrama BPMN.
Por lo tanto, una Tarea pueden interpretarse como el límite del Proceso de Negocio, en cuanto a que el
detalle de ésta no entra dentro de su ámbito. En este sentido, en la Metodología de Alineamiento las
Tareas son usadas para identificar los puntos donde un Proceso de Negocio requiere TIC, y el detalle de
la Tarea será parte del Modelo de los Sistemas de Información.
La definición de Ámbitos, es decir, la diferenciación de Participantes Internos y Externos, y su carácter
Sistémico o Normal, lleva a que sea necesario definir qué tipo de Tareas pueden o no ir en qué tipo de
Piscinas y Carriles. (Para una descripción de los tipos de Tareas ver 3.2.1.1).

49
La especificación de BPMN establece que como todo objeto de flujo, en una Colaboración, las Tareas
deben localizarse dentro de Piscinas. Sin embargo, la Metodología de Alineamiento establece ciertas
restricciones respecto a qué tipo de Tareas deben ir en qué tipo de Piscinas.
5.2.3.1 Tareas relacionadas con TIC
Hay tres tipos de Tareas que hacen referencia a actividades realizadas por software: Servicio, Regla de
Negocio y Script.
Figura 5-8. Tareas Tecnológicas en Piscinas Sistémicas
Estas Tareas sólo pueden aparecer en Piscinas Sistémicas Internas o Externas. También pueden
aparecer en Carriles Sistémicos.
Todo Flujo de Mensaje entrante o saliente de estas Tareas debe llegar de o dirigirse a
 otra Piscina Sistémica, o
 un Carril Sistémico en otra Piscina de un Participante Normal Externo, o
 un Carril de Rol en otra Piscina normal.
Estas restricciones permitirán diferenciar claramente en el Proceso de Negocio las Tareas
automatizadas y asociarlas a los Participantes Sistémicos.

50
5.2.3.2 Tareas con participación humana
Las Tareas Manuales son realizadas por personas sin ningún tipo de apoyo tecnológico informático.
Las Tareas Usuario representa la interacción de una persona con un Sistema de Información, por
ejemplo un usuario de un banco que accede al sitio web de éste para consultar y hacer transacciones.
Figura 5-9. Tareas humanas en Piscinas normales
Estas Tareas sólo pueden aparecer en Piscinas normales Internas o Externas. Además, las Tareas
Usuario sólo pueden aparecer en Carriles asociados a Roles.
Todo Flujo de Mensaje entrante o saliente de una Tarea Usuario debe llegar de o dirigirse a:
 una Piscina Sistémica, o
 un Carril Sistémico en otra Piscina de un Participante Normal Externo.
Estas restricciones permitirán identificar claramente en el Proceso de Negocio dónde las personas,
jugando determinados roles, interactúan con los Sistemas de Información.

51
5.2.3.3 Otras Tareas
Los demás tipos de Tarea: Abstracta, Envío de Mensaje y Recepción de Mensaje pueden o no
representar uso de TIC.
Figura 5-10. Tareas en cualquier tipo de Piscina
Las Tareas Abstractas se pueden usar para cualquier propósito del modelador. Este tipo de Tarea no
participa en ninguno de los Patrones de la Metodología de Alineamiento, por lo tanto el modelador
puede usarla en cualquier parte donde no se requiera uso de TIC.
Las Tareas de Envío o Recepción de Mensajes no están asociadas necesariamente a comunicación
tecnológica. Por ejemplo, si un Ejecutivo de comunica cara a cara con un Cliente se representa con un
Flujo de Mensaje con las respectivas Tareas de Envío y Recepción. Por otro lado, si un Sistema de
Información envía automáticamente un archivo a otro Sistema de Información también se usará la
misma notación de interacción mensajes.
Por lo tanto, estos tres tipos de Tareas se pueden usar en cualquier tipo de Piscina y Carril. En el caso
del envío y recepción de mensajes, dependiendo de dónde estén localizadas las Tareas representarán o
no el uso de TIC.
Si una Tarea de Envío (o Recepción) de Mensaje está en una Piscina o Carril Sistémico, entonces la
Tarea de Recepción (o Envío) asociada debe estar en:
 otra Piscina Sistémica, o
 un Carril Sistémico en otra Piscina de un Participante Normal Externo, o
 un Carril de Rol en una Piscina normal.
Estas restricciones permitirán identificar claramente en el Proceso de Negocio dónde las personas y
Sistemas de Información se envían mensajes unos a otros.

52
5.3 Patrones
En la sección anterior se definieron los Ambientes, es decir, las reglas sobre cómo definir los
Participantes de las Colaboraciones: Piscinas y Carriles, cuando en el Proceso de Negocio hay uso de
TIC. También se definieron restricciones respecto a qué tipo de Tareas usar para identificar el uso de
TIC y en qué lugares (Piscinas y Carriles) usarlas.
Al aplicar las reglas y restricciones anteriores se pueden presentar 15 configuraciones de uso de TIC en
Colaboraciones de Procesos de Negocio. A estas situaciones las llamamos Patrones, pues son
soluciones reutilizables para situaciones comunes en el uso de TIC.
Los 15 Patrones están divididos en 3 categorías:
 3 Patrones de Interacción: Roles Internos o Externos interactúan con Sistemas Internos o
Externos. Por ejemplo un Cliente de Banco sacando dinero de un Cajero Automático.
 9 Patrones de Mensajes: Roles o Sistemas Internos o Externos reciben o envían Mensajes
desde o hacia Sistemas Internos o Externos. Por ejemplo un Cliente recibe un correo automático
de un Banco, o un Sistema de Información envía un archivo a otro Sistema de Información.
 3 Patrones de Servicios: Sistemas Internos o Externos acceden a los Servicios de Sistemas
Internos o Externos. Por ejemplo un Sistema de Información accede a un Servicio Web provisto
por otro para obtener el pronóstico meteorológico para unas coordenadas geográficas.
Las colaboraciones entre Roles (Internos o Externos) no son parte de los Patrones pues no involucran el
uso de TIC. Queda a criterio del modelador hacer uso libre de las posibilidades que da BPMN, o usar
algún conjunto de Patrones orientados a ese tipo de interacciones.
Las Colaboraciones entre Participantes Externos (Normales y Sistémicos) no están consideradas en los
Patrones pues son situaciones que ocurren fuera del ámbito interno de la Empresa y de su entorno
directo.
Las Colaboraciones entre Sistemas de Información están incluidas en los Patrones (de Servicio y
algunos de los de Mensajes). Sin embargo, el modelador debe considerar sólo aquellas interacciones
relevantes para el Proceso de Negocio y no involucrarse en detalles tecnológicos del Modelo de los
Sistemas de Información.
La descripción de cada Patrón consta de tres partes:
1. Proceso de Negocio: describe la configuración que desbribe la aplicación de TIC usando las
reglas definidas por la Metodología de Alineamiento.
2. Requerimientos de Software: describe los Casos de Uso y Actores que se derivan de lo descrito
en el Proceso de Negocio.
3. Mapeo: muestra la trazabilidad entre los Casos de Uso y Actores, y las Tareas, Piscinas y
Carriles.
La aplicación de los Patrones genera una primera versión del Modelo de Casos de Uso. Luego éste
puede ser refinado: agregando nuevos Casos de Uso, adecuando sus nombres, uniendolos o
sepandolos, creando extensiones entre ellos, etc.. Todo esto para optimizar el modelo o para reflejar

53
aspectos técnicos no considerados en los Procesos de Negocio. Es importante mantener la trazabilidad
entre el modelo refinado y el original, para no perder el Alineamiento con los Procesos de Negocio.
5.3.1 Patrones de Interacción
Los Patrones de Interacción son tres.
1. Interacción Rol Interno-Sistema Interno (Int RI<>SI).
 Un Empleado de Banco usando una intranet.
2. Interacción Rol Interno-Sistema Externo (Int RI<>SE).
 Un Empleado municipal usando sistema del Ministerio de Desarrollo Social.
3. Interacción Rol Externo-Sistema Interno (Int RE<>SI).
 El Cliente de un banco usando una aplicación web para consultar y realizar
transacciones bancarias.
5.3.1.1 Interacción Rol Interno-Sistema Interno (Int RI < > SI)
Este Patrón representa la típica interacción entre una persona cumpliendo un rol en una Empresa y una
aplicación provista por la misma Empresa. La aplicación puede ser un sitio web, una aplicación
desktop, una aplicación móvil, etc.
5.3.1.1.1 Proceso de Negocio
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea Usuario la
que tiene comunicación vía Flujo de Mensajes con un Sistema Interno representado por una Piscina
separada.
Figura 5-11. Sistema Interno “caja negra” – Int RI <> SI

54
El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos
sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software
de orquestación de procesos (BPMS). La contraparte de la Tarea Usuario en el Sistema Interno puede
ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee modelar.
Figura 5-12. Sistema Interno detallado – Int RI <> SI
La contraparte de la Tarea Usuario en el Sistema Interno puede ser una Subproceso o una Tarea
Abstracta, dependiendo de lo que se desee modelar.
5.3.1.1.2 Requerimiento de Software
La configuración del Proceso de Negocio conduce a un Caso de Uso utilizado por el Actor
representado por el Carril en el que está la Tarea Usuario.
Figura 5-13. Requerimientos - Int RI <> SI

55
Por ejemplo, si el Proceso de Negocio describe que el Analista ingresa todos los días las horas
dedicadas a las actividades asignadas, y esto lo hace ingresando al Sistema de Imputaciones. Entonces,
habrá un Caso de Uso – Ingresar Imputación de Horas – que es utilizado por el Actor – Analista.
5.3.1.1.3 Mapeo
El Actor Rol 1 tiene una traza hacia el Carril Rol 1 donde está localizada la Tarea Usuario Interactuar
con Sistema Interno.
El Caso de Uso Interactuar con Sistema Interno tiene trazas hacia la Tarea Usuario Interactuar con
Sistema Interno y, si el Sistema Interno está detallado, hacia el Subproceso Soportar Interacción.
Figura 5-14. Mapeo Negocio-Requerimientos - Int RI <> SI

56
5.3.1.2 Interacción Rol Interno-Sistema Externo (Int RI < > SE)
Este Patrón representa una interacción entre una persona cumpliendo un rol en una Empresa y una
aplicación provista por un Sistema de Información de otra Empresa. La aplicación puede ser un sitio
web, una aplicación desktop, una aplicación móvil, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea Usuario la
que tiene comunicación vía Flujo de Mensaje con un Sistema Externo representado por una Piscina
separada.
Figura 5-15. Sistema Externo "caja negra" – Int RI <> SE
El Sistema Externo puede estar como una Piscina “caja negra” o detallada indicando aspectos
sistémicos relevantes para la comprensión del Negocio. La contraparte de la Tarea Usuario en el
Sistema Externo puede ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee
modelar. El Sistema Externo también puede estar detallado en un Carril dentro de una Piscina que
representa a la Empresa Externa.

57
Figura 5-16. Sistema Externo en Carril – Int RI <> SE
Puesto que la funcionalidad es provista por un Sistema Externo no hay Requerimientos de Software
que deban ser trabajados por el Área de Desarrollo de Software.
Puede ocurrir que la aplicación de la otra Empresa sea accedida a través de una funcionalidad provista
por un Sistema Interno. El modelador del Proceso de Negocio podría obviar este aspecto técnico y
mostrar una interacción directa entre el Rol y el Sistema Externo. Sin embargo, la Metodología de
Alineamiento indica que en este caso corresponde aplicar los Patrones Interacción Rol Interno-Sistema
Interno (Int RI < > SI) y

58
Petición de Servicio desde Sistema Interno a Sistema Externo (Serv SI > SE).
5.3.1.2.3 Mapeo
Puesto que no hay Requerimientos no aplica el Mapeo.

59
5.3.1.3 Interacción Rol Externo-Sistema Interno (Int RE < > SI)
Este Patrón representa una interacción entre una persona cumpliendo un rol en otra Empresa y una
aplicación provista por la Empresa modelada. La aplicación puede ser un sitio web, una aplicación
desktop, una aplicación móvil, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal Externo) realiza una Tarea
Usuario la que tiene comunicación vía Flujo de Mensaje con un Sistema Interno representado por una
Piscina separada.
Figura 5-17. Sistema Interno "caja negra" – Int RE <> SI
de orquestación de procesos (BPMS). La contraparte de la Tarea Usuario en el Sistema Interno puede
ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee modelar.

60
Figura 5-18. Sistema Interno detallado – Int RE <> SI
representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea Usuario.
Figura 5-19. Requerimientos - Int RE <> SI
Por ejemplo, si en un Proceso de Negocio del Servicio de Impuestos Internos describe que un
Contribuyente puede consultar las Facturas que ha recibido. Entonces, habrá un Caso de Uso –
Consultar Facturas Recibidas – que es utilizado por el Actor – Contribuyente.

61
5.3.1.3.3 Mapeo
El Actor Rol Externo tiene una traza hacia el Carril Rol Externo donde está localizada la Tarea
Usuario Interactuar con Sistema Interno.
El Caso de Uso Interactuar con Sistema Interno tiene trazas hacia la Tarea Usuario Interactuar con
Sistema Interno y, si el Sistema Interno está detallado, hacia el Subproceso Soportar Interacción.
Figura 5-20. Mapeo Negocio-Requerimientos – Int RE <> SI

62
5.3.2 Patrones de Mensajes
Los Patrones de Interacción son nueve.
1. Mensaje a Rol Interno desde Sistema Interno (Msj RI < SI)
 Asignación automática de Incidencia a Desarrollador.
2. Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)
 Correo electrónico automático desde Dirección de Aduanas a Encargado de
Importaciones.
3. Mensaje a Rol Externo desde Sistema Interno (Msj RE < SI)
 Aviso a Cliente de Banco que tiene crédito pre-aprobado.
4. Mensaje de Rol Interno hacia Sistema Interno (Msj RI > SI)
 Analista de Riesgo da el visto bueno a Solicitud de Crédito.
5. Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)
 Administrativo OTEC27
cierra Curso SENCE28
.
6. Mensaje de Rol Externo hacia Sistema Interno (Msj RE > SI)
 Contribuyente envía su Declaración de Impuestos al SII29
.
7. Mensaje de Sistema Interno hacia Sistema Interno (Msj SI>SI)
 Sistema de Registro Horario envía datos de horas trabajadas a Sistema de
Remuneraciones.
8. Mensaje de Sistema Externo hacia Sistema Interno (Msj SE > SI)
 Sistema de Registro Académico de una Universidad recibe datos de alumnos
seleccionados mediante Proceso de Selección Nacional gestionado por el Ministerio de
Educación.
9. Mensaje de Sistema Interno hacia Sistema Externo (Msj SI > SE)
 Sistema de Registro Académico de una Universidad envía al Ministerio de Educación
datos de titulados.
El envío y recepción de Mensajes se representa en los Procesos de Negocio con Tareas de Envío y
Recepción de Mensajes. Alternativamente se pueden usar Eventos de Envío y Recepción de Mensajes.
27
OTEC: Organismo Técnico de Capacitación.
28
SENCE: Servicio Nacional de Capacitación y Empleo.
29
SII: Servicio de Impuestos Internos.

63
5.3.2.1 Mensaje a Rol Interno desde Sistema Interno (Msj RI < SI)
Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en una
Empresa desde un Sistema de Información de la misma Empresa. La comunicación puede ser por
correo electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario
cuando ingresa a una aplicación, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Recepción
de Mensaje que recibe un Flujo de Mensaje desde un Sistema Interno representado por una Piscina
separada.
Figura 5-21. Sistema Interno "caja negra" – Msj RI < SI
de orquestación de procesos (BPMS).

64
Figura 5-22. Sistema Interno detallado – Msj RI < SI
La configuración del Proceso de Negocio conduce a un Caso de Uso. Sin embargo no hay Actor, pues
el receptor del Mensaje en el Carril en el que está la Tarea Recepción de Mensaje no está interactuando
con el Sistema de Información cuando éste le envía en Mensaje, con posterioridad podría ocurrir una
interacción.
El Caso de Uso refleja lo que hace el Sistema de Información, es decir, preparar y enviar el Mensaje,
por ejemplo: construir y enviar un correo electrónico, o grabar algún registro en la base de datos para
que cuando el usuario ingrese a una aplicación le aparezca un aviso.
Este Caso de Uso representa una funcionalidad que será utilizada (“incluida por”) otros Casos de Uso.
Figura 5-23. Requerimientos - Msj RI < SI
Por ejemplo, si el Proceso de Negocio describe que el Desarrollador al comienzo de su jornada verifica
las incidencias que le han sido asignadas para que las resuelva y esto lo hace ingresando a una
aplicación donde le aparece un aviso con las nuevas incidencias. Entonces, habrá un Caso de Uso –
Registrar y Comunicar Incidencias a Desarrollador.

65
5.3.2.1.3 Mapeo
El Caso de Uso Enviar Mensaje tiene trazas hacia la Tarea de Recepción de Mensaje Recibir
Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Envío de Mensaje Preparar y
Enviar Mensaje.
Figura 5-24. Mapeo Negocio-Requerimientos – Msj RI < SI

66
5.3.2.2 Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)
Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en una
Empresa desde un Sistema de Información de otra Empresa. La comunicación puede ser por correo
electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario cuando
ingresa a una aplicación, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Recepción
de Mensaje que recibe un Flujo de Mensaje desde un Sistema Externo representado por una Piscina
separada.
Figura 5-25. Sistema Externo "caja negra" - Msj RI < SE
El Sistema Externo puede estar como una Piscina “caja negra”, o detallado indicando aspectos
sistémicos relevantes para la comprensión del Negocio.

67
Figura 5-26. Sistema Externo en Carril - Msj RI < SE
5.3.2.2.3 Mapeo

68
5.3.2.3 Mensaje a Rol Externo desde Sistema Interno (Msj RE < SI)
Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en otra
Empresa desde un Sistema de Información de la Empresa modelada. La comunicación puede ser por
correo electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario
cuando ingresa a una aplicación, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Externo) realiza una Tarea de Recepción
de Mensaje que recibe un Flujo de Mensaje desde un Sistema Interno representado por una Piscina
separada.
Figura 5-27. Sistema Interno "caja negra" - Msj RE < SI

69
Figura 5-28. Sistema Interno detallado - Msj RE < SI
La configuración del Proceso de Negocio conduce a un Caso de Uso. Sin embargo no hay Actor, pues
el receptor del Mensaje en el Carril en el que está la Tarea Recepción de Mensaje no está interactuando
con el Sistema de Información cuando éste le envía en Mensaje, con posterioridad podría ocurrir una
interacción.
El Caso de Uso refleja lo que hace el Sistema de Información, es decir, preparar y enviar el Mensaje,
por ejemplo: construir y enviar un correo electrónico, o grabar algún registro en la base de datos para
que cuando el usuario ingrese a una aplicación le aparezca un aviso.
Este Caso de Uso representa una funcionalidad que será utilizada (“incluida por”) otros Casos de Uso.
Figura 5-29. Requerimientos - Msj RE < SI
Por ejemplo, si el Proceso de Negocio describe que el Cliente de un Banco recibe un aviso de crédito
pre-aprobado cuando ingresa al sitio web, y, además, recibe un correo electrónico automático.
Entonces, habrá un Caso de Uso – Comunicar Crédito Pre-Aprobado a Cliente.

70
5.3.2.3.3 Mapeo
El Caso de Uso Enviar Mensaje tiene trazas hacia la Tarea de Recepción de Mensaje Recibir
Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Envío de Mensaje Preparar y
Enviar Mensaje.
Figura 5-30. Mapeo Negocio-Requerimientos - Msj RE < SI

71
5.3.2.4 Mensaje de Rol Interno hacia Sistema Interno (Msj RI > SI)
Este Patrón representa una información, normalmente una decisión, que una persona cumpliendo un rol
en una Empresa comunica a un Sistema de Información de la misma Empresa y que provoca que el
flujo del Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la
selección de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo
electrónico que es recibido y procesado automáticamente, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Envío de
Mensaje que lanza un Flujo de Mensaje hacia un Sistema Interno representado por una Piscina
separada.
Figura 5-31. Sistema Interno "caja negra" - Msj RI > SI

72
Figura 5-32. Sistema Interno detallado - Msj RI > SI
representado por el Carril del Participante Normal en el que está la Tarea Envío de Mensaje.
Figura 5-33. Requerimientos - Msj RI > SI
Por ejemplo, si el Proceso de Negocio describe que el Analista de Riesgo luego de revisar los
antecedentes da el visto bueno a Solicitud de Crédito, y esto lo hace seleccionando una opción en una
aplicación. Entonces, habrá un Caso de Uso – Dar Visto Bueno a Solicitud de Crédito.

73
5.3.2.4.3 Mapeo
El Actor Rol 1 tiene una traza hacia el Carril Rol 1 donde está localizada la Tarea de Envío de Mensaje
Preparar y Enviar Mensaje.
El Caso de Uso Preparar y Enviar Mensaje tiene trazas hacia la Tarea de Envío de Mensaje
Preparar y Enviar Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Recepción de
Mensaje Recibir Mensaje.
Figura 5-34. Mapeo Negocio-Requerimientos - Msj RI > SI

74
5.3.2.5 Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)
en una Empresa comunica a un Sistema de Información de otra Empresa y que provoca que el flujo del
Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la selección
de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo electrónico
que es recibido y procesado automáticamente, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Envío de
Mensaje que lanza un Flujo de Mensaje hacia un Sistema Externo representado por una Piscina
separada.
Figura 5-35. Sistema Externo "caja negra" - Msj RI > SE
El Sistema Externo puede estar como una Piscina “caja negra”, o detallado indicando aspectos
sistémicos relevantes para la comprensión del Negocio.

75
Figura 5-36. Sistema Externo en Carril - Msj RI > SE
5.3.2.5.3 Mapeo

76
5.3.2.6 Mensaje de Rol Externo hacia Sistema Interno (Msj RE > SI)
en otra Empresa comunica a un Sistema de Información de la Empresa modelada y que provoca que el
flujo del Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la
selección de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo
electrónico que es recibido y procesado automáticamente, etc.
En el Proceso de Negocio un Rol (un Carril en un Participante Externo) realiza una Tarea de Envío de
Mensaje que lanza un Flujo de Mensaje hacia un Sistema Interno representado por una Piscina
separada.
Figura 5-37. Sistema Interno "caja negra" - Msj RE > SI

77
Figura 5-38. Sistema Interno detallado - Msj RE > SI
representado por el Carril del Participante Externo en el que está la Tarea Envío de Mensaje.
Figura 5-39. Requerimientos - Msj RE > SI
Por ejemplo, si el Proceso de Negocio del SII describe que el Contribuyente luego de preparar su
declaración de impuestos la envía para su revisión, y esto lo hace seleccionando una opción en una
aplicación. Entonces, habrá un Caso de Uso – Enviar Declaración de Impuestos para Revisión.

78
5.3.2.6.3 Mapeo
El Actor Rol Externo tiene una traza hacia el Carril Rol Externo donde está localizada la Tarea
Usuario Preparar y Enviar Mensaje.
El Caso de Uso Preparar y Enviar Mensaje tiene trazas hacia la Tarea de Envío de Mensaje
Preparar y Enviar Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Recepción de
Mensaje Recibir Mensaje.
Figura 5-40. Mapeo Negocio-Requerimientos - Msj RE > SI

79
5.3.2.7 Mensaje de Sistema Interno hacia Sistema Interno (Msj SI>SI)
Este Patrón representa una comunicación asíncrona que envía un Sistema de Información de una
Empresa a otro Sistema de Información de la misma Empresa. La comunicación puede ser mediante el
envío de archivos vía ftp, usando casillas electrónicas, accediendo a una base de datos, etc.
En el Proceso de Negocio un Sistema Interno lanza un Flujo de Mensaje hacia otro Sistema Interno,
ambos representado por Piscinas separadas.
Figura 5-41. Sistemas Internos "cajas negras" - Msj SI > SI
Los Sistemas Internos puede estar como Piscinas “caja negra”, o detallados indicando aspectos
sistémicos relevantes para la comprensión del Negocio y/o porque están implementados con un
software de orquestación de procesos (BPMS). En caso de estar detallados habrá en uno la Tarea de
Envío de Mensaje y en el otro la Tarea de Recepción de Mensaje.

80
Figura 5-42. Sistemas Internos detallados - Msj SI > SI
La configuración del Proceso de Negocio conduce a dos Casos de Uso, uno por cada Sistema Interno
representados por las Piscinas en las que están la Tarea de Envío y Recepción de Mensaje.
Figura 5-43. Requerimientos Sistema 1- Msj SI > SI
Desde el punto de vista del Sistema 1 hay un Actor – el Sistema 2 que requiere recibir un Mensaje. Por
lo tanto habrá un Caso de Uso en el Sistema 1 – Recibir Mensaje que se encargará de satisfacer esa
necesidad del Sistema 2, es decir, enviarle un Mensaje.
Figura 5-44. Requerimientos Sistema 2 - Msj SI > SI

Alineamiento de Procesos y Sistemas usando BPMN y UML

Alineamiento de Procesos y Sistemas usando BPMN y UML

Recomendados

Recomendados

Más contenido relacionado

Similar a Alineamiento de Procesos y Sistemas usando BPMN y UML

Similar a Alineamiento de Procesos y Sistemas usando BPMN y UML (20)

Último

Último (10)

Alineamiento de Procesos y Sistemas usando BPMN y UML