Discussion :

[SuisCapable]

Bonjour,
j'ai une préoccupation au niveau de mon diagramme de classe.
Est ce que tous les elements qui doivent apparaitre sous forme de formulaire à remplir dans une application web doivent etre des classe ou des attributs ? aussi, dans l'application, des annexes doivent être insérer sous forme de fichier afin que l'utilisateur puisse saisir, editer ces annexes, les elements de ces annexes seront aussi etre des classe dans le diagramme de classe? Est ce possible de joindre Microsoft Excel au formulaire pour éditer un fichier ?

Merci d'avance pour vos éventuelles réponses.

[thierryc]

Bonjour,
j'ai une préoccupation au niveau de mon diagramme de classe.
Est ce que tous les elements qui doivent apparaitre sous forme de formulaire à remplir dans une application web doivent etre des classe ou des attributs ? aussi, dans l'application, des annexes doivent être insérer sous forme de fichier afin que l'utilisateur puisse saisir, editer ces annexes, les elements de ces annexes seront aussi etre des classe dans le diagramme de classe? Est ce possible de joindre Microsoft Excel au formulaire pour éditer un fichier ?

Merci d'avance pour vos éventuelles réponses.

Bonjour,
ta question est trop générale, cela dépend de ton formulaire et de la complexité des informations à remplir par l'utilisateur.

Il peut y avoir des attributs et des classes composants, avec d'autres attributs. Peux-tu montrer ton formulaire et ton diagramme proposé?

[SuisCapable]

Salut.. D'accord
voici le diagramme de classe que j'ai eu à realiser
J'ai considéré les champs des formulaires comme etant des attributs de la classe FormulaireCandidature.
Les differentes fiches sont les annexes, comme les classes LettreSoutien, CurriculumVitae, ... et ces annexes doivent etre integrés dans la plateforme pour permettre aux utilisateurs de pouvoir les telecharger puis de les remplir enregistrer dans la base, l'idée c'est de garder la forme des annexes pour faciliter l'evaluation des projets soumis.
Merci d'avance.

[thierryc]

Salut.. D'accord
voici le diagramme de classe que j'ai eu à realiser
J'ai considéré les champs des formulaires comme etant des attributs de la classe FormulaireCandidature.
Les differentes fiches sont les annexes, comme les classes LettreSoutien, CurriculumVitae, ... et ces annexes doivent etre integrés dans la plateforme pour permettre aux utilisateurs de pouvoir les telecharger puis de les remplir enregistrer dans la base, l'idée c'est de garder la forme des annexes pour faciliter l'evaluation des projets soumis.
Merci d'avance.

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

[SuisCapable]

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

Bonjour.. Je vous remercie une fois de plus de m'avoir accorder votre temps dans l'objectif de pouvoir m'aider. Oui tout à fait.. J'ai consideré la classe ProjetDetaille comme etant le plus important.. J'avais pas la notion en ce qui concerne la position des classes par ordre d'importance, je m'arrangeais à ce que la lisibilité puisse se faire et que les relations n'encombrent pas le diagramme, j'en tiendrai compte pour l'amelioration à venir.

Pour ce qui est du decoupage entre "FicheSignaletique" et "InfoProjet", c'est que le projet dans sa soumission, doit se faire en deux phases, la premiere phase appelée note conceptuelle de projet, qui doit etre composée de la fiche signaletique, d'une fiche parlant du contexte et de la justification du projet et enfin des partenaires, leur role et leur responsabilité, voila pour quoi jai eu les divisé en classe, mais je vais les associé. La 2e partie qui concerne ceux qui seront retenu apres la note conceptuelle est le projet detaillé.

Concernant les types des attributs, effectivement, le type string est vraiment repetitif, mais c'est que j'ai cherché d'autre type que j'ai finalement pas jugé compatible. Pour l'attribut dureeProjet, un exemple de valeur peut etre "3 ans", voila pourquoi j'ai opté pour le string, pour ce qui est de "budgetDetaille", je crois que ça eté mal placé, cst en fait un fiché à remplir meme, cest tout ce que le fond devra servir, les travaux et achats liés a l'accomplissement du projet, les formations suivi, cest tous ce qui regroupe le budget detaillé.

Oui, effectivement, d'autres attributs peuvent devenir des objets, je verrai cela egalement.
Oui, pour les realtion composites, ainsi que les cardinalités, je reverrai tout ceci.

Pour l'objet "Annexe", je compte l'enlever et tout rattach" a l'objet "ProjetDetaillé" et voir leur relations si l'heritage pourra aller.

Les objets qui semblent etre inutiles, j'avais y penser, mais tout ces objet sont des fichiers qu'on les appelle des annexes, sous format word, qui devront etre integré dans la plateforme sans modification du contenu et que les soumissionnaires doivent teleecharger et remplir les points manquants, ce sont ces point manquqnts à remplir que j'ai consideré comme etant des attributs. La logique que j'ai adopté est que chaque annexe, c'est à dire chaque fiche est une classe et que les points à remplir sont des attributs.. Oubien on peut faire mieux pour une diminution des classe ?

D'accord.. Les informations concernant les diagramme, je les donnerai egalement
L'interet de "ProjetDetaille", vue que cest l'une des phases de soumission dans le projet, je me dis qu'il doit pouvoir fournir certaines informations que jai mentioné comme atant ces attributs.

Au fait pour la nomination des associations, l'outil PowerAMC que jutilise n'affiche pas les noms, cest pour cela.
Ok.. Merci davance
Je referai le diagramme et le rebverrai le plutot possible.


Cordialement.

[thierryc]

Bonjour,
on attend votre diagramme remanié.

Bonjour..
Pour ce qui est du decoupage entre "FicheSignaletique" et "InfoProjet", c'est que le projet dans sa soumission, doit se faire en deux phases, la premiere phase appelée note conceptuelle de projet, qui doit etre composée de la fiche signaletique, d'une fiche parlant du contexte et de la justification du projet et enfin des partenaires, leur role et leur responsabilité, voila pour quoi jai eu les divisé en classe, mais je vais les associé. La 2e partie qui concerne ceux qui seront retenu apres la note conceptuelle est le projet detaillé.
[...]

Cette partie de votre descriptif est très éclairante. Cela peut faire l'objet d'un diagramme d'activités séparé pour expliquer le phasage de la soumission de projet, ou encore par un diagramme de cas d'utilisation, ou bien cela peut se faire dans une note dans le diagramme de classe. En général, il vaut mieux simplifier les diagrammes et les séparer plutôt que de tout mettre sur le même diagramme.

A bientôt,
ThierryC

[SuisCapable]

Bonjour,
on attend votre diagramme remanié.


Cette partie de votre descriptif est très éclairante. Cela peut faire l'objet d'un diagramme d'activités séparé pour expliquer le phasage de la soumission de projet, ou encore par un diagramme de cas d'utilisation, ou bien cela peut se faire dans une note dans le diagramme de classe. En général, il vaut mieux simplifier les diagrammes et les séparer plutôt que de tout mettre sur le même diagramme.

A bientôt,
ThierryC

Bonjour.. Desolé du retard.. Au fait les utilisateurs n'avaient pas bien exprimé leur besoin de façon claire. En realité, le soumissionnaire doit rediger hoers plateforme lan note conceptuelle ainsi que le projet detaillé et le charger ensuite dans la plateforme.. Les informations qu'ils devra enregistrer sur la plateforme sous forme de formulaire sont celles du projet, des organismes partenaires, de l'equipe de recherche, .... et cela a donné un nouveau digramme de classe.