L'objectif de cette phase est de construire un premier diagramme des classes avec les éléments qui sont à notre disposition à ce stade de l'étude. La recherche des classes candidates commencera en étudiant le discours de l'utilisateur et notamment par une analyse des cas d'utilisation.
Les classes déduites des UC sont appelées classes métiers car elles représentent les objets sur lesquels les utilisateurs agissent dans le cadre de leur métier (Clients, Produits, Commandes…). Les autres, appelées classes techniques sont des ensembles d'objets purement informatiques inconnus des utilisateurs (tables, pointeurs, paramètres, données de personnalisation…) et dont le rôle est de faire fonctionner le logiciel.
Remarquons que la décomposition des cas d'utilisation n'est pas le seul moyen pour trouver les classes métiers. On pourra aussi en découvrir en examinant les fichiers existants, les résultats souhaités, les documents utilisés, les prévisions d'évolution, le DCT…
Lors de cette étape on construira un premier diagramme des classes composé uniquement des classes métiers. Les classes techniques seront rajoutées au moment du développement. A ce niveau de conception, il n'est pas utile de faire apparaître les contrôles d'accès aux attributs et aux méthodes. Ils seront rajoutés au moment de la conception détaillée.
Les paquetages
Si le nombre de classes métiers est important (cas des gros projets pouvant comporter plusieurs dizaines de classes), on regroupera les classes en paquetages de façon à améliorer la lisibilité du diagramme et permettre par la suite de réaliser des regroupements de classes au sein du logiciel (packages Java par exemple).
Chaque paquetage aura un nom significatif et donnera lieu à un diagramme des classes indépendant. Seules les relations de composition et d'association pourront exister entre des classes appartenant à des paquetages différents. Les relations de généralisation (héritage) ne pourront donc exister qu'à l'intérieur d'un paquetage. Pour représenter une association ou une composition existant entre deux classes situées dans deux paquetages différents, on matérialisera les classes impliquées par un rectangle situé en bordure du paquetage. Chaque paquetage donnera lieu à la constitution d'un diagramme des classes spécifique.
Recherche des attributs
La méthode de recherche des attributs des classes s'appuie généralement sur les résultats (affichage écrans, états imprimés, autres) demandés par les utilisateurs (méthode ascendante).
Pour chacun des résultats on dresse la liste de toutes les données qu'il contient afin de voir si elles sont obtenues à la suite d'un calcul (arithmétique, logique, algorithmique complexe). Si c'est le cas, on décompose la méthode de calcul pour faire apparaître de nouvelles données qui sont à nouveau analysées. On itère le processus tant que l'on obtient des données calculées. Les données non calculées sont dites "primaires" et constitueront les attributs qu'il faut répartir dans les classes.
Dans certains cas, généralement pour des raisons d'optimisation, on peut conserver comme attribut une donnée calculée qui sera représentée dans le diagramme de classes UML par le symbole "/" précédant son nom. Par exemple "/Moyenne" représente l'attribut "moyenne d'un étudiant" de la classe "Etudiants" qui est enregistrée et devra être recalculée par une méthode spécifique chaque fois qu'un événement influant sur la moyenne se produit (nouvelle note par exemple).
Recherche des méthodes
Les méthodes rattachées aux classes métiers sont définies essentiellement à partir des fonctions utilisateur. Certaines fonctions techniques peuvent également leur être affectées bien qu'habituellement elles soient plutôt rattachées aux classes techniques qui apparaîtront lors du développement. Chaque méthode sera, dans un premier temps définie publique et on lui donnera un nom abrégé significatif. On conservera malgré tout le nom de la fonction dont elle est issue afin de garder la trace de son origine.
Chaque méthode est généralement placée dans la classe correspondant aux objets qu'elle traite. Cependant il existe des cas où une méthode met en œuvre des objets provenant de plusieurs classes. Son placement dans l'une des classes devra être décidé en cherchant à minimiser le nombre d'accès à effectuer dans les autres classes. Dans ce but, on pourra s'aider d'un diagramme de communications qui permet de visualiser tous les messages échangés entre les classes.
Les classes persistantes
Une classe est dite persistante si les objets qui la composent sont enregistrés de façon permanente (conservation des objets entre deux exécutions du logiciel) dans une base de données ou un fichier. Il est conseillé de réaliser un sous-diagramme des classes persistantes afin de constituer le schéma de la base de données ou la structure des fichiers qui sera mis en œuvre dans le projet.
Remarque : Dans ce qui suit nous utiliserons les règles de nommage Java pour désigner les attributs, les méthodes et les classes.
Les classes métiers dans le projet "Assurance-Auto"
Les cas d'utilisation et les informations contenues dans le CCU font apparaître les classes métiers et les attributs suivants :
Contrat (numContrat, nomAssuré, adresse, téléphone, dateNaissance, datePermis, datePaiementPrime, montantDû, montantPayé, lien vers TypeContrat)
Véhicule (immatriculation, puissance, genre, modèle, marque, /bonus-malus, lien vers Contrat, lien vers Catégorie)
Dossier (numDossier, dateOuverture, dateAccident, descriptionAccident, dateClôture, montantDégâts, partResp, montantRéglé, dateRèglement, montantExpert, datePaiementExpert, lien vers Véhicule, lien vers Expert)
Tiers (typeTiers : interne, externe)
TiersInterne (lien vers Véhicule)
TiersExterne (immatriculation, nom, adresse, téléphone, lien vers Compagnie)
Compagnie (raisonSociale, adresse, téléphone)
Expert (nom, adresse, téléphone)
TypeContrat (codeType, libellé)
Catégorie (numCat)
