Discussion :

[bizulk]

Bonjour,

Je modélise actuellement un système industriel dans lequel interviennent plusieurs automates et un PC pour la partie commande.
J'ai décrit au niveau 'systèmes' les interactions entre les automates et le PC pour la réalisation des scénarios avec des diagrammes de séquences.


Dans l'ouvrage "introduction à UML" par tom penders, on propose d'utiliser les diagrammes de séq existants pour générer ces états en prenant tous les états actifs représentés entre deux messages, ce que je trouve une très bonne idée, cela permet de lier les diagrammes et de se relire.
Le complément du diagramme d'état sera pour moi de définir les activités du systèmes.

Je voudrais mettre en évidence que je suis susceptible de passer d'un scénario à une autre grace au diagramme d'état, parce que certains scénarios sont prioritaires, et bien sur le système met en oeuvre plusieurs scénarios en parallèle. C'est une chose assez facile à présenter lors de la conception (multi-threading, etc ...) mais je trouve moins à mon niveau d'analyse.

Il me semble que je dois utiliser les états composites avec des états historiques. Qu'en pensez-vous ?

De même peut-on confondre des sous-machines et des états composites.
Sous bouml j'ai systématiquement utilisé des sous-machines pour "factoriser" certaines étapes des processus. D'un point de vue édition de diagramme c'était plus productifs mais peut-être que j'induis ensuite des erreurs d'interprétation ?

Question bonus : sous bouml il ne m'est pas possible de nommer un état final. Dans "modélisation objet avec UML" des éditions Eyrolles on indique qu'en "général ces états ne sont pas nommés". J'assimile alors les états initiaux/finaux à des 'pointeurs' vers les états nommés. Mais je rencontre des exemples dans lesquels les transitions depuis/vers ces états sont elle nommées avec des évènements/actions, ce qui me laisse penser que j'ai tort.
Ou alors tout simplement la norme (que j'ai pas lu) n'oblige rien a ce sujet. Quelqu'un peut-il porter une lumière là-dessus ?

Merci.

[bruno_pages]

Je voudrais mettre en évidence que je suis susceptible de passer d'un scénario à une autre grace au diagramme d'état, parce que certains scénarios sont prioritaires

je ne comprends pas, une machine à état montre ... les états d'un système, je ne vois pas le lien avec le fait que certains scénarios soient prioritaires.

il y a une différence entre une (sous) machine et un état composite, une machine est un 'tout' avec son contexte propre. Une sous machine est donc aussi un 'tout', celle-ci peut très bien devenir une non-sous-machine c.a.d. en l'extrayant de son conteneur et en remplaçant celle-ci par un état-sous-machine (submachine state) dans son ancien conteneur, un état-sous-machine étant en fait l'appel d'une machine.

Dans Bouml j'implémente un état final comme un pseudo état pour me simplifier la vie, c'est pour cela qu'on ne peut les nommer, je ne pense pas que cette entrave à la norme soit vraiment un problème vu ce qu'est un état final

Attention, il n'y a pas d'état initial, il s'agit de pseudo état initial, malheureusement on voit souvent état initial y compris dans le cours de Laurent audibert qui dit de plus qu'un état final est un pseudo état

Votre remarque à propos des pointeurs est étonnée, et je ne comprends pas votre surprise à propos des transitions. La norme est difficile à lire mais vous devriez la lire.

[bizulk]

Pour la question de l'état initial/final, je vais la reformuler :
Si l'état initial et apparemment aussi final sont des pseudo-états qui servent à indiquer les états initiaux et finaux respectifs, pourquoi peut-on les nommer ainsi que les transitions associées (ce qui reviendrait a associer un évènement de transition et une action vers ces pseudo état ?).

Pour ce qui est de mon étude, prenons les scénarios suivants :
_ entrée de produit en stock
_ sortie de produit en stock

entrée : la réception déclare le produit, je décide de l'emplacement de stockage, je demande le transfert vers la zone de stockage. A l'arrivée vers la zone de stockage, j'exécute rangement dans le stock.
Sortie : demande de sortie depuis la zone l'expédition, extraction du stock, transfert vers l'expédition.

Je peux être en train de gérer l'entrée et la sortie pour plusieurs produits en même temps, voir même exécuter plusieurs entrée en série. Il me semble que je ne dois faire qu'un seul diagramme d'état pour le système.
L'idée était des sous-machines pour chaque scénario, et d'utiliser les états historiques pour montrer que je pouvais prendre en compte à tout moment une nouvelle demande d'entrée ou de sortie de produit.

[bruno_pages]

Bonjour et bonne année,

Si l'état initial et apparemment aussi final sont des pseudo-états qui servent à indiquer les états initiaux et finaux respectifs, pourquoi peut-on les nommer

encore une fois la norme est pseudo état initial et état final, mais dans Bouml ils sont tout les deux vus comme des pseudo états.

dans les diagrammes ils n'indiquent/référencent pas le 'vrai' (pseudo) état, il sont eux même, de même que dans un diagramme de classes la représentation d'une classe est la classe elle même.

désolé mais je ne comprends toujours pas en quoi le fait de nommer un état final pose un problème, à noter qu'il n'y a pas un unique état final

ainsi que les transitions associées (ce qui reviendrait a associer un évènement de transition et une action vers ces pseudo état ?).

non, le nom (optionnel) d'une transition n'a rien à voir avec les possibles événements et/ou garde-contrainte et/ou comportement. Vous devez distinguer l'affichage du nom de la transition et du trio événement1..,événementn [ garde-contrainte] / comportement si c'est cela qui vous induit en erreur

... Je peux être en train de gérer l'entrée et la sortie pour plusieurs produits en même temps... Il me semble que je ne dois faire qu'un seul diagramme d'état pour le système.

non le résultât serait inextricable et sans doute faux car ne permettant pas tout les cas envisageable ... à moins d'avoir finalement un seul état où tout est possible. Le fait d'utiliser une machine à état n'est jamais une obligation, leur cadre d'utilisation est assez limité, il faut vraiment que le sous système décrit est des états ayant un sens.

vous devez bien comprendre qu'une machine à états décrit un comportement, et peut donc correspondre au corps d'une opération/fonction, et il ne vous viendrait pas à l'idée d'écrire toute votre application dans la seule fonction main, non ?

sans regarder si vous utiliserez ou non une/des machines à états, comment votre système pourra prendre en compte plusieurs demandes d'entrée / sortie de produit, cela reposera-t-il des threads séparés ou chaque étape d'une demande d'entrée / sortie de produit sera-t-elle atomique au sens exécution ?

[bizulk]

encore une fois la norme est pseudo état initial et état final, mais dans Bouml ils sont tout les deux vus comme des pseudo états.
désolé mais je ne comprends toujours pas en quoi le fait de nommer un état final pose un problème, à noter qu'il n'y a pas un unique état final

C'est peut-être parce que je confonds mes règles ne nommage (j'interprete l'ensemble des attributs et l'activité avec la lecture du nom), avec le fait que au sens UMLle nommer permet seulement d'identifier l'état de manière unique ?
Est-ce qu'un état final peut être actif ? Bon il faut que je replonge dans mes lectures a ce sujet, j'ai peut-être zappé quelque chose.

Vous devez distinguer l'affichage du nom de la transition et du trio événement1..,événementn [ garde-contrainte] / comportement si c'est cela qui vous induit en erreur

Je viens de m'en rendre compte tout juste hier lorque j'utilisais bouml et que j'ai souhaité faire apparaître les trios.

Je ne sais pas encore si je fais un contexte multi-thread thread/processus. On m'impose une communication asynchrone donc je ne suis pas bloqué lors de la comm avec les automates de reception/expedition. Ne définir qu'un seul process m'éviterait des problèmes de synchronisation et de mettre en place des mécanismes de communication (shared mem, queue de msg, ...).

Pour répondre à mon problème je pense tout simplement définir plusieurs états actifs avec une barre de synchronisation et des super états ou sous-machine.