Discussion :

[sara21]

Bonjour,
mon projet est une application web d'une gestion collaborative...
le principe est :
- On a 3 acteurs (Admin, Chef du Projet, Consultant)

->Admin :
- créer des nouveux projets
- définir le chef du projet (qui est un acteur)
- désigner les consultants (qui est un acteur)
- définir les missions de chaque projet
- définir les livrables (Rapports) de chaque mission

-> Chef du Projet :
- désigner les consultants (qui est un acteur)
- définir les missions du projet
- définir les livrables (Rapports) du mission
- définir le contenu du rapport (définir le sommaire du rapport et désigner les consultants qui ont le droit de modification dans chaque partie)
- Valider la version du rapport
- Régénérer le rapport ( exportation en format pdf, doc,...)

-> Consultant:
- Consulter les parties du rapport
- Modifier les parties du rapport aux quelles il a droit
- Mettre des remarques dans une partie du rapport

-> le chef du projet peut faire les fonctions du consulatnts et l'admin peut aussi faire les fonctions du chef de projet.

Voila mon diagramme et je suis presque sûre qu'il est invalide vous pourrez le corriger avec moi et me donner vos suggestions



et Merci les gas pour tout l'aide que vous m'apporter sur ce forum

[bruno_pages]

bonsoir,

si on s'en tient strictement a ce que tu donnes comme role à chaque acteur, il n'y a pas d'héritage Admin ---|> Chef du Projet ---|> Consultant car le consultant fait des choses que ne fait pas le chef de projet, qui lui meme fait des choses que ne fait pas l'administrateur, même si l'intersection est effectivement non nulle. Mais peut être que je lis trop strictement le rôle de chacun

il faut que tu vérifies les includes entre UCs, par exemple definir les consultants ne peut inclure creer projet car seul l'admin peut creer un projet mais definir les consultants peut être fait par un chef de projet. Il ne faut pas confondre pré-requis (le projet a été crée) et UC, par contre un UC peut évidemment avoir des pre-requis et il est bien de les indiquer dans sa description.

Tu aurais peut etre pu utiliser des extends, par exemple entre Consulter les parties du rapport et Mettre des remarques dans une partie du rapport, car la consultation peut aboutir à l'ajout de remarques (mais pas obligatoirement, donc ce n'est pas un include). Attention au sens de l'extend, comme je le disais hier (ce qui m'a rafraichis la mémoire ) quand UCA - - -extend - - -> UCB alors UCA peut être fait lorsque UCB l'est), extend est une sorte d'include non obligatoire et dessiné a l'envers

[sara21]

Bonsoir,
merci bruno pour ta réponse même si j'ai pas tout compris mais j'ai essayé de corriger un peu mon diagramme

-> si par exemple je met tous les rôles comme suit :

-> Consultant:
- Consulter les parties du rapport
- Modifier les parties du rapport aux quelles il a droit
- Mettre des remarques dans une partie du rapport

-> Chef du Projet :
- désigner les consultants (qui est un acteur)
- définir les missions du projet
- définir les livrables (Rapports) du mission
- définir le contenu du rapport (définir le sommaire du rapport et désigner les consultants qui ont le droit de modification dans chaque partie)
- Valider la version du rapport
- Régénérer le rapport ( exportation en format pdf, doc,...)
- Consulter les parties du rapport
- Modifier les parties du rapport
- Mettre des remarques dans une partie du rapport

->Admin :
- créer des nouveux projets
- définir le chef du projet (qui est un acteur)
- désigner les consultants (qui est un acteur)
- définir les missions de chaque projet
- définir les livrables (Rapports) de chaque mission

Question : l'admin doit définir le chef du projet qui est un acteur, est-ce qu'on devrez créer un UC "définir le chef du projet" ou bien mettre une liaison entre l'acteur "Admin" et l'acteur "Chef de projet" ?

[bruno_pages]

l'admin doit définir le chef du projet qui est un acteur, est-ce qu'on devrez créer un UC "définir le chef du projet" ou bien mettre une liaison entre l'acteur "Admin" et l'acteur "Chef de projet" ?

mettre un UC, la seule liaison possible entre acteurs dans un diagramme d'UC est l'héritage

sinon coté forme : à partir du moment ou il n'y a plus de point commun entre la partie associée à admin et le reste, je te conseille de séparer ton diagramme en deux : un diagramme d'UC doit être simple

remarque : je te conseille la lecture de ce très bon tutoriel sur UML
et donc en particulier la chapitre sur les UCs

[Nip]

Comme l'a dit Bruno, un diagramme d'UC doit rester simple; ici tu multiplies les includes et du decomposes trop tes UCs; par ailleurs certains sont incomprehensibles comme "regenerer les rapports" alors que tu n'as pas de gestion de rapport!
Les includes se croisent et recroisent, je ne comprends plus qui est dependant de qui ou pas; tu crees un projet quand tu es admin mais t'as pas de moyen de les lister, modifier, supprimer (un UC gerer les projets peut etre utile dans ce cas)...
Regardes aussi le tuto d'ego a ce sujet: http://ego.developpez.com/uml/tutoriel/casUtilisation/

Citation du jour: les UC ca parait simple mais ca l'est pas

[sara21]

Bonsoir,
merci bruno et Nip pour votre aide et vos réponses.
aprés lecture des cours de vos liens et quelques cours sur le web sincerment j'ai toujours du mal a comprendre la réalisation de ce diagramme mais j'ai essayée comme même et voila ma dérniére modification et j'espére bien la finir avant la fin de ce week-end

Partie Admin :



Partie Consultant et chef du projet :



le chef de projet peut modifier les consultants d'un projet, est-ce que je dois ajouter un UC "Modifier les consultants" ? et si le cas est-ce que je dois la réalisée par une simle relation d’association entre l'acteur "Chef Projet" et le UC "Modifier les consultants" ?

merci les gas je sais que je demande trop

[bassim]

je te propose pour te donner une idée un fichier qui contient la spécification fonctionnelle de mon projet, il contient entre autres le diagramme des cas d'utilisation et une description détaillée de chaque cas .

[sara21]

Bonjour,
merci bassim et je crois que ton fichier va me servir prochenement.
Mais je vous demande tous les gas, est-ce que mes 2 derniers diagrammes contient des erreurs ?

[bruno_pages]

bonjour,

je nous le disions Nip et moi, tes diagrammes sont trop complexes : il ne faut surtout pas confondre Uc et design, le design doit par définition prendre en compte tous les cas dans le détail (sinon qui le ferai !), pas les UCs, attention donc à ne pas penser implementation quand tu fais tes UCs, ce qui est un piège classique.

Si tu veux cependant donner des détails dans les UCs, ne donne pas tous dans le meme diagrammes : fait des UCs globaux qui auront leur diagrammes propre, par exemple comme le dit Nip un UC gerer les projets. Tu te retrouveras donc avec un premier diagramme contenant des UCs généraux, ceux-ci étant détaillés si besoin dans d'autres diagrammes

regards les remarques faites sur avis sur mes diagrammes de cas d'utilisation

[pigeon11]

J'ai établit mes diagrammes uml (des cas d'utilisation, de sequence, d'états

transition, de classe)

mais je ne sais pas quels sont les diagrammes que je dois mettre dans

la phase d'analyse et ceux que je dois metre dans la phase de conception ?

La seule chose que je sais c'est que les usecase font partie de la phase

d'analyse et le diagramme de classes fait partie de la phase de conception.

Merci pour votre aide

[firaponte]

J'ai établit mes diagrammes uml (des cas d'utilisation, de sequence, d'états

transition, de classe)

mais je ne sais pas quels sont les diagrammes que je dois mettre dans

la phase d'analyse et ceux que je dois metre dans la phase de conception ?

Je suis ok pour les use case, les utilisateurs du forum le répètent souvent ça sert à l'analyse du besoin
Pour moi diagrammes de classe c'est dans la conception, tu commences déjà à "imaginer" ton programme et tu ne te contente plus d'analyser ce qu'on te demande de faire, tu cherches déjà une solution.
D'après le bouquin UML2 en action: "Les diagramme de séquence servent à développer en analyse les scénarios d'utilisation du système" du coup ils se "classent" dans la phase analyse
Par contre le diagramme d'états/transition permet de concevoir des méthodes (toujours d'apres le livre) du coup dans la conception

Mais ensuite, toujours dans le même livre, ils découpent la modelisation uml suivant les 3 activités principales: capture des besoins, analyse, conception.
Et on retrouve dans chaque phase chaque type de diagramme. Du coup je pense que en fait il n'y a pas (a part pour les cas d'utilisation) de phase dediée à un type de diagramme . Ca dépend du niveau de modelisation ou tu te trouves et de la granularité employée.

Mais bon, je peux me tromper mais j'espere t'avoir aidé un peu quand même.