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

[man56]

Merci pour votre réponse

1- Par exemple si dans un digramme d’état/transition (first StateMachine) on a comme effect d’une transition une action callBehaviorAction qui lance un autre diagramme d’état/transition (second StateMachine), est ce que graphiquement je lie l’action callBehaviorAction à l’état initial de second StateMachine (dans le cas échéant, avec quoi je les lis ? avec une flèche, une ligne, …, ligne remplie ou en pointillée) ou alors je précise le diagramme d’états/transitions cible entre parenthèse de l’action callBehaviorAction, comme suit callBahaviorAction (secondStateMachine) ?

====================stateMachine.jpg


2- vous avez dit « 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 »

Et si on veut passer comme argument à l’action des champs complexes autre que chaine de caractères ; par exemple, des variables de type vecteur, des objets, un message par exemple ? je parle tjrs des actions dans un diagramme d’état/transition.

3- je crois que le problème que j’avais vient du fait que j’utilise un outil qui supporte UML alors que mon méta-modèle n’est pas UML. En effet, ce que j’ai proposé dans les images prop1.jpg et prop2.jpg et dans toute cette discussion avant ne sont pas de l’UML mais sont des parties de mon méta-modèle en cours d’élaboration et ce n’est pas UML.

Pour rappel, je redonne prop1.jpg et prop2.jpg (qui sont semblables à la différence du rajout d’une classe stéréotypée « message » dans prop1.jpg). Pour les cardinalités affichés, j’espère arriver comme ça à régler le problème de liaison entre les send et receive : 1..1 veut dire qu’une action sendMessage (respectivement receiveMessage) a exactement un seul message à envoyer (respectivement à recevoir) et 0..1 veut dire qu’une action sendMessage (respectivement receiveMessage) peut avoir ou non une précédente action receiveMessage (respectivement sendMessage) correspondante.

D’après votre expérience laquelle des deux est plus crédible ?

Proposition1

Les cardinalités indique que SendMessage a un message à envoyer et peut correspondre ou non à un message déjà reçu. De même Receive message a un message à recevoir et peut correspondre ou non à un message déjà envoyé.

============ prop1.jpg


Proposition2

• En supposant que j’exploite le message lié à SendSignalAction ou AcceptEventAction

============= prop2.jpg

• Ou bien je rajoute mon propre message et j’ignore le message lié à SendSignalAction et AcceptEventAction

============= prop2Amenagee.jpg

4- Est ce que vous avez un petit exemple concret montrant une transition dont le guard ou l’effect est une action SendSignalAction ou AcceptEventAction et cette action est reliée à l’objet message envoyé ou reçu?

Finalement mon choix du diagramme d’état/transition pour représenter les comportements découle du fait qu’on sait traduire les automates d’état fini en code exécutable, ce qui me facilitera la phase de génération du code.

[bruno_pages]

Bonjour,

1- Par exemple si dans un diagramme d’état/transition (first StateMachine) on a comme effect d’une transition une action callBehaviorAction qui lance un autre diagramme d’état/transition (second StateMachine)

callBehaviorAction est un type d'action, vous n'aurez pas directement cela dans votre transition car une action n'est pas un comportement, vous aurez quelque chose d'autre appelant la machine à état et dépendant du ype d'expression utilisé (langage naturel ou code dans votre langage cible)

.. est ce que graphiquement je lie l’action callBehaviorAction à l’état initial de second StateMachine

non, cela n'a pas de sens

... ou alors je précise le diagramme d’états/transitions cible entre parenthèse de l’action callBehaviorAction, comme suit callBahaviorAction (secondStateMachine) ?

déjà ce qui compte c'est la machine à état et non un éventuel diagramme

un diagramme ne fait que montrer sous forme graphique une partie du modèle

de même il y a une grande différence entre vous et une photo de vous

Et si on veut passer comme argument à l’action des champs complexes

encore une fois tout dépend de ce que vous mettez dans vos expressions (langage naturel ou non), mais dans le cas de variable il suffit d'utiliser leur noms

ceci dit il n'est pas nécessaire de tout montrer dans le diagramme, si vous le faites cela risque de devenir illisible car il y aura trop d'informations

au niveau affichage dans un diagramme vous pouvez non pas afficher le 'vrai' code mais un résumé textuel indiquant de quoi il s'agit

encore une fois un diagramme n'est qu'un zoom montrant certaiens informations, un diagramme doit rester lisible, toutes les informations présentent dans le modèle ne sont pas affichées, un modèle n'est pas qu'une suite de diagrammes

j’espère arriver comme ça à régler le problème de liaison entre les send et receive

très franchement vous êtes en train de faire une usine à gaz, vous n'utiliser pas cette solution parce que c'est une solution à votre problème mais à l'inverse vous semblez chercher un cas qui utiliserait cette solution

une appli c'est d'abord du code, et certaines chose se résolvent avec du code 'invisible' au niveau modélisation à moins de faire l'équivalent via une activité qui risque d'être très complexe pour rien

Est ce que vous avez un petit exemple concret montrant une transition dont le guard ou l’effect est une action SendSignalAction ou AcceptEventAction et cette action est reliée à l’objet message envoyé ou reçu?

comme je l'ai dis au début de ma réponse cela n'a pas de sens

vous n'avez pas besoin de modifier le méta modèle pour mémoriser des informations, les expressions des gardes/actions/états exécutent du code qui fait ce qu'il veut (sauf contraintes de non modification sur les gardes par exemple). La façon de mettre cela en pratique va par contre dépendre des capacités du modeleur utilisé, dans Bouml le générateur de machines à états produit des classes les implémentant et l'utilisateur peut modifier ces classes pour ajouter les membres souhaités.

Finalement mon choix du diagramme d’état/transition pour représenter les comportements découle du fait qu’on sait traduire les automates d’état fini en code exécutable, ce qui me facilitera la phase de génération du code.

certes, mais si pour cela il faut monter une usine à gaz alors ce n'est pas la solution

[man56]

Bonsoir Bruno

Je reviens à vous pour vérifier si je modélise les stateMachines.
Je cherche à modéliser le comportement de deux agents (processus) : Supplier qui délivre le prix d’un article (on considère qu’il y a un seul article) et MobileCustomer qui demande ce prix.

1- J’ai vérifié dans la spécification d’UML concernant SendSignalAction et AcceptEventAction mais je n’ai pas trouvé comment lier une action send (repectivement réceive) à une précédente action receive (repectivement send) ; voir la figure SignalAction.jpg tirée de la page 245 d’UML2.3 superstructure).
Alors j’ai rajouté deux actions SendMessage et ReceiveMessage qui héritent respectivement de SendSignalAction et AcceptEventAction et je les ai lié entre elles pour connaitre s’il y a une action précédente ou pas (voir la figure SendAndReceiveMsg.jpg).

2- est ce que la modélisation (StateMachine) dans les figures PriceDelivering.jpg et waitingForGettingPrice.jpg est conforme (correcte), sinon comment la rendre conforme ?
Est-ce qu’on peut mettre n’importe quelle classe comme InputPin ou OutputPin d’une action ? sinon comment faire pour qu’on puisse lier une classe à une action SendSignalAction ou AcceptEventAction, comme étant argument, result ou target?

Merci Par avance

[man56]

Bonjour Bruno

Je reviens à vous pour vérifier si je modélise les stateMachines.
Je cherche à modéliser le comportement de deux agents (processus) : Supplier qui délivre le prix d’un article (on considère qu’il y a un seul article) et Customer qui demande ce prix.

1- J’ai vérifié dans la spécification d’UML concernant SendSignalAction et AcceptEventAction mais je n’ai pas trouvé comment lier une action send (repectivement réceive) à une précédente action receive (repectivement send) ; voir la figure SignalAction.jpg tirée de la page 245 d’UML2.3 superstructure.
Alors j’ai rajouté deux actions SendMessage et ReceiveMessage qui héritent respectivement de SendSignalAction et AcceptEventAction et je les ai lié entre elles pour connaitre s’il y a une action précédente ou pas (voir la figure SendAndReceiveMsg.jpg).

2- Est ce que la modélisation (par StateMachine) dans les figures PriceDelivering.jpg et waitingForGettingPrice.jpg est conforme (correcte), sinon comment la rendre conforme ?
PriceDelivering.jpg concerne le comportement de l’agent Supplier, qui reçoit le signal GetPriceSignal ayant comme résultat l’identifiant du sender (l’agent Customer) vers lequel il renvoi le signal PriceSignal ayant comme argument (price de type réel).
waitingForGettingPrice.jpg concerne le comportement de l’agent Customer, qui commence par envoyer le signal GetPriceSignal avec comme argument son identité vers l’agent Supplier. Attends ensuite la réception du prix (price) de l’agent supplier puis l’affiche.

3- Est-ce qu’on peut mettre n’importe quelle classe comme InputPin ou OutputPin d’une action ? sinon comment faire pour qu’on puisse lier une classe à une action SendSignalAction ou AcceptEventAction, comme étant un argument, un result ou un target?

Merci Par avance