AILES : Le travail d'un développeur : spécifier (Analyse)

Analyse : une action structurante
Cette "formule" résume le premier niveau de l'analyse : face à un système plus ou moins complexe et élaboré, il faut réussir à le structurer en sous systèmes et descendre ainsi jusqu'à des "composants logiciels" ou "packages" élémentaires.
Ces packages seront enfin décomposés en classes.
(cf. question en entretien d'embauche)
Il est rare qu'un développeur "junior" participe directement à la structuration des sous-projets : ceux-ci lui sont le plus souvent fournis (à moins que la taille du projet ne justifie pas cette première étape d'analyse).

Analyse : une action de modélisation
La modélisation participe bien sûr à la structuration du système en sous-système...
Elle s'appuie sur un modèle (= formalisme ou outils de représentation : par exemple :

,
ici le modèle statique, formalisme UML, critiqué par un certain B. Meyer dès 1997 !).
Si l'on reste dans le modèle objet général UML, ce dernier propose trois modèles particuliers : statique (le plus connu avec ses diagrammes objet), dynamique (avec ses diagrammes de séquence, de collaboration, d'état) et opératoire (avec ses pré et post conditions).
Modéliser, c'est appliquer un modèle (outils de représentation, formalisme) à une méthodologie (processus qui décrit l'utilisation du modèle au sein du cycle de développement -"analyse", "conception", ... -) en étant guidé par une méthode (qui valide, à l'aide règles, la modélisation). Approche systémique classique.
C'est la modélisation qui vous permet de structurer un projet, depuis la vision "haut niveau" jusqu'aux classes (bas niveau, juste avant l'implémentation).

Analyse détaillée
Pour le développeur que vous êtes, c'est la phase qui vous concerne le plus souvent.
Il s'agit au minimum d'identifier les classes et des les organiser au sein d'un modèle statique.
2 scénarios sont possibles :
- soit vous vous appuyez sur une spécification formalisée et sur une première analyse de haut niveau qui a structuré votre système en sous-systèmes,
- soit il s'agit d'un petit projet et vous êtes à la bourre. Il n'est pas rare alors de passer directement du cahier des charges à l'analyse détaillée!!! (relisez ce qui précède ainsi que l'article précédent pour vous rendre compte de ce que vous loupez!).

Impératifs
A ce niveau de modélisation, lorsque, après raffinements successifs, vous définissez vos classes, il faut toujours garder à l'esprit que l'on est, à ce stade, au niveau des concepts et non de l'implémentation.
Ainsi, lorsque une classe "connaît" une autre (Comme, dans l'exemple, ClasseA "connaît" de 0 à n instances de ClasseC), il faut toujours se demander si le concept représenté par classe A a besoin de celui de classeC pour se définir.
Par exemple, si vous avez les objets BILLET_DE_TRAIN et TRAIN, on peut envisage que le premier "connaisse" le deuxième, mails il faut éviter que le deuxième connaisse le premier, pour deux raisons :
- un Train n'a pas besoin de billet pour se définir (et pour rouler!),
- une dépendance cyclique entre deux classes est à éviter (pas toujours, mais le plus souvent possible...)
Une classe qui "connaît" une autre, cela s'appelle un "couplage" ou "dépendance" (la première ne peut se définir sans la deuxième) et c'est une énorme source potentielle de problèmes pour un jeune développeur encore peu expérimenté, comme les parties suivantes le démontreront.