«Une journée dans la vie d'un écureuil» ou de la modélisation des processus à la conception d'un système automatisé de comptabilité des valeurs matérielles «Écureuil-1.0» (Partie 2)
Résumé de l'épisode précédent
Dans nous avons utilisé un domaine «féérique», inspirés par des exemples d'étude de diagrammes UML basés sur des contes (voir, par exemple, [1]). Avant de commencer la modélisation, nous avons convenu de l'utilisation de certains éléments du diagramme d'activité et avons commencé à établir un accord sur la modélisation. En tenant compte de ces accords, nous avons décrit le processus à la première étape sous forme de diagrammes d'activité, et à la deuxième étape, nous avons identifié les étapes du processus pour lesquelles l'automatisation est nécessaire (et possible).
Rappelons que nous prévoyons d'automatiser l'activité de comptabilité des valeurs matérielles, qui se manifeste 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)
…
(D'A.S. Pouchkine «La légende du roi Salton, de son fils célèbre et puissant héros le prince Guidon Saltonovich et de la belle princesse Cygne», )
Dans cet exemple, j'utilise l'environnement Enterprise Architect de l'entreprise australienne [2], et dans le cadre des cours, j'applique [3].
Rappelons que les processus peuvent être différents, on peut s'en informer, par exemple, [4] et [5].
Pour plus d'informations sur les approches de modélisation et de conception utilisées, voir [6, 7].
Pour la spécification complète de l'UML, voir [8].
Nous sommes désormais prêts à passer aux étapes suivantes et à commencer la conception des fonctionnalités du système et de son organisation interne. La numérotation des illustrations sera poursuivie.
Étape 3. L'étape à automatiser doit être associée à une ou plusieurs fonctions du système
Le système automatisé (SA) en cours de développement est destiné à assurer un suivi strict des noix, vous vous en souvenez ? Pour chaque étape identifiée (voir Figure 3, Figure 4 ), que nous allons automatiser, nous rédigerons un cahier des charges fonctionnel en utilisant une construction du type «Le système doit permettre ...» et développerons un diagramme de cas d'utilisation. Maintenant, nous complétons effectivement notre accord de modélisation avec de nouvelles règles. J'expliquerai quels éléments nous allons utiliser.
Entre le « Rôle utilisateur » et la « Fonction », nous allons utiliser une relation de type « Association » (Figure 5), ce qui signifie qu'un utilisateur avec ce rôle peut effectuer cette fonction.
Figure 5. Utilisation de la relation de type « Association »
De la « Fonction » au « Besoin », nous établirons une relation de type « Réalisation » (Figure 6) pour montrer que ce besoin sera réalisé par ces fonctions, la relation peut être de type « plusieurs à plusieurs », c'est-à-dire qu'une fonction peut participer à la réalisation de plusieurs besoins, et plusieurs fonctions peuvent être nécessaires pour réaliser un besoin.
Figure 6. Utilisation de la relation de type « Réalisation »
Si une fonction nécessite qu'une autre fonction soit exécutée, et cela de manière obligatoire, nous utiliserons une relation de type « Dépendance » avec le stéréotype « Include » — inclusion (Figure 7). Si l'exécution de cette fonction supplémentaire est requise sous certaines conditions, nous utiliserons la relation de type « Dépendance » avec le stéréotype « Extend » — extension. C'est très facile à retenir : « Include » — TOUJOURS, et « Extend » — PARFOIS.
Figure 7. Utilisation de la relation de type « Dépendance (inclusion) »
En fin de compte, notre diagramme ressemblera à peu près à cela (Figure 8).
Figure 8. Diagramme Use-case (modèle fonctionnel du SI)
De plus, le diagramme Use-case est utilisé pour modéliser les rôles des utilisateurs (Figure 9).
Figure 9. Diagramme Use-case (rôles des utilisateurs du SI)
Étape 4. Nous décrivons l'organisation interne du Système Automatisé à l'aide d'un diagramme de classes
En utilisant les informations sur les artefacts d'entrée et de sortie de notre processus (voir les diagrammes d'Activité — Figure 2, Figure 3, Figure 4), nous allons développer un diagramme de classes. Nous allons utiliser des éléments modélisants de type « Classe » et différents types de relations entre eux.
Pour montrer la relation « tout-partie », nous allons utiliser une relation de type « Agrégation » (Figure 10) : la noix est le tout, tandis que les coques et le noyau sont les parties.
Figure 10. Relation « tout-partie »
En fin de compte, le fragment de notre diagramme ressemblera à peu près à cela (Figure 11). Les classes mises en surbrillance sont celles que nous avons extraites directement de la description textuelle du processus.
Figure 11. Diagramme de classes
Le diagramme de classes a également été utilisé pour modéliser d'autres artefacts – pas seulement ceux qui seront liés au modèle conceptuel du processus automatisable de comptabilité des valeurs matérielles, mais aussi ceux qui concernent l'environnement d'exécution – l'environnement (Figure 12) et les processus « voisins » (Figure 13), qui peuvent influencer le processus automatisable, mais qui ne sont pas encore au centre de notre attention (nous supposons que le système évoluera et que cette information sera utile).
Figure 12. Diagramme de classes (environnement)
La relation d'héritage montre la généralisation de différentes structures, les « classes filles » sous la classe « parent » généralisante « Structure ».
Figure 13. Diagramme de classes (informations supplémentaires sur les artefacts)
La « réaction à la situation » dépend des « données de contrôle visuel ». Pour plusieurs relations de dépendance, le stéréotype « trace » est utilisé pour montrer la traçabilité des classes, qui ne sont pas explicitement mentionnées dans la description du processus, mais qui sont nécessaires pour son automatisation, vers les classes pour lesquelles il y a une référence précise dans notre description.
Étape 5. Nous analysons les notes sur la piste « Règles métier »
Les règles indiquées sont (voir Figure 2 ):
- la nécessité de diviser une des étapes en 2 parties, la seconde partie ne commençant qu'à certaines conditions ;
- la désignation d'un fonctionnaire spécifique pour effectuer le suivi des noix ;
- un procédé technique (couleur blanche des éléments), qui indique que l'élément n'a pas été explicitement mentionné dans la description du processus.
Il convient de noter que toutes ces règles ont déjà été utilisées lors de l'élaboration des diagrammes.
Remarques finales
Ainsi, nous avons franchi 5 étapes et construit 3 types de diagrammes. J'ajouterai un petit commentaire sur l'organisation de nos modèles dans l'environnement de modélisation. Il existe de nombreux frameworks qui aident à structurer les modèles en développement, mais ce n'est pas l'objet de cet article, donc nous nous limiterons à ce simple ensemble de packages pour une gestion ordonnée de notre projet : Processus métier, Modèle fonctionnel, Artefacts, Participants et Environnement (Figure 14).
Figure 14. Structure des packages du projet
Ainsi, nous avons développé des modèles cohérents décrivant le système de comptabilité des biens matériels sous divers angles : le modèle de processus métier automatisé, le modèle fonctionnel et le modèle d'organisation interne du système au niveau conceptuel.
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.
- Spécification UML Unifiée OMG (OMG UML). Version 2.5.1. [Ressources électroniques] Accès : Internet :
Source : habr.com
