Unidad 3. UML y BPD en El Modelado Del Negocio

Modelado de negocios
Unidad 3. UML y BPMN en el modelado del negocio
Ingeniería en Desarrollo de Software

3er semestre
Programa de la asignatura:
Unidad 3. UML y BPMN en el Modelado del negocio
Ciudad de México, Noviembre, 2020
Clave:
Ingeniería TSU
15142314/ 16142314
Universidad Abierta y a Distancia de México
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1

Índice
Unidad 3. UML y BPMN en el modelado del negocio ........................................................... 3

Presentación de la Unidad ..................................................................................................... 3
Propósitos ............................................................................................................................... 3
Competencia específica ......................................................................................................... 3
Recomendaciones específicas de la unidad ......................................................................... 4
3.1. Diagramas de procesos de negocio (BPD) .................................................................... 4
3.1.1. Elementos de un BPD .................................................................................................. 4
3.1.2. Procesos de alto nivel .................................................................................................. 8
3.2. Modelo de casos de uso del negocio.............................................................................. 8
3.2.1. Objetivo de los casos de uso en el modelado del negocio ......................................... 8
3.2.2. Elementos del modelo de casos de uso del negocio .................................................. 9
3.2.3. Relaciones de inclusión, extensión y generalización .............................................. 102
3.3. Definición de los actores del negocio ........................................................................... 14
3.3.1. Conceptos .................................................................................................................. 14
3.3.2. Tipos de actores ......................................................................................................... 14
Cierre de la Unidad............................................................................................................... 15
Para saber más .................................................................................................................... 15
Fuentes de consulta ............................................................................................................. 15

Presentación de la Unidad
En la unidad anterior viste los temas para comprender el BPMN, los cuales te han servido
para seguir adentrándote en el modelado de negocios.
En esta unidad aprenderás el modelado de procesos, así como el uso y elaboración de

casos de uso. Estos temas te serán de ayuda para crear modelos más complejos, para
que cierres la materia en la siguiente unidad con los temas faltantes para un modelado
completo.
Propósitos
Al término de la unidad lograrás:

• Definir procesos de negocio.
• Distinguir los artefactos que se utilizan para los
diagramas del proceso de negocio.
• Distinguir los elementos y uso de los casos de
uso del negocio.
• Definir los actores del negocio.
• Distinguir los elementos para modelar actores.
Competencia específica
• Construir diagramas para representar las reglas

del negocio que se está modelando, a través de la
utilización de software especializado en la
notación de UML y BPMN.

Recomendaciones específicas de la unidad
Es muy importante que realices todas las actividades planteadas para que logres
comprender los temas vistos. Asimismo, realiza los ejemplos de diagramas para que te
familiarices con los componentes gráficos. Para esto puedes utilizar el programa Visio de
Microsoft.
3.1. Diagramas de procesos de negocio (BPD)
En las empresas u organizaciones existentes hoy, la cantidad de personas que participan

es inmensa, y junto con ello se encuentra la diversidad cultural, cognitiva, de género,
entre otros. Las relaciones que se entrelazan no sólo en las unidades funcionales, sino
entre las mismas personas, llevarán a formar una red de interacción con una alta
complejidad. El departamento de contabilidad interactúa con el departamento de
desarrollo de software al asignarles presupuesto o depreciar el equipo de cómputo que
usan a diario. En el caso contrario, el departamento de desarrollo de software interactúa
con el departamento de mantenimiento para proveerlos de sistemas de información que
les ayude a llevar control de su trabajo y el departamento de mantenimiento interactúa
con el departamento de contabilidad al programar revisiones de sus equipos de aire
acondicionado. Este breve relato te da a entender, entre líneas, que los expertos de los
distintos departamentos, aunque lleven relaciones a diario, nada tienen que ver con el
trabajo del otro.
Ellos no deben entender el proceso interno de tal o cual departamento, incluso

perteneciendo a una misma organización sólo se observa lo general, dejando lo particular
de lado, esto no quiere decir que esté mal hecho. Es por esto que un diagrama de
procesos del negocio (BPD por sus siglas en inglés) se utiliza para modelar gráficamente
las operaciones de los procesos del negocio, de forma que los usuarios que no tengan
instrucción formal en el proceso (como ya se explicó en párrafos anteriores) puedan leer y
comprender hasta los procesos más complejos.
3.1.1. Elementos de un BPD
Un BPD se estructura a partir de un grupo de elementos gráficos base, que son:

• Objetos de flujo
• Objetos de conexión
• Carriles
• Artefactos
En el desarrollo de la unidad actual se te ha insistido mucho en que el resultado de

modelar procesos debe ser un producto fácil de manejar/entender, pero al mismo tiempo,
que abstraiga la complejidad inherente de la consecución de cualquier proceso, grande o
pequeño. Entonces, los elementos que comprenden un BPD están limitados a un número
pequeño, de esta manera, quienes tengan la responsabilidad de modelar el proceso del
negocio no tendrán que recordar un gran número de elementos o variables y, así al ser
compacto el número de elementos de entrada, la salida será igual, aunque la combinación
de ellos es suficiente para modelar cualquier proceso de cualquier tamaño.
Enseguida se describen cada uno de los elementos gráficos de un BPD:
Objetos de flujo
BPD tiene tres elementos centrales que comprenden los objetos de flujo:
Evento: Su representación es a través de un círculo y quiere decir “algo que pasa”

durante la consecución de un proceso de negocio, afectan al flujo del proceso y tienen un
evento disparador y un resultado; causa y efecto. Este tipo de objetos de flujo acepta tres
estados válidos con su respectiva representación.
Figura 3.1. Eventos del objeto de flujo
Actividad: Su representación es a través de un rectángulo con las esquinas

redondeadas, y en general describe el trabajo que se hace; puede ser una sola actividad
(básica) o conformarse de un conjunto de actividades básicas (compuesta). Este tipo de
objetos de flujo acepta dos estados válidos con su respectiva representación.

Figura 3.2. Representación de actividad
Decisión: su representación es familiar para las personas acostumbradas a crear

diagramas de flujo, pues es un rombo y tiene la misma funcionalidad, decisión de la
divergencia o convergencia del flujo de la información. Puede crear nuevos caminos o
hacer que se fundan a través del resultado de la evaluación lógica (lógica booleana con
verdadero o falso) de sus enunciados.
Figura 3.3. Representación de decisión
Objetos de conexión
Para poder hacer la descripción del flujo de la información se hace uso de estos
elementos que describen el sentido, desde dónde y hacia dónde, fluirá. Los tres
conectores que hacen esta función son:
• Flujo de secuencia, se representa con una línea lisa y con una terminación en la
punta de flecha igualmente lisa (rellena), y denota la secuencia en que se ejecutan
las tareas del proceso.
• Flujo de mensaje, se representa con una línea entrecortada (discontinua) y con
una terminación en la punta de flecha sin relleno (sólo el contorno de la punta de
flecha); su uso es para denotar el flujo de mensajes entre dos actores (pero no
limitado) del o de los procesos. Se usa igual para unidades funcionales del
negocio separadas.
• Asociación, se representa por una línea punteada (formada por puntos) sin
terminación en punta de flecha; su uso es para asociar textos, datos, entre otros
artefactos, con los objetos de flujo, además de mostrar las entradas/salidas de las
actividades.
Figura 3.4. Representación de asociación
A simple vista puede pensarse que los elementos son insuficientes para poder describir
procesos de negocio, pero debe recordarse que la experiencia del diseñador es lo que
dará la correcta combinación de elementos para describir el proceso que se necesite.
Carriles
Por definición, los carriles usados en la metodología de modelado de procesos se han
utilizado para hacer la descripción separada de distintas acciones de varios roles.
Proponen gráficamente una idea clara de los límites de las responsabilidades y, sobre
todo, la secuencia de ellas. BPD no es ajena a esta representación ni al significado de
ella, de tal modo que hace uso de igual manera. Los tipos de carriles que BPD soporta
son dos:
• Pool: actúa como delimitador (contenedor) gráfico de un actor o a un proceso
único, diferencia las distintas actividades únicas del actor o de la unidad funcional
con el de otros pools.
• Lane: es un pool que conforma otros pools. Es decir, es una partición; y extiende
la longitud y el alcance del pool padre. Se usa para organizar y categorizar
actividades. Son subdivisiones del pool. Representan roles, actores o participantes
de la organización.

Figura 3.5. Representación de carriles
3.1.2. Procesos de alto nivel
Los procesos de alto nivel son aquellos vistos de manera resumida o corta. Todos los
diagramas, en su fase de inicio, comienzan con este nivel, porque es en donde se van
identificando de manera general los posibles componentes que deberá contener el
modelo.
Cuando se comienza a realizar la especificación de los diagramas, es decir, que se realiza

el modelado de los pequeños detalles y componentes, suele llamarse procesos de bajo
nivel o diagramas extendidos.
3.2. Modelo de casos de uso del negocio
Según Gibert (2005), “los casos de uso permiten expresar gráficamente las relaciones
entre los diferentes usos del sistema y sus participantes o actores. El resultado es un
conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los
analistas del proyecto”.
3.2.1. Objetivo de los casos de uso en el modelado del negocio
En general, los casos de uso son de ayuda para comprender la manera en que los
actores interactúan con un sistema, definiendo claramente los pasos a seguir y opciones
que debe proporcionarle al actor el sistema que se está controlando, definen qué se hace
(no cómo se hace)
De tal manera que el caso de uso muestre lo que un actor requiere de un sistema y los
resultados que dicho sistema deba proporcionarle para satisfacer sus necesidades de
información y así lograr cumplir los objetivos que se deban conseguir para una correcta
función de la organización.
3.2.2. Elementos del modelo de casos de uso del negocio
Un caso de uso es una representación gráfica entre los actores y el sistema, en este caso,
la relación con la empresa. Por tanto, los casos de uso en el ámbito de los negocios son
de ayuda para la identificación de las funciones que realizan las personas en la
organización.
Es importante resaltar el hecho de que un caso de uso puede ser muy pequeño o
extenderse mucho, todo depende de la cantidad de funciones que deba realizar cada
usuario. En la tabla 3.1 se muestran los artefactos básicos que se requieren para la
construcción de un diagrama de casos de uso y su descripción.
Tabla 3.1. Artefactos básicos de los casos de uso

Forma de uso:
Imagina que tienes la lista de las actividades que hace cada rol, tomando el ejemplo que
se ha trabajado desde la unidad 1.
• Solicitante de venta (cliente):
o Realiza una petición
o Envía petición
o Aprueba pedido
• Responsable de ventas:
o Decide
o Discrimina
o Encamina
o Aprueba o rechaza
o Procesa
• Operario:
o Entrega
Los diagramas de caso de uso que se representan en las actividades que realiza el cliente
a nivel macro se podrían englobar en realizar la compra de un producto, donde el cliente
da información y también es quien la recibe del negocio por internet, tal como se ve en la
figura 3.6.
Figura 3.6. Caso de uso nivel macro
3.2.3. Relaciones de inclusión, extensión y generalización
Para entrar en detalle de las actividades se deben realizar diferentes tipos de relaciones.
UML cuenta con: inclusión, extensión y generalización, las cuales se muestran en la
siguiente tabla.

Tabla 3.2. Relaciones de los casos de uso
Atendiendo a las definiciones mencionadas en la tabla 3.2., el caso de uso puede

contener otros casos de uso que tienen la funcionalidad como parte integrante suya, es
decir, que se pueden crear subdivisiones del caso de uso general que en conjunto
describan el caso de uso global. Por ejemplo, para la compra de un producto se pueden
crear casos de uso dependientes de la compra, y que si se une todo se muestra esa
acción. En la figura 3.7 se puede descomponer la compra de un producto en las
siguientes actividades:
• Analizar productos
• Elegir productos
• Solicitar productos
• Enviar los datos de compra
• Analizar los cargos del pedido
• Enviar los datos de pago y entrega
• Aprobar los cargos del pedido

Figura 3.7. Caso de uso con inclusión
Por su parte, la extensión indica actividades similares a la actividad global, pero de

manera especializada, es decir, este tipo de relación es útil cuando se pretende mostrar
diferentes opciones de la misma actividad. Para el ejemplo de la compra de un producto,
se está suponiendo que se venden camisas, pantalones y zapatos, por lo que se coloca a
manera de extensión estas opciones de compra, tal como se muestra en la siguiente
figura 3.8.
Figura 3.8. Caso de uso con extensión
En otro ejemplo, la relación de generalización para los casos de uso es utilizada para
mostrar que un caso de uso puede tener relación con otro que, a su vez, podría llegar a
sustituirlo sin mayor problema. Para este ejemplo se muestran dos casos de uso con
relación de generalización a la compra de un producto, las cuales son, tal como se
muestra en la figura 3.9., la compra de un producto nuevo y la compra de un producto
usado, las cuales, si se analiza realmente, se podría sustituir sin ningún problema con la

compra de un producto, porque la acción de realizar la compra es la misma, sólo

cambiaría el tipo de producto que se adquiera, pero las acciones serían las mismas.
Figura 3.9. Caso de uso con generalización
Por último, se muestra el mismo caso de uso, pero con una visión micro, es decir, a
detalle, donde se muestran todas las relaciones, tanto de inclusión, extensión y
generalización, tal como se muestra en la figura 3.10.
Figura 3.10. Caso de uso a nivel micro

3.3. Definición de los actores del negocio
Básicamente, un actor es lo que se comunica con el sistema o negocio; no siempre son

usuarios, porque los actores pueden representar diferentes roles, dependiendo del caso
de uso que se esté mostrando. Para lograr determinar los actores es más fácil pensar en
los roles existentes, no en las personas ni en los puestos (pues pueden existir varios
puestos que realizan básicamente las mismas acciones y sólo se modelaría un rol).
3.3.1. Conceptos
Por lo general, los actores en los casos de uso se utilizan para:

• Iniciar un caso de uso: un caso de uso debe ser inicializado por un actor, porque
debe existir alguien o algo que provoque el inicio de actividades.
• Terminar un caso de uso: un caso de uso al final debe proveer información, y es
el actor con quien está interactuando el que debe recibirla, por tanto, es quien
debe realizar la finalización.
• Solicitar información: es el actor con quien está interactuando el caso de uso, y
por lo tanto es el actor quien provee de información al caso de uso para esperar su
respuesta.
• Modificar la información: igual que el anterior.
Es muy importante identificar a los actores de un caso de uso para así estar al tanto de
quién está relacionado con cada actividad que se deba realizar y saber quién debe
proporcionar la información necesaria para que el caso de uso se efectué de manera
correcta, así como identificar al receptor de la información con que se retroalimenta el
mismo caso de uso.
3.3.2. Tipos de actores
Básicamente se tienen dos tipos de actores:

• Primarios: son aquellos actores que tienen una interacción directa con el sistema
o negocio.
• Secundarios: son aquellos actores que sirven de ayuda a los actores principales
para que puedan realizar sus actividades.
Para dejar en claro los tipos de actores, piensa en el ejemplo del negocio por internet,
donde se tiene que el cliente compra un producto, y se tiene también el rol del operario,
que sólo se encarga de entregar el producto al cliente. En este caso el operario es un
actor secundario, debido a que está sirviendo al cliente a completar su compra, pero el
operario en sí mismo no tiene interacción con el negocio más allá de llevar productos (que
serían información de respuesta).
Cierre de la unidad
Has concluido la tercera unidad del curso. A lo largo de ésta has repasado la unidad
anterior con los temas de procesos de negocio, los cuales se retomaron para remarcarse.
Además, a lo largo de esta unidad has visto lo que son los casos de uso, su definición,
beneficios y objetivos, así como los componentes de este tipo de diagramas y sus
asociaciones.
Es aconsejable que revises nuevamente la unidad en caso de que los temas que se
acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, ya
estás preparado para seguir con la unidad cuatro, en donde continuarás con la revisión
del modelado conceptual, con el fin de modelar recursos, metas, interacciones y
comunicaciones dentro de las organizaciones. Todo ello con el fin de obtener el
conocimiento necesario para comenzar a realizar modelos de negocios complejos al final
de la asignatura Modelado de negocios.
Para saber más
Consulta la página oficial de UML, donde podrás encontrar manuales de referencia sobre
este tema.
• Unified Modeling Language™ (UML®). Recuperado de
http://www.omg.org/spec/UML/
Fuentes de consulta
• Fowler, M. y Scott, K. (1999). UML Gota a Gota. México: Addison Wesley

Longman.
• Gibert, M. y Peña, A. (2005). Ingeniería del software en entornos de SL.

Barcelona: Fundación per a la Universitat Oberta de Catalunya.
• Schmuller, J. (2001). Aprendiendo UML en 24 horas. México: Prentice Hall.

Unidad 3. UML y BPD en El Modelado Del Negocio

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 3. UML y BPD en El Modelado Del Negocio

Cargado por

Copyright:

Formatos disponibles

Modelado de negocios

Unidad 3. UML y BPMN en el modelado del negocio

Ingeniería en Desarrollo de Software

Unidad 3. UML y BPMN en el Modelado del negocio

Ciudad de México, Noviembre, 2020

Universidad Abierta y a Distancia de México

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1

Unidad 3. UML y BPMN en el modelado del negocio ........................................................... 3

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 2

Unidad 3. UML y BPMN en el modelado del negocio

En esta unidad aprenderás el modelado de procesos, así como el uso y elaboración de

Al término de la unidad lograrás:

• Construir diagramas para representar las reglas

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 3

Recomendaciones específicas de la unidad

3.1. Diagramas de procesos de negocio (BPD)

En las empresas u organizaciones existentes hoy, la cantidad de personas que participan

Ellos no deben entender el proceso interno de tal o cual departamento, incluso

3.1.1. Elementos de un BPD

Un BPD se estructura a partir de un grupo de elementos gráficos base, que son:

En el desarrollo de la unidad actual se te ha insistido mucho en que el resultado de

Enseguida se describen cada uno de los elementos gráficos de un BPD:

Evento: Su representación es a través de un círculo y quiere decir “algo que pasa”

Figura 3.1. Eventos del objeto de flujo

Actividad: Su representación es a través de un rectángulo con las esquinas

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 5

Figura 3.2. Representación de actividad

Decisión: su representación es familiar para las personas acostumbradas a crear

Figura 3.3. Representación de decisión

Figura 3.4. Representación de asociación

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 7

Figura 3.5. Representación de carriles

3.1.2. Procesos de alto nivel

Cuando se comienza a realizar la especificación de los diagramas, es decir, que se realiza

3.2. Modelo de casos de uso del negocio

3.2.1. Objetivo de los casos de uso en el modelado del negocio

3.2.2. Elementos del modelo de casos de uso del negocio

Tabla 3.1. Artefactos básicos de los casos de uso

Figura 3.6. Caso de uso nivel macro

3.2.3. Relaciones de inclusión, extensión y generalización

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 10

Tabla 3.2. Relaciones de los casos de uso

Atendiendo a las definiciones mencionadas en la tabla 3.2., el caso de uso puede

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 11

Figura 3.7. Caso de uso con inclusión

Por su parte, la extensión indica actividades similares a la actividad global, pero de

Figura 3.8. Caso de uso con extensión

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 12

compra de un producto, porque la acción de realizar la compra es la misma, sólo

Figura 3.9. Caso de uso con generalización

Figura 3.10. Caso de uso a nivel micro

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 13

3.3. Definición de los actores del negocio

Básicamente, un actor es lo que se comunica con el sistema o negocio; no siempre son

Por lo general, los actores en los casos de uso se utilizan para:

3.3.2. Tipos de actores

Básicamente se tienen dos tipos de actores:

Para saber más

• Fowler, M. y Scott, K. (1999). UML Gota a Gota. México: Addison Wesley

• Gibert, M. y Peña, A. (2005). Ingeniería del software en entornos de SL.

• Schmuller, J. (2001). Aprendiendo UML en 24 horas. México: Prentice Hall.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 15

También podría gustarte