Discussion :

[man56]

Salut

j'ai un méta-modèle qui comporte des actions stéréotypées (ici l'envoi et la réception de messages), comme montré sur la première image.

je sais utiliser dans les diagrammes d'activités des actions stéréotypés (comme illustré dans la partie gauche de la deuxième image), et je veux savoir si je peux les utiliser aussi dans le diagramme d'état/transition (voir la partie doite de la duxième image)?

sinon comment indiquer dans un diagramme d'état/transition que les triggers et les activités (ici de simples actions) sont stéréotypés.

pour rappel, une transition prend la forme : trigger [condition] / effect

Finalement, comment associer un ou plusieurs objets à une action (trigger ou effect) d'une transition dans un diagramme d'état? dans notre cas, on veut associer au trigger getPrice (dont le stéréotype est <<Send Message>>) et au effect (dont le stéréotype est <<Receive Message>>) un objet message.

Merci

[bruno_pages]

Bonjour,

vous faite une confusion de type, getPrice n'est pas le trigger et price n'est pas un comportement

par contre votre trigger peut être associé à la réception du message getPrice, et votre comportement peut contenir l'émission du message price

[man56]

Merci Bruno pour votre réponse.

j'ai refais mes diagrammes pour mieux expliquer ma requête (voir les fichiers en attachement à ce nouveau message; c-a-d: picture1, picture2, picture3).

En fait j'ai élaboré un méta-modèle avec des stéréotypes. Et je veux établir un diagramme d'états/transitions d'un objet "fournisseur", dont le comportement est de renvoyer son prix quand il reçoit une requette de consultation du prix; et ce, en boucle infinie. Ce diagramme d'états/transitions comporte des actions stéréotypées et ces dernières sont associées à des objets (messages ici).

Mon soucis est que je ne suis pas sûr si je suis conforme à UML. Ceci découle du fait que je n'ai pas rencontré dans les documents que j'ai pu lire, des travaux qui illustrent comment dans un diagramme d'état/transition on peut utiliser des actions stéréotypées et comment associer des objets à des actions.

A travers cette discussion je souhaite savoir si ce que j'ai élaboré est correct et conforme à UML ou pas (je parle surtout du diagramme d'état/transition, car le diagramme d'activité est donné juste pour mieux comprendre mon exemple)

Si mon diragramme est faux, comment le rendre correct et conforme.

De plus, j'utilise powerDesigner et je n'ai pas pu avec, élaborer un diagramme d'états/transitions comportant des actions stérétypées. Est ce qu'il y a un outil qui supporte ou traite ceci?

Remarques:
- Dans l'exemple du diagramme d'états/transitions, j'ai associé à l'action sendPrice, en plus de l'objet priceResp, l'objet getPriceReq afin de relier cette action indirectement à l'action receiveGetPrice.
sinon est ce qu'il y a une autre manière pour connaitre à quelle receive correspond un send donné ou inverssement à quel send correspond un receive donné (par exemple on exécute plusieurs actions send puis une action receive; alors ce receive correspond à quel send!? de même si on fait plusieurs receive puis un send; alors à quel receive correspond le send? bien sûr on peut avoir des sends et des receives indépendants mais en général ce n'est pas le cas, on fait un send pour recevoir une réponse, et on attend la réception de quelque chose pour envoyer ensuite une autre)
-si je cherche des réponses à ces questions c'est parce que le diagramme d'états/transactions que j'essaye d'élaborer servira dans la génération automatique du code.

Merci

[bruno_pages]

Bonjour,

tout cela me parait turnabuleux

je ne sais pas si c'est à cause de votre outil, mais votre façon de définir des stéréotypes n'est pas conforme à la norme : stereotype n'est pas un stéréotype pour les dépendances et ne permet pas de définir des stéréotype.

Je suis septique concernant votre activité. Étendre accept event pour stoker le message me parait aussi bizarre qu'inutile car l'action d'origine est tout à fait suffisante pour spécifier quels évènements sont acceptés et fournir celui-ci ou leur attributs en sortie. De même pour l'extension de send signal, pourquoi ne pas avoir utiliser une action send object par exemple ?

Force est de constater que c'est pire pour la machine à états. Une machine à états comme la votre ne contenant qu'un état et une transition réflexive ne sert strictement à rien, cela n'a pas de sens, tout comme vos associations objet/état

[man56]

Bonjour

J’ai revu la spécification de l’OMG*; vous avez raison pour la façon d’écrire des stéréotypes alors j’ai rectifié au niveau de mes diagrammes et je vous remercie.

Mon travail rentre dans le cadre du MDA. Les parties de diagrammes que j’ai mis dans cette discussion sont tirées de mon méta-modèle PIM. Ce dernier comporte une partie structurelle avec des diagrammes de classes et une partie comportementale avec des diagrammes d’état/transition (appelé aussi StateMachine ou encore Statechart).

Les stéréotypes que j’ai rajoutés me servent pour projeter les concepts du PIM vers les concepts du PSM (lors du passage PIM vers PSM).

Les exemples donnés sont trop simples, car le but est d’expliquer le problème que je rencontre et qui est le suivant*:

Pourr générer le code à partir du diagramme d’état/transition, et à la rencontre d’une action de réception de message, j’ai besoin de savoir s’il ya eu un envoi de message (en relation) auparavant ou pas. Car si la réception ne correspond pas à un précédent envoi de message alors il s’agit d’une sollicitation d’une méthode locale que je dois rajouter dans ma classe réceptrice. Et si la réception correspond à un précédent envoi de message alors il s’agit d’une réponse et là je vais sur l’objet qui a servi pour l’envoi (par exemple priceRequest) et j’appelle sa méthode getReply (comme suit priceRequest.getReply(), la syntaxe varDenvoi.getReply() est une instruction offerte par la plateforme d’exécution que j’utilise, puisque je parle là de la génération de code).

Ma question est comment dans un diagramme d’état/transition je peux lier entre émission et réception de messages.

Est-ce que l’une des deux propositions suivantes est correcte (ou alors comment faire autrement*? est ce que UML2 propose une solution à ce problème).

1- Propsition 1
je pense que je vais l’abandonner car vous avez raison en me disant que je n’exploite pas ici le message déjà lié aux actions (SendSignalAction et AcceptEventAction). Est-ce que vous pouvez me donner un exemple concret avec l’une de ces actions*(SendSignalAction ou AcceptEventAction)?

======== image de prop1.jpg (en attachement)

2- Proposition 2
Avec cette deuxième proposition je peux continuer à exploiter le message déjà lié dans UML2 aux actions AcceptEventAction et SendSignalAction et je suis capable de savoir si pour une réception (respectivement une émission) j’ai eu une précédente émission (respectivement réception)

======= image de prop2.jpg (en attachement)

Finalement comme je dois générer du code à partir du diagramme d’état/transition, pouvez vous me donner un petit exemple concret sur comment modéliser une action comportant un argument (par exemple print(‘‘bonjour’’) et comment dans un diagramme d’état/transition je peux lier entre l’action (callBehaviorAction) et un autre digramme d’état/transition*?

Merci par avance

[bruno_pages]

Bonjour,

prop2 : comment allez-vous lier vos actions send/receive ? vous allez refaire le générateur de code des activités ? avec des multiplicités 0..1 vous ne gérer au plus qu'un message, êtes vous certains que ce sera toujours le cas ?

je ne pense pas que la solution soit dans l'utilisation de machine à états

comment modéliser une action comportant un argument (par exemple print(‘‘bonjour’’)

dans une machine à états si l'action est l'activité associée à une transition ou à l'entrée/sortie/exécution d'un état il suffit de donner print(‘‘bonjour’’) comme expression

dans une activité si vous utiliser une action d'appel d'une opération alors cette action à les pins d'entrée fournissant les arguments, et les pins de sortie produisant les résultats. Par exemple on a une classe ostream ayant l'opération print prenant une chaîne de caractères en argument (param s) et qu'on l'applique à l'instance cout (param target)

vous pouvez aussi avoir une action opaque dont le corps est print(‘‘bonjour’’)

comment dans un diagramme d’état/transition je peux lier entre l’action (callBehaviorAction) et un autre digramme d’état/transition*?

une machine à états et une activité sont des comportements (behavior), vous pouvez donc référencer l'un ou l'autre partout où vous avez un comportement, par exemple associé à une transition, où même comme étant le corps d'une opération. Dans une activité vous avez également les actions de type call behavior