Comparación de dos enfoques para estructurar un diagrama de actividades (basado en "Ardillas")
В Modelamos los procesos de un área temática de "cuento de hadas": líneas sobre una ardilla de "El cuento del zar Saltan, su hijo, el glorioso y poderoso héroe, el príncipe Gvidon Saltanovich y la bella princesa cisne" de A. S. Pushkin. Y comenzamos con el diagrama de Actividades, acordando estructurar el campo del diagrama mediante “carriles de nado”. El nombre de la pista corresponde al tipo de elementos del diagrama que están presentes en esa pista: artefactos de entrada y salida, pasos del proceso, participantes y reglas comerciales. Este enfoque difiere del estándar, cuando las pistas se designan con los nombres de los participantes del proceso, asignándoles así ciertas áreas de responsabilidad en el proceso.
En este ejemplo, estoy usando el entorno Enterprise Architect de una empresa australiana. [1].
Para obtener más detalles sobre los enfoques de modelado aplicados, consulte [2].
Para obtener la especificación UML completa, consulte [3].
Repetiré la versión del diagrama del artículo anterior (Figura 1) y mostraré un diagrama rediseñado con pistas "estándar" (Figura 2), intentaré delinear los pros y los contras, quizás un poco subjetivamente.
Figura 1. Diagrama de actividades - vista general del proceso
Figura 2. Diagrama de actividades: estructuración del diagrama estándar
- Hay que admitir que el número de flechas es ligeramente menor en el segundo diagrama.
- Pero en el segundo diagrama, los objetos están "manchados" en todo el campo del diagrama, lo que, para mi gusto, no es muy conveniente.
- La misma historia con notas: reglas. Y para insertar la regla sobre el nombramiento de un diácono, todos los elementos del diagrama tuvieron que desplazarse hacia abajo en algún momento.
- Tuve que clonar el paso “recibir/transmitir…” para mostrar que varios participantes están presentes en este paso.
- En la segunda opción, tuve que renunciar a una bifurcación y una fusión del proceso, bueno, ¡era absolutamente imposible organizarlas “bien”! Afortunadamente, entonces sería necesario publicar un comentario: la regla.
Por supuesto, no hay compañeros en gusto y color, pero la primera opción me parece también más conveniente para recopilar datos sobre el proceso.
Pero no mentiré: a veces es mejor considerar ambas opciones para comprender el proceso.
Lista de fuentes
- Sitio web de Sparx Systems. [Recurso electrónico] Modo de acceso: Internet:
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelado de procesos de negocio. - M.: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Especificación del lenguaje de modelado unificado OMG (OMG UML). Versión 2.5.1. [Recurso electrónico] Modo de acceso: Internet:
Fuente: habr.com