Discussion :

[ze_corsaire]

Bonjour, je suis désolé si je vous écrit un message privée mais je suis obligée je n'ai plus le temps et je dois accéléré.

Les messages privés c'est pas bien !

Tu m'a vraiment aidé dans le sujet de gestion de projet mais je trouve un problème pour imaginer les méthodes en faite parfois une méthode me parait utile dans deux classes....
Comment peut on identifier les méthodes d'une classe?

Pour t'aider, il me semble plus simple que tu postes tes diagrammes.
Les méthodes dépendent du rôle que tu décides de donner à l'objet considéré(désolé de rester vague, tu pourras trouver de la doc plus précise en cherchant GRASP).
Dans la pratique, je définis en paralèlle un diagramme de séquence à un diagramme de classe. La mise en place de scenarii facilite la détermination des rôles de chaque classe et vice-versa.

Autre chose dans mon diagramme de classe le projet dépend du commercial et du chef de projet c a d le commercial crée un nouveau projet et l'affecte à un chef j'ai pu modéliser ce problème même quand j'ai fait une classe associative ?
Vous pouvez m'aidez ?

Désolé, je n'ai pas saisi la question

_______________

[hed62]

Les messages privés c'est pas bien !

C'est bien sinon le boutons n'existerai pas Mais effectivement, pas dans cet objectif.

Pour t'aider, il me semble plus simple que tu postes tes diagrammes.

Encore une fois, cette façon de faire est la plus rapide.

je définis en paralèlle un diagramme de séquence à un diagramme de classe

Ca permet de dégager certaines méthodes.
Ensuite, si une méthode peut aller dasn plusieurs classes, et que cela se justifie, penses aux interfaces.

D'autres méthodes peuvent être intrinsèques (et/ou privées). C'est le cas de méthodes outils (qui n'apparaissent pas forcément sur le DC)

Enfin, comme déjà dit, il faut bien délimiter les responsabilité des classes,

[hed62]

Les messages privés c'est pas bien !

C'est bien sinon le boutons n'existerai pas Mais effectivement, pas dans cet objectif.

Pour t'aider, il me semble plus simple que tu postes tes diagrammes.

Encore une fois, cette façon de faire est la plus rapide.

je définis en paralèlle un diagramme de séquence à un diagramme de classe

Ca permet de dégager certaines méthodes.
Ensuite, si une méthode peut aller dasn plusieurs classes, et que cela se justifie, penses aux interfaces.

D'autres méthodes peuvent être intrinsèques (et/ou privées). C'est le cas de méthodes outils (qui n'apparaissent pas forcément sur le DC)

Enfin, comme déjà dit, il faut bien délimiter les responsabilité des classes, avec

[hed62]

Les messages privés c'est pas bien !

C'est bien sinon le boutons n'existerai pas Mais effectivement, pas dans cet objectif.

Pour t'aider, il me semble plus simple que tu postes tes diagrammes.

Encore une fois, cette façon de faire est la plus rapide.

je définis en paralèlle un diagramme de séquence à un diagramme de classe

Ca permet de dégager certaines méthodes.
Ensuite, si une méthode peut aller dasn plusieurs classes, et que cela se justifie, penses aux interfaces.

D'autres méthodes peuvent être intrinsèques (et/ou privées). C'est le cas de méthodes outils (qui n'apparaissent pas forcément sur le DC)

Enfin, comme déjà dit, il faut bien délimiter les responsabilité des classes, avec dans l'idéal 1 classe = 1 responsabilité

[mimosa803]

Je présente ma spécification :

Un projet comporte plusieurs ressources : Personnel, taches, Document,Livrable, Risque, Problème.
Le projet est crée par le commercial.
La tache est crée par le chef de projet.
La tache est affectée à 1 ou plusieurs équipiers.
Le projet est affecté à un chef.

Bon, je trouve un problème au niveau de la méthode affecterprojet() est ce que je la met dans la classe commercial ou projet ?
C'est le meme cas dans la méthode affectertache() ?

[hed62]

Je verrai plutot un Equipier.AddTache(Tache) qui se charge d'appeler Tache.SetEquipierResponsable(this) .

Idem pour le reste.

[ze_corsaire]

Je pense que tu n'es pas descendu suffisamment bas dans ton analyse. Il manque les dissociations entre les classes de type boundary, control et entity (ton diagramme de classe met seulement en exergue les classes de type entity) ...
En fait, je verrais plutôt une action disponible pour le commercial : CreationProjet. L'appel de cette action exécuterait la méthode creerProjet d'une classe GestionnaireProjet. Lors de cet appel, la classe GestionnaireProjet instancierait un nouveau Projet et ouvrirait le formulaire FormulaireProjet. Ensuite le commercial intéragit avec le FormulaireProjet : il y choisit un nomDeChefDeProjet et valide le formulaire FormulaireProjet qui délègue l'action de validation au GestionnaireProjet et qui met à jour le Projet.
Ce cas est l'illustration que l'aspect dynamique facilite la définition des rôles pour chaque classe. Par suite, je te conseille de réaliser pour chaque diagramme de classe (généralement j'en fais un par UC, ici "Gérer projet") un ou plusieurs diagrammes de séquence.


_______________

[hed62]

Effectivement, la démarche de ze_corsaire est bonne. Je n'avais pas relu le début du post : le DC présenté en un DC métier (et là c'est normal de n'avoir que les classes entity je trouve).

Pour continuer, il faut raffiner pour trouver attributs et méthodes, et effectivement on passe par des gestionnaires/controller pour simplifier la conception.