Discussion :

[anaxagore2claxomene]

Salut la communauté,

Je suis en train d'apprendre la modélisation UML. À ce titre j'ai découvert le logiciel BoUML. J'ai rapidement survolé sa documentation et constaté que des 13 digrammes officiels de l'UML, BoUML en propose 9 à savoir: le diagramme de cas d'utilisation, le diagramme de séquence, le diagramme de collaboration, le diagramme des classes, le diagramme d'objets, le diagramme d'état-transition, le diagramme d'activité, le diagramme de composants et le diagramme de déploiement. Pour réaliser un TP, j'ai besoin de construire un diagramme de contexte et un diagramme de package. Est-il possible de le faire avec BoUML? Si oui, comment m'y prendre? J'ai mis en pièce jointe des exemples de ce que je veux faire.

Vos réponses me seront vraiment d'une grande utilité. Merci d'avance.

[bruno_pages]

Bonjour,

... des 13 digrammes officiels de l'UML, BoUML en propose 9 à savoir: le diagramme de cas d'utilisation, le diagramme de séquence, le diagramme de collaboration, le diagramme des classes, le diagramme d'objets, le diagramme d'état-transition, le diagramme d'activité, le diagramme de composants et le diagramme de déploiement. Pour réaliser un TP, j'ai besoin de construire un diagramme de contexte et un diagramme de package.

Le diagramme de contexte ne fait pas parti des 14 diagrammes de la norme (http://www.omg.org/spec/UML/2.5/PDF/") comme vous pouvez le voir page 683

Si vous faites ces deux diagrammes via des diagrammes de cas d'utilisation il vous suffit d'utiliser un "sujet" pour représenter "system", la seule différence avec vos diagrammes d'origine c'est que vous ne pouvez pas créer de relation entre les acteurs et le sujet ou les paquetages et vous devrez pour cela utiliser les ancres/anchor (lignes pointillées) ou des dépendances (flèches pointillées)

Si vous utiliser des diagrammes de classe, "system" devient une classe, "client" et autres pouvant soit être des classes "standard" ou des acteurs issus de vue de cas d'utilisation (un acteur est une classe stéréotypée "actor"), via les options de dessins demandez de cacher les propriétés/attributs et les opérations pour ne pas voir les séparateurs horizontaux. "system" étant une classe vous pouvez avoir des relations avec les autres classes/acteurs. Par contre il n'est toujours pas possible d'avoir une relation entre un paquetage et une classe et pour cela il faudra encore utiliser les ancres/anchors ou des dépendances (flèches pointillées)

Si vous voulez vraiment voir des relations au lieu des ancrages/anchors vous pouvez évidemment tricher en mettant sous le sujet/paquetages un cas d'utilisation dans le cas d'un diagramme de cas d'utilisation et une classe dans le cas d'un diagrammes de classe vers lesquels les relations vont, et en plaçant au dessus du cas d'utilisation bidon/ de la classes bidon votre sujet ou paquetage et en modifiant sa couleur pour qu'il ne soit pas transparent afin de cacher le subterfuge, mais bon ...

La seule chose qui manque dans Bouml pour avoir les deux diagrammes exactement comme il faut sans tricher c'est donc d'avoir une option de dessins demandant à dessiner une ancre/anchor ou une dépendance autrement que via leur représentation standard. Mais 1) le diagramme de contexte ne fait donc pas parti des diagrammes UML officiels, et 2) si vous regardez dans la norme vous verrez que dans un diagramme de package ne sont dessinés que des packages et que les relations entre eux sont des dépendances

[Ottakar]

Ah ah, je suis le même cours et la recherche d'un diagramme de package me fait tomber ici
Bref, j'ai fais deux diagrammes de cas d'utilisation et un diagramme de packages (avec un «subject» pour system comme suggéré). Le rendu graphique me convient et ressemble à ça.
Pièce jointe 379392

[bruno_pages]

Pièce jointe 379392

la pièce jointe n'est pas accessible

[Ottakar]

Ah? Pour moi c'est OK:
https://www.developpez.net/forums/at...hmentid=379392

[bruno_pages]

c'est sans doute ok pour vous parce qu'elle vient de vous, par contre dans mon cas :

[Ottakar]

On va y arriver!


Bon par contre mes diagrammes de package ont évolués vers un niveau plus haut, là je trouve que je m'approchai trop du diagramme d'activité.