De la modélisation des processus à la conception d'un système automatisé (partie 2)

«Un jour dans la vie d'un écureuil» ou des processus de modélisation à la conception d'un système automatisé de comptabilisation des valeurs des matériaux «Écureuil-1.0» (Partie 2)

L'illustration du conte du tsar Saltan de A.S.Pouchkine a été utilisée, publiée par la littérature pour enfants, Moscou, 1949, Leningrad, dessins de K.Kuznetsov

Résumé de la série précédente

Dans la première partie, nous avons utilisé un sujet «conte de fées», inspiré par des exemples d'étude de diagrammes UML basés sur des parcelles de conte de fées (voir par exemple ici [1]). Avant le début de la modélisation, nous nous sommes mis d'accord sur l'utilisation de certains éléments du diagramme d'activité et avons commencé à formuler un accord de modélisation. Sur la base de ces accords, à la 1ère étape, nous avons décrit le processus sous forme de diagrammes d'activité, et à la 2ème étape, nous avons identifié les étapes du processus pour lesquelles l'automatisation est requise (et possible).

Permettez-moi de vous rappeler que nous allons automatiser l'activité de comptabilisation des valeurs matérielles qui se pose dans ces processus.

...
L'île se trouve sur la mer, (E1, E2)
Ville sur les peuplements de l'île (E3, E1)
Avec des églises au dôme d'or, (E4)
Avec des tours et des jardins; (E5, E6)
L'épicéa pousse devant le palais, (E7, E8)
Et en dessous, il y a une maison de cristal; (E9)
L'écureuil y vit manuel (A1)
Quel artiste! (A1)
Squirrel chante des chansons, (P1, A1)
Oui, les noix rongent tout, (P2)
Et les noix ne sont pas simples, (C1)
Tous les coquillages sont dorés, (C2)
Les grains sont de l'émeraude pure; (C3)
Des serviteurs gardent l'écureuil, (P3, A2)
Ils lui servent un autre serviteur (P4)
Et le greffier a reçu l'ordre (A3)
Compte strict des noix; (P5, C1)
Salue son armée; (P6, A4)
D'un obus versez une pièce, (P7, C2, C4)
Oui flotte autour du monde; (P8)
Filles pour émeraude (P9, A5, C3)
Dans les garde-manger, mais en arrière-plan; (E10, E11)
...
(A.S. Pouchkine "Le conte du tsar Saltan, de son héros glorieux et puissant, le prince Gvidon Saltanovich et de la belle princesse Cygnes", comme on le croit, un traitement gratuit du conte folklorique "jusqu'au genou en or, le coude de la main en argent," qui a été enregistré par Pouchkine de diverses manières )

Dans cet exemple, j'utilise l'environnement Enterprise Architect de la société australienne Sparx Systems [2], et dans le cadre de la formation, j'utilise Modelio [3].
Permettez-moi de vous rappeler que les processus sont différents, vous pouvez vous familiariser, par exemple, ici [4] et ici [5].
Pour plus d'informations sur les approches appliquées à la modélisation et à la conception, voir [6, 7].
Voir la spécification UML complète ici [8].

Nous sommes maintenant prêts à passer aux étapes suivantes et à commencer à concevoir les fonctions du système et de son organisation interne. La numérotation des chiffres se poursuivra.

Étape 3. L'étape automatisée doit correspondre à la ou aux fonctions du système

Le système automatisé développé (AS) est conçu pour conserver un enregistrement strict des noix, vous vous souvenez? Pour chaque étape sélectionnée (voir Figure 3, Figure 4 dans la 1ère partie ), que nous allons automatiser, nous notons l'exigence fonctionnelle, en appliquant approximativement la construction suivante: «Le système doit avoir la possibilité d'être implémenté ...» et développons le diagramme de cas d'utilisation. Maintenant, nous complétons actuellement notre accord de modélisation avec de nouvelles règles. Permettez-moi d'expliquer quels éléments nous utiliserons.

Entre le «rôle d'utilisateur» et la «fonction», nous utiliserons l'association d'association (figure 5), ce qui signifie que pour un utilisateur avec ce rôle, l'exécution de cette fonction est disponible.

Figure 5. Utilisation de la communication de type association

De la «Fonction» à l '«Exigence», nous dessinons la relation «Implémentation» (Figure 6) pour montrer que cette exigence sera mise en œuvre 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 une exigence.

Figure 6. Utilisation d'une relation de type "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 relation «Dépendance» avec le stéréotype «Inclure» - inclusion (figure 7). Si l'exécution d'une fonction supplémentaire est requise dans certaines conditions, nous utiliserons alors la relation «Dépendance» avec le stéréotype «Étendre» - extension. Tout est très facile à retenir: «Inclure» - TOUJOURS, et «Étendre» - PARFOIS.

Figure 7. Utilisation d'une relation de type «Dépendance (inclusion)»

En conséquence, notre diagramme ressemblera à quelque chose comme ceci (figure 8).

Figure 8. Diagramme de cas d'utilisation (modèle fonctionnel AS)

De plus, le diagramme de cas d'utilisation est utilisé pour modéliser les rôles d'utilisateur (figure 9).

Figure 9. Diagramme de cas d'utilisation (rôles d'utilisateur du locuteur)

Étape 4. Nous décrivons l'organisation interne de l'AS à l'aide du 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 développerons un diagramme de classes. Nous utiliserons les éléments de modélisation «Class» et différents types de connexions entre eux.

Pour montrer la relation «partie entière», nous utiliserons la relation de type «Agrégation» (figure 10): l'écrou est le tout, et les coques et le noyau sont des parties.

Figure 10. La relation "partie entière"

Par conséquent, un fragment de notre diagramme ressemblera à ceci (figure 11). La couleur indique les classes que nous avons identifiées directement dans la description textuelle du processus.

Figure 11. Diagramme de classe

Le diagramme de classes a également été utilisé pour modéliser d'autres artefacts - non seulement ceux qui seront liés au modèle conceptuel du processus automatisé de comptabilisation des valeurs des matériaux, mais qui sont liés à l'environnement d'exécution - l'environnement (figure 12) et les processus «voisins» (figure 13), qui peuvent pour influencer le processus automatisé, mais 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 une généralisation de divers bâtiments, classes «enfants», sous la classe généralisante «parent» «Structure».

Figure 13. Diagramme de classes (informations supplémentaires sur les artefacts)

La «réponse à la situation» dépend des «données d'inspection visuelle». 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 pour son automatisation, aux classes dont les instances sont explicitement indiquées dans notre description.

Étape 5. Nous analysons les notes sur la piste "Business Rules"

Les règles étaient indiquées (voir figure 2 dans la 1ère partie ):

1. la nécessité de diviser l'une des étapes en 2 parties, la deuxième partie ne commence à être exécutée que sous certaines conditions;
2. Nomination pour effectuer la comptabilité des noix d'un fonctionnaire particulier;
3. technique technique (couleur blanche des éléments), qui indique que l'élément n'était pas explicitement indiqué dans la description du processus.

Il convient de noter que nous avons déjà utilisé toutes ces règles lors du développement de diagrammes.

Observations finales

Nous sommes donc passés par 5 étapes et avons construit 3 types de diagrammes. Ajoutez un petit commentaire sur l'organisation de nos modèles dans l'environnement de modélisation. Il existe un grand nombre de cadres qui aident à structurer les modèles en cours de développement, mais ce n'est pas le sujet de cet article, nous nous limiterons donc à l'ensemble simple de packages suivants pour mener à bien notre projet: processus métier, modèle fonctionnel, artefacts, participants et environnement (figure 14).

Figure 14. Structure du package de projet

Ainsi, nous avons développé des modèles cohérents qui décrivent le système de comptabilisation des valeurs matérielles 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.

De la modélisation des processus à la conception d'un système automatisé (partie 1)