Envoyé par
thierryc
Bonjour, Merci pour le diagramme.
Oui, c'est une stratégie d'avoir un objet pour chaque objet de l'interface utilisateur, ici la fiche pour créer une candidature pour un projet (de recherche?).
En lisant le diagramme, je comprends que les autres classes sont les objets du domaine.
Visuellement, votre diagramme est difficilement lisible. En général, on choisit parmi deux possibilités :
- on lit de haut en bas et de gauche à droite, les objets les plus importants en haut à gauche. L'objet ProjetDétaillé semble ici mal placé en bas à droite.
- ou bien l'objet le plus important est au centre et les autres objets sont autour. Ici, j'ai une confusion entre l'objet Projet et l'objet ProjetDetaillé. En fait, avec toutes ses relations, l'objet Annexe attire l'oeil, à tort.
Également, on utilise les couleurs pour séparer les types d'objets, notamment entre les objets du domaine et les objets de l'interface utilisateur.
Également, on évite les couper les lignes de relations, et on essaie de positionner les objets qui ont des relations les uns près des autres, pour faire des "sous-diagrammes".
Certains objets sont bien nommés, notamment le formulaire, ou l'objet projet. On ne comprend pas d'autres objets, pourquoi une séparation entre la "FicheSignalétique" et "InfoProjet".
Le travail sur les attributs n'est pas abouti: il y a trop de types String. On essaie en général d'éviter les types de base, et même quand on les utilise, on essaie d'éviter d'utiliser toujours le type "string", ou le type "variant". Par exemple, la duréeProjet peut être un entier. le budget annuel peut être un "double" ou un "currency", etc.
Certains attributs seraient plutôt des classes, et devraient être renommés. Par exemple: Membre de l'équipe semble être un objet (formulaire et objet du domaine), avec un attribut CV, et une relation entre les deux formulaires.
Idem peut être, pour les références bibliographiques, à voir.
Par ailleurs, pourquoi seulement 2 relations de compositions? Si l'objet "Projet" est détruit, pourquoi pas tous les autres objets? En général, la relation de composition forme un arbre entre les différents objets et les objets racine. Ici, vious avez au moins deux objets racine: le "Projet", et la "Candidature"... tous les autres objets appartiennent à l'une ou l'autre hiérarchie ou bien il manque un ou plusieurs objets racines.
Également, la relation de composition, côté composite, peut très bien avoir une multiplicité "0..1" plutôt que "1..1" pour éviter des problèmes techniques à la création des objets (si vous disposez d'outils vérifiant les invariants de classe).
L'objet Annexe possède énormément de relations, et son nom est très général. Les relations entre cet objet et les autres ne seraient-elle pas des héritages plutôt que des relations simples?
Certains objets semblent trop petits pour être vraiment utiles: InfoProjet, CompositionEquipeRecherche, BesoinFinance, LettreEngagement, LettreSoutien n'ont qu'un ou deux attributs. Sont-ils indispensables? Dans ce cas, il doit manquer des attributs importants Sinon, on peut replier les informations sur d'autres objets.
Enfin, le diagramme n'a pas de titre, et manque d'une note expliquant l'auteur, la date, le n° de version, le point de vue et un petit descriptif du diagramme.
Quel est L’intérêt de l'objet "ProjetDétaillé"?
Les associations ne sont pas nommées. Si vous les nommez, vous devriez pouvoir enlever des objets inutiles. comme ProjetDétaillé...
Enfin, il faut toujours vérifier l'orthographe des objets et attributs d'un diagramme. "Partenariat", "Outil", etc. à corriger. Un attribut n'est pas nommé: "Attribute_4". Rien de grave, mais faire attention.
Cordialement,
ThierryC
