Discussion :

[Lyna77]

Bonjour à tous

Je n'ai pas une grande expérience dans l'utilisation d'UML.
Je suis une novice .
J'aurais simplement une question sur l'utilisation des stéréotypes d'UML. Je n'ai pas vraiment compris comment on peut stéréotyper les composants d'UML.

Ma question est la suivante.

J'aimerais utiliser le diagramme d'activité d'UML pour modéliser des workflows mais voilà: J'aimerais introduire un composant qui traduit l’exécution récursive d'un ensemble d'actions (activité). En gros j'aimerais introduire un composant qui est la sémantique du pattern "recursion" dont le comportement est expliqué dans ce lien : http://www.workflowpatterns.com/patt.../new/wcp22.php

Est ce que proposer un tel composant est possible sans faire n'importe quoi au méta model d'UML?

Merci de votre aide

[bruno_pages]

Bonjour,

Je ne pense pas qu'il soit nécessaire de faire une spécialisation d'UML via des stéréotypes pour faire cela.
Rien empêche une activité de se rappeler en d'en appeler d'autres.
Sinon, l'utilisation d'une expansion region parallèle (ou même itérative / stream) ne serait-elle pas suffisante ?

[Lyna77]

Bonjour

Merci pour cette réponse.
Mais je ne comprend toujours pas
J'avoue que je ne voit pas comment est ce qu'on peut modéliser dans le diagramme d'activité d'UML des appels recursifs d'une activité (ou encore une région) vers elle même ou vers une autre actvité l'englobant (ou région l'englobant). J'aimerais utiliser cette constrcution. Il est vrai que toute récursion peut être éxprimée par une boucle mais je suis curieuse de voir comment exprimer le principe de récursion sans faire appel à une boucle pour la décrire. D'après le même lien http://www.workflowpatterns.com/patt.../new/wcp22.php
les auteurs sitent qu'en UML il n'est pas possible d'exprimer la composition récursive dans un model de processus. J'aimeraissavoir si il est possible de créer un stéréotype permettant de décrire cette composition récursive d'une activité (ou région)

Merci encore pour votre aide

[bruno_pages]

L'action call behavior permet d'appeler une activité, ou autre behavior.

Par exemple fact(n) := (n <= 1) ? 1 : n*fact(n-1) serait la chose suivante (j'avoue ne pas être certain de la validité de la chose ) :


Une expansion region permet d'effectuer les traitements qu'elle contient pour chaque entrée, et ce de façon itérative (cas ci dessous, essayez donc de casser des œufs pour séparer blanc et jaune en même temps avec un œuf par main !) ou parallèle :

[Lyna77]

Merci Bruno pour ton aide. Je continue à travailler dessus

ps: L'exemple est vraiment drôle

[bruno_pages]

L'exemple sur la mousse au chocolat fait parti des exemples de copies d'écran que je présente sur http://bouml.fr/screenshots.html
C'est une adaptation d'un exemple de diagramme d'activité que j'avais trouvé sur le net. En dehors du fait qu'il est parlant il a le grand avantage de présenter un large échantillonnage des notations possibles dans un diagramme d'activité. A consommer sans modération donc

Je pense donc que la spécialisation d'UML via des stéréotypes n'est pas nécessaire dans le cas présent, mais peut être que je simplifie trop les choses, il faudrait qu'un vrai spécialiste d'UML (ego, Hephaistos007 ...) passe pas là

[Lyna77]

Bonjour,

Merci encore pour toutes ces informations Bruno ainsi que pour le lien.

J'aurais encore une question qui reste dans le même esprit.

En fait en étudiant le lien http://www.workflowpatterns.com/patterns/control/
où les auteurs montrent les avantages et inconvénients du diagramme d'activité d'UML pour la représentation des processus workflows, j'ai voulut savoir s'il était possible de proposer des stéréotypes qui permettent de modéliser ces comportements qui ne peuvent pas être représentés avec les composants standard d'UML (diagramme d'activité d'UML) ou bien est ce que ceci nécessite une révision d'UML 2.0 par les spécialistes et ainsi proposer une version plus élaborée.

exp: pouvoir modéliser la synchronisation de plusieurs instances d'un sous processus tout en sachant que le nombre d'instance (de ce sous processus) n'est pas connu avant le début de l'exécution du processus principale et que à tout moment il est possible d'ajouter une nouvelle instance lorsque d'autres instances sont déjà en cours d'exécution (ce qui est connu comme le pattern MI without a priori Runtime Knowledge)

[bruno_pages]

il ne faut pas chercher à tout représenter dans le détail via des diagrammes d'activité, d'abord parce qu'il y en a d'autres, et ensuite parce que cela devient rapidement illisible et peu adapté. L'exemple de factorielle via un diagramme d'activité est un exemple de ce qu'il ne faut pas faire en réalité (j'avais juste voulut imager le call behavior de l'activité elle même) car il s'agit d'algorithmique pure ... et en plus on ne calcule pas factorielle avec une fonction récursive !.

Modéliser la synchronisation de plusieurs instances d'un sous processus peut très bien se faire via une opération synchronizeSubProcesses définie sur la classe SynchronizableProcess dont hériteraient tes processus, et en montrant au pire la chose dans un diagramme de classes, en mieux de collaboration (où on voit plusieurs instances) et en nettement mieux dans un diagramme de séquence permettant d'ajouter des informations sur la dynamique de l'exécution.

Il ne faut pas se figer un un type de diagramme, et ne pas chercher a tout montrer via un seul diagramme, et une modélisation peut aussi comporter un texte explicatif

[Lyna77]

Merci pour ces infos !

[Alec6]

Pour tout ce qui est Workflow et process il est interessant de regarder du coté des BPML.