Comparaison de deux approches de structuration d'un diagramme d'activité (inspiré par « Les écureuils »)
Dans Nous avons modélisé les processus du domaine « féérique » — des passages sur un écureuil tirés de « La légende du roi Saltan, de son fils, le grand et puissant héros le prince Guidon Saltanovitch et de la belle princesse Cygne » par A.S. Pouchkine. Nous avons commencé par un diagramme d'activité, convenant de structurer le champ du diagramme à l'aide de « voies de nage » – Swim lanes. Le nom de la voie correspond au type d'éléments de diagramme présents dans cette voie : « Artefacts d'entrée et de sortie », « Étapes du processus », « Participants » et « Règles d'affaires ». Cette approche se distingue de la norme, où les voies sont désignées par les noms des participants au processus, attribuant ainsi des zones de responsabilité définies dans le processus.
Dans cet exemple, j'utilise l'environnement Enterprise Architect de l'entreprise australienne [1].
Pour plus de détails sur les approches appliquées à la modélisation, consulter [2].
Pour la spécification complète de l'UML, voir [3].
Je vais répéter la version du diagramme de l'article précédent (Figure 1) et montrer le diagramme redessiné avec des voies « standard » (Figure 2), et j'essaierai d'indiquer les avantages et les inconvénients, peut-être aussi un peu subjectivement.
Figure 1. Diagramme d'activité – vue générale du processus
Figure 2. Diagramme d'activité – structuration standard du diagramme
- Il faut reconnaître que le nombre de flèches est légèrement inférieur sur le deuxième diagramme.
- Mais sur le deuxième diagramme, les objets sont « étalés » sur tout le champ du diagramme, ce qui, à mon sens, n'est pas très pratique.
- C'est la même histoire avec les annotations — les règles. Et pour insérer la règle sur la nomination du diacre, il a fallu déplacer tous les éléments du diagramme vers le bas à un moment donné.
- Il a fallu cloner l'étape « réception / transfert… » pour montrer que plusieurs participants étaient présents à cette étape.
- Dans la deuxième variante, j'ai dû renoncer à une branche et à une fusion du processus, il était tout simplement impossible de les agencer « joliment » ! Idéalement, un commentaire aurait dû être attaché — la règle.
Sur le plan du goût et de la couleur, bien sûr, il n'y a pas de camarades, mais je trouve que la première variante est également plus pratique pour collecter des données sur le processus.
Mais je ne vais pas mentir — parfois, il est préférable de dessiner les deux options pour mieux comprendre le processus.
Liste des sources
- Site de Sparx Systems. [Ressources électroniques] Accès : Internet :
- Zolotukhina E.B., Vishnya A.S., Kraskinova S.A. Modélisation des processus métiers. — M.: KURC, NIC INFRA-M, EBS Znanium.com. — 2017.
- Spécification UML Unifiée OMG (OMG UML). Version 2.5.1. [Ressources électroniques] Accès : Internet :
Source : habr.com
