Comparaison de deux approches pour structurer un diagramme d'activité (basé sur les « Écureuils »)
В nous avons modélisé les processus d'un domaine de « conte de fées » - des lignes sur un écureuil du « Conte du tsar Saltan, de son fils, du glorieux et puissant héros le prince Gvidon Saltanovich et de la belle princesse cygne » de A.S. Pouchkine. Et nous avons commencé avec le diagramme d'activité, en nous mettant d'accord sur la structuration du champ du diagramme en utilisant des « couloirs de nage ». Le nom de la piste correspond au type d'éléments de diagramme présents dans cette piste : artefacts d'entrée et de sortie, étapes de processus, participants et règles métier. Cette approche diffère de l'approche standard, lorsque les pistes sont désignées par les noms des participants au processus, leur attribuant ainsi certains domaines de responsabilité dans le processus.
Dans cet exemple, j'utilise l'environnement Enterprise Architect d'une société australienne. [1].
Pour plus de détails sur les approches de modélisation appliquées, voir [2].
Pour la spécification UML complète, voir [3].
Je vais répéter la version du schéma de l'article précédent (Figure 1) et montrer un schéma redessiné avec des voies « standards » (Figure 2), je vais essayer d'exposer les avantages et les inconvénients, peut-être un peu subjectivement.
Figure 1. Diagramme d'activité - vue générale du processus
Figure 2. Diagramme d'activités - structuration du diagramme standard
- Il faut admettre que le nombre de flèches est légèrement inférieur dans le 2ème schéma.
- Mais dans le 2ème schéma, les objets sont « étalés » sur tout le champ du schéma, ce qui, à mon goût, n'est pas très pratique.
- La même histoire avec des notes - des règles. Et pour insérer la règle sur la nomination d'un diacre, tous les éléments du diagramme ont dû être déplacés vers le bas à un moment donné.
- J'ai dû cloner l'étape « recevoir/transmettre… » pour montrer que plusieurs participants sont présents à cette étape.
- Dans la deuxième option, j'ai dû renoncer à un branchement et à une fusion du processus, eh bien, il était absolument impossible de les organiser « joliment » ! Heureusement, il faudrait alors poster un commentaire - la règle.
Bien sûr, il n'y a pas de camarades en termes de goût et de couleur, mais la première option me semble également plus pratique pour collecter des données sur le processus.
Mais je ne mentirai pas : il est parfois préférable de dessiner les deux options afin de comprendre le processus.
Liste des sources
- Site Web de Sparx Systems. [Ressource électronique] Mode d'accès : Internet :
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modélisation des processus métiers. - M. : KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Spécification du langage de modélisation unifié OMG (OMG UML). Édition 2.5.1. [Ressource électronique] Mode d'accès : Internet :
Source: habr.com