Comparación de dous enfoques para estruturar un diagrama de actividades (baseado en "Esquíos")
В modelamos os procesos dunha área temática de "conto de fadas": liñas sobre un esquío de "O conto do tsar Saltan, o seu fillo, o glorioso e poderoso heroe Príncipe Gvidon Saltanovich e a fermosa princesa cisne" de A.S. Pushkin. E comezamos co diagrama de actividade, acordando estruturar o campo do diagrama mediante “carrís de natación”. O nome da pista corresponde ao tipo de elementos do diagrama que están presentes nesa pista: artefactos de entrada e saída, pasos do proceso, participantes e regras de negocio. Este enfoque difire do estándar, cando as pistas son designadas polos nomes dos participantes no proceso, asignándolles así certas áreas de responsabilidade no proceso.
Neste exemplo estou a usar o framework Enterprise Architect dunha empresa australiana [1].
Para máis detalles sobre os enfoques de modelaxe aplicados, consulte [2].
Para a especificación completa de UML, consulte [3].
Repetirei a versión do diagrama do artigo anterior (Figura 1) e mostrarei un diagrama redeseñado con pistas "estándar" (Figura 2), tentarei esbozar os pros e os contras, quizais un pouco subxectivamente.
Figura 1. Diagrama de actividade - vista xeral do proceso
Figura 2. Diagrama de actividade - estruturación do diagrama estándar
- Hai que admitir que o número de frechas é lixeiramente menor no 2o diagrama.
- Pero no segundo diagrama, os obxectos están "untados" en todo o campo do diagrama, o que, para o meu gusto, non é moi conveniente.
- A mesma historia con notas - regras. E para inserir a regra sobre o nomeamento dun diácono, todos os elementos do diagrama tiveron que ser movidos para abaixo nalgún momento.
- Tiven que clonar o paso "recibir/transmitir..." para mostrar que varios participantes están presentes neste paso.
- Na segunda opción, tiven que renunciar a unha ramificación e unha fusión do proceso, ben, era absolutamente imposible organizalas "ben"! Afortunadamente, entón sería necesario publicar un comentario: a regra.
Por suposto, non hai compañeiros de gusto e cor, pero a primeira opción paréceme tamén máis conveniente para recoller datos sobre o proceso.
Pero non mentirei - ás veces é mellor debuxar ambas opcións para comprender o proceso.
Lista de fontes
- 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.: CURSO, SIC INFRA-M, EBS Znanium.com. - 2017.
- Especificación da linguaxe de modelado unificado OMG (OMG UML). Versión 2.5.1. [Recurso electrónico] Modo de acceso: Internet:
Fonte: www.habr.com