«Un jour dans la vie d'un écureuil» ou de la modélisation des processus à la conception d'un système automatisé de gestion des biens matériels «Écureuil-1.0» (Partie 1)
Quel rapport avec «l'écureuil»?
Je vais tout de suite expliquer quel est le rapport avec «l'écureuil». En tombant sur des projets amusants sur Internet pour étudier UML en s'appuyant sur un domaine thématique emprunté à des contes (par exemple, [1]), j'ai également décidé de préparer un exemple similaire pour mes étudiants, afin qu'ils puissent étudier au départ trois types de diagrammes : Diagramme d'activité, Diagramme de cas d'utilisation et Diagramme de classe. Je ne traduis pas les noms des diagrammes en russe pour éviter des débats sur les «difficultés de traduction». J'expliquerai un peu plus tard à quoi sert quoi. Dans cet exemple, j'utilise l'environnement Enterprise Architect d'une entreprise australienne [2] – un bon outil à un prix raisonnable. Et dans le cadre des cours, j'utilise [3], un bon outil gratuit de conception orientée objet, qui respecte les normes UML2.0 et BPMN, sans excès dans les capacités graphiques, mais tout à fait suffisant pour apprendre les bases du langage.
Nous avons l'intention d'automatiser l'activité de gestion des biens matériels, qui survient dans ces processus.
…
Une île dans la mer, (E1, E2)
Une ville se dresse sur l'île (E3, E1)
Avec des églises dorées, (E4)
Avec des TEREMes et des jardins; (E5, E6)
Un sapin pousse devant le palais, (E7, E8)
Et sous lui une maison en cristal; (E9)
Un écureuil y vit en captivité, (A1)
Et quelle fantaisie ! (A1)
L'écureuil chante des chansons, (P1, A1)
Et grignote des noix, (P2)
Mais les noix ne sont pas ordinaires, (C1)
Tout en coques dorées, (C2)
Les noyaux sont des émeraudes pures; (C3)
Les serviteurs gardent l'écureuil, (P3, A2)
Ils lui servent de domestiques variés (P4)
Et un diacre a été assigné (A3)
Un compte strict des noix à tenir; (P5, C1)
L'armée lui rend hommage; (P6, A4)
On fond des pièces à partir des coques, (P7, C2, C4)
Et on les fait circuler à travers le monde; (P8)
Les filles versent des émeraudes (P9, A5, C3)
Dans les entrepôts, sous la dalles; (E10, E11)
…
(A.S. Pouchkine "Conte du roi Saltan, de son fils glorieux et puissant, le héros prince Guidon Salтанovitch et de la belle princesse Cygne", — 10 ans entre l'idée et la publication, je vous le rappelle !
Un peu sur les codes qui sont écrits à droite des lignes. "A" (pour "Actor") signifie que la ligne contient des informations sur le participant au processus. "C" (pour "Class") – des informations sur les objets de classes qui sont traités pendant l'exécution des processus. "E" (pour "Environment") – des informations sur les objets de classes qui caractérisent l'environnement d'exécution des processus. "P" (pour "Process") – des informations sur les processus eux-mêmes.
Au fait, la définition précise du processus est également sujette à des débats méthodologiques, ne serait-ce que parce que les processus sont variés : affaires, production, technologiques, etc. (on peut s'en informer, par exemple, [4] et [5]). Pour éviter toute polémique, convenons que le processus nous intéresse du point de vue de sa répétabilité dans le temps et du besoin d'automatisation, c'est-à-dire de transférer l'exécution d'une partie des opérations du processus à un système automatisé.
Notes sur l'utilisation du diagramme d'Activité
Commençons à modéliser notre processus en utilisant le diagramme d'Activité. Pour commencer, j'expliquerai comment les codes mentionnés ci-dessus seront utilisés dans le modèle. Il est plus simple d'expliquer avec un exemple graphique, et nous examinerons en même temps certains (presque tous les nécessaires) éléments du diagramme d'Activité.
Analysons le fragment suivant :
…
L'écureuil chante des chansons, (P1, A1)
Et grignote des noix, (P2)
Mais les noix ne sont pas ordinaires, (C1)
Tout en coques dorées, (C2)
Les noyaux sont des émeraudes pures; (C3)
…
Nous avons deux étapes du processus P1 et P2, le participant A1, et des objets de trois classes différentes : un objet de la classe C1 entre à l'étape, les objets des classes C2 et C3 sortent, comme résultat de cette étape P2 de notre processus. Pour le diagramme, nous utiliserons les éléments de modélisation suivants.
Le fragment de notre processus peut être représenté comme suit (Figure 1).
Figure 1. Fragment du diagramme d'Activité
Pour organiser l'espace et structurer le diagramme d'Activité, nous appliquerons une approche pas tout à fait standard, du point de vue de l'utilisation classique de la notation UML. Mais il y a plusieurs raisons à cela. Tout d'abord, simplement avant de commencer la modélisation, nous établirons ce qu'on appelle un accord sur la modélisation, où nous enregistrerons toutes les caractéristiques de l'utilisation de la notation. Deuxièmement, cette approche a été appliquée avec succès à plusieurs reprises lors de la modélisation commerciale dans des projets réels de création de systèmes logiciels, les résultats ayant été documentés par notre petite équipe d'auteurs dans l'objet de droits d'auteur correspondant [6], et également utilisés dans le manuel [7]. Pour le diagramme d'Activité, nous déterminerons que le champ du diagramme est structuré à l'aide de « couloirs » - Swim lanes. Le nom du couloir correspondra au type d'éléments du diagramme qui seront placés dans ce couloir.
« Artefacts d'entrée et de sortie » : dans ce couloir se trouveront les éléments Objects – objets utilisés ou résultant de l'exécution d'une certaine étape du processus.
« Étapes du processus » : ici, nous placerons les éléments Activity – actions des participants au processus.
« Participants » : un couloir pour les éléments qui indiqueront les rôles des exécutants dans notre processus, pour cela, nous utiliserons à nouveau l'élément modélisateur Object – objet, mais nous ajouterons le stéréotype « Actor ».
Le prochain couloir s'appelle « Règles métier » et dans ce couloir, nous placerons sous forme textuelle les règles d'exécution des étapes du processus, et pour cela, nous utiliserons l'élément modélisateur Note – remarque.
Nous nous arrêterons ici, bien qu'il aurait été également possible d'utiliser un couloir « Outils » pour recueillir des informations sur le niveau d'automatisation du processus. Un couloir « Postes et départements des participants », peut également être utilisé pour lier les rôles aux postes et départements des participants au processus.
Tout ce que je viens de décrire est un extrait de l' accord de modélisation, cette partie de l'accord concerne les règles d'organisation d'un diagramme et, par conséquent, les règles de sa rédaction et de sa lecture.
« Recette »
Maintenant, examinons une option de modélisation du système précisément à partir du diagramme d'Activité. C'est seulement l'une des options, je souligne qu'elle n'est bien sûr pas la seule. Le diagramme d'Activité nous intéressera en raison de son rôle pour la transition de la modélisation de processus à la conception de systèmes automatisés. Pour cela, nous suivrons les recommandations méthodologiques – une sorte de recette composée uniquement de cinq étapes et prévoyant le développement de trois types de diagrammes. L'application de cette recette aidera à obtenir une description formalisée du processus que nous souhaitons automatiser et à rassembler des données pour la conception du système. Pour les étudiants commençant à étudier UML, c'est une certaine bouée de sauvetage qui les empêchera de couler dans toute cette diversité de moyens d'expression et de techniques disponibles dans UML et les outils de modélisation modernes.
Voici, en fait, la recette elle-même, suivie des diagrammes construits pour notre domaine d'objet « féerique ».
Étape 1. Nous décrivons le processus sous forme de diagramme d'Activité. Pour un processus comportant plus de 10 étapes, il est judicieux d'appliquer le principe de décomposition des étapes du processus afin d'améliorer la lisibilité du diagramme.
Étape 2. Nous identifions ce qui peut être automatisé (les étapes peuvent être, par exemple, mises en évidence sur le diagramme).
Étape 3. L'étape à automatiser doit être associée à une ou plusieurs fonctions du système (la relation peut être plusieurs-à-plusieurs), nous dessinons un diagramme de Cas d'utilisation. Ce sont les fonctions de notre système.
Étape 4. Nous décrivons l'organisation interne du Système Automatisé à l'aide d'un diagramme de classes – Classe. La piste « Objets d'entrée et de sortie (documents) » sur le diagramme d'Activité est la base pour construire le modèle objet et le modèle entité-relation.
Étape 5. Nous analysons les notes sur la piste « Règles métier », elles imposent toutes sortes de restrictions et conditions, se transformant progressivement en exigences non fonctionnelles.
L'ensemble des diagrammes (Activité, Cas d'utilisation, Classe) nous donne une description formalisée dans une notation suffisamment stricte, c'est-à-dire ayant une interprétation sans ambiguïté. Nous pouvons maintenant développer le cahier des charges, préciser les spécifications des exigences, etc.
Commençons la modélisation.
Étape 1. Nous décrivons le processus sous forme de diagramme d'Activité
Je rappelle que le champ du diagramme a été structuré à l'aide de pistes « flottantes », où chaque piste contient des éléments du même type (Figure 2). En plus des éléments décrits ci-dessus, nous allons utiliser des éléments supplémentaires, décrivons-les.
La décision (Decision) indique dans le diagramme un point de branchement de notre processus, tandis que la fusion des flux (Merge) représente le point de leur réassemblage. Les conditions de transition sont notées entre crochets sur les transitions.
Entre deux synchroniseurs (Fork), nous allons montrer des branches parallèles du processus.
Notre processus ne peut avoir qu'un seul point de départ – un point d'entrée (Initial). En revanche, il peut y avoir plusieurs finalités (Final), mais pas pour notre diagramme spécifique.
Avec un grand nombre d'éléments et de liens, il y a beaucoup de flèches, et on peut d'abord distinguer les étapes du processus avant de procéder à la décomposition de ces étapes. Cependant, je souhaiterais montrer notre processus « féerique » dans son intégralité sur un seul diagramme, tout en veillant à ce que les flèches ne soient pas « collées », afin de pouvoir tracer exactement quelles sont les relations.
Figure 2. Diagramme d'Activité – vue d'ensemble du processus
Comme certaines détails du processus ont été omis dans les lignes poétiques, il a fallu les rétablir, et ils sont représentés par des éléments avec un fond blanc. Ces détails incluent l'étape « Transmission/ réception pour stockage et traitement » ainsi que plusieurs artefacts d'entrée et de sortie. Il convient de noter que cette étape ne révèle pas complètement le processus, car il faudrait distinguer séparément l'étape de transmission et l'étape de réception, et ajouter une étape distincte pour les coques, tout en suggérant que toutes ces valeurs matérielles devraient être temporairement stockées quelque part, etc.
Notons également que la question de l'origine des noix reste pour l'instant sans réponse – d'où proviennent-elles et comment arrivent-elles à l'écureuil ? Cette question (mise en évidence en rouge dans la note – élément Note) nécessite un travail approfondi ! C'est ainsi que fonctionne un analyste – en rassemblant des informations par petites touches, en formulant des hypothèses et en obtenant un « ok » ou « non-ok » de la part des experts du domaine – des personnes très importantes et tout simplement indispensables lors de la modélisation commerciale lorsqu'il s'agit de créer des systèmes.
Notons également que l'étape du processus P5 se compose de deux parties.
Nous décomposons chaque partie et l'examinons plus en détail (Figure 3, Figure 4), car les activités effectuées dans le cadre de ces étapes seront automatisées.
Figure 3. Diagramme d'Activité – détails (partie 1)
Figure 4. Diagramme d'Activité – détails (partie 2)
Étape 2. Nous identifions ce qui peut être automatisé
Les étapes à automatiser sur les diagrammes sont mises en évidence en couleur (voir Figure 3, Figure 4).
Tout cela est effectué par un seul participant au processus – le Diacre commandant :
- Il insère les informations sur le poids de la noix dans le registre ;
- Il insère les informations sur le transfert de la noix dans le registre ;
- Il fixe le fait de la transformation de la noix en coques et en cœur ;
- Il insère les informations sur le cœur de la noix dans le registre ;
- Il insère les informations sur les coques de noix dans le registre.
Analyse du travail accompli. Quelles sont les prochaines étapes ?
Ainsi, nous avons accompli un important travail préparatoire : rassembler des informations sur le processus que nous souhaitons automatiser ; commencer à élaborer un accord sur la modélisation (pour l'instant seulement concernant l'utilisation du diagramme d'Activité) ; réaliser la modélisation du processus et même décomposer plusieurs de ses étapes ; identifier les étapes du processus que nous allons automatiser. Nous sommes maintenant prêts à passer aux étapes suivantes et à commencer la conception des fonctionnalités du système et de son organisation interne.
Comme on le sait, la théorie sans la pratique est inutile. Il est impératif d'essayer "la modélisation" par soi-même, c'est utile pour comprendre l'approche proposée. Par exemple, on peut travailler dans un environnement de modélisation [3]. Nous n'avons décomposé qu'une partie des étapes du diagramme général du processus (voir Figure 2). Comme devoir pratique, il peut être proposé de reproduire tous les diagrammes dans l'environnement Modelio et de décomposer l'étape « Transfert / réception pour stockage et transformation ».
Nous n'examinons pas pour l'instant le travail dans des environnements de modélisation spécifiques, mais cela pourrait faire l'objet d'articles et d'analyses autonomes.
Dans la deuxième partie de l'article, nous examinerons les techniques de modélisation et de conception nécessaires aux étapes 3-5, nous utiliserons les diagrammes UML de cas d'utilisation et de classes. À suivre.
Liste des sources
- Site « UML2.ru ». Forum de la Communauté des Analystes. Section générale. Exemples. Exemples de contes présentés sous forme de diagrammes UML. [Ressource électronique] Mode d'accès : Internet :
- Site de Sparx Systems. [Ressources électroniques] Accès : Internet :
- Site Modelio. [Ressource électronique] Mode d'accès : Internet :
- Grand Dictionnaire Encyclopédique. Processus (interprétation). [Ressource électronique] Mode d'accès : Internet :
- Site «Organisation de la gestion efficace». Blog. Rubrique «Gestion des processus métiers». Définition du processus métier. [Ressource électronique] Mode d'accès : Internet :
- Certificat n° 18249 d'enregistrement et de dépôt d'une œuvre issue d'une activité intellectuelle. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscrit du manuel intitulé «Modélisation du domaine avec Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Kraskinova S.A. Modélisation des processus métiers. — M.: KURC, NIC INFRA-M, EBS Znanium.com. — 2017.
Source : habr.com
