Discussion :

[Neckara]

Bonjour,

Je suis actuellement un étudiant qui va rentrer en 2ème année d'IUT informatique.

Je travaille depuis 1 an sur un projet personnel qui me tient à cœur.
Or au moment où je l'ai commencé, je ne connaissais pas encore le Merise ou l'UML.
Je n'ai donc jamais fait tout le travail de conception.

Avec un peu de recul, je me rend compte que je ne peux pas continuer ainsi.
J'éprouve des difficultés à :
- estimer ce qu'il me reste à faire (et donc estimer un temps de réalisation) ;
- faire comprendre aux autres membres du projet le fonctionnement du programme ;
- donner des tâches aux autres programmeurs.

Je ne parle pas de ce qui est déjà codé.

Je souhaiterais alors faire de A à Z tout le travail de conception en UML.
En cours on a vu :
- les diagrammes de cas d'utilisations ;
- les diagrammes de séquences systèmes ;
- le modèle relationnel ;
- les diagrammes de classes.

Mais il me reste encore beaucoup à apprendre. Ce n'est pas la peine de faire un travail de conception si celui-ci contient trop d'énormités.

Je recherches donc des personnes pour m'accompagner.
Juste pour me donner un peu la direction à suivre (quel diagramme faire en premier, s'il y a des outils plus pratiques pour faire les diagrammes- j'utilise open office draw pour l'instant - ...) et me faire des remarques sur les diagrammes (un peu comme un prof quoi^^).

J'aimerais donc utiliser ce sujet pour montrer mes diagrammes, poser quelques questions et si possible pouvoir parler de la conception via skype (l'échange étant plus rapide et plus aisé que par forum).



Sur ce, je vais commencer à poser ma première question :

Quels diagrammes faudrait-il que j'utilise et par lequel commencer?

Je suppose qu'il faudra :
- en premier lieu faire une courte présentation (15-20 lignes (?) ).
- puis faire un diagrammes de cas d'utilisations.
- ensuite faire un diagramme de classe (?)
- pour chaque cas d'utilisations faire un diagramme de séquence système.
- se servir des diagrammes de séquences système pour compléter le diagramme de classe en mettant les méthodes nécessaires
- et à la fin faire le modèle relationnel pour la base de données.

Mais est-ce qu'il y a d'autres diagrammes (il y en a environ 15 différents en UML si je ne me trompe pas) que vous me conseillerez de faire (en gros vaut-il le coup que j'apprenne à le faire par rapport à ce qu'il m'apporterait dans la conception)? Si oui à quel moment, dans quel but?

[bruno_pages]

Bonjour,

A moins que vous ne soyez profondément masochiste et que vous n'ayez vraiment aucune contrainte de temps, il faut vraiment que vous utilisiez un modeleur UML et non un outil de dessin. Puisque votre projet est en C++ prenez en un vous permettant de faire un reverse du code C++ existant afin de ne pas avoir à définir l'existant à la main. Je ne sais pas si vous souhaitez aussi pouvoir générer votre code C++, par contre je vous conseille de prendre un modeleur vous permettant de générer une documentation de votre modèle. Comme vous êtes plusieurs sur le même projet choisissez un modeleur permettant le travail collaboratif.

Si j'ai bien compris vous ne repartez pas de zéro, mais vous allez documenté l'existant, puis le faire vivre en le complétant/améliorant. En ce qui concerne l'existant vous n'avez pas vraiment d'ordre à respecter, c'est à dire que vous êtes pas obligé de commencer par les UCs, par contre pour les évolutions futures commencez par les UCs puisque ce sont eux qui disent quoi faire.

On n'utilise pas des diagrammes d'un certain type parce qu'on le doit, mais parce que cela est utile. Certains diagrammes comme les cas d'utilisation, classes, interactions (séquence / communication) sont quasi obligatoire dans les faits. Un diagramme de paquetages peut aussi être très utile pour montrer le découpage logique (même si vous n'utilisez pas de namespaces). Si vous avez défini des interfaces (classes abstraites) vous pouvez utilisez les composants et leur diagramme associé. Si vous avez des algorithmes compliqués et que vous souhaitez les modéliser vous pouvez utiliser les activité. Bien évidemment si vous avez des machines à états modélisez les. Il est moins probable que les diagrammes de déploiement vous soient utile.

Bon courage, et bien-sûr n'hésitez pas à demander de l'aide en publiant vos diagrammes.

[Neckara]

Bonjour,

A moins que vous ne soyez profondément masochiste et que vous n'ayez vraiment aucune contrainte de temps, il faut vraiment que vous utilisiez un modeleur UML et non un outil de dessin. Puisque votre projet est en C++ prenez en un vous permettant de faire un reverse du code C++ existant afin de ne pas avoir à définir l'existant à la main. Je ne sais pas si vous souhaitez aussi pouvoir générer votre code C++, par contre je vous conseille de prendre un modeleur vous permettant de générer une documentation de votre modèle. Comme vous êtes plusieurs sur le même projet choisissez un modeleur permettant le travail collaboratif.

Je dois avouer que je n'ai jamais utilisé de modeleur^^.
Par contre, je ne comprend pas pour la génération de la documentation du modèle. Nous en cours on fait tous les diagrammes à la main.
La génération de la documentation va "trier" tous les diagrammes et commentaires au sein d'un unique document ou va-t-elle générer d'autres diagrammes ?

Si j'ai bien compris vous ne repartez pas de zéro, mais vous allez documenté l'existant, puis le faire vivre en le complétant/améliorant. En ce qui concerne l'existant vous n'avez pas vraiment d'ordre à respecter, c'est à dire que vous êtes pas obligé de commencer par les UCs, par contre pour les évolutions futures commencez par les UCs puisque ce sont eux qui disent quoi faire.

Après discutions avec un chef d'un autre projet, je pense qu'on va essayer de repartir sur des bases saines (j'ai fait un peu trop d'énormités dans le code) et je vais prendre le temps de répertorier toutes les idées pour constituer un cahier des charges complet et précis. Je pense que ça pourra bien aider.

On n'utilise pas des diagrammes d'un certain type parce qu'on le doit, mais parce que cela est utile. Certains diagrammes comme les cas d'utilisation, classes, interactions (séquence / communication) sont quasi obligatoire dans les faits. Un diagramme de paquetages peut aussi être très utile pour montrer le découpage logique (même si vous n'utilisez pas de namespaces). Si vous avez défini des interfaces (classes abstraites) vous pouvez utilisez les composants et leur diagramme associé. Si vous avez des algorithmes compliqués et que vous souhaitez les modéliser vous pouvez utiliser les activité. Bien évidemment si vous avez des machines à états modélisez les. Il est moins probable que les diagrammes de déploiement vous soient utile.

Le problème c'est que c'est la première conception que je fais tout seul sur un projet perso, je manque donc un peu d'expérience pour savoir ce qui est utile ou non.
Mais je pense que je dois poser la question un peu trop tôt et que je devrais d'abord commencer par écrire un cahier des charges pour montrer ce que je veux faire précisément avec quelques premiers diagrammes comme le cas d'utilisation pourra me permettre de vous demander ce qu'il serait bien que je précise avec un diagramme UML.

Bon courage, et bien-sûr n'hésitez pas à demander de l'aide en publiant vos diagrammes.

Merci beaucoup pour votre aide, j'y vois déjà beaucoup plus clair.
Je vais d'abord commencer par le début (Analyse) puis je reviendrais ici dès que j'aurais fini.

[bruno_pages]

Par contre, je ne comprend pas pour la génération de la documentation du modèle. Nous en cours on fait tous les diagrammes à la main.
La génération de la documentation va "trier" tous les diagrammes et commentaires au sein d'un unique document ou va-t-elle générer d'autres diagrammes ?

une modélisation UML ce n'est pas que des diagrammes, et l'ensemble des éléments du modèle n'est pas forcément visible dans des diagrammes, ou pas complètement.

Générer la documentation permet de retrouver tout les éléments du modèle, et d'y accéder sans devoir passer par le modeleur etc

Par contre un générateur de doc ne peut en aucun cas auto générer des diagrammes qui n'existent pas.

[Cincinnatus]

Bonjour,

Effectivement, les diagrammes les plus souvent utilisés sont ceux de séquence et de classes.

Les cas d'utilisation sont un des moyens de définir les fonctionnalités de l'application ; les diagrammes de cas d'utilisation ne servent qu'à représenter une vue d'ensemble, l'essentiel étant dans la description textuelle des cas.

Ensuite, les diagrammes de classes permettent de représenter le modèle métier et les diagrammes de séquences de définir les interactions de ces classes nécessaires à la réalisation des cas d'utilisation. Ces deux types de diagrammes sont donc souvent construits en même temps, par aller-retour.

Les autres diagrammes largement utilisés sont les diagrammes d'activités (comparables aux MCT de Merise) détaillant graphiquement les cas d'utilisation. Quant aux diagrammes d'état, ils permettent de documenter les changements d'état et les transitions lorsqu'une évolution d'un objet change son comportement ou s'il se comporte comme un automate, avec des cycles par exemple.

Les autres types de diagrammes (UML ou autres) permettent de documenter d'autres aspects, dont le déploiement ou la structure, selon ce qui est nécessaire au projet.

Il ne faut réaliser que les diagrammes qui vous semblent nécessaires (ou qui sont imposés). Ne jamais oublier qu'ils seront soit jetés après utilisation soit à synchroniser avec le code.

[bruno_pages]

les diagrammes d'activités (comparables aux MCT de Merise) détaillant graphiquement les cas d'utilisation.

les activités sont bien plus que les MCTs, et ne sont pas réservés à la description des UCs

Ne jamais oublier qu'ils seront soit jetés après utilisation

que voulez-vous dire ?

... soit à synchroniser avec le code.

d’où l’intérêt de générer le code à partir du modèle, et non de mettre à jour le modèle à partir du code, même si des outils facilite cette (re)mise à jour du modèle via un roundtrip