MODELISATION ORIENTÉE OBJET UML

Etablissement : 3iA

Département : Génie Logiciel

Enseignant : Mme NANFACK DJIOGO B. L.

Objectifs : Ce cours vise à rendre l’apprenant capable de :

➢ Comprendre les Principes de la modélisation

orientée-objet
➢ Manipuler quelques Méthodes d’analyse orientée
objet
➢ Faire une Comparaison entre divers langages de programmation orientée objet

PROGRAMME D’ENSEIGNEMENT
CHAPITRE 1 PRÉSENTATION DE UML

CHAPITRE 2 - LES CONCEPTS DE L’APPROCHE PAR OBJETS

CHAPITRE 3 - LA MODÉLISATION DES EXIGENCES

CHAPITRE 4 - LA MODÉLISATION DE LA DYNAMIQUE

CHAPITRE 5 - LA MODÉLISATION DES OBJETS

CHAPITRE 6 - LANGAGES DE PROGRAMMATION ORIENTES OBJETS

Modélisation Orientée Objet Page 1

 CHAPITRE 1 PRÉSENTATION UML

A. LIMITES DE L’APPROCHE FONCTIONNELLE

Ø La découpe fonctionnelle d'un problème informatique : une approche intuitive : La
découpe fonctionnelle d’un problème (sur laquelle reposent les langages de
programmation structurée) consiste à découper le problème en blocs indépendants. En ce sens,
elle présente un caractère intuitif fort.

Ø La réutilisabilité du code Le découpage d’un problème en blocs indépendants

(fonctions et procédures) va permettre aux programmeurs de réutiliser les fonctions déjà
développées (à condition qu’elles soient suffisamment génériques). La productivité se trouve
donc accrue.

Ø Le revers de la médaille : maintenance complexe en cas d'évolution Le découpage en

blocs fonctionnels n'a malheureusement pas que des avantages. Les fonctions sont
devenues interdépendantes : une simple mise à jour du logiciel à un point donné, peut impacter
en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on
utilise des fonctions plus génériques et des structures de données ouvertes. Mais respecter
ces contraintes rend l'écriture du logiciel et sa maintenance plus complexe. En cas
d'évolution majeure du logiciel (passage de la gestion d'une bibliothèque à celle d'une
médiathèque par exemple), le scénario est encore pire. Même si la structure générale du
logiciel reste valide, la multiplication des points de maintenance, engendrée par le chaînage
des fonctions, rend l'adaptation très laborieuse. Le logiciel doit être retouché dans sa
globalité :
- On a de nouvelles données à gérer (ex : DVD)
- Les traitements évoluent : l’affichage sera différent selon le type (livre, CD, DVD
…)

o Problèmes générés par la séparation des données et des traitements : Examinons le

problème de l'évolution de code fonctionnel plus en détail.
Faire évoluer une application de gestion de bibliothèque pour gérer une médiathèque, afin de
prendre en compte de nouveaux types d'ouvrages (cassettes vidéo, CD-ROM, etc), nécessite :
- De faire évoluer les structures de données qui sont manipulées par les
fonctions,
- D’adapter les traitements, qui ne manipulaient à l'origine qu'un seul type de
document (des livres).
Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour
gérer les données et les actions propres aux différents types de documents. Il faudra par exemple
modifier la fonction qui réalise l'édition des "lettres de rappel" (une lettre de rappel est une
mise en demeure, qu'on envoie automatiquement aux personnes qui tardent à rendre un ouvrage
emprunté). Si l'on désire que le délai avant rappel varie selon le type de document emprunté, il
faut prévoir une règle de calcul pour chaque type de document.

En fait, c'est la quasi-totalité de l'application qui devra être adaptée, pour gérer les
nouvelles données et réaliser les traitements correspondants. Et cela, à chaque fois qu'on décidera de
gérer un nouveau type de document !

B. GENESE D’UML
UML (Unified Modeling Language ou langage unifié de modélisation) est un langage
graphique destiné à la modélisation de systèmes et de processus. UML est un langage basé sur
l’approche par objets, et provient de plusieurs notations qui l’ont précédé. Aujourd’hui, UML
est promu par l’OMG (Object Management Group), un consortium de plus de 800 sociétés et
universités actives dans le domaine des technologies de l’objet.
UML est sémantiquement riche, il est donc assez difficile de retenir tous ses concepts. Nous
espérons que cet ouvrage vous sera utile pour les appréhender et les mémoriser. Lorsque vous
serez amené à modéliser en UML, nous espérons également que le présent document vous servira
de guide dans la mesure ou il est basee sur un .ouvrage de reference editee par la celebre maison
d’edition Editions ENI.
UML est basé sur l’approche par objets. Cette dernière voit le jour bien avant UML dans le
domaine des langages de programmation. Simula, le tout premier langage à objets est né dans les
années 1960. Ce langage connaît de nombreux successeurs : Smalltalk, C++, Java ou plus récemment
C#.
Dans un langage de programmation, la description des objets est réalisée de façon formelle
avec une syntaxe rigoureuse. Cette syntaxe n’est pas lisible par des non-programmeurs et reste
difficile à déchiffrer pour des programmeurs. À la différence des machines, les humains
préfèrent utiliser les langages graphiques pour représenter des abstractions. Ils maîtrisent ce type
de langage plus facilement et obtiennent une vue d’ensemble d’un système en un temps beaucoup plus
court.
Dans les années 1980 et au début des années 1990, les notations graphiques se multiplient,
chacun utilisant bien souvent sa propre notation. En 1994, James Rumbaugh et Grady Booch
décident de se regrouper pour unifier leurs notations. Celles-ci provenaient de leurs méthodes
: OMT pour James Rumbaugh et méthode Booch pour Grady Booch. En 1995, Yvar Jacobson
décide de rejoindre l’équipe des "trois amigos". Cette équipe travaille alors au sein de Rational
Software.
La version 1.0 d’UML est publiée en 1997. Le travail d’évolution de la notation est
devenu trop important pour trois personnes. Les trois amigos demandent l’aide de l’Object
Management Group (OMG), un consortium de plus de 800 sociétés et universités travaillant dans le
domaine des technologies de l’objet. La notation UML est adoptée par l’OMG en novembre 1997
dans sa version 1.1. L’OMG crée en son sein une
Task Force chargée de l’évolution d’UML Depuis cette époque, cette Task Force a mis à jour
UML plusieurs fois. En mars 2003, la version 1.5 voit le jour et la version récente de UML est 2.5,
elle constitue la première évolution majeure depuis la sortie d’UML en 1997. De nouveaux
diagrammes ont été ajoutés et les diagrammes existants ont été enrichis de nouvelles
constructions.Rappelons qu’UML est une notation(langage) destinée à la modélisation par
objets de systèmes et de processus. UML ne contient pas un guide méthodologique (une
méthode ou processus) mais constitue un support de modélisation. Les méthodes de modélisation
basées sur UML sont nombreuses (XP, UP, RUP ...).
 CHAPITRE 2 - LES CONCEPTS DE L’APPROCHE PAR
OBJETS
Ce chapitre a pour objectif de vous faire découvrir les différents concepts et principes de
l’approche objet qui sont à la base d’UML. Leur connaissance est indispensable pour comprendre
les éléments utilisés dans la panoplie des diagrammes d’UML qui seront abordés dans les chapitres
suivants.
A. L’objet
Un objet est une entité identifiable du monde réel. Il peut avoir une existence physique
(un cheval, un livre) ou ne pas en avoir (un texte de loi). Identifiable signifie que l’objet peut être
désigné.
Exemple :
- Ma jument Jorphée
- Mon livre sur UML
- L’article 15 du code de procédure pénal
En UML, tout objet possède un ensemble d’attributs (sa structure) et un ensemble de
méthodes (son comportement). Un attribut est une variable destinée à recevoir une valeur. Une
méthode est un ensemble d’instructions prenant des valeurs en entrée et modifiant les valeurs des
attributs ou produisant un résultat. Même un objet statique du monde réel est toujours perçu
comme dynamique. Ainsi en UML, un livre est perçu comme un objet capable de s’ouvrir lui-
même à la énième page. Tout système conçu en UML est composé d’objets interagissant entre eux
et effectuant les opérations propres à leur comportement.
Exemple : Un troupeau de chevaux est un système d’objets interagissant entre eux, chaque objet
possédant son propre comportement. Le comportement global d’un système est ainsi réparti entre
les différents objets. Dans notre exemple, il suffit de faire le parallèle avec le monde réel pour le
comprendre.
B. L’abstraction
L’abstraction est un principe très important en modélisation. Elle consiste à retenir
uniquement les propriétés pertinentes d’un objet pour un problème précis. Les objets utilisés en
UML sont des abstractions d’objets du monde réel. L’abstraction est une simplification
indispensable au processus de modélisation. Un objet UML est donc une abstraction de l’objet du
monde réel par rapport aux besoins du système, dont on ne
retient que les éléments essentiels
Exemple : On s’intéresse aux chevaux pour l’activité de course. Les propriétés d’aptitude de
vitesse, d’âge et d’équilibre mental ainsi que l’élevage d’origine sont pertinentes pour cette
activité et sont retenues.
On s’intéresse aux chevaux pour l’activité de transport des charges . Les propriétés d’âge, de taille,
de force et de corpulence sont pertinentes pour cette activité et sont retenues.
.
C. Les classes d’objets
 Un ensemble d’objets similaires, c’est-à-dire possédant la même structure et le même
comportement et constitués des mêmes attributs et méthodes, forme une classe d’objets. La
structure et le comportement peuvent alors être définis en commun au niveau de la classe.
Chaque objet d’une classe, encore appelé instance de classe, se distingue par son identité propre et
possède des valeurs spécifiques pour ses attributs.

Exemple : L’ensemble des chevaux constitue la classe Cheval qui possède la structure et le
comportement décrits à la figure ci-contre.

Le nom d’une classe apparaît au singulier. Il est toujours constitué d’un nom
commun précédé ou suivi d’un ou plusieurs adjectifs qualifiant le nom. Ce nom est
significatif de l’ensemble des objets constituant la classe.

D. L’encapsulation
L’encapsulation consiste à masquer des attributs et des méthodes de l’objet vis-à-vis
des autres objets. En effet, certains attributs et méthodes ont pour seul objectif des traitements
internes à l’objet et ne doivent pas être exposés aux objets extérieurs. Encapsulés, ils sont appelés
les attributs et méthodes privés de l’objet.
L’encapsulation est une abstraction puisque l’on simplifie la représentation de l’objet
vis-à-vis des objets extérieurs. Cette représentation simplifiée est constituée des attributs et
méthodes publiques de l’objet. La définition de l’encapsulation se fait au niveau de la classe.
Les objets extérieurs à un objet sont donc les instances des autres classes.
Exemple : Lorsqu’il court, un cheval va effectuer différents mouvements comme lever les jambes,
lever la tête, lever la queue. Ces mouvements sont internes au fonctionnement de l’animal et n’ont
pas à être connus à l’extérieur. Ce sont des méthodes privées. Ces opérations accèdent à une partie
interne du cheval : ses muscles, son cerveau et sa vue. Cette partie interne est représentée sous
la forme d’attributs privés. L’ensemble de ces attributs et méthodes est illustré à la figure ci-
contre.
 Dans la notation UML, les attributs et méthodes publics sont précédés du signe plus
tandis que les attributs et méthodes privés (encapsulés) sont précédés du signe moins

E. La spécialisation et la généralisation
Jusqu’à présent, chaque classe d’objets est
introduite séparément des autres classes. Une classe peut
également être définie comme un sous-ensemble d’une
autre classe, ce sous-ensemble devant toujours constituer
un ensemble d’objets
similaires. Il s’agit alors d’une sous-classe d’une autre
classe. Elle constitue ainsi une spécialisation de cette autre
classe.
Exemple : La classe des chevaux est une sous-classe de
la classe des mammifères.
La généralisation est la relation inverse de
la spécialisation. Si une classe est une spécialisation d’une
autre classe, cette dernière est une généralisation de la
première. Elle en est sa surclasse.
Exemple : La classe des mammifères est une surclasse de la classe des chevaux.
La relation de spécialisation peut s’appliquer à plusieurs niveaux, donnant lieu à une
hiérarchie de classes.
Exemple : La classe des chevaux est une sous-classe de la classe des mammifères, elle-même sous-classe
de la classe des animaux. La classe des chiens est une autre sous-classe de la classe des
mammifères. La hiérarchie correspondante des classes est représentée à la figure ci-contre.
 F. L’héritage
L’héritage est la propriété qui fait bénéficier à une sous-classe de la structure et du
comportement de sa surclasse. L’héritage provient du fait qu’une sousclasse est un sous-
ensemble de sa surclasse. En conséquence, elles bénéficient de la structure et du comportement
définis dans cette surclasse, en plus de la structure et du comportement introduits au niveau de la
sous-classe.
Exemple : Soit un système où la classe Cheval est une sous-classe directe de la classe Animal,
un cheval est alors décrit par la combinaison de la structure et du comportement issus des classes
Cheval et Animal, c’est-à-dire avec les attributs âge, taille, poids, nom et élevage ainsi que les
méthodes manger et courir.
G. Les classes abstraites et concrètes
L’examen de la hiérarchie présentée à la section spécialisation et generalisation montre
qu’il existe deux types de classes dans la hiérarchie :
Ø Des classes qui possèdent des instances, à savoir les
classes Cheval et Chien. Ces classes sont appelées classes
concrètes.
Ø Des classes qui n’en possèdent pas directement, comme
la classe Animal. En effet, si dans le monde réel, il
existe des chevaux, des chiens, le concept d’animal reste,
quant à lui, abstrait. Il ne suffit pas à définir
complètement un animal. La classe Animal est appelée
une classe abstraite.
Une classe abstraite a pour vocation de posséder
des sous-classes concrètes. Elle sert à factoriser des attributs
et des méthodes communs à ses sous-classes.
Exemple : La figure ci-contre reprend la hiérarchie en
indiquant précisément les classes abstraites et les classes
concrètes. En UML, le nom des classes abstraites apparaît en
caractères italiques.

H. Le polymorphisme
Le polymorphisme signifie qu’une classe
(très généralement abstraite) représente un
ensemble constitué d’objets différents car ils sont instances
de sous-classes distinctes. Lors de l’appel d’une méthode de
même nom, cette différence se traduit par des
comportements différents (sauf dans le cas où la méthode
est commune et héritée de la surclasse dans les
sous-classes).
Exemple Soit la hiérarchie de classes illustrée à la
figure 3.7. La méthode caresser a un comportement
différent selon que le cheval est instance de
ChevalSauvage ou de ChevalDomestiqué. Dans le
premier cas, le comportement sera un refus (se traduisant
par un cabrement) alors que dans le second, le
comportement sera une acceptation. Si l’on considère la
classe Cheval dans son intégralité, on a donc un ensemble
de chevaux qui ne réagissent pas de la même façon lors de
l’activation de la méthode
Caresser.

I- La composition

Un objet peut être complexe et composé d’autres objets. L’association qui unit alors ces
objets est la composition. Elle se définit au niveau de leurs classes mais les liens sont bâtis entre les
instances des classes. Les objets formant l’objet composé sont appelés composants.
Exemple: Un cheval est un exemple d’objet complexe. Il est constitué de ses différents organes
(jambes, tête, etc.).
La composition peut prendre deux formes :
Ø la composition faible ou
agrégation ; Ø la composition
forte.
Dans la composition faible, les composants peuvent être partagés entre plusieurs objets
complexes. Dans la composition forte, les composants ne peuvent être partagés et la destruction
de l’objet composé entraîne la destruction de ses composants.
Exemple : Si l’on reprend l’exemple précédent
dans le cas d’un cheval de course harnaché et si l’on
ajoute la selle dans les composants, on obtient :
Ø Une composition forte pour les jambes et la tête
; en effet, jambes et tête ne peuvent pas être
partagées et la disparition du cheval entraîne la
disparition de
ses organes.
Ø Une agrégation ou composition faible pour la selle.
L’ensemble est illustré à la figure ci contre
 J. La spécialisation des éléments : la notion de stéréotype
Nous avons introduit dans ce chapitre les concepts de
l’approche par objets. Nous introduisons maintenant les
stéréotypes d’UML dont le but est de spécialiser ces concepts. Un
stéréotype est constitué d’un mot clé explicitant cette
spécialisation. Celui-ci est noté entre guillemets. Cette
spécialisation est réalisée indépendamment du système que l’on
cherche à modéliser.
Exemple Le concept de classe abstraite est un concept
spécialisé du concept de classe. Nous avons vu qu’une classe
abstraite est représentée comme une classe avec un nom en
italiques. Cette représentation graphique inclut un stéréotype
implicite, mais il est
également possible de ne pas mettre le nom de la classe en italiques et de
préciser explicitement le stéréotype «abstract». Ce stéréotype explicite est illustré à la figure
ci-contre Il peut être employé lors de l’écriture manuelle de diagrammes UML.

En résumé, L’approche par objets forme la base d’UML. Elle est constituée de concepts
(objets, classes, spécialisation, composition) et de principes (abstraction, encapsulation).
Cet ensemble fait de l’approche par objets un véritable support pour la modélisation de
systèmes complexes, et au-delà d’UML, pour leur programmation.
Nous verrons dans les chapitres suivants comment les différents diagrammes d’UML
s’appuient sur les concepts et principes de l’approche par objets.
 CHAPITRE 3 - LA MODÉLISATION DES
EXIGENCES
Ce chapitre a pour objectif de vous faire découvrir les cas d’utilisation employés pour
décrire les exigences fonctionnelles. attendues, lors de la rédaction du cahier des charges d’un
système, ou les fonctionnalités d’un système existant.
L’ensemble des cas d’utilisation d’un système contient les exigences fonctionnelles
attendues ou existantes, les acteurs (utilisateurs du système) ainsi que les relations qui unissent
acteurs et fonctionnalités. Cet ensemble détermine également les frontières du système, à savoir
les fonctionnalités remplies par le système et celles qui lui sont externes.
Les cas d’utilisation servent de support pour les étapes de modélisation, de développement
et de validation. Ils constituent un référentiel du dialogue entre les informaticiens et les clients et,
par conséquent, une base pour l’élaboration au niveau fonctionnel du cahier des charges. Nous
débuterons par présenter les concepts clés de cette étape que nous appuierons par la suite d’exemples.
1. CONCEPTS DE BASE
A. Notion de Cas d’utilisation
Les cas d’utilisation décrivent sous la forme d’actions et de réactions, le comportement du
système étudié du point de vue des utilisateurs. Ils définissent les limites du système et ses
relations avec son environnement.
Cette définition doit être complétée. En effet, elle ne précise pas si un cas d’utilisation doit
décrire l’intégralité ou une partie du dialogue entre un utilisateur et le système. Elle peut être
formulée ainsi : "Entre un utilisateur et le système, un cas d’utilisation décrit les interactions liées
à un objectif fonctionnel de l’utilisateur".
Un cas d’utilisation explicite la partie des exigences fonctionnelles du système concernant
l’un des objectifs d’un utilisateur. Ce dernier est aussi appelé, de façon plus précise, cas
d’utilisation avec objectif utilisateur. Exemple : Considérons comme système un élevage de
chevaux. L’achat d’un cheval par un client constitue un cas d’utilisation.
B. Notion d’Acteur
Un utilisateur externe du système peut jouer différents rôles vis-à-vis du système. Un
couple (utilisateur, rôle) constitue un acteur spécifique désigné en UML uniquement par le nom
du rôle. Cette définition est étendue aux autres systèmes qui interagissent avec le système. Ils
forment autant d’acteurs qu’ils jouent de rôle. Deux catégories d’acteurs doivent être distinguées :
Ø les acteurs primaires, pour lesquels l’objectif du cas d’utilisation est essentiel ;
Ø les acteurs secondaires qui interagissent avec le cas d’utilisation mais dont l’objectif
n’est pas essentiel.
Exemple : Reprenons l’exemple précédent du cas d’utilisation de l’achat d’un cheval par un
client. L’acheteur d’un cheval est un acteur primaire. Les haras nationaux qui enregistrent le
certificat de vente constituent un acteur secondaire.
C. Notion de Scénario
 Un scénario est une instance d’un cas d’utilisation dans laquelle toutes les conditions
relatives aux différents événements ont été fixées. Il n’y a donc pas d’alternatives lors du
déroulement. À un cas d’utilisation donné correspondent plusieurs scénarios. Comme une classe
qui détient les aspects communs de ses instances, un cas d’utilisation décrit de façon commune
l’ensemble de ses scénarios en utilisant des branchements conditionnels pour représenter les
différentes alternatives.
Exemple : L’achat de Jorphée par Fien constitue un exemple de scénario du cas
d’utilisation d’achat d’un cheval. Toutes les alternatives du déroulement sont connues, car Fien a
acquis Jorphée.

2. RELATION DE COMMUNICATION
La relation qui lie un acteur à un cas d’utilisation s’appelle la relation de communication.
Cette relation supporte différents modèles de communication, par exemple :
Ø les services que le système doit fournir à chacun des acteurs du cas
d’utilisation ; Ø les informations du système qu’un acteur peut introduire,
consulter ou modifier ;
Ø les changements intervenant dans l’environnement dont un acteur informe le
système ; Ø les changements intervenant au sein du système dont ce dernier
informe un acteur.
Exemple : Lorsque Fien a acquis Jorphée, elle a reçu des informations de l’élevage
comme la proposition de prix, les papiers de la jument, son carnet de vaccination et a fourni des
informations comme une contre-proposition de prix, une promesse d’achat.

3. LE DIAGRAMME DES CAS D’UTILISATION

Le diagramme des cas d’utilisation montre les cas
d’utilisation représentés sous la forme d’ovales et les acteurs
sous la
forme de personnages. Il indique également les relations
de communication qui les relient. Il est possible de
représenter le système qui répond au cas d’utilisation sous la
forme d’un rectangle
englobant le cas
Exemple : Le cas d’utilisation de l’achat d’un cheval dans un
centre d’élevage de chevaux est représenté par la figure ci contre
:

Un acteur secondaire est représenté comme un

acteur primaire. Souvent, le sens de la relation de
communication entre un acteur secondaire et le système est
inversé par rapport au sens de la relation entre un acteur
primaire et le système. En effet, la communication est
initiée par le système et non par l’acteur.

Exemple : Dans l’exemple précédent, le changement de

propriétaire du cheval est réalisé par les haras nationaux.
Ces derniers constituent un acteur secondaire comme nous le
montre la figure ci-contre :

4. LES RELATIONS ENTRE LES CAS D’UTILISATION

a. La relation d’inclusion
La relation d’inclusion sert à enrichir un cas d’utilisation
par un autre cas d’utilisation. Cet enrichissement est réalisé par
une inclusion impérative, il est donc systématique. Le cas
d’utilisation inclus existe uniquement dans ce but. En effet, il
ne répond pas à un objectif d’un acteur primaire. Un tel cas
d’utilisation est une sous-fonction.
L’inclusion sert à partager une fonctionnalité commune
entre plusieurs cas d’utilisation. Elle peut également être
employée pour structurer un cas d’utilisation en décrivant ses
sous-fonctions. Dans le
diagramme des cas d’utilisation, cette relation est représentée
par une flèche pointillée munie du stéréotype «include».
L’inclusion peut également être employée pour décomposer
l’intérieur d’un cas d’utilisation sans que le cas inclus soit partagé. À la figure ci-contre,
l’examen des maternités d’une jument n’est pas partagé mais sa présence illustre bien que cet examen
fait partie des points étudiés lors de l’achat d’une jument.
b. La relation d’extension
Comme la relation d’inclusion, la relation d’extension enrichit un cas d’utilisation
par un cas d’utilisation de sous-fonction. Cet enrichissement est analogue à celui de la relation
d’inclusion mais il est optionnel. L’extension se fait dans le cas d’utilisation de base, en des
points précis et prévus lors de la conception, appelés points d’extension. L’application de
chaque extension est décidée lors du déroulement
d’un scénario. Par conséquent, le cas d’utilisation de
base peut être employé sans être étendu.
Comme pour l’inclusion, l’extension sert à
structurer un cas d’utilisation ou à partager un cas
d’utilisation de sous-fonction. Dans le diagramme des
cas d’utilisation, cette relation est représentée par une
flèche pointillée munie du stéréotype «extend».
Exemple Lors de l’achat d’un cheval, un acheteur
peut vérifier son caractère ou sa robe. Par conséquent,
le cas d’utilisation d’achat d’un cheval peut être
étendu par l’une de ses vérifications. Prenons le cas où
l’achat d’un étalon est modélisé séparément de celui
d’une jument. Sa capacité à
donner naissance peut être vérifiée de façon optionnelle. D’autre part, les cas d’utilisation de la
vérification du caractère et de la vérification de la robe sont partagés comme nous pouvons le voir
sur la figure ci-contre:

c. La spécialisation et la généralisation des cas d’utilisation

C o m m e nous l’avons vu dans le chapitre Les concepts de l’approche par objets pour
les classes d’objet, il est également possible de spécialiser un cas d’utilisation en un autre. On
obtient ainsi un sous-cas d’utilisation. Comme pour les classes, le sous-cas hérite du
comportement du sur-cas d’utilisation. Un sous-cas d’utilisation hérite également des relations de
communication, d’inclusion et d’extension du sur-cas. Souvent, le sur-cas d’utilisation est abstrait,
c’est-à-dire qu’il correspond à un comportement partiel complété dans les sous-cas d’utilisation.
Un sous-cas d’utilisation a le même niveau que son sur-cas. Si le sur-cas est un cas avec
objectif utilisateur, il en va de même pour le sous-cas. Si le sur-cas est un cas de sous-fonction, le
sous-cas est lui aussi une sous- fonction. Dans le diagramme des cas d’utilisation, la relation de
spécialisation est représentée par une flèche pleine de spécialisation identique à celle qui relie les
sous-classes aux surclasses. Le nom d’un cas d’utilisation abstrait est écrit en italique
(ou accompagné du stéréotype «abstract»).
Exemple : Le cas d’utilisation d’achat
d’un cheval est spécialisé en deux
sous-cas : l’achat d’une jument ou d’un
étalon. Ce cas est un cas abstrait et son nom
apparaît en italiques La figure 4.9 illustre
cette spécialisation. Les cas d’utilisation
d’achat de la jument et d’achat de
l’étalon sont des cas d’utilisation avec
objectif utilisateur et communiquent
avec l’acheteur. En effet, la relation de communication qui existe entre le cas d’utilisation d’achat
du cheval et Acheteur est héritée dans les deux sous-cas d’utilisation.

Exemple: Les relations d’extension concernant les différentes inclusions et extensions de vérification
peuvent être factorisées au niveau du cas abstrait. Elles sont alors héritées dans les sous-cas à l’image
de la relation de communication dans l’exemple précédent (voir figure ci-dessous)
NB: La représentation textuelle des cas d’utilisation n’est pas spécifiée dans UML. Elle est
cependant couramment utilisée. Cette représentation sous forme textuelle des cas d’utilisation donne
une description de leurs comportements, de leurs actions et réactions. Le contenu de cette
représentation textuelle est la suivante :
- le nom du cas d’utilisation
;
Ø l’acteur primaire ;
Ø le système concerné par le cas d’utilisation ;
Ø les intervenants (ensemble des acteurs) ;
Ø le niveau du cas d’utilisation pouvant être soit :
-un objectif utilisateur ;
- ou une sous fonction ;
Ø les préconditions qui sont les conditions à remplir pour que le cas d’utilisation puisse être
exécuté ; Ø les opérations du scénario principal ;
Ø les extensions.
Tout ceci dans un tableau semblable a celui-ci:

En conclusion, Les cas d’utilisation servent à exprimer les exigences fonctionnelles

conférées au système par les utilisateurs lors de la rédaction du cahier des charges, vérifier que le
système répond à ces exigences lors de la livraison ; déterminer les frontières du système ; écrire la
documentation du système ; construire les jeux de test.
 Les cas d’utilisation offrent une technique de représentation qui convient au dialogue
avec l’utilisateur car son formalisme reste proche du langage naturel. Il est conseillé d’y adjoindre
un lexique pour éviter les risques de confusion.
 CHAPITRE 4 - LA MODÉLISATION DE LA
DYNAMIQUE
Ce chapitre a pour objectif de vous faire découvrir comment UML représente les
interactions entre les objets. Nous avons découvert au chapitre Les concepts de l’approche par
objets que les objets d’un système possèdent leur propre comportement et interagissent entre
eux afin de doter le système de sa dynamique globale. Nous avons étudié au chapitre La
modélisation des exigences la façon dont les cas d’utilisation représentent les actions et réactions
entre un acteur externe et le système. Du point de vue de la modélisation, ces deux types
d’interactions se distinguent par leur différence interne/externe mais nullement par leur nature.
UML propose deux diagrammes pour répondre à ce besoin de représentation des
interactions entre objets :
Ø Le diagramme de séquence se focalise sur les aspects temporels.
Ø Le diagramme de communication se focalise sur la représentation spatiale.
Dans ce chapitre, nous allons étudier ces deux diagrammes. Nous examinerons ensuite
comment découvrir progressivement les objets composant un système. Cette découverte sera basée
sur les interactions entre objets intervenant dans les cas d’utilisation du système. Pour représenter
ces interactions, nous ferons le choix du diagramme de séquence, cette option ayant très souvent la
faveur des personnes chargées de la modélisation d’un projet. Le diagramme de communication
porte ce nom depuis UML 2. En UML 1, il s’appelait diagramme de collaboration.

1. DIAGRAMME DE SEQUENCE
a. Définition
Le diagramme de séquence décrit la dynamique du système. À moins de modéliser un
très petit système, il est difficile de représenter toute la dynamique d’un système sur un seul
diagramme. Aussi la dynamique globale sera représentée par un ensemble de diagrammes
de séquence, chacun étant généralement lié à une sous-fonction du système. Le diagramme de
séquence décrit les interactions entre un groupe d’objets en montrant, de façon séquentielle, les
envois de message qui interviennent entre les objets. Le diagramme peut également montrer les
flux de données échangées lors des envois de message.
Pour interagir entre eux, les objets s’envoient des messages. Lors de la réception d’un
message, un objet devient actif et exécute la méthode de même nom. Un envoi de message est donc
un appel de méthode.
b. Ligne de vie d’un objet
Comme il représente la dynamique du système,
le diagramme de séquence fait entrer en action les instances
des classes intervenant dans la réalisation de la sous-fonction
qui lui est liée. À chaque instance est associée une ligne de vie
qui montre ses actions et réactions, ainsi que les périodes
pendant lesquelles elle est active, c’est-à-dire où elle exécute
l’une de ses méthodes. La représentation graphique de la
ligne de vie est illustrée à la figure ci contre:
 La notation "role : Classe" représente le rôle d’une instance suivi du nom de sa classe. Dans
cet ouvrage, par souci de simplification, nous considérons que le rôle de l’instance
correspond à son nom, comme c’était le cas en UML 1. Le rôle de l’instance est optionnel
si une seule instance de cette classe participe au diagramme de séquence. Un diagramme
de séquence contient plusieurs lignes de vie car il traite des interactions entre plusieurs
objets.

c. L’envoi d’un message

Les envois de message sont représentés par des flèches horizontales reliant la ligne de vie de
l’objet émetteur à la ligne de vie de l’objet destinataire. Dans la figure la figure ci-contre, l’objet
de gauche envoie un message à l’objet de droite. Ce message donne lieu à l’exécution
de la méthode message de l’objet de droite, ce qui
provoque son activation.
Les messages peuvent etre numérotés
séquentiellement, à partir de un. Si un message est envoyé
alors que le traitement du précédent n’est pas terminé, il est
possible d’utiliser une numération composée où l’envoi du
message 2 intervient pendant l’exécution du message 1
Il existe différents types d’envois de message:
Ø Le message synchrone est le plus fréquemment utilisé. Son
emploi signifie que l’expéditeur du message attend que
l’activation de la méthode invoquée chez le destinataire
soit terminée avant de continuer son activité.
Ø Dans le cas du message asynchrone, l’expéditeur n’attend pas
la fin de l’activation de la méthode invoquée chez le
destinataire. Ceci se produit lors de la modélisation d’un
système où les objets peuvent
fonctionner en parallèle (cas des systèmes multi-thread
où les traitements sont effectués en parallèle).
Ø Le message de retour de l’invocation d’une méthode n’est pas systématique, toutes les
méthodes ne retournant pas un résultat(différence entre les fonctions et les procédures). Un
objet peut envoyer un message à lui-même.

d. La création et la destruction d’objets

Le diagramme de séquence décrivant la dynamique d’un système,
celle-ci contient fréquemment des créations et des destructions d’objets. La
création d’objet est représentée par un message spécifique qui donne lieu au
début de la ligne de vie du nouvel objet.La destruction d’objet est un message
envoyé à un objet existant et qui donne lieu à la fin de sa ligne de vie. Il est
représenté par une croix. Ces deux messages sont illustrés à la figure suivante:
.
 il nous est maintenant possible de construire l’intégralité d’un diagramme de séquence et de
décrire la dynamique d’un petit système ou une sous-fonction d’un système plus important.
Exemple :La figure qui suit représente un scénario d’achat d’une jument déjà étudié au
chapitre La modélisation des exigences. Il n’y a aucune alternative ; il s’agit donc bien d’un scénario.
Nous verrons par la suite comment introduire les alternatives et les boucles

e. Les cadres d’interaction

Jusqu’ici, les constructions introduites pour l’écriture des diagrammes de séquence sont
celles d’UML 1. Les diagrammes ainsi construits décrivent des scénarios. Par conséquent,
pour représenter tous les scénarios de la dynamique d’un système, il convient d’écrire autant de
diagrammes. UML 2 généralise les diagrammes de séquence pour y introduire les cadres
d’interaction. Cette extension importante offre le support des alternatives et des boucles et
confère au diagramme de séquence le statut d’un véritable modèle
des interactions
Un cadre d’interaction est une partie du diagramme de séquence associé à une étiquette. Elle
contient un opérateur qui en détermine la modalité d’exécution. Les principales modalités
sont le branchement conditionnel et la boucle.
i. L’alternative
L’alternative s’obtient en utilisant l’opérateur opt suivi d’une condition de test. Si la
condition est vérifiée, le contenu du cadre est exécuté. Il existe un autre opérateur pour
l’alternative. Nommé alt, il est suivi de plusieurs conditions de test puis du mot clé else. Le cadre
est alors scindé en plusieurs parties dont le contenu n’est exécuté que si la condition associée est
remplie. Le contenu de la dernière partie est associé au mot clé else (sinon). Il est exécuté uniquement
si aucune des conditions précédentes n’est vérifiée.
 ii. La boucle
La boucle est réalisée par l’opérateur loop suivi des
paramètres min, max et d’une condition de test. Le contenu du
cadre est exécuté min fois, puis tant que la condition de test est
vérifiée et tant que le nombre maximal d’exécutions de la
boucle ne dépasse pas max. Chaque paramètre est optionnel.

Exemple : Pour franchir un obstacle, un cavalier peut s’y prendre à plusieurs reprises, sans
toutefois dépasser deux refus.

iii. Utilisation des cadres d’interaction

À partir des différents éléments introduits jusqu’ici, il est maintenant possible de décrire
de façon plus générale la dynamique du système.
Exemple: La figure qui suit représente le cas d’utilisation d’achat d’une jument. À la
différence de la figure 5.8, les alternatives et boucles introduites dans le cas d’utilisation sont
prises en compte. Notamment, le diagramme de séquence n’est exécuté jusqu’au bout que si les
vaccinations et maternités sont validées par l’acheteur. Par ailleurs, la boucle de négociation du
prix de vente est également représentée.
 2. LE DIAGRAMME DE COMMUNICATION

diagramme de communication est une alternative au diagramme de séquence. Il se focalise sur

une représentation spatiale des objets. Chaque objet intervient dans ce diagramme de la même façon
que dans le diagramme de séquence. Il n’est pas associé à une ligne de vie mais relié graphiquement
aux objets avec lesquels il interagit.
Les envois de messages sont placés le long des liens interobjets. Les messages sont
obligatoirement numérotés, la numérotation composée étudiée dans le cadre des diagrammes
de séquence pouvant également être employée. Il est également possible de transmettre des
informations lors de l’envoi, de la même façon que dans le cas du diagramme de
séquence.
Exemple: Dans un troupeau de
chevaux, il existe une jument
dominante qui est responsable de
l’éducation de tous les poulains. Elle peut
passer le relais à une autre jument pour la
surveillance d’un poulain particulier.
Dans l’exemple de la figure ci-contre,
la jument dominante délègue la
surveillance du poulain
Espiègle à une autre jument, qui lui donne un ordre auquel il refuse d’obéir. Il est donc puni.
 CHAPITRE 5 - LA MODÉLISATION DES
OBJETS
L’objectif de ce chapitre est de vous faire découvrir les techn iques UML de modélisation
Statique des objets. Cette modélisation est statique car elle ne décrit pas les interactions ou le cycle
de vie des objets. Les méthodes sont introduites d’un point de vue statique, sans description
de leur enchaînement. Nous découvrirons le diagramme des classes. Ce diagramme contient les
attributs, les méthodes et les associations des objets. Comme nous l’avons vu au chapitre Les concepts
de l’approche par objets, cette description est réalisée par les classes. Ce diagramme est central lors
d’une modélisation par objets d’un système. De tous les diagrammes UML, il est le seul obligatoire
lors d’une telle modélisation.
La décomposition par le diagramme de séquence, comme la décomposition guidée par les
données apparaissent naturelles pour découvrir les objets. Ce résultat est normal car un objet est
l’assemblage d’une structure et d’un comportement. Il convient enfin de remarquer que ces
deux approches ne sont pas incompatibles. La décomposition guidée par les données est plus
efficace quand la personne chargée de la modélisation connaît bien le domaine. La décomposition en
objets est alors immédiate.

1. La forme simplifiée de représentation des classes

Les objets du système sont décrits par des classes dont une forme
simplifiée de la représentation en UML est donnée à la figure ci-contre. Cette
représentation est constituée de trois parties:
Ø La première partie contient le nom de la classe: Rappelons que
le nom d’une classe est au singulier. Il est toujours
constitué d’un nom commun précédé ou suivi d’un ou plusieurs
adjectifs qualifiant le nom. Ce nom est significatif de l’ensemble
des objets constituant la classe. Il représente la nature des
instances d’une classe.
Ø La deuxième partie contient les attributs: Ceux-ci
contiennent l’information portée par un objet. L’ensemble des
attributs forme la structure de l’objet
Ø La troisième partie contient les méthodes : Celles-ci correspondent aux services
offerts par l’objet. Elles peuvent modifier la valeur des attributs. L’ensemble des
méthodes forme le comportement de l’objet.
Le nombre d’attributs et de méthodes est variable selon chaque classe. Toutefois, un
nombre élevé d’attributs et/ou de méthodes est déconseillé. Il ne reflète pas, en général, une bonne
conception de la classe.

2. L’encapsulation
L’encapsulation a été introduite dans le chapitre Les concepts de l’approche par objets.
Certains attributs et méthodes ne sont pas exposés à l’extérieur de l’objet. Ils sont encapsulés et
appelés attributs et méthodes privés de l’objet. UML, comme la plupart des langages modernes,
introduit trois possibilités d’encapsulation :
 Ø L’attribut ou la méthode privée : la propriété n’est pas exposée en dehors de la
classe, y compris au sein de ses sous-classes.
-L’attribut ou la méthode protégée : la propriété n’est exposée qu’aux instances de la
classe et de ses sous-classes.
Ø L’encapsulation de paquetage : la propriété n’est exposée qu’aux instances des
classes de même paquetage.

3. La notion de type
Nous appelons ici variable tout attribut, paramètre et valeur de retour d’une méthode.
D’une façon générale, nous appelons variable tout élément pouvant prendre une valeur. Le
type est une contrainte appliquée à une variable. Il consiste à fixer l’ensemble des valeurs
possibles que peut prendre cette variable. Cet ensemble peut être une classe, auquel cas la variable
doit contenir une référence vers une instance de cette classe. Il peut être standard comme
l’ensemble des entiers, des chaînes de caractères, des booléens ou des réels. Dans ces derniers cas, la
valeur de la variable doit être respectivement un entier, une chaîne de caractères, une valeur
booléenne et un réel.
Les types standard sont désignés ainsi :
Ø Integer pour le type des entiers ;
ØString pour le type des chaînes de caractères
;
Ø Boolean pour le type des booléens ;
Ø Real pour le type des réels.

4. La signature des méthodes

Une méthode d’une classe peut prendre des paramètres et renvoyer un résultat. Les
paramètres sont des valeurs transmises :
Ø à l’aller, lors de l’envoi d’un message appelant la
méthode ;
Ø ou au retour d’appel de la méthode.
Le résultat est une valeur transmise à l’objet appelant lors du
retour d’appel.
Les paramètres ainsi que le résultat peuvent être typés. L’ensemble
constitué du nom de la méthode, des paramètres avec leur nom et leur
type ainsi que le type du résultat s’appelle la signature de la méthode.
Une signature prend la forme
suivante : <nomMéthode> (<direction><nomParamètre> : <type>, ...) : <typeRésultat>
Rappelons que le nombre de paramètres peut être nul et que le type du résultat est optionnel.
.

5. Les associations entre objets

le monde réel, de nombreux objets sont liés entre eux. Ce lien correspond à une association
qui existe entre les objets. Exemple le lien qui existe entre un fils et son père ; En UML, ces liens
sont décrits par une association, comme un objet est décrit par une classe. Un lien est une
occurrence d’une association. Par conséquent, une association relie des classes. Chaque occurrence
de cette association relie entre elles des instances de ces classes. Une association porte un nom.
Comme pour une classe, ce nom est significatif des occurrences de l’association.

Il est possible de faire précéder le nom d’une association du signe < ou de le faire
suivre par le signe > pour indiquer le sens de lecture du nom vis-à-vis du nom des classes.
Si l’association est située sur un axe vertical, il est possible de faire précéder le nom par ^ ou
v.
Chaque extrémité d’une association peut également être nommée. Ce nom est
significatif du rôle que jouent les instances de la classe correspondante dans l’association.
 6. La cardinalité des associations

La cardinalité située à une extrémité d’une

association indique à combien d’instances de la classe située à
cette extrémité une instance de la classe située à l’autre
extrémité est liée. Il est possible de spécifier, à une
extrémité d’une association, la cardinalité minimale et la
cardinalité maximale pour indiquer un intervalle de valeurs
auquel doit toujours appartenir la cardinalité. La syntaxe
de spécification des cardinalités minimales et
maximales est décrite dans le tableau ci-après. En l’absence de spécification explicite des
cardinalités minimales et maximales, celles-ci valent 1.

7. Les classes-associations
Les liens entre les instances des classes peuvent porter des informations. Celles-ci sont
spécifiques à chaque lien. Dans ce cas, l’association qui décrit de tels liens reçoit le statut de classe,
dont les instances sont des occurrences de l’association. Comme toute autre classe, une telle classe
peut être dotée d’attributs, d’opérations et être reliée au travers d’associations à d’autres classes.
Exemple quand un client achète un produit pour cheval (produits d’entretien, etc.), il convient de
spécifier la quantité de produits acquis par une classe association, ici la classe Acquisition.

8. Les objets composés

Nous avons vu qu’un objet peut être composé d’autres objets. Dans ce cas, il s’agit d’une
association entre objets d’un cas particulier appelé association de composition. Elle associe un
objet complexe aux objets qui le constituent, à savoir ses composants. Il existe deux formes de
compositions, forte ou faible, que nous allons examiner maintenant.
a. La composition forte ou composition
La composition forte est la forme de composition telle que les composants sont une partie
de l’objet composé. Chaque composant ne peut ainsi être partagé entre plusieurs objets composés.
La cardinalité maximale, au niveau de l’objet composé, est donc obligatoirement de un. La
suppression de l’objet composé entraîne la suppression de ces composants. Exemple Un cheval est
composé d’un cerveau. Le cerveau n’est pas partagé. La mort du cheval entraîne la mort de son
cerveau. Il s’agit donc d’une association de composition. Celle-ci est illustrée à la figure suivante
 .

b. La composition faible ou agrégation

La composition faible, appelée plus couramment agrégation, impose beaucoup moins de
contraintes aux composants que la composition forte étudiée jusqu’à présent. Dans le cas
de l’agrégation, les composants peuvent être partagés par plusieurs composés (de la même
association d’agrégation ou de plusieurs associations distinctes d’agrégation) et la destruction du
composé ne conduit pas à la destruction des composants.
L’agrégation se rencontre plus fréquemment que la composition. Lors d’une première
phase de modélisation, il est possible d’utiliser seulement l’agrégation puis, plus tard, de
déterminer quelles associations d’agrégation sont des associations de composition. Déterminer,
sur un modèle, qu’une association d’agrégation est une association de composition, revient à
ajouter des contraintes, au même titre que donner un type ou préciser des cardinalités.
Exemple Un cheval harnaché est composé d’une selle. Une selle est elle-même composée d’une
sangle, d’étriers et d’un tapis de selle. Cette composition relève de l’agrégation (voir figure 6.33).
En effet, perte du cheval n’entraîne pas la perte de ces objets et la perte de la selle n’entraîne
pas la perte de ses composants.
Le tableau suivant résume l’ensemble des différences entre agrégation et composition.

9. La relation de généralisation/spécialisation entre les classes

a. L’héritage
Les instances d’une classe sont aussi instances de sa ou de ses surclasses. En conséquence,
elles profitent des attributs et des méthodes définis dans la ou les surclasses, en plus des attributs et
des méthodes introduites au niveau de leur classe. Cette faculté s’appelle l’héritage, c’est-à-dire
qu’une classe hérite des attributs et méthodes de ses surclasses pour en faire bénéficier ses instances.
Rappelons que les attributs et méthodes privés d’une surclasse sont hérités dans ses
sous-classes mais n’y sont pas visibles. Lors d’un héritage, une méthode peut être redéfinie dans la
sous-classe. Nous verrons par la suite que cette redéfinition s’applique principalement dans le cas de
l’héritage d’une classe abstraite.
b. Classes concrètes et abstraites
Une classe concrète possède des instances. Elle constitue un modèle complet d’objet
(tous les attributs et méthodes sont complètement décrits). À l’opposé, une classe abstraite ne
peut pas posséder d’instance directe car elle ne fournit pas une description complète. Elle a pour
vocation de posséder des sous-classes concrètes et sert à factoriser des attributs et méthodes communs
à ses sous-classes.
Souvent, la factorisation de méthodes communes aux sous-classes se traduit par la seule
factorisation de la signature. Une méthode introduite dans une classe avec sa seule signature et sans
code est appelée une méthode abstraite. En UML, une classe ou une méthode abstraite sont
représentées par le stéréotype «abstract». Graphiquement, celui-ci est représenté soit
explicitement, soit implicitement avec une mise en italiques du nom de la classe ou de la
méthode. Toute classe possédant au moins une méthode abstraite est une classe abstraite. En
effet, la seule présence d’une méthode
Incomplète (le code est absent) implique que la classe ne soit
pas une description complète d’objets.
Exemple Un animal peut dormir ou manger mais de façon
distincte selon la nature de l’animal. Ces méthodes possèdent
Pour unique description, au niveau de la classe Animal, leur signature. Il s’agit donc de
méthodes abstraites. La figure suivante illustre ces méthodes abstraites au sein de la classe
abstraite Animal. Elle montre aussi leur redéfinition pour les rendre concrètes (c’est-à-dire leur
attribuer du code) dans les classes Cheval et Loup. En effet, un cheval dort debout alors qu’un
loup dort couché. Ils ne mangent pas de la même façon : un loup est carnivore alors que le cheval
est un herbivore.

c. L’héritage multiple
L’héritage multiple en UML consiste à ce qu’une sous-classe hérite de plusieurs
surclasses. Il pose un seul problème : il engendre un conflit lorsqu’une même méthode,
c’est-à-dire de même signature, est héritée plusieurs fois dans la sous- classe. En effet, lors de la
réception d’un message appelant cette méthode, il faut définir un critère pour en choisir une
parmi toutes celles qui sont héritées. Une solution, dans ce cas, consiste à redéfinir la méthode
dans la sous-classe afin de supprimer le conflit.
Si l’utilisation de l’héritage multiple est bien sûr possible en modélisation, il est
souvent nécessaire de transformer les diagrammes de classes pour le supprimer lors du passage
au développement. En effet, rares sont les langages de programmation supportant cette forme
d’héritage. Pour cela, il existe différentes techniques parmi lesquelles la transformation de
chaque héritage multiple en une agrégation.

d. Interface
Une interface est une classe totalement abstraite, c’est-à-dire sans attribut et dont
toutes les méthodes sont abstraites et publiques. Une telle classe ne contient aucun élément
d’implantation des méthodes. Graphiquement, elle est représentée comme une classe avec le
stéréotype «interface».
L’implantation des méthodes est réalisée par une ou plusieurs classes concrètes,
sous-classes de l’interface. Dans ce cas, la relation d’héritage qui existe entre l’interface et une
sous-classe d’implantation est appelée relation de réalisation. Graphiquement, elle est
représentée par un trait pointillé au lieu d’un trait plein pour une relation d’héritage entre deux
classes.
Exemple Un cheval de course peut être considéré comme une interface. Celle-ci est
composée de plusieurs méthodes : courir, arrêter, etc. L’implantation peut ensuite différer. Une
course de galop ou de trot se fait seulement avec des chevaux entraînés pour l’une ou l’autre de
ces courses. Pour des chevaux de galop, courir signifie galoper. Pour des chevaux de trot (un
trotteur), courir signifie trotter. Tous deux répondent à l’interface ChevalCourse mais avec
une implantation différente due à leur entraînement. La figure suivante illustre l’exemple
 Une même classe peut réaliser plusieurs interfaces. Il s’agit d’un cas particulier de
l’héritage multiple. En effet, aucun conflit n’est possible car seules les signatures des méthodes
Sont héritier dans la même classe de réalisation. Si plusieurs interfaces contiennent la
même signature, cette signature est implantée par une seule méthode dans la classe commune de
réalisation.
 FICHE DE TD
Exercice 1 Analyse des besoins d'un vidéo Club

Un vidéo club est un centre de distribution qui assure essentiellement la

location de films préenregistrés

Les éditeurs procurent les cassettes aux exploitants soit en location soit en vente.
Les exploitants peuvent donc passer avec les éditeurs des contrats de location d'une durée
moyenne de 6 mois ou passer des commandes à partir de catalogues fournis régulièrement
par les éditeurs. Un vidéo club entretient des relations avec une trentaine d'éditeurs
environ. Lorsque les exploitants constatent une usure des cassettes qui leur appartiennent, ils
ont la possibilité de les vendre à des grossistes qui peuvent alors pratiquer des ventes au
rabais.

Un seul statut est proposé aux clients, celui d'adhérent. Chaque adhérent se voit
attribuer une carte d'adhésion sur laquelle est mentionné un code adhérent. Il peut
alors choisir entre plusieurs types d’abonnement. Les tarifs varient selon le mode
d'abonnement choisi. Quatre tarifs adaptés aux locations sont proposés en fonction des
différents types d'abonnement. Toutefois, on peut louer des cassettes aux clients non abonnés
sans leur faire profiter des avantages tarifaires réservés aux abonnés.

Exercice 2 Gestion des réservations de vols

Le déroulement normal d’utilisation d’une caisse de supermarché est le suivant :

Ø un client arrive à la caisse avec ses articles à payer

Ø le caissier enregistre le numéro d’identification de chaque article, ainsi que
la quantité si elle est supérieure à 1
Ø la caisse affiche le prix de chaque article et son libellé
Ø lorsque tous les achats sont enregistrés, le caissier signale la
fin de la vente Ø la caisse affiche le total des achats
Ø le caissier annonce au client le montant
total à payer Ø le client choisit son mode
de paiement
§ liquide : le caissier encaisse l’argent, la caisse indique le montant à
rendre au client § chèque : le caissier note le numéro de pièce
d’identité du client
§ carte de crédit : la demande d’autorisation est envoyée
avant la saisie Ø la caisse enregistre la vente et l’imprime
Ø le caissier donne le ticket de caisse au client
Exercice 3 Gestion des réservations de vols

Une compagnie aérienne propose différents vols. Un vol est ouvert à la réservation et
fermé sur ordre de la compagnie. Un client peut réserver un ou plusieurs vols, pour des
passagers différents. Une réservation concerne un seul vol, et un seul passager. Une
réservation peut être annulée ou confirmée. Un vol a u n a é r o p o r t de départ et un
aéroport d’arrivée. Un vol a un jour et une heure de départ et un jour et une heure
d’arrivée. Un vol peut comporter des escales dans des aéroports Une escale a une heure
d’arrivée et une heure de départ. Chaque aéroport dessert une ou plusieurs villes
TAF: Produire le DCU et le Diagramme de Classe

Exercice 4 Gestion Société de livraison express

On s'intéresse à une société de livraison express à domicile. Le service Clientèle

reçoit chaque jour les clients qui désirent une livraison en France ou à l'étranger. Ce
service gère deux catégories de paquets :

· les paquets légers ou lettres dont le poids

est < =à 2 kg,
· les paquets lourds ou colis dont le poids est
> à 2 kg.

Le tarif est calculé en fonction du poids du colis et de sa destination avec un forfait

de 10 Euros si le client opte pour un envoi avec accusé de réception. Le service Clientèle
enregistre alors les références des paquets client (coordonnées expéditeur + destinataire,
poids, etc.) en ordinateur et impriment un récépissé pour le client. La facturation des
paquets légers ou à destination de la France sont gérés aussi par ce service. Le paiement
effectué, le service transmet le paquet au service Logistique pour l'acheminement. Les
paquets lourds, à destination de l'international, doivent respecter la réglementation
douanière et doivent donc faire l'objet de démarches plus lourdes qui rallongent leur
délai d'acheminement de 48h au moins et sont sur-facturés de 10%. En particulier, le
client doit remplir et signer une liasse de transport qui précise la nature et la valeur du
contenu du (ou des) paquets à acheminer. Le paquet, accompagné de ce document, est
transmis au service Export de l'entreprise.

Les paquets dont le poids dépasse les 20kg ou, dont le contenu est répertorié dans
une liste de marchandises bien définie par la réglementation douanière, doivent subir des
formalités avec les douanes Françaises, en liaison avec le service Export. Le paquet ne peut
être acheminé avant accord des douanes qui se matérialise par un bordereau avec les
références du paquet à acheminer et le montant de la taxe à la
charge du client. Le service Export de l'entreprise transmet alors l'information au service
de facturation. Celui-ci émet ensuite la facture finale à destination du client. Après
règlement, le service Export en est informé et transmet le paquet avec le bordereau des
douanes au service Logistique qui se charge de la livraison.

Travail à Faire :

1. Donner le diagramme des cas d’utilisation qui décrit le fonctionnement de cette société.

2. Décrire la structure statique de ce système par un diagramme de classes.

EXERCICE 5 : Etablissement scolaire

Dans un établissement scolaire, on désire gérer la réservation des

salles de cours ainsi que du matériel pédagogique (ordinateur portable
ou/et Vidéo projecteur). Seuls les enseignants sont habilités à
effectuer des réservations (sous réserve de disponibilité de la salle ou
du matériel). Le planning des salles peut quant à lui être consulté par
tout le monde (enseignants et étudiants). Par contre, le récapitulatif
horaire par enseignant (calculé à partir du planning des salles) ne peut
être consulté que par les enseignants. Enfin, il existe pour chaque
formation un enseignant responsable qui seul peut éditer le
récapitulatif horaire pour l’ensemble de la formation. Pour réserver
une salle, un enseignant contacte le responsable des études qui vérifie
la disponibilité de cette dernière. Si la salle est disponible, le
responsable valide la réservation de la salle par cet enseignant et le
notifie aussitôt. En cas d’indisponibilité de la salle, l’enseignant reçoit
également une notification. L’accès au module de réservation des
salles est réservé uniquement aux enseignants enregistrés dans le
système.
1- Quels sont les acteurs de ce système ?
2- Modéliser cette situation par un diagramme de cas d’utilisation
3- Après avoir identifié clairement les classes présentes dans ce
problème, élaborer le diagramme de classe correspondant
 4- Schématisez le processus de réservation d’une salle de cours à
l’aide d’un diagramme de séquence. On s’intéressera uniquement
au cas de réservation réussie.

Exercice 6 : Magasin
Dans un magasin, le processus de vente est le suivant : le client entre,
passe dans les rayons, demande éventuellement des renseignements
ou procède à des essais, prend des articles (si le stock est suffisant),
Passe à la caisse où il règle ses achats (avec tout moyen de paiement
accepté : carte bancaire, liquide, chèque). Il peut éventuellement
bénéficier d’une réduction.
1- Modéliser cette situation par un diagramme de cas d’utilisation
2- Ressortir le diagramme de classes correspondant
3- Construire le diagramme de séquence pour le scénario d’achat
d’un produit.