Chapitre 3

La modélisation – UML

3.1 LA NOTION DE MODÈLE

3.1.1. Définition d’un modèle
Marvin Minsky donne la définition suivante d’un modèle : « pour un observateur B, un objet
A∗ est un modèle d’un objet A s’il permet à B de répondre à une question qu’il se pose sur
A » [Min65].
On peut prolonger cette définition en précisant qu’un modèle est une représentation
simplifiée, on dit souvent « abstraite », de la réalité – c’est l’objet de Minsky – qui met en
évidence certains aspects jugés comme étant significatifs dans le contexte considéré – ce sont
les réponses aux questions de Minsky.
C’est donc une vue « orientée » de la réalité, fonction des objectifs visés. Par exemple,
une carte est un modèle qui peut mettre en avant soit les villes et les routes pour faciliter
les déplacements des automobilistes, soit les caractéristiques géographiques (cours d’eau,
forêts, montagnes, etc.) pour informer les promeneurs, soit les limites administratives
(régions, départements, cantons, arrondissements, etc.) pour les personnes impactées par ces
découpages territoriaux.
Modéliser un objet peut servir à mieux le comprendre, comme en physique, ou à mieux le
construire, comme en ingénierie. Dans tous les cas, le modèle est avant tout un vecteur de
communication.
46 Partie 1. Le développement logiciel

3.1.2. Caractéristiques d’un modèle

Un modèle peut être exprimé par des mathématiques, des mots ou des représentations
visuelles. En raison de son importance en informatique la catégorie visuelle est détaillée au
paragraphe 3.2.
Un modèle peut être exprimé à divers niveaux de précision (abstraction). C’est une erreur
classique de croire que plus un modèle est détaillé plus il est juste. En réalité, juste est le
contraire de faux, alors que détaillé est le contraire de général.
On utilise souvent plusieurs modèles pour décrire tous les aspects d’un système complexe,
plusieurs « vues ». On distingue le plus souvent trois vues principales pour un logiciel : la
vue fonctionnelle qui décrit les services rendus, la vue structurelle (statique) qui décrit les
composants et la vue comportementale (dynamique) qui décrit les évolutions.

F IGURE 3.1 Les trois vues essentielles d’un logiciel

3.1.3. Des conseils pour modéliser

Scott Ambler et Ron Jeffries [AJ02] proposent des conseils de modélisation de bon sens qui
dépassent le cadre des seules approches agiles dont ils parlent. Beaucoup d’entre eux peuvent
concerner toutes les formes de développement logiciel :
– Le but principal des développeurs est de produire du logiciel, pas des modèles.
– Il faut « voyager léger », c’est-à-dire éviter de créer des modèles non indispensables.
– Il faut s’efforcer de produire les modèles les plus simples possibles qui décrivent de
manière adéquate le problème ou le logiciel.
– Il faut construire des modèles « utiles » et oublier l’idée de modèles « parfaits ».
– Il ne faut pas se polariser sur la syntaxe du modèle. Ce qui est important c’est que le
modèle communique avec succès des idées.
– Il faut essayer d’obtenir du feedback aussitôt que possible, par des revues.
3 • La modélisation – UML 47

3.2 LA MODÉLISATION VISUELLE

Tout le monde connaît l’adage célèbre « un beau dessin vaut mieux qu’un long discours ».
Il s’explique par le fait que les langages visuels sont « naturels » et « faciles » pour le
cerveau humain. On estime en effet qu’au moins 50 % de notre cerveau est impliqué dans
les processus visuels.
Les modèles visuels et schématiques sont efficaces à condition toutefois qu’ils soient compris
par tous de la même manière. C’est-à-dire, si la sémantique de leurs éléments visuels est
suffisamment précise et partagée par tous les lecteurs.
La modélisation visuelle tient depuis toujours une rôle important en développement logiciel :
organigrammes, schéma entités/associations, SADT, réseaux de Petri, UML, etc.

3.3 FONCTIONS ET OBJETS

3.3.1. La décomposition fonctionnelle
Dans cette approche, la fonction donne la forme. Le système est décomposé selon les
fonctions qu’il assure. L’analyse se conduit souvent de manière descendante, par raffinements
successifs, jusqu’à l’obtention de fonctions élémentaires, facilement compréhensibles et
implantables. C’est la stratégie du « diviser pour régner ».
Cette approche a été beaucoup utilisée dans le passé pour les applications de gestion, dans le
cadre de processus de développement linéaires. Pour ces applications, l’état du système (ses
données) est centralisé et partagé par les fonctions.

F IGURE 3.2 Décomposition fonctionnelle

3.3.2. La décomposition objet

Dans cette approche, la fonction est réalisée par des objets inspirés du monde réel qui
interagissent.
Exemple
La figure 3.3 donne quelques objets inspirés de la réalité qui interagissent pour réaliser la
fonction d’appel d’un ascenseur.
48 Partie 1. Le développement logiciel

F IGURE 3.3 Décomposition objet

Un objet regroupe données et fonctions. L’état du système est distribué entre tous les objets.
Cette approche présente des avantages dus à la modularité et la réutilisabilité des objets. Elle
est bien adaptée aux processus de développement itératifs et incrémentaux.
Le paragraphe suivant donne de courtes définitions des principaux concepts de l’orientation
objet. Le lecteur trouvera dans le volume dédié à la conception [Lon14] un chapitre beaucoup
plus étoffé sur ces concepts en lien avec la programmation Java.

3.3.3. Brefs rappels sur les concepts objet

Orientation objet : organisation d’un logiciel sous la forme d’une collection d’objets qui
incorporent structure de données et comportement.
Objet : regroupe identité, état (valeurs des attributs) et comportement (méthodes).
Identité : tout objet possède une identité unique et invariable, qui permet de le distinguer des
autres objets. Cette identité est indépendante des valeurs des attributs.
Attributs : variables stockant des informations d’état de l’objet.
Méthodes : opérations que l’objet est à même de réaliser et qui caractérisent son
comportement. Ces opérations permettent de faire réagir l’objet aux sollicitations
extérieures et d’agir sur les autres objets.
Les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des
valeurs des attributs et/ou les modifier.
Classification : regroupement dans des classes des objets ayant même structure de données
(attributs) et même comportement (opérations).
Classe : abstraction décrivant un ensemble d’objets potentiellement infini partageant la
même structure et le même comportement. Génératrice d’instances conformes au modèle
qu’elle définit.
Instance d’une classe : objet appartenant à la classe.
Héritage ou généralisation/spécialisation : on peut définir une classe (la sous-classe ou
classe fille) à partir d’une autre classe (la superclasse ou classe mère). Les objets de
la sous-classe héritent de tous les attributs et de toutes les méthodes de la superclasse et
peuvent en ajouter d’autres.
3 • La modélisation – UML 49

La sous-classe est une spécialisation de la superclasse. La superclasse est une

généralisation de la sous-classe.
Polymorphisme : possibilité de comportements différents d’une même opération selon les
situations (vient du grec ancien polús qui signifie nombreux et morphê qui signifie forme).
Le polymorphisme s’appuie sur le fait que les méthodes sont appelées en fonction du type
réel (dynamique) de l’objet, c’est-à-dire la classe dont il est instance, et non pas du type
de la variable dans laquelle il est stocké (type statique).
Le polymorphisme permet que certaines parties du code, écrites de manière « générique »
avec les types statiques, soient exécutées de manières différentes en fonction des types
réels des objets.
Délégation : on parle de délégation quand une classe (cliente) délègue à une autre classe
(serveuse) une partie de son activité. Il y a donc réutilisation de code. Une raison peut
être le souhait de séparer du reste ce qui est susceptible d’évoluer souvent.
La délégation s’implante grâce à un attribut de la classe cliente contenant une référence
vers la classe serveuse. En changeant la référence on peut changer le comportement, y
compris pendant l’exécution.
Interface : une interface est la définition abstraite d’un type, indépendamment de la façon
dont il est implanté (type abstrait). Concrètement, c’est un ensemble de méthodes
publiques abstraites.
Il est très conseillé de typer aux maximum les variables par des interfaces (qui évoluent
peu) plutôt que par des implantations (qui sont susceptibles d’évoluer plus souvent).
Association : une association représente une relation sémantique particulière entre des
classes, qui porte un nom.
La relation d’héritage ci-dessus et d’agrégation/composition ci-après sont des formes
particulières d’association qui ne portent pas de nom.
Agrégation et composition : une agrégation est une association avec une sémantique du
type « un tout (un agrégat) vers les parties de ce tout ».
Une composition est une agrégation particulière dans laquelle la durée de vie des parties
est liée à celle du tout : les parties ne peuvent exister que si l’agrégat existe. Si l’agrégat
est supprimé les parties le sont aussi.

3.4 LE LANGAGE UML

3.4.1. Présentation d’UML
UML (Unified Modeling Language) est un langage visuel normalisé qui aide à découvrir,
spécifier et documenter les artefacts d’une application orientée objets tout au long de son
développement. Ses 4+1 vues couvrent les aspects fonctionnels, structurels (statiques),
comportementaux (dynamiques), d’implantation et de déploiement (cf. figure 3.4).
UML est un langage qui n’est pas lié à un processus de développement objet particulier.
En UML, les mêmes concepts et la même notation sont utilisables tout au long du processus
de développement, mais avec des changements d’objectifs et des changements de niveaux
de détail (d’abstraction). Concrètement, une classe de conception comporte plus de détails
50 Partie 1. Le développement logiciel

F IGURE 3.4 Les 4+1 vues d’UML

qu’une classe conceptuelle (« métier ») et moins de détails qu’une classe qui documente
un code. Par exemple, les classes conceptuelles ne portent pas d’opérations, les classes de
conception précisent les noms des principales opérations, les classes qui documentent le code
donnent les profils détaillés des opérations avec les types de leurs paramètres.

3.4.2. Modes d’utilisation d’UML

La richesse et la flexibilité de la notation UML autorisent plusieurs modes d’utilisation.
Martin Fowler en distingue trois [Fow03].

a) « UML as sketch »
Dans les approches agiles qui seront détaillées dans les deux chapitres suivants, c’est
l’aspect découverte qui est mis en avant, avec une utilisation d’UML en mode « esquisse »
(sketch), c’est-à-dire sans trop de détails, centrée sur les seuls aspects difficiles et conduite
en collaboration autour d’un tableau blanc, plutôt qu’avec un environnement de modélisation
sophistiqué.

b) « UML as blueprint »
Dans les approches classiques (prescriptives) qui seront également évoquées au chapitre
suivant, c’est l’aspect modélisation systématique qui est mis en avant. L’analyse produit des
modèles pour mieux comprendre le problème et la conception produit des modèles pour
mieux implanter le système. Ces derniers modèles sont progressivement détaillés jusqu’à
ce que les codeurs n’aient plus que des décisions de détail à prendre. Des squelettes de
programmes peuvent être générés. Les modèles peuvent aussi pour partie être reconstruits
à partir du code (reverse engineering).
Dans ce mode, les environnements de modélisation (CASE tools) sont préconisés.

c) « UML as programming language »

Enfin, dans la mouvance des approches dirigées par les modèles (Model Driven Architecture
ou MDA), l’objectif est de parvenir à une extension d’UML suffisamment précise en termes
de sémantique pour permettre la génération complète ou presque de l’application à partir des
modèles.
3 • La modélisation – UML 51

3.5 LES PRINCIPAUX DIAGRAMMES UML

Cinq diagrammes UML jouent un rôle prépondérant dans le cadre des phases en amont de la
conception. Ils sont brièvement présentés ci-après 1.
Cet ouvrage fait l’hypothèse que les notations UML de base sont connues et que la pratique
de la modélisation élémentaire est acquise. Les exercices en fin de chapitre mettent en œuvre
quelque-unes de ces compétences supposées acquises.

3.5.1. Le diagramme de cas d’utilisation

Il est fondamental en ingénierie des besoins. Il synthétise les interactions entre les acteurs
et l’application. Les cas d’utilisation et les diagrammes de cas d’utilisation sont étudiés en
détail au chapitre 11.

F IGURE 3.5 Diagramme de cas d’utilisation

3.5.2. Le diagramme de classes

Il est essentiel dans toute analyse et conception orientées objets.

F IGURE 3.6 Diagramme de classes

1. Les diagrammes de l’ouvrage ont été générés avec le logiciel libre PlantUML (plantuml.sourceforge.net).
52 Partie 1. Le développement logiciel

Au stade de l’analyse, il sert essentiellement à décrire la nature des concepts du domaine

applicatif (modèle des classes du domaine). Au stade de la conception, il représente, à
différents niveaux de détail, l’organisation du code orienté objet.

3.5.3. Le diagramme de séquences

Il précise les échanges de messages entre objets, dans le cadre d’un fonctionnement particulier
du système. Au stade de l’analyse, il sert à exprimer les scénarios d’utilisation du système.
Au stade de la conception, il sert à montrer les enchaînements d’appels de méthodes entre les
objets qui contribuent à implanter une certaine fonctionnalité complexe.

F IGURE 3.7 Diagramme de séquences

3.5.4. Le diagramme d’états

Il détaille le cycle de vie des objets d’une certaine classe. Il permet de préciser la description
des classes complexes en montrant leurs différents états et les transitions possibles entre eux.
Il peut également être utilisé pour décrire la navigation dans une application web ou dans
l’IHM interactif d’une application classique.

F IGURE 3.8 Diagramme d’états

3 • La modélisation – UML 53

3.5.5. Le diagramme d’activités

Il représente les enchaînements d’actions et de décisions au sein d’une activité. Il peut
également être utilisé comme alternative au diagramme d’états pour décrire la navigation
dans une application web ou dans l’IHM interactif d’une application classique.

F IGURE 3.9 Diagramme d’activités

54 Exercices

EXERCICES

Exercice 3.1. Modélisation des relations

Classer les relations suivantes en généralisation/spécialisation, agrégation ou association.
(1) Un pays possède une capitale.
(2) Un philosophe qui dîne utilise une fourchette.
(3) Un fichier est un fichier ordinaire ou un répertoire.
(4) Les fichiers contiennent des enregistrements.
(5) Un polygone se compose d’un ensemble ordonné de points.
(6) Un développeur emploie un langage informatique pour un projet.
(7) Les modems et les claviers sont des périphériques d’entrée/sortie.
(8) Les classes d’objets peuvent avoir plusieurs attributs.
(9) Un joueur joue dans une équipe pendant une année donnée.
(10) Une route relie deux villes.

Exercice 3.2. Diagramme de classes

Donner les schémas de classes d’un graphe non orienté et d’un graphe orienté (sans sommets
isolés), conformes aux figures ci-après.

Exercice 3.3. Diagramme d’états

Donner un diagramme d’états qui décrit la dynamique d’un thread (processus léger) définie
de la manière suivante.
Le thread est :
– non_démarré, initialement,
– en_cours, lorsqu’il possède toutes ses ressources applicatives plus le processeur,
– en_attente, lorsqu’il lui manque une ressource applicative,
– prêt, lorsqu’il a toutes ses ressources applicatives et pas le processeur,
– terminé, lorsqu’il a fini son exécution.

Le thread reçoit des événements qui le font changer d’état :

3 • La modélisation – UML 55

– début, au démarrage du thread (start en Java, execlv en Unix, etc.). Avant la réception
de début, le thread est non_démarré.
– ressource_attendue, correspond à l’indication qu’une ressource applicative requise
n’est pas disponible.
– ressource_OK, correspond à la libération d’une ressource applicative par un autre
thread et à sa réservation.
– processeur_OK, correspond à la libération du processeur par un autre thread et à son
utilisation.
– fin correspond soit à l’exécution de la dernière instruction du programme exécuté par le
thread soit à la réception d’un événement pour tuer définitivement le thread. Sur réception
de fin, le thread devient terminé.

Exercice 3.4. Diagramme d’activités

Donner un diagramme d’activités qui rende compte du processus suivant.
Dans un garage, le chef d’atelier ouvre une « fiche réparation » pour chaque véhicule traité.
Le magasinier ajoute à la fiche les pièces utilisées. En parallèle, le chef d’atelier ajoute à
la fiche les temps passés par les mécaniciens. Quand la réparation est validée par le chef
d’atelier, la fiche sert de base à la facturation, effectuée à la comptabilité.

Exercice 3.5. Diagramme de séquences

On considère une application de type carnet d’adresses avec laquelle l’utilisateur peut ouvrir
et fermer le carnet, chercher, ajouter, supprimer et modifier des adresses.
Donner un diagramme de séquences montrant les interactions entre l’utilisateur et
l’application (considérée comme un objet unique) pour un scénario où l’utilisateur ajoute
une adresse puis en modifie une autre.
On modélisera la possibilité de succès et la possibilité d’échec des opérations.