AILES : Le travail d'un développeur : concevoir

Conception Préliminaire
Si les modèles précédents (statiques, dynamiques, etc.) vous ont aidé à spécifier votre système, vous allez les reprendre pour les "préciser" : ici, vous n'êtes plus seulement au niveau des concepts. Vous devez déterminer comment vous allez manipuler ces concepts, donc comment les implémenter.
Pour cela, vous pouvez vous appuyer sur des "patrons de modélisation objet" qui vous aident à implémenter plus facilement des... :
- gestions d'événements,
- gestion d'états,
- gestion d'interface, ...
Cela s'appelle les Design Patterns et vous permet de ne pas "réinventer la roue" à chaque fois que vous devez gérer vos concepts de telle ou telle façon.
Vous pouvez également en profiter pour valider toutes les dépendances entre classes : si, soudainement, une classe a besoin d'une autre alors qu'en phase d'analyse, leurs packages (ensemble logique de classes) respectifs s'ignorent, c'est qu'il y a un problème (soit au niveau de l'analyse ou de la conception, dans le choix d'implémentation)

Conception Détaillée
En principe, vous devez compléter vos classes de façon à ce que leurs interfaces soient complètement définies et documentées.
Tous les choix de conception (et, en particulier, les choix de Design Patterns) doivent être justifiés.
On peut également en profiter pour documenter certains algorithmes complexes.
Tout l'aspect dynamique de l'application doit également être décrit.
Enfin, la phase d'intégration (comment assembler tous les morceaux) peut être préparée sur la base de ce document : celui-ci indique en effet clairement qui dépend de qui, et l'on peut en déduire un premier ordre d'intégration qui permet de rapidement cerner les problèmes, module après module.

En pratique
Le plus souvent, le débutant commence par faire de la conception qui se limite hélas trop souvent à quelques diagrammes objets vites faits avant de se ruer sur le code.
La conception détaillée n'est, en générale, faite que pendant voire après le codage, à l'aide d'un outils d'extraction de code automatique.
A ce niveau, le modèle objet de l'application est le plus défini. Le gros problème est qu'il devient vite incohérent au fur et à mesure que le codage avance. Celui-ci introduit en effet des changements rapides de conception selon l'apparition de certaines difficultés non-prévues lors de la conception initiale ou encore selon les "modifications inopinées"des spécifications par le client... (cf. aussi les critiques de B. Meyer)

Pourquoi faire de la Conception ?
Bien sûr, il s'agit d'une phase vitale qui permet de se poser les "vraies questions" avant de se lancer dans le code. En théorie, le codage ne devrait être qu'une simple "transcription" de la conception...
Une utilisation courante consiste également à servir de base pour vous aider à déterminer en combien de temps vous comptez réaliser ce que vous avez conçu.
Attention, ce nombre de jour devra comprendre le codage, le test mais aussi toutes les emm... inhérentes à tout projet (serveur en rade, outils de développement défaillants, librairie qui manque, mise-à-jour d'un produit qui se fait attendre alors que seule la nouvelle version propose la fonctionnalité dont vous avez besoin...)
Pour estimer cette durée, il n'y a pas de recette exceptée celle-ci : si vous débutez, vous pouvez tranquillement multiplier par deux (2!) votre estimation... non que vous soyez "mauvais" développeur, mais surtout parce que vous ne connaissez pas encore suffisamment votre projet pour savoir à quelle fréquence les ennuis précédemment évoqués vous tomberont sur la g... figure!