Discussion :

[ftrifiro]

Bonjour,

Je me pose des questions existentielles sur le diagramme de classes et plus précisément la façon de le faire vivre pendant un projet pour qu'il reste conforme à l'architecture logicielle élaborée par ailleurs.

Je m'explique.

Enoncé
Au début, j'ai fait des classes représentant les concepts à modéliser. J'ai mis la +part des attributs, et imaginé les opérations nécessaires. Pas de souci particulier. Et puis, parallèlement, j'ai fait une architecture logicielle en couches, classique, pour une cible J2EE avec des EJB.

Problème
Je me rends bien compte aujourd'hui que le diagramme n'est pas conforme à l'architecture. On n'y voit pas du tout les couches puisqu'il n'est que métier. Et j'ai groupé les attributs et les opérations alors que l'architecture prévoir d'utiliser les EJB, les DAO et les DTO...

Questions
A quoi doit ressembler un diagramme de classes qu'on fournirait au développeur en fin de phase de conception ? Et dans une doc de projet ? Quelles sont les bonnes pratiques ? Faut-il que le diagramme reflète l'architecture logicielle ? ...

Autant de questions que d'autres ont déjà dû se poser mais je n'ai pas vu de réponse qui m'ait convaincue...

Merci d'avance,

Fred

[ego]

Je pense que le premier modèle dont tu parles (les diagrammes métier) et ce que l'on appelle le modèle d'analyse.

Un modèle d'analyse ne contient effectivement pas l'architecture logicielle.
Suite à l'analyse, tu dois faire un modèle de conception. Ce modèle est une déclinaison du modèle d'analyse "équipé" avec les classes techniques, les classes, justement, de ton architecture logicielle (couches, dao, dto, ejb,...)

Ensuite, tu vas avoir le "problème" de la conservation ou non de ces 2 modèles. Si tu conserves le modèle d'analyse, tu devras gérer la synchronisation avec le modèle de conception = savoir ce qui a changé entre 2 versions de ton modèle d'analyse et quels sont les impacts sur le modèle de conception existant.
En fait, le modèle d'analyse peut ne pas être conservé. Tout dépend de la nature de ton projet et du fait que le modèle de conception soit vraiment différent du modèle d'analyse. On peut, en effet, avec les supers frameworks du moment et l'utilisation des méta-tags servant à générer des classes techniques, se dire que les classes d'analyse peuvent ne pas être trop distordues dans le modèle de conception et se retrouver presque telles quelles dans la couche "métier" de ton architecture. Ainsi, si tu ne conserves que le modèle de conception, tu retrouveras en partie tes éléments d'analyse.
Bref, ce peut être complexe de gérer en parallèle des versions d'analyse et des versions de conception donc autant savoir pourquoi on le fait.

[ftrifiro]

Merci ego. Ce que tu écris entre totalement dans ma problématique.

Je pense effectivement qu'il est possible de retrouver les classes métier du diagramme d'analyse de façon assez claire dans un diagramme de conception tu as raison. Les noms sont conservés et éventuellement suffixés par DTO ou EJB, ce qui permet de s'y retrouver.

Je vois par contre encore mal comment représenter les couches de l'architecture sur un diagramme de classes, sans qu'il devienne trop immense et donc illisible. Faut-il qu'il contienne toutes les classes de l'application ? J'imagine que non. Je me vois mal y faire figurer toutes les classes Action ou ActionForm de Struts par exemple ?? En fait, j'aimerais bien voir à quoi ressemble un diagramme de classes en fin de conception... Un bon schéma valant parfois mieux qu'un long discours ! Cela dit, je prends aussi les longs discours !

Autre remarque, en ne gardant que le diagramme de conception, on perd par contre un peu le contact avec la MOA et les informaticiens ne connaissant pas trop l'objet et les architectures. Il en existe, même sur les projets objets...

Merci encore.

[ndp]

Salut,
Pour moi c'est une bonne idée de garder le modele objet de l'analyse, je trouve aussi que le modele de conception obscurcie un peu les choses. La facilite de la POO vient plus de la possiblite de retrouver dans le modele de conception les objets du modele d'analyse. L'inverse est moins facile.

Je pense aussi que si tu garde une tracabilite entre tes diagrammes, tu peux en faire plusieurs. Par exemple: un par couche et un explicitant les relations entre les couches.

[ego]

Les couches sont plutôt représentées par des packages.
Pour ce qui est de la complétude du modèle par rapport à toutes tes classes, c'est à toi de voir.
Il est classique, je pense, de ne pas faire figurer les classes de la couche "IHM" type ActionForm ou autre Action. D'ailleurs, ces classes ne doivent pas faire grand chose mais déléguer la majorité du boulot à des classes non teintées par le framework utilisé (cf. principes énoncés dans le framework SPRING). Maintenant, tu peux quand même déclarer les Action dans le modèle sans les faire figurer sur des diagrammes; les outils UML sachant faire du reverse, cela ne coûte rien !

[ftrifiro]

Je pense voir à peu après...

Mais ce qui serait vraiment extra, c'est que je puisse voir un diagramme de classes de fin de conception (fichier joint ou sur mon mail ?) pour voir un peu à quoi ça ressemble plus concrètement.

Ca pourrait être possible ?

Merci, Fred

[ego]

Achete UML 2 en action ou UML 2 par la pratique, ce sont des bouquins très utiles avec des exemples et même une étude de cas

nb: je n'en suis pas l'auteur !