Version imprimable
Bonjour,
je travaille sur un sujet de gestion de projet selon le PMBOK, et j'ai établi un diagramme de cas d'utilisation tres grand et si compliqué, et je voudrai savoir comment passer au diagramme de classe et si c'est vraiment l'étape qui suit le use case.
je suis nouvelle parmi vous ;)
Normalement, après les CU, on passe aux diagrammes de séquence...
Ensuite, on réfléchit en fonction de ces spécifications à la manière dont on va concevoir l'application et donc au diagramme de classe proprement dit.
Merci.
et pour le diagramme de classe, est ce qu'on peut mettre autant de relations d'héritage qu'on veut sans crainte de problème apres?
bonjour,
j'ai toujours des problèmes à ce niveau, certains disent qu'il y a une certaine indépendance entre les diagrammes UML d'autres disent non 8O ... après dans les livres UML j'ai remarqué que le diagramme des classes est toujours défini juste après les UC :roll: ... donc je me demande est ce qu'il y a une méthologie pour la définition des diagrammes UML (ordre, dépendances, ...)
merci
Il y a une discussion a ce sujet: http://developpez.net/forums/showthread.php?t=320077
Apparement chacun voit la succession des diagrammes differemment des autres. mais je voudrai savoir s'il y a une méthode standard qui aboutit à une bonne conception UML.
non, il n'y a pas de méthode standard aboutissant forcément à une bonne modélisation, ce serait trop simple ;)
comme tu peux le voir dans la discussion citée par Nip il n'y a pas UNE façon de faire. La seule certitude c'est qu'il faut d'abord se demander 'quoi' (use cases) avant de se demander 'comment'.
Pour le reste cela dépend du problème à résoudre, on ne fait pas un schéma de base de données comme on fait un compilateur.
Cela dépend aussi énormement des personnes, certains de clarifient plus facilement les idées en partant des données pour aboutir aux comportement, d'autres c'est l'inverse. L'ordre de creation des diagrammes est donc variable, il est donc sans reelle importance et de plus on rafine generalement au fur et a mesure, on ne fait pas les diagrammes de facon sequentielle sans jamais revenir sur ceux fait préalablement
En réalité, UML est un langage, et non une méthode. De ce fait, il te faut choisir une méthode avec laquelle tu vas utiliser UML. Personnellement je te conseille de chercher "Rationnal Unified Process" ou "Processus rationnel unifié" (le mot rationnel étant parfois omis)
Sinon je te conseille brièvement cette démarche :
use case simple
use case détaillé (ajout de texte explicitant toutes les étapes des scénarii possibles)
diagramme de séquence système (2 entités : acteur et système)
puis tu commence à découper ton diagramme de séquence en métant une vue, un controller, un gestionnaire de données
enfin tu pars sur un diagramme de classes. Puis, comme tu auras de toutes manière des problèmes, tu va "cycler" en revenant à la première étape.
Si tu as la moindre question...
UP : processus unifie, terme general.
RUP : version Rational (IBM maintenant) d'UP
2TUP : le cycle en Y
de plus haut niveau :
USDP : unified software development process, des 3 qui ont fait UML (apres le langage, la methode), peu connu, mais une reference.
cf librairies (ou google) "processus unifie de developpement logiciel"
http://en.wikipedia.org/wiki/Unified...opment_Process
http://en.wikipedia.org/wiki/Rational_Unified_Process
http://fr.wikipedia.org/wiki/2TUP
ils sont tous (USDP) :
- guides par les UC (le fil conducteur, equivalent 'user stories' de XP),
- centres sur l'architecture,
- iteratifs et incrementals,
- orientes vers la reduction des risques.
Avec en plus (RUP, 2TUP) :
- integration continue,
- gestion du changement,
- approche par composants.
Alex.