Accueil
 Sommaire
 1  Objectifs de ce cours de modélisation orientée objet
 2  Généralités sur la modélisation orienté objet et sur UML
 3  Analyse, vues cas d'utilisation et processus
 4  Analyse et conception, aspects statiques de la vue logique
 4.1  Diagrammes communs à l'analyse et à la conception
 4.2  Diagramme de classes
 4.2.1  Modéliser la structure logique du système dans un diagramme de classes
 4.2.2  Classe
 4.2.3  Instanciation: création d'un objet d'une classe
 4.2.4  Attributs et opérations de classe
 4.2.5  Attribut dérivé
 4.2.6  Association entre classes
 4.2.7  Nom de rôle et multiplicité
 4.2.8  Généralisation spécialisation ou héritage
 4.2.9  Généralisation spécialisation: vision ensembliste
 4.2.10  Généralisation spécialisation: vision encapsulation
 4.2.11  Généralisation et redéfinition d'opérations
 4.2.12  Méthode Polymorphique et liaison dynamique
 4.2.13  Agrégation
 4.2.14  Exemple de diagramme de classes
 4.2.15  Éléments de méthodologie
 4.3  Diagramme d'objets
 QCM
 4.4  Concepts avancés du diagramme de classes
 5  Analyse et conception, aspects dynamiques de la vue logique
 6  Conception, aspects langage et technique
 7  Conception, vues développement et physique
 8  Conclusion
 9  Bibliographie

 Contacts

W3C validator

Département INF  
 Conception et programmation orientées objet


4.2.15 Éléments de méthodologie
  • Analysez le texte pour rechercher les noms qui sont des classes métier et les verbes qui les relient qui sont des associations
  • Construisez un premier diagramme de classes à partir de ces noms
  • Enrichissez ce diagramme avec les associations à l’aide des verbes obtenus
  • Affinez le diagramme en éliminant les associations redondantes,
    en simplifiant le schéma dès lors qu’il respecte les spécifications de l’énoncé
  • Ne cherchez les généralisations spécialisations que lorsque les classes sont déjà bien établies
  • Ne cherhez les agrégations qu’à la fin
  • Terminez cette première version du diagramme en ajoutant les multiplicités
  • Dans une seconde itération seulement, ajoutez les attributs et les opérations
  • Pensez à vérifier que tous les concepts métier sont présents
  • Pensez à vérifier que vous pouvez réaliser les cas d’utilisation par parcours du graphe de classes

    précédent     suivant 


La seconde étape de l’analyse consiste à analyser le texte du cahier des charges, afin d’y rechercher les différentes classes métier et leurs associations. Il est préférable de sur-spécifier le modèle d’analyse avec beaucoup de classes métier ; il sera plus facile de les regrouper plus tard que de trouver celles que nous aurions ignorées. Recherchez les noms qui correspondent le plus souvent aux classes métier, et les verbes qui les relient qui correspondent aux associations ; attention toutefois à certains verbes (comme le verbe être) qui peuvent correspondre à des attributs ou à des opérations. L’opération habituelle consiste à établir des listes exhaustives puis à les trier / sélectionner afin de ne garder que celles utiles à la résolution : suppression des classes métier trop vagues ou non pertinentes, élimination des noms ou verbes inutiles car ce peut être du bruit introduit lors de la rédaction du cahier des charges, chasse aux synonymes, etc.

Une autre manière de trouver ces classes métier est de partir des cas d’utilisation : dans les descriptions des actions effectuées par les acteurs, les noms sont des classes métier et les verbes utilisés sont des associations.

Remarquez que, partant d’un énoncé, cette méthode d’analyse n’est pas une fin en soi : les limites sont celles apportées par un texte ; cela nécessite un dialogue avec le « client ». Il est important de bien choisir le nom des classes métier et des associations : on retrouve en général des noms pour les classes métier et des verbes pour les associations.

Nous vous conseillons de :

  • construire un premier diagramme de classes à partir des noms obtenus dans la phase précédente,
  • par étapes successives, enrichir ce diagramme avec les associations à l’aide des verbes obtenus,
  • affiner le diagramme en éliminant les associations redondantes en simplifiant le schéma dès lors qu’il respecte les spécifications de l’énoncé,
  • ne chercher les généralisations et spécialisations qu’à la fin, lorsque les classes sont déjà bien établies.

Concernant les associations, recherchez les relations simples, les relations d’agrégation et les relations de généralisation spécialisation. Ensuite, trouvez la multiplicité / cardinalité de chaque association et portez-la sur le schéma si elle diffère de la valeur par défaut (« 1 »).

Enfin, trouvez les attributs et les opérations des classes. À ce niveau, quelques retours en arrière sont possibles à cause d’oublis ou de mauvaises compréhensions du système. Lors de l’analyse, il s’agit des attributs ou opérations que les spécifications du problème nécessitent : ils sont liés au modèle statique. Dans la partie conception, d’autres attributs et opérations sont trouvés, comme par exemple utilisant des classes dites « techniques ». Si un nom est associé à une valeur (nombre, texte, etc.) dans le monde réel, alors il s’agit certainement d’un attribut. Dans le doute, en faire une classe métier. Un critère de validité d’un attribut est qu’il doit être simple (type/valeur) : par exemple, date, nombre, texte. Dans le cas contraire, en faire une classe métier. D’autre part, les classes métier doivent être reliées entre elles par des associations et non avec des attributs.

Pour placer une opération dans une classe, recherchez la classe responsable : c’est celle qui détient toutes les informations nécessaires pour effectuer l’opération. En cas de création, cela devrait être la classe conteneur (agrégation) ou celle qui détient les valeurs d’initialisation. Concernant les opérations, le niveau de détail d’un diagramme de classes de l’analyse doit rester faible afin de ne pas empiéter sur la phase de conception.

Pour valider le diagramme de classes, reprenez l’énoncé et vérifiez que toutes les spécifications demandées y sont présentes : cela consiste à vérifier que vous répondez à tous les cas d’utilisation. Dans le cas contraire, reprenez le schéma et corrigez-le. Dans certains cas, cela peut remettre énormément de choses en question. Vous devez également contrôler si des fonctionnalités nouvelles ont été ajoutées par rapport à l’énoncé. Ces nouveautés doivent rester mineures : « vous n’êtes pas payés pour faire plus que ce que demande le client ».

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2015