Discussion :

[fisherman]

Bonjour,
je réalise un outil de génération de code exécutable à partir de diagrammes d'activités UML2 (plateforme eclipse)
Et j'ai une question !

sur l'image que je viens d'insérer on peut voir 5 actions
Sémantiquement on doit pouvoir comprendre que opaque_action_1 s'exécute 2 fois une première fois quand opaque_action_0 et opaque_action_2 se soient exécutées (implicit fork dixit la norme UML2) et une deuxième fois une fois que l'action 4 se soit exécuté.
Mon problème est le suivant je ne sais pas comment faire pour différencier mes deux cas. Et j'ai rien trouvé dans la norme qui le mentionne . Je pourrai stipuler a l'utilisateur de toujours utiliser des join node mais cette solution ne me plait pas . Si vous savez quelle information dans le métamodel me permettrait de savoir qu'une activité doit se reproduire et comment différencier des transitions je suis preneur

[bruno_pages]

Bonjour,

attention : implicit fork concerne les sorties d'une action. Cela veut dire que si par exemple on a deux sorties et que chacune 'aille' dans une action différente, ces deux actions peuvent se faire en parallele (sauf s'il y a d'autres contraintes invalidant la chose bien-sûr)

il n'y a donc pas de rapport entre le concept d'implicit fork et le fait que les opaques actions 0 et 2 'aillent' dans l'opaque action 1, ce que tu laisses entendre. En plus ce serait un join et non un fork

Sinon ton schéma est invalide : il manque un point d'entrée, qui peut être l'acceptation d'un signal, l'utilisation d'un paramètre de l'activité ou un initial node

Mon problème est le suivant je ne sais pas comment faire pour différencier mes deux cas.

il faut ajouter une entrée suplémentaire à ton opaque action

Je pourrai stipuler a l'utilisateur de toujours utiliser des join node mais cette solution ne me plait pas

je ne comprends pas, quel est le vrai but ?

Si vous savez quelle information dans le métamodel me permettrait de savoir qu'une activité doit se reproduire

drôle de question, une activité s'exécute lorsque toutes ses entrées sont présentes

[fisherman]

Bonjour et merci de votre réponse
et désolé de m'avoir mal exprimé
en effet la norme stipule implict join et fork pour les entrées et sorties.

Pour mon diagramme je n'ai mis qu'une partie qui m'intéresse il étati évident qu'il manquait un point d'entrée

quand à mon problème

Citation:
Envoyé par fisherman Voir le message
Si vous savez quelle information dans le métamodel me permettrait de savoir qu'une activité doit se reproduire
drôle de question, une activité s'exécute lorsque toutes ses entrées sont présentes

c'est exactement mon problème dans l'exemple de mon image OpaqueAction1 ne doit s'exécuter une fois que toutes ses entrées sont présentes. Mais ce n'est pas ce que je veux représenter. Puisque OpaqueAction1 ne doit pas dépendre de OpaqueAction4

En gros la sémantique que je comprends de mon schéma et que je voudrais déduire du modèle de manière formelle
...
=> Execution Action0 et Action2 en parallele
=> attente des action precedentes puis execution action 1
=> execution action 3
=> execution action 4
=> enfin reexecution action 1
...

[bruno_pages]

ah ok, et bien il faut effectivement mettre un 'join' en sortie de OP0 et OP1 pour avoir ce que tu veux, le join est justement là pour cela, pourquoi cela ne te plait pas ?

[bruno_pages]

au fait, tu ne pourrais pas utiliser autre chose pour publier tes images ? les fenetres popup de pub qui saute à la figure c'est pas terrible pour les relecteurs

pour info : tu peux télécharger des images sur DVP ... jusqu'a une certaine limite

[fisherman]

ah ok, et bien il faut effectivement mettre un 'join' en sortie de OP0 et OP1 pour avoir ce que tu veux, le join est justement là pour cela, pourquoi cela ne te plait pas ?

d'abord désolé pour les popup quand j'ai uploadé je croyais que picfront c'etait bien

le probleme est que je voudrais savoir comment différencier des inputs. Car meme en mettant des joins la sémantique que je connais actuellement d'UML2 est :
Une action ne s'exécute qu'une fois les actions précédentes exécutées or OpaqueAction4 ne s'exécutera jamais avant OpaqueAction1 et je voudrai savoir si la norme comprend des références concernant des transitions qui pourraient "relancer" des activités

[bruno_pages]

attention, dans les activités on ne parle pas de transition mais de flux (de donnée ou de contrôle), et ce n'est vraiment pas la même chose.

OpaqueAction4 ne s'exécutera jamais avant OpaqueAction1

ben oui, sinon il ne fallait pas mettre ces flux

je voudrai savoir si la norme comprend des références concernant des transitions qui pourraient "relancer" des activités

que veux-tu dire par là ?
c'est une question portant sur la manipulation d'une activité (par exemple pour produire du code) ou quelque chose qui doit se faire à l'exécution du code issus de l'activité ?

je suis désolé, mais j'ai vraiment du mal à te comprendre

[fisherman]

Bon désolé je crois qu'on s'embourbe pour pas grand chose je vais reformuler ma question

sur une action n flots de control peuvent etre en input
la norme spécifie que l'action est en implicit join sur toutes ses entrées donc qu'elle ne peut démarre que dans le cas ou toutes ses entrées se sont consumées
or comment eviter le blocage de mon diagramme ou une action attend une autre action qui doit s'exécuter apres ? Y a t'il une autre facon de le représenter ?

j'espere etre plus clair

[bruno_pages]

ok, cette fois je crois que j'ai compris : le but est de faire OP1 par exemple après OP0 sans avoir fait OP2 etOP4, ou après OP2 sans avoir fait OP1 ou OP4 etc ...

Il y a plusieurs solutions :

• remplacer les branchements directs vers les opaques actions par des actions de type 'call'. D'une certaine façon une opaque action c'est directement du code, une action call c'est un appel fonctionnel
• utiliser une pin unique (de contrôle ou de donnée) d'entrée sur OP1 sur laquelle se branchent les flux issus de OP0, OP2 et OP4 (sans join)

[fisherman]

ok pour les réponses je vais voir du coté des call action mais je crois que pour les pins le join est aussi implicit d'ou l'utilisation possible de pin set
enfin je savais pas qu'il y avait des pins de controle je vais regarder ca

[bruno_pages]

non non, si tu branches tout sur une unique pin il n'y a pas de joins des flux associés.

Sinon tu peux effectivement mettre 3 pins d'entrée sur OP1 chacune dans un parameter set propre, mais je n'ai pas proposé cela car il faudra alors que OP1 traite la chose