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

En théorie
Le mot clé résumant le codage devrait être traduction. Votre modélisation devrait vous apporter suffisamment d'éléments qui, à eux seuls, peuvent facilement vous générer jusqu'à 50% du code.
En effet :
- le modèle statique (graphe des classes) doit vous permettre de générer les .h et .cpp (dans l'exemple du C++), avec toutes les méthodes et leurs signatures.
Pour peu que vous ayez une politique fixe concernant les associations et autres agrégations, vous savez comment traduire vos liens entre vos classes.
Vous pouvez même automatiser l'influence d'un Design Pattern sur le code de votre classe. Ainsi, une classe dite "singleton" se construira toujours de la même manière, de façon à n'offrir aux autres classes de l'application qu'une seule instance.
- le modèle opératoire présent dans UML permet de positionner toutes les pré- et post-conditions.
- le modèle dynamique, au travers de ses diagrammes d'état et d'activités, peut également se révéler utile pour commencer à coder certains algorithmes ou enchaînement de messages entre classes.

En pratique
Les premiers AGL commencent seulement à se généraliser et permettent d'assurer une réelle cohérence entre le modèle et le code généré...
En attendant, vous le savez bien, vous tapez tout, depuis le constructeur d'une classe jusqu'aux moindres petites fonctions, y compris les inline...
(en 2002, cette cohérence est bien réelle, mais pas encore complète, cf. les critiques de B. Meyer)

Le couplage
Le codage recèle plusieurs pièges et cet article se concentre sur l'un d'entre eux. On peut facilement l'éviter avec une "bonne" modélisation, mais il a de toutes façons tendance à resurgir pendant cette phase du projet.
Il s'agit du fameux "couplage" : lorsqu'une classe A connaît (dépendance) une autre C (cf. shéma), cela n'a rien d'innocent, surtout lorsque vous n'êtes pas tout seul à développer :
- Si l'interface de C évolue "dans votre dos", vous allez devoir faire évoluer A en "urgence" afin de rester compatible,
- Si vous voulez tester A dans votre coin, vous devez "tirer à vous" (c.à.d. compiler avec) C (qui est une classe, mais qui peut être également un package d'une cinquantaine de classes formant une librairie de plusieurs Mo!),
- Si D (une troisième classe) a besoin des services de A, elle devra également connaître C, même si C n'a rien à voir avec D...
Si le couplage est si pernicieux, c'est aussi parce que l'on retrouve ses effets couplés à d'autres, comme celui de la gestion de configuration.
Cette gestion vous permet de développer dans votre coin, tout en bénéficiant des classes d'autres parties de l'application, classes qui sont dites "publiques", car stabilisées.
Cependant, si A a besoin d'un nouveau service de C, et que C se trouve (comme par hasard) dans une autre partie, vous ne verrez de C que sa version "ancienne" (mais publique donc stable). Il vous faudra attendre la prochaine livraison publique des "autres parties" (dont C) avant, enfin, de pouvoir en bénéficier.
Bref, tout couplage doit être pensé... de préférence avant codage! (voir même bien avant au niveau de l'architecture...)