Cours UML

Cours Mapping UML et JAVA


Télécharger Cours Mapping UML et JAVA

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


Cours Mapping UML et JAVA enjeux et pratique

...

La Modélisation

La modélisation est une notion indissociable du fonctionnement de l’homme. Notre appréhension du monde est entièrement basée sur cette idée : nos objectifs naturels de compréhension et d’anticipation nous amènent naturellement à construire une représentation mentale et abstraite de l’ensemble des éléments qui composent notre environnement. Ce processus d’assimilation et de représentation peut se résumer ainsi :

Modéliser, c’est représenter une entité connue ou inconnue selon des concepts et un vocabulaire connus

Dessiner un plan, prévoir les réactions des gens, faire un portrait, manœuvrer un véhicule, faire un croquis pour expliquer une idée sont des activités ayant directement trait avec la modélisation.

En termes de vision industrielle, la modélisation constitue un outil essentiel dans les domaines de l’analyse (définition du produit) de la conception (description du produit à réaliser) et du développement (réalisation du produit). De manière plus générale, la modélisation intervient tout au long de la gestion de projet, comme outil de description et de communication entre les acteurs. Le document résultant de l’activité de modélisation constitue le modèle. Un modèle permet de décrire et de figer la réponse que l’on pense apporter aux exigences :

Un modèle est une représentation abstraite et non-ambiguë du sujet dans un langage donné

Une maquette, un plan, une photo, des mensurations, un émulateur, un organigramme sont des modèles.

Ses fonctions premières d’outil de description et de communication doivent faire tendre un modèle à être compréhensif, rigoureux, évolutif, complet, convivial, raffinable… Néanmoins, un modèle n’existe que parce qu’il résulte d’un point de vue. En effet, un modèle est toujours une vision simplifiée et formalisée d’un sujet. Cette simplification et cette formalisation résultent du rôle qu’on attend du modèle : une photo d’une maison ou ses plans de masses sont deux modèles d’un même sujet destinés à des usages différents et résultant par conséquent d’axes d’observation différents (un axe purement visuel et un axe plus structurel).

Le point de vue de modélisation est dicté par l’usage qui va être fait du modèle

Considérer un sujet selon une vue de profil, selon son aspect physique, selon ses réactions thermiques, selon son organisation, selon son comportement, c’est se placer selon différents points de vue de modélisation.

La modélisation est finalement une activité de projection :

  • d’un sujet réel (existant ou non),
  • sur le plan d’un langage de modélisation,
  • selon un angle de considération résultant de l’utilisation attendue du modèle,
  • pour obtenir une vision abstraite, partielle et formalisée du sujet (le modèle).

Figure n°1 : Principe de Modélisation

 1.2 Les concepts « objet »

Comme tout domaine de réflexion et de travail, le domaine « orienté-objet » relève de concepts, d’outils, de règles et d’éléments spécifiques. La légitimité de toute ambition d’évoluer ou d’étudier dans ce type d’espace passe par l’adoption et la compréhension de l’ensemble de ces notions propres au domaine « orienté-objet ».

1.2.1 L’objet

Les activités « orientées-objet » reposent, comme leur nom l’indique, sur le concept d’objet. Dans ce contexte, l’objet constitue la brique élémentaire à partir de laquelle ces activités se construisent. Dans une activité « orientée-objet », tout est objet. La bonne manipulation de ces briques élémentaires repose en partie sur la connaissance de leur nature, de leurs caractéristiques, de leurs aptitudes et de leur structure.

Un objet est donc une entité identifiée qui possède un comportement propre (des fonctions spécifiques) dépendant de son état interne et avec laquelle on peut interagir (échange de messages)

Cette définition informelle pose plusieurs questions :

  1. entité identifiée : Comment identifie-t-on et délimite-t-on les objets ?
  2. comportement propre : Qu’est-ce qui constitue pratiquement le comportement de l’objet ?
  3. état interne : Qu’est-ce qui caractérise l’état d’un objet ?
  4. interaction : Par quel procédé interagit-on avec un objet ?

Une partie des réponses à ses interrogations se trouvent dans la représentation structurelle des objets :

Figure n°2 : Structure d’un objet

  1. Si la question de la désignation des objets est évidemment résolue par la présence d’une dénomination de l’objet (le Nom de l’objet, qui traduit la continuité de son existence), le problème de la délimitation des objets demeure en suspens. Il s’agit d’une liberté laissée à la personne en charge de l’activité « orientée-objet » et en tant que telle, cette latitude permet d’une part d’exprimer une approche plus personnelle du sujet et d’autre part, elle accroît l’incertitude dans la façon d’aborder ce sujet. On peut néanmoins indiquer que les critères qui guident généralement la délimitation des objets relèvent du point de vue de description adopté (au sens où le point de vue a été abordé dans la partie Modélisation). Ainsi, pour décrire un ordinateur on pourra dire qu’il se compose d’une unité centrale, d’un écran, d’un clavier, d’une connectique (chacun de ces éléments étant lui-même décomposable) ou encore d’un système d’exploitation, d’une interface homme-machine, d’un logiciel de traitement de texte, de jeux, d’un navigateur (chacun de ces éléments étant également décomposable).
  2. Le comportement d’un objet est déterminé par les aptitudes dont il dispose (i.e. ses opérations). Ces fonctionnalités pourront être « déclenchées » en interne ou appelées de l’extérieur (par d’autres objets).
  3. L’état interne d’un objet est caractérisé par le vecteur de ses attributs. L’ensemble des valeurs des attributs d’un objet permet de situer l’objet dans l’ensemble des états auxquels il peut accéder.
  4. Concernant l’interaction avec l’objet, elle va porter essentiellement sur l’appel d’opérations depuis l’extérieur ou plus rarement sur l’intervention directe sur les attributs (et donc l’état) de l’objet.

1.2.2 La Classe

Du point de vue d’une activité « orientée-objet », les objets résultent de l’instanciation de classes (où l’instanciation est l’action de créer une entité réelle à partir d’un concept théorique). Une classe constitue donc à la fois le domaine de définition et la description générique d’un ensemble d’objets. Chaque objet appartient ainsi à une unique classe.

Une classe est une description générique d’une collection d’objets ayant une structure similaire

On peut illustrer les relations entre classes et objets à l’aide de la figure suivante :

Figure n°3 : Objets et classes (vue de principe et exemple)

1.2.3 L’Héritage

Une notion importante du monde de l’objet est le concept d’héritage. Cette idée permet de factoriser les éléments communs d’un ensemble de classes dans une classe plus générale. On dira par exemple que le vin, l’eau, la bière ou la vodka-orange héritent des propriétés des liquides ; et ce même s’ils disposent en plus de propriétés propres.

L’héritage permet de décrire les notions de spécialisation ou de généralisation

Il faut également noter que l’héritage peut être « multiple » (i.e. une classe hérite de plusieurs autres). Dans ce cas, le processus d’héritage n’effectue pas une union des propriétés héritées mais une somme, ce qui peut induire des conflits et des collisions de dénominations.

Figure n°4 : héritage et héritage multiple (vue de principe et exemple)

Forte de ces considérations théoriques, la suite du document va être consacrée à l’étude et à la description du formalisme UML en tant que langage de modélisation orientée-objet.



  1. Présentation d’UML

La modélisation et les formalismes existent depuis toujours (croquis, plans, maquettes…). La modélisation orientée-objet est apparue durant les années 70 et 80 suite à l’émergence de la programmation orientée-objet. En effet, il était indispensable d’associer à ces nouvelles techniques de développement de nouveaux outils de description adaptés. Entre 1989 et 1994, le nombre de méthodes et de langages de modélisation orientés objet est passé de moins de 10 à plus de 50. Parmi cet assortiment d’outils, 3 émergeaient plus particulièrement :

  • La méthode Booch (du nom de Grady Booch son concepteur),
  • La méthode OOSE (pour Object-Oriented Software Engineering crée par Ivar Jacobson),
  • La méthode OMT (pour Object Modeling Technique conçue par James Rumbaugh).

Face à l’évolution convergente de ces méthodes, leurs auteurs (Booch, Rumbaugh et Jacobson) ont décidé de s’associer au sein de l’entreprise Rational pour créer le langage UML (Unified Modeling Language) ; l’objectif de cet outil de modélisation étant d’unir les apports de leurs travaux respectifs. Le formalisme UML est « stabilisé » depuis 1997 (avec la mouture UML 1.1, ce qui n’empêche pas les évolutions puisque actuellement la toute récente version UML 2.0 fait référence) et est suivi par l’OMG (Object Modeling Group, autorité de normalisation liée à l’objet).

UML ne constitue aucunement une méthode de conception mais bien un langage de modélisation UML a été conçu selon les objectifs suivants :

  • Objectif longitudinal : accompagner l’ensemble du cycle de conception,
  • Objectif vertical : être adapté à toutes les échelles de modélisation (du plus haut niveau de considération à la prise en compte des détails les plus fins),
  • Objectif tranversal : être suffisamment compréhensible et convivial pour être facilement accessible à l’homme et être dans le même temps suffisamment formel et rigoureux pour être adapté au traitement informatique.

Comme tout langage évolué, UML propose :

  • Un vocabulaire :  un ensemble de symboles graphiques

Ce sont les éléments de modélisation propre à UML (classes, états, relations…) et leur sémantique (la signification de chaque symbole).

  • Une grammaire : un ensemble des règles d’agencement de ces symboles

Ce sont les lois de construction en UML (un état doit être relié à un autre état par une transition, les héritages ne doivent pas présenter de cycles, l’accès aux propriétés d’une classe par une autre classe dépend des relations qui les associent…).

  • Une liberté d’expression : un ensemble d’alternatives dépendantes du point de vue

Ce sont les différents diagrammes proposés par UML (ou combinaisons de diagrammes) qui peuvent être choisis selon l’angle de description (et donc de lecture) que l’on veut donner au modèle (vue structurelle : diagrammes de classes et d’objets, vue comportementale : diagrammes de séquences et d’états-transitions, vue architecturale : diagrammes de composants et de déploiement…).

Le formalisme UML peut être vu comme une boîte à outil offrant au concepteur un panel de diagrammes parmi lesquels il va choisir ceux qui sont adaptés à la finalité du modèle qu’il veut construire. Ces diagrammes sont les suivants :

  • Diagramme de cas d’utilisation : ensemble des contextes de mise en œuvre du sujet modélisé

Ce diagramme permet de représenter les fonctionnalités principales du système modélisé, considérées du point de vue de l’utilisateur.

  • Diagrammes de classes : description de la structure statique du sujet modélisé

Ce diagramme permet de décrire tout ou partie du système modélisé, d’une manière abstraite, en terme de classes, de structure et d’associations.

  • Diagrammes d’objets : description de la structure statique d’une instance du sujet modélisé

Ce diagramme permet de décrire des exemples de configuration de tout ou partie du système modélisé, en terme d’objets, de valeurs et de liens.

  • Diagrammes de séquence : représentation temporelle du comportement du sujet modélisé

Ce diagramme permet de décrire des scénarios au travers du séquencement des interactions entre les acteurs et composants du modèle (description chronologique).

  • Diagrammes de collaboration : représentation spatiale et temporelle du comportement du sujet

Ce diagramme permet de décrire l’agencement des chaînes fonctionnelles impliquées dans les scénarios. Ce diagramme est très proche du diagramme de séquence qu’il complète de notions de répartition physique des objets.

  • Diagrammes d’états-transitions : description du comportement spécifique d’une classe

Ce diagramme utilise les automates à états finis (statecharts) pour décrire l’activité propre d’une classe en terme d’états, d’évènements, d’actions, de conditions et de transitions permettant le changement d’état.

  • Diagrammes d’activité : description d’opérations en terme de succession d’actions

Ce diagramme permet de décrire le déroulement des fonctions et des processus par le biais de la représentation de l’organisation des sous-taches et des flux entre les objets.

  • Diagrammes de composants : projection du diagramme d’objets sur le plan physico-réel

Ce diagramme permet d’effectuer l’allocation des composants depuis une vue logique (diagramme de classes ou d’objets) vers la représentation et l’organisation des composants physiques qui implémenteront réellement le sujet et de leurs dépendances.

  • Diagrammes de déploiement : description de la mise en place de l’architecture du sujet modélisé

Ce diagramme permet de représenter le déploiement des composants sur les dispositifs matériels.

Cette présentation très théorique des éléments constitutifs du formalisme UML n’est destinée qu’à fournir une vision globale du langage et de son organisation. Cette approche « haut-niveau » sera reprise à l’issue de la présentation détaillée des différents diagrammes mais elle permet d’ores et déjà de positionner les composants qui vont être présentés (symboles et  conventions graphiques) dans l’organisation globale du langage UML.

Concernant la structure du formalisme UML, on peut en donner la première vision suivante :

Figure n°5 : Une répartition des diagrammes UML

Ces différentes « classifications » de l’espace des diagrammes UML (logique/physique, statique/dynamique, et fonctionnel/structurel/comportemental/architectural) permettent de déterminer les jeux de diagrammes à choisir en fonction du point de vue adopté. Le point de vue de modélisation tel qu’il a été présenté en préambule de ce document est principalement supporté en UML par le choix des vues du sujet qui doivent être décrites et donc par le choix des diagrammes au sein de ses vues. Afin de mieux appréhender la signification et l’intérêt de ces différentes vues on peut en donner les définitions partielles suivantes :

  • Vue logique : facette théorique du sujet. Cette vue, déconnectée de toute considération matérielle, fournit une description basée sur les rôles, les responsabilités et les relations associées.
  • Vue physique : aspect organique et matériel du sujet. Cette vue fournit une description basée sur les composants physiques qui implémentent réellement le sujet.
  • Vue statique : facette relative à l’agencement des composants. Cette vue s’apparente à une description figée du sujet fournissant une photographie de sa physionomie.
  • Vue dynamique : facette liée à l’activité du sujet. Cette vue fournit une représentation vivante du sujet et décrit ses comportements et ses réactions.
  • Vue fonctionnelle : facette relative aux contextes d’activité du sujet. Cette vue particulière relève d’une description externe du sujet en tant que fournisseurs de services à l’environnement et aux utilisateurs.
  • Vue structurelle : aspect organisationnel logique du sujet. Cette vue décrit la structuration des différents constituants fonctionnels du système.
  • Vue comportementale : facette liée au fonctionnement du sujet et de ses composants. Cette vue fournit une description des actions, processus et modes de fonctionnement sur divers niveaux de granularité.
  • Vue architecturale : aspect organisationnel physique du sujet. Cette vue décrit la structuration des différents composants matériels qui constituent organiquement le sujet

Toujours d’un point de vue « vision générale d’UML », ce formalisme de modélisation comprend en plus des 9 diagrammes évoqués un langage de description de contraintes. Ce langage nommé OCL (pour Object Constraints Language) permet d’ajouter une composante sémantique plus riche à certains diagrammes. Il faut comprendre que le graphe obtenu lors de la modélisation d’une facette d’un sujet selon un diagramme donné peut parfois manquer d’une nuance précise qu’on souhaiterait voir apparaître. Il est alors toujours possible d’associer une note au diagramme qui explicite cette notion (et c’est souvent ce qui est fait). Cependant, si l’on revient sur l’objectif tranversal évoqué en début de cette partie, il semble clair que l’interprétation par une machine de ces notes en langage naturel (par exemple lors de la génération de code à partir de modèle UML) est totalement utopique (aujourd’hui au moins). OCL pallie ce manquement en offrant un langage de contraintes formalisé qui pourra être interprété par un ordinateur (comme un langage de programmation). La description du langage OCL et de ses applications ne fait pas partie des objectifs de ce document.



La présentation détaillée d’UML qui va suivre s’articule autour de la découpe selon les différentes vues fonctionnelle, structurelle, comportementale et architecturale. Ce sont donc les diagrammes de cas d’utilisation qui sont présentées dans un premier temps (vue fonctionnelle) avant qu’on ne s’intéresse plus spécifiquement aux diagrammes de classes et d’objets (en tant que vue structurelle), puis au groupe comportementale avec les diagrammes de séquence, de collaborations, d’activité et d’états-transitions avant de terminer par les diagrammes de composants et de déploiement pour la vue architecturale.

  1. Modèle Fonctionnel

Les diagrammes de cas d’utilisation composent la vue fonctionnelle du formalisme UML. Ce sont des diagrammes cruciaux vis à vis de la cohérence et de la pertinence du modèle en cours de description. En outre, leur originalité et leur relative indépendance parmi les diagrammes UML leur confèrent une certaine spécificité qui nécessite une étude distincte.

3.1 Concepts de base

Un diagramme de cas d’utilisation fait appel à deux concepts :

  • L’acteur : entité extérieure en interaction avec le système
  • Le cas d’utilisation : une manière d’utiliser le système

3.1.1 Acteur

Les acteurs représentent les éléments externes aux délimitations du système qui sont amenés à interagir avec celui-ci. Ils comprennent aussi bien les acteurs humains (utilisateurs) que les acteurs d’autre type (machine, autre système, tout élément de l’environnement).

Les acteurs définissent les partenaires extérieurs interagissant avec le sujet

Les acteurs jouent un rôle important dans le travail de délimitation des frontière du sujet modélisé, ils permettent de positionner le système dans son environnement en représentant son entourage actif .

Un acteur se représente graphiquement sous la forme d’un personnage accompagné de sa désignation (visuel créé avec Objecteering UML Modeler) :

Figure n°6 : Aspect visuel d’un acteur

3.1.2 Cas d’utilisation

Les cas d’utilisation répondent à la question « pour quoi le système va-t-il être utilisé ? » (Quels services va-t-il rendre, vu de l’extérieur ?) et décrivent les rôles du sujet. Ces symboles représentent le point de vue des utilisateurs du système.

Les cas d’utilisation décrivent les fonctionnalités externes du sujet

Il faut également noter que les cas d’utilisation couvrent implicitement l’ensemble des scénarios opérationnels associés au sujet (vu de l’extérieur en tant qu’entité globale).

Un cas d’utilisation se représente graphiquement sous la forme d’une figure ovale (éventuellement incluse dans un cadre structurant) complétée de la fonctionnalité représentée (visuel créé avec Objecteering UML Modeler) :

Figure n°7 : Aspect visuel d’un cas d’utilisation

3.2 Diagramme de cas d’utilisation (Use-Case Diagram)

L’objet d’un diagramme de cas d’utilisation est de positionner le système dans son contexte opérationnel et de décrire les « nouvelles règles de fonctionnement » issues de sa mise en œuvre. Ce type de diagrammes se consacre à la description des interactions du sujet avec les acteurs qui l’entourent.

Les diagrammes de cas d’utilisation présentent l’intégration du sujet dans son environnement en s’intéressant à sa description fonctionnelle

Le formalisme associé est relativement simple afin de faciliter l’expression du besoin et le dialogue avec le maître d’ouvrage. La construction de diagrammes de cas d’utilisation est une excellente façon d’aborder la description et la conception d’un système.

Les relations admises au sein d’un diagramme de cas d’utilisation sont les suivantes :

  • Les relations de type déclenchement qui relient un acteur à un cas d’utilisation : ces relations sont représentées sous la forme d’un trait simple et traduisent l’implication d’un acteur vis à vis d’un cas d’utilisation (du type l’acteur déclenche le cas d’utilisation),
  • Les relations de type inclusion ou utilisation qui relient deux cas d’utilisation : ces relations sont représentées sous la forme d’une flèche pointillée accompagnée du terme « include » et traduisent le fait que le cas d’origine contient obligatoirement le cas destination,
  • Les relations de type extension ou raffinement qui relient deux cas d’utilisation : ces relations sont représentées sous la forme d’une flèche pointillée accompagnée du terme « extend » et traduisent le fait que le cas d’origine peut optionnellement être rajouté au cas destination,
  • Les relations de type généralisation ou spécialisation qui relient deux cas d’utilisation : ces relations sont représentées sous la forme d’une flèche pleine à pointe triangulaire vide et traduisent le fait que le cas d’origine peut remplacer le cas destination.

Pour illustrer ces concepts relatifs à la construction d’un diagramme de cas d’utilisation, on peut s’intéresser à la description des fonctionnalités d’un système de gestion de commande en ligne pour un organisme de VPC (visuel créé avec Objecteering UML Modeler) :

Figure n°8 : Exemple de diagramme de cas d’utilisation

  1. Modèle Structurel

Les diagrammes de classes et d’objets composent la vue structurelle du formalisme UML. Le diagramme de classes décrit de manière abstraite une vision générique du sujet alors que le diagramme d’objets décrit un exemple de configuration du système.

4.1 Diagramme de classes (Class Diagram)

Un diagramme de classe décrit l’agencement de classes connectées par des relations de différents types. Ce type de diagramme fait partie de la vue structurelle du sujet et participe à sa description logique et statique.

Les diagrammes de classes décrivent la structure logique du sujet sous une vision orienté-objet

Une classe décrit un groupe d’objets ayant la même structure (même ensemble d’attributs) et le même comportement (mêmes opérations). Les relations signifient la sémantique de l’organisation des classes.

4.1.1 Classe

Le formalisme UML décrit une classe en utilisant la symbolique suivante (visuel créé avec Objecteering UML Modeler) :

Figure n°9 : Représentation graphique d’une classe (vue de principe et exemple)

Le nom d’une classe est unique. Il est dit « simple » lorsqu’il est de la forme NomClasse et « complet » lorsqu’il est de la forme NomPackage::NomClasse (où NomPackage désigne l’ensemble de classes dans lequel la classe NomClasse est incluse).

Un attribut représente une propriété de la classe modélisée (il sera donc commun à tous les objets de la classe et pour chaque objet il sera valué). La notation complète d’un attribut est la suivante :

[visibilité] nomAttribut [ [multiplicité] ] [:type] [=valeur initiale] [ {propriétés} ]  [ ] : éléments optionnels

    + - #             [0..1], [n]            {constant, addOnly}

exemple :       + taille : real = 1,8 qui signifie que les objets de cette classe ont un attribut taille de type réel, d’accès publique et dont la valeur par défaut est 1,8 (en rajoutant constant, on aurait pu interdire de le modifier pour préciser par exemple que tous les objets ont définitivement une taille de 1,8).

Une méthode (opération) est l’implémentation d’un service qui peut être demandé à tous les objets de la classe modélisée. Les méthodes sont associées au comportement. La notation complète d’une méthode est la suivante :

[visibilité] nomMéthode [ (paramètres:types) ] [:type retourné] [ {propriétés} ]  [ ] : éléments optionnels

    + - #    ( param1:type1, param2:type2 )             {query, abstract}



exemple :       - moyenne(a,b:real):real qui signifie que les objets de cette classe ont une méthode moyenne qui prend en entrée deux réels (a et b) et fournit un résultat réel. Cette méthode est privée (visible pour la classe).

En terme de lisibilité de la classe, on se contente généralement de faire apparaître sur le modèle les attributs et méthodes importants pour sa compréhension (ce qui n’empêche leur existence mais les outils informatiques UML permettent généralement de cacher certains attributs ou méthodes). Les stéréotypes (noms entre guillemets, par exemple : « caractéristiques visuelles » ou « propriétés dynamiques ») permettent de structurer l’affichage des attributs et des méthodes (plutôt que de les montrer en vrac).

Il est possible d’ajouter un 4ème compartiment à la représentation graphique d’une classe : la responsabilité. Ce compartiment permet de décrire les attentes vis à vis de la classe. Cette notion de responsabilité permet de revenir sur les critères de découpe d’un sujet en classe. En général, il est pertinent de se contenter d’une ou deux responsabilités par classes. Si les classes sont trop vastes (modèle peu réutilisable) ou si elles sont trop petites (modèle trop abstrait), le modèle risque d’être peu représentatif et inexploitable.

4.1.2 Relations entre classes

Le formalisme UML associe aux classes un certain nombre de relations permettant d’expliciter leurs rapports.

4.1.2.1 Généralisation / Spécialisation

Il s’agit d’une relation entre une classe-mère (ou super-classe) et une classe-fille (ou sous-classe) qui décrit la relation d’héritage entre la classe-fille et la classe-mère : la sous-classe est dérivée de la super-classe (elle hérite de l’ensemble de ses propriétés : attributs, méthodes, associations). La représentation graphique est la suivante (visuel créé avec Objecteering UML Modeler) :

Figure n°10 : Représentation de la relation de généralisation / spécialisation (vue de principe et exemple)

Ce type de relation permet l’introduction de classes dites abstraites. Il s’agit de classes dont le nom est indiqué en italique et qui ne peuvent pas être instanciées. Arbre est une classe abstraite dans la mesure où tout arbre réel instancie une espèce donnée et non la classe Arbre (il n’existe pas d’arbre d’aucune espèce).

L’héritage peut être multiple (une classe-fille héritant de plusieurs classes-mères) afin de préciser en particulier la nature multiple d’une classe. Ce type d’héritage peut s’avérer relativement délicat à manipuler du fait des « collisions » qui peuvent être entraînées parmi les attributs et les méthodes. En effet, la classe-fille n’hérite pas de l’union des caractéristiques de ses classes-mères mais de la somme. Si les classes-mères disposent de propriétés communes, la classe-fille hérite des deux propriétés (estampillées chacune de leur provenance afin de les différencier).

Ces considérations amènent à évoquer la notion de polymorphisme. Une classe-fille peut redéfinir ou simplement compléter une propriété héritée d’une classe mère (en particulier une méthode qui peut être précisé dans le cadre d’utilisation de la classe-fille). Les descendants de la classe-fille hériteront théoriquement de la nouvelle propriété (celle affinée par la définition de la classe-fille) qui remplace la propriété initiale dans la chaîne d’héritage. En pratique, les outils logiciels de modélisation orientée objet ont tendance à conserver les deux propriétés dans la chaîne d’héritage (dès la classe qui redéfinit la propriété et qui possède ainsi les deux versions) et à laisser à la phase d’utilisation de ces propriétés la responsabilité de préciser celle qui est utiliser (si la précision n’est pas donnée, c’est la version la plus récente de la propriété, i.e. celle redéfinie, qui devient prioritaire). Cette notion de redondance de signature de propriété est désignée sous le terme de polymorphisme.

Concernant les notions d’héritage multiple, la représentation graphique est la suivante (visuel créé avec Objecteering UML Modeler) :

Figure n°11 : Représentation d’héritages multiples (exemple issu d’une application bancaire)

4.1.2.2 Association

Il s’agit de la relation la plus générale entre classes. Cette relation permet de donner du sens (l’association est complétée d’indications sémantiques) à un lien organisationnel entre classes.

L’association permet de décrire une relation structurelle entre classes, enrichie d’un contenu sémantique

Une association peut concerner une seule classe (association unaire) ou plusieurs classes (association binaire ou n-aire). La représentation graphique est la suivante (visuel créé avec Objecteering UML Modeler) :

Figure n°12 : Représentation d’associations entre classes (vue de principe et exemple)

Une association peut contenir un descriptif (qui donne du sens à l’association et justifie son existence), des cardinalités (1 = un et un seul, 1..* = au moins 1, n = une valeur précise, * = une valeur quelconque) qui précise dans quelles quantités l’association doit être instanciée, des rôles qui permettent de préciser l’implication de chaque classe dans l’association.

Il faut noter qu’il est également possible d’enrichir la description d’une association en complétant sa description à l’aide d’une classe qui est dédiée à l’association. Cette classe s’appelle alors une Classe-association et présente les caractéristiques d’une classe (héritage, relations, attributs, méthodes…) et celles d’une association (descriptif, cardinalités, rôles…)  :

  • Ce type de relation traduit le fait que la classe-association n’est liée aux deux classes composant l’association que du fait de l’existence d’une relation entre elles (et non pas liée à chacune d’elle indépendamment).
  • Ce type d’entité correspond globalement à un besoin de décrire les propriétés et les caractéristiques de l’association entre les deux classes (c’est une amplification de la représentation de l’association).



742