Version imprimable
Bonjour,
Avec la norme UML, comment représenter les tâches (parallélisme) d'un système?
Par tâche, j'entends représentation vue d'un point de vue système d'exploitation (multi-tâche).
Il existe le diagramme des classes, mais une classe ou plutôt un objet n'est pas (obligatoirement) une tâche.
Merci
Bonjour,
un diagramme de classes montre le coté statique des choses et n'est en effet pas la bonne cible.
Les diagrammes dynamiques pouvant faire apparaître le parallélisme sont les diagrammes de séquence, de machine à états et d'activité. Cependant ces diagrammes indiquent seulement que les traitement peuvent se faire en //, pas qu'ils sont effectivement fait en //. De toute façon dans le cas d'un mono processeur il n'y a pas de 'vrai' parallélisme ;)
Pour indiquer un multi-processeur il faut passer aux diagrammes de déploiement, le hard n'existant pas avant (en dehors d'indication éventuelles sous forme de note ou autre commentaires)
Si c'est suivant le point vue d'un système d'exploitation alors ce sera très 'gros grain', on verra juste les tâches être créées, s'exécuter, disparaître, avec éventuellement des synchronisations entre elles. Il est pas exemple possible d'utiliser un diagramme de séquence utilisant une classe Tache instanciée autant de fois que nécessaire :
http://bouml.fr/taches.png
note : inutile de ne dire que cela ne se passe pas tout a fait comme cela en réalité, c'est juste pour illustrer :lol:
Dois-je en déduire qu'UML ne permet pas de réprésentation statique des tâches ?Citation:
un diagramme de classes montre le coté statique des choses et n'est en effet pas la bonne cible.
Pour les diagrammes dynamique, je connais un peu l'existence des diagrammes de séquence. Est-ce qu'il existe un moyen de differentier:
- l'émission d'un signal (gestion de queue, ...): dialogue inter-tâche
- l'appel d'une méthode d'un objet: pas de dialogue inter-tâche
c'est quoi la représentation statique des tâches ?Citation:
Envoyé par Bayard
en tout cas ce que je voulais dire c'est que que coté dynamique d'une exécution (début, perte du CPU au profit d'une autre etc ) n'est pas représentable dans un DC
à la limite le type du receveur devrait être suffisant pour savoir de quoi il s'agit. Si c'est une 'vraie' classe c'est un appel de méthode, si c'est une tâche c'est un signal. Il est aussi possible ajouter des informations supplémentaires dans le 'message' disant de qui il s'agitCitation:
Envoyé par Bayard
cependant le diagramme de séquence n'est sans doute pas le plus approprié, il serait préférable d'utiliser pour cela un diagramme d'activité dans lequel les signaux ont des représentations spécifiques. Par exemple, même si c'est très imagé :
http://bouml.fr/doc/figs/activity3.png
burnt chocolate est une action de type accept event, wait 4 hours en est une autre mais avec la représentation spécifique aux timers
Ben, le but est de définir ce que va fonctionner en parallèle. Il me parait important de définir cela dés la conception.Citation:
c'est quoi la représentation statique des tâches
Lorsque l'on définit les classes avec le diagramme des classes, n'est pas possible de spécifier si c'est une tâche ou non ?
Sinon, comment fonctionne un générateur de code ? Tout est déclaré dans des classe et il n'y a aucun lien avec un schéduleur ?
Lorsqu'on défini des classes, un générateur de code produira une classe (ou struct, enum ...), mais rien qui ressemble à une tâche ou qui est un lien avec un schéduleur, et c'est normal.
Par contre le code des opérations puis lui faire des fork au autre, mais cela c'est de ta responsabilité, sauf peut être via des activités et machines à état, mais là c'est très dépendant du générateur
OK