Avant de coder

salut tout le monde

je voudrais vous poser les questions suivantes :
- quand vous faites un programme java est ce que vous faites un jolie digramme uml avant de coder histoire de recenser toutes les classesn faire ressortir les relations
ou
- est ce que c'est en codant vous vous savez quel classe créer et quel relation il y a entre ces classes

ps : moi c'est plutot la seconde option mais je ne sais pas si c'est la meilleure facon d aborder les choses ? (enfin au debut je sais quels sont les classes principales mais pour la suite c est en codant que je me rend compte du reste

Est-ce que par diagrammes UML tu entends modélisation? Car UML n'est qu'un langage et on peut faire une très bonne modélisation sans jamais utiliser UML.

Les éléments à prendre en compte (pour savoir quelle doit être la profondeur de la modélisation) sont l'envergure projet, sa finalité, sa portée ...

Pour un gros projet par exemple, tu gagneras toujours du temps si tu prends le temps de bien faire ta modélisation. Par contre si tu veux faire un petit programme histoire de tester que ton environnement de développement est bien configuré, je ne suis pas sûr qu'il faille toujours faire de jolis diagrammes UML.

Ca peut dépendre de ton type d'application.

Par exemple pour des applications Web, les diagrammes de classe UML (je parle pas des diagrammes de séquences etc.) servent surtout pour les classes métiers (par exemple, les beans qui mappent des tables de base de données).

Hello,

Je pense que la première option est la meilleure. Avoir un temps de réflexion avant de commencer à coder est toujours une bonne chose.

Cela permet de prendre un peu de recule et d'éviter des retours en arrière parce qu'on a oublier de prendre en compte la dernière page du CDC ;).

Maintenant pour des développements simples ou pour des cas déjà rencontrés effectivement on peut toute de suite se lancer dans la bataille!

Comme toujours et partout, une règle d'or: ne pas vouloir avoir fini avant de commencer, ce qui implique un minimum d'analyse.

Personnellement je pense qu'il faut effectivement une phase d'analyse préalable qui va faire ressortir un model de conception, y compris un premier jet de modèle de classe.
A partir de là, après le démarrage du projet, on réalise que certaines choses peuvent être mieux conçues, qu'on a oublié des trucs et que les demandes évoluent.
Il ne faut alors pas hésiter à "refactorer" l'application, y compris son architecture, par phase successives, pour aboutir à une solution globale optimisée.

C'est Martin Fowler qui a développé ce concept de refactoring :
http://www.refactoring.com/

Citation:

---

Envoyé par slevy

....
Il ne faut alors pas hésiter à "refactorer" l'application, y compris son architecture, par phase successives, pour aboutir à une solution globale optimisée.

C'est Martin Fowler qui a développé ce concept de refactoring :
http://www.refactoring.com/

---

Hello,

Tout à fait d'accord !!:D:D

Je suis devenu un adepte du refactoring par constat, tant il est difficile de viser juste du premier coup.

C'est d'autant plus facile aujourd'hui que les outils aident à cette tâche.

La modelisation est je pense indispensable si tu a un gros ou meme moyen projet en tete pour de petits programmes qui ne depassent pas 500 ou 600 lignes (avec interface) par contre sa equivaut a pisser dans un violon (sorry pour l'ecart de language :oops:)

Conception et modélisation ne font que traduire de façon structurée les idées qu'on a en tête pour résoudre un problème donné: le codage participe a ces activités.

S'il est souvent nécessaire de passer par une modélisation avec des boites et des flèches avec papier/crayon (ou UML) plutôt que de coder directement, c'est surtout parce que le "codage" signifie en général d'avoir précisé nombre de détails.

A défaut d'avoir arrêté une vue d'ensemble de ce que nous voulons faire (plus ou moins diffuse ou précise en fonction du projet), il faudra toujours préciser ces détails au prix de difficultés pour préserver la cohérence d'ensemble.

Le pire, si on n'y prend garde est que la réalisation devienne contrainte par le code déjà été réalisé plutot que parce que nous souhaitions faire.

Je reconnais que parfois "coder" d'abord est un bon raccourci pour se rassurer ou pour voir comment résoudre le problème posé surtout quand on bricole seul sur un petit projet. Ceci dit, pourquoi ne pas considérer le travail réalisé comme un brouillon ou un prototype et commencer un minimum de conception à partir de là.

- W

La modélisation préalable permet l'établissement des "contrat" (interfaces inter modules) et donc la parallelisation du développement (qqun pour l'ihm, qqun pour le dao ...).

Mais surtout, ça permet à toute personne travaillant sur le projet de savoir quoi faire et où le faire, établir un planning de développement puisque des modules dépendent d'autres etc.

Donc, je rejoint les autres : si tu veux faire une appli vite fait pour toi, te casses pas la tête, si ça dépasse 2 jours de travail, ou si tu n'es pas seul à travailler, reflechit avant.

L'UML n'est qu'un langage de représentation de ta modélisation. Il en existe d'autre, mais celui ci est (normalement) connu de tous.