"Un jour dans la vie d'un écureuil" ou des processus de modélisation à la conception d'un système automatisé de comptabilisation des actifs matériels "Belka-1.0" (Partie 2)
Résumé de la série précédente
В nous avons utilisé un domaine "conte de fées" inspiré d'exemples d'étude de diagrammes UML basés sur des tracés de contes de fées (voir, par exemple, [1]). Avant la modélisation, nous nous sommes mis d'accord sur l'utilisation de certains éléments du diagramme d'activité et avons commencé à former un accord de modélisation. Tenant compte de ces accords, en 1ère étape nous avons décrit le processus sous forme de diagrammes d'activités, et en 2ème étape nous avons identifié les étapes du processus pour lesquelles une automatisation est requise (et possible).
Permettez-moi de vous rappeler que nous allons automatiser l'activité de comptabilisation des valeurs matérielles, qui survient dans ces processus.
...
Une île dans la mer se trouve, (E1, E2)
Grêle sur les stands de l'île (E3, E1)
Aux églises au dôme doré, (E4)
Avec des tours et des jardins ; (E5, E6)
L'épicéa pousse devant le palais, (E7, E8)
Et en dessous se trouve une maison de cristal; (E9)
L'écureuil y habite, apprivoisé, (A1)
Oui, quel animateur ! (A1)
L'écureuil chante des chansons, (P1, A1)
Oui, il ronge toutes les noix, (P2)
Et les noix ne sont pas simples, (C1)
Toutes les coquilles sont dorées, (C2)
Grains d'émeraude pure; (C3)
Les serviteurs gardent l'écureuil, (P3, A2)
Servez-la comme serviteurs de toutes sortes (P4)
Et un greffier a été affecté (A3)
Compte rendu strict de l'actualité des noix ; (P5, C1)
Donne l'honneur à son armée ; (P6, A4)
Une pièce est coulée des coquillages, (P7, C2, C4)
Laissez-les flotter autour du monde; (P8)
Les filles lancent l'émeraude (P9, A5, C3)
Dans les garde-manger, mais sous le boisseau ; (E10, E11)
...
(A.S. Pouchkine "Le conte du tsar Saltan, de son fils glorieux et puissant, le prince Gvidon Saltanovitch et de la belle princesse des cygnes", )
Dans cet exemple, j'utilise l'environnement Enterprise Architect d'une société australienne. [2], et dans le cadre de formations j'utilise [3].
Permettez-moi de vous rappeler que les processus sont différents, vous pouvez vous familiariser, par exemple, [4] et [5].
Voir [6, 7] pour plus de détails sur les approches appliquées à la modélisation et à la conception.
Pour la spécification UML complète, voir [8].
Nous sommes maintenant prêts à passer aux étapes suivantes et à commencer à concevoir les fonctions du système et son organisation interne. La numérotation des figures continuera.
Étape 3. L'étape automatisée doit se voir attribuer une fonction ou des fonctions du système
Le système automatisé (AS) en cours de développement est conçu pour tenir un registre strict des noix, vous vous souvenez ? Pour chaque étape en surbrillance (voir Figure 3, Figure 4 ), que nous allons automatiser, écrivez l'exigence fonctionnelle, en utilisant quelque chose comme cette construction "Le système doit être capable de ..." et développez un diagramme de cas d'utilisation. Maintenant, nous complétons en fait notre accord de modélisation avec de nouvelles règles. Laissez-moi vous expliquer quels éléments nous allons utiliser.
Entre le « Rôle de l'utilisateur » et la « Fonction », nous utiliserons la relation « Association » (Figure 5), ce qui signifie que l'utilisateur ayant ce rôle peut exécuter cette fonction.
Figure 5. Utilisation d'une relation de type association
De "Fonction" à "Exigence", nous tracerons le lien "Implémentation" (Figure 6) pour montrer que cette exigence sera implémentée par ces fonctions, la relation peut être "plusieurs à plusieurs", c'est-à-dire une fonction peut être impliquée dans la mise en œuvre de plusieurs exigences, et plusieurs fonctions peuvent être nécessaires pour mettre en œuvre l'exigence.
Figure 6. Utilisation d'une relation d'implémentation
Si une fonction nécessite pour son exécution qu'une autre fonction soit exécutée, et que cela soit nécessaire, nous utiliserons la connexion "Dépendance" avec le stéréotype "Inclure" - inclusion (Figure 7). Si l'exécution d'une fonction supplémentaire est requise sous certaines conditions, nous utiliserons la connexion "Dépendance" avec le stéréotype "Extend" - une extension. Tout est très facile à retenir : "Inclure" - TOUJOURS, et "Étendre" - PARFOIS.
Figure 7. Utilisation du type de lien "Dépendance (inclure)"
En conséquence, notre diagramme ressemblera à ceci (Figure 8).
Figure 8. Diagramme de cas d'utilisation (modèle fonctionnel d'AS)
De plus, le diagramme de cas d'utilisation est utilisé pour modéliser les rôles des utilisateurs (Figure 9).
Figure 9. Diagramme de cas d'utilisation (rôles des utilisateurs AS)
Etape 4. Décrivons l'organisation interne de l'AS à l'aide d'un diagramme de classes
En utilisant des informations sur les artefacts d'entrée et de sortie de notre processus (voir Diagrammes d'activité - Figure 2, Figure 3, Figure 4), nous allons développer un diagramme de classes. Nous utiliserons les éléments de modélisation "Classe" et divers types de relations entre eux.
Pour montrer la relation « tout-partie », nous utiliserons la relation de type « Agrégation » (Figure 10) : la noix est le tout, et les coques et l'amande sont les parties.
Figure 10. Relation tout-partie
En conséquence, un fragment de notre diagramme ressemblera à ceci (Figure 11). Les classes sont marquées par une couleur, que nous avons mise en évidence directement dans la description textuelle du processus.
Figure 11. Diagramme de classes
Le diagramme de classes a également été utilisé pour modéliser d'autres artefacts - non seulement ceux qui seront pertinents pour le modèle conceptuel du processus d'inventaire automatisé, mais liés à l'environnement d'exécution - l'environnement (Figure 12) et les processus "voisins" (Figure 13) qui peuvent influencer le processus automatisé, mais qui ne sont pas encore au centre de notre attention (nous supposons que le système se développera et que ces informations seront utiles).
Figure 12. Diagramme de classes (environnement)
La relation d'héritage montre la généralisation de divers bâtiments, classes "filles", sous la classe "parente" généralisante "Bâtiment".
Figure 13. Diagramme de classes (plus d'informations 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 le traçage des classes qui ne sont pas explicitement indiquées dans la description du processus, mais qui sont nécessaires à son automatisation, vers des classes dont les instances sont précisément indiquées dans notre description.
Etape 5. Analysons les notes sur la piste "Business Rules"
Comme les règles ont été spécifiées (voir Figure 2 ):
- la nécessité de scinder l'une des étapes en 2 parties, la deuxième partie ne commence à être effectuée que sous certaines conditions ;
- nomination d'un certain fonctionnaire pour effectuer la comptabilité des noix;
- une technique (couleur blanche des éléments), qui indique que l'élément n'était pas explicitement listé dans la description du processus.
Il convient de noter que nous avons déjà utilisé toutes ces règles lors de l'élaboration de diagrammes.
Remarques finales
Nous sommes donc passés par 5 étapes et avons construit 3 types de diagrammes. J'ajouterai un commentaire supplémentaire sur l'organisation de nos modèles dans l'environnement de modélisation. Il existe un grand nombre de frameworks permettant de structurer les modèles que nous développons, mais ce n'est pas l'objet de cet article, nous nous limiterons donc au simple ensemble de packages suivant pour une maintenance ordonnée de notre projet : Business Process, Functional Model, Artefacts, participants et environnement (Figure 14).
Figure 14. La structure des packages de projet
Ainsi, nous avons développé des modèles cohérents qui décrivent le système de comptabilisation des actifs matériels sous différents angles : un modèle de processus métier automatisé, un modèle fonctionnel et un modèle d'organisation interne du système au niveau conceptuel.
Liste des sources
- Site "UML2.ru". Forum de la communauté des analystes. Rubrique générale. Exemples. Exemples de contes de fées sous forme de diagrammes UML. [Ressource électronique] Mode d'accès : Internet :
- Site Web de Sparx Systems. [Ressource électronique] Mode d'accès : Internet :
- Site Web Modelio. [Ressource électronique] Mode d'accès : Internet :
- Grand dictionnaire encyclopédique. Processus (interprétation). [Ressource électronique] Mode d'accès : Internet :
- Site "Organisation d'une 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 sur l'enregistrement et le dépôt d'un produit du résultat d'une activité intellectuelle. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Le manuscrit du support pédagogique intitulé "Modélisation de la matière à l'aide d'Enterprise Architect" // 2011.
- 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