Page |1

UNIVERSITE LIBRE DE
KISANGANI
Faculté des Sciences Informatiques

PROGRAMMATION ORIENTEE
OBJET


ASSISTANT TEGE SIMBONI

Janvier 2009
 Page |2

Objectifs du cours

Les principaux objectifs de ce cours sont les suivants :

 Permettre aux étudiants d’avoir un aperçu général sur le concept de la

programmation orientée objet.

 Etre familier avec la modélisation UML

 Connaître le processus de développement orienté objet des logiciels

 Les concepts importants de l’analyse, de la conception et de la
programmation par objets
 Pouvoir développer des programmes en Java, C++, C# ou autres en utilisant de
bonnes pratiques
 Abstraction, généralisation, héritage, polymorphisme, modularité, …
 Apprendre à travailler en groupe
 Page |3

Sommaire du cours

Chapitre 1 : Les concepts de base de la POO

Chapitre 2 : Modélisation orientée objet avec UML
Chapitre 3 : Programmation orientée objet en Java
Chapitre 4 : Le Modèle MVC et Le Pattern DAO
 Page |4

CHAPITRE I : CONCEPTS DE BASE DE LA POO

1.1. INTRODUCTION

Avant que nous puissions décrire les concepts de la programmation orientée

objet, nous devons d’abord connaitre à quoi sert la programmation orientée objet ?

En fait, on peut dire que la POO est une façon de développer une application
qui consiste à représenter ou « modéliser » une application informatique sous la forme
d’objets, ayant des propriétés et pouvant interagir entre eux. La modélisation orientée objet
est proche de la réalité ce qui fait qu’il sera relativement facile de modéliser une
application de cette façon.

Cette manière de modéliser les choses permet également de découper une

grosse application, généralement floue, en une multitude d’objets interagissant entre eux.
Cela permet de découper un gros problème en plus petits afin de le résoudre plus
facilement.

Utiliser une approche orientée objet améliore également la maintenabilité. Plus

le temps passe et plus une application est difficile à maintenir. Il devient difficile de
corriger des choses sans tout casser ou d’ajouter des fonctionnalités sans provoquer une
régression par ailleurs.

Un autre avantage de la POO est la réutilisabilité. Des objets peuvent être

réutilisés ou même étendus grâce à l’héritage.

Nous pouvons dire que l’approche orientée objet permet :

 Modéliser son application sous la forme d’interactions entre objets.
 Les objets ont des propriétés et peuvent faire des actions.
 Ils masquent la complexité d'une implémentation grâce à
l'encapsulation.
 Les objets peuvent hériter de fonctionnalités d'autres objets s'il y a
une relation d'héritage entre eux.
 Page |5

Il faut savoir que la POO, c’est beaucoup plus que ça et nous en verrons plus
dans la suite de ce cours, mais comprendre ce qu’est un objet est globalement suffisant
pour une grande partie du cours.

Les langages objets sont fondés sur la connaissance d’une seule catégorie
d’entités informatiques : les objets. Un objet incorpore des aspects statiques et dynamiques
au sein d’une même notion. Avec les objets les données sont prépondérantes. Et nous
devons répondre tout d’abord à la question « De quoi parle-t-on ? »

Un programme est constitué d’un ensemble d’objets chacun disposant d’une

partie procédures et d’une partie données. Les objets interagissent par envoi de messages.

Données Données

Méthodes Méthodes

Objet 1 Objet 2
1.2. DEFINITIONS

1.2.1 POO

La POO est une méthode d’implémentation dans laquelle les programmes sont
organisés sous formes de collections coopératives d’objets, dont chacun représente une
instance d’une classe quelconque et dont toutes les classes sont membres d’une hiérarchie
de classes unis à travers des relations d’héritage.

1.2.2 Classe

Une classe est la modélisation informatique d'un concept. Le concept doit avoir
une notion bien précise possédant plusieurs aspects, alors la représentation informatique de
cette notion, le sera sous forme de classe. Une classe est l’équivalent d’un type de donnée
(abstrait). Une classe permet de définir les données relatives à une notion, ainsi que les
actions qu'y s'y rapportent. Les variables à l'intérieur d'une classe seront appelées attributs,
et les procédures et les fonctions seront appelées méthodes.
La représentation d’une classe :
NomClasse
Les Attributs
(propriétés)
Les Méthodes
 Page |6

1.2.3 Objet

Un objet est une instance d’une classe ou soit est une entité logicielle. Si on
prend le monde réel, nous sommes entourés d’objets : une chaise, une table, une voiture,
etc. Ces objets forment un tout.

 Ils possèdent des propriétés (la chaise possède 4 pieds, elle est de couleur bleue,
etc.).
 Ces objets peuvent faire des actions (la voiture peut rouler, klaxonner, etc.).
 Ils peuvent également interagir entre eux (l’objet conducteur démarre la voiture,
l’objet voiture fait tourner l’objet volant, etc.).

Il faut bien faire attention à distinguer ce qu’est l’objet et ce qu'est la définition

d’un objet. La définition de l’objet (ou structure de l’objet) permet d’indiquer ce qui
compose un objet, c'est-à-dire quelles sont ses propriétés, ses actions etc. Comme par
exemple le fait qu’une chaise ait des pieds ou qu’on puisse s’asseoir dessus. Par contre,
l’objet chaise est bien concret. On peut donc avoir plusieurs objets chaises : on parle
également d’instances.

Finalement la notion d’objet est plutôt simple quand on la ramène à ce qu’on

connait déjà.

1.2.4 Attributs

Les attributs d’un objet sont l’ensemble des informations se présentant sous
forme de variable et permettant de représenter l’état de l’objet.

1.2.5 Message

Un message est une demande d’activation d’une méthode envoyé à un objet.

1.2.6 Méthodes

Une méthode est une fonction ou procédure liée à un objet qui est déclenchée à
la réception d’un message particulier : la méthode déclenchée correspond strictement au
message reçu. La liste des méthodes définies au sein d’un objet constitue l’interface de
l’objet pour l’utilisateur : ce sont les messages que l’objet peut comprendre si on les lui
envoie et dont la réception déclenche les méthodes correspondantes.
 Page |7

1.2.7 Signature

La signature d’une méthode représente la précision de son nom, du type de ses

arguments et du type de donnée retournée.
1.2.8 Constructeur

Le constructeur est une méthode particulière de l’objet qui permet de faire des
choses au moment de la création d’un objet, c’est-à-dire au moment où nous utilisons le
mot-clé new. Il est en général utilisé pour initialiser des valeurs par défaut d’un objet. Il est
en fait une méthode spéciale qui a le même nom que la classe et qui ne possède pas de type
de retour. Elle est appelée lors de la création de l’objet, avec new.

1.2.9 Mot-clé this

Lorsque nous écrivons le code d’une classe, le mot-clé this représente l’objet
dans lequel nous nous trouvons. Il permet de clarifier éventuellement le code, mais Il est
généralement facultatif. Ainsi, pour accéder à une variable de la classe ou éventuellement
une méthode, nous pouvons les préfixer par « this. ».

1.3. CONCEPT DE BASE DE LA POO

La Programmation orientée objet se base sur les notions clés suivantes : Classe
et objets, Encapsulation, Abstraction, Héritage ainsi que Polymorphisme.

1.3.1 Classes, objets, instances

Une classe est un ensemble d’objets qui ont en commun :
- Les mêmes méthodes

- Les mêmes types d’attributs

Classe = attributs + méthodes + instanciations

 Une instance d’une classe est un objet particulier d’une classe qui peut activer les
méthodes de la classe et qui a des valeurs particulières de ses attributs.
 On définit l’objet comme l’instance d’une classe. La classe représente pour l’objet ce
que représente le type pour la variable. Un objet est caractérisé par :
 Son identité (OID) : valeur unique et invariante qui caractérise l’objet
 Page |8

 Son comportement : qui est défini à travers les méthodes applicables à cet
objet et qui caractérisent sa façon d’agir et de réagir dans son environnement.
 Son état : qui constitue l’ensemble des valeurs des attributs de cet objet.

 Une classe est un type abstrait qui encapsulent données et traitement. C’est une sorte de
boite noire qui permet ensuite de créer autant d’instances qu’on veut. Ces instances
seront des objets de la classe auxquelles on pourra effectivement envoyer des messages
qui activeront les méthodes correspondantes.

Un exemple : Supposons que chaque étudiant soit caractérisé par sa note en

mathématiques (NoteMath) et sa note en informatique (NoteInfo). Un étudiant doit pouvoir
effectuer éventuellement des opérations de calcul de ses moyennes dans ces deux matières
(MoyMath, MoyInfo) et connaître sa moyenne générale calculée à partir de ces deux notes
(MoyTotale).

La classe Etudiant a été créée. Elle ne possède que les attributs NoteMath et
NoteInfo. On peut aussi ajouter d’autres attributs comme le nom, post-nom, …. Et Les
méthodes de cette classe sont par exemple MoyMath, MoyInfo, MoyTotale.

Nous avons créé deux objets étudiants (deux instances : Julien et Claudie) de la
classe Etudiant.

1.3.2 Encapsulation

L’encapsulation est le fait qu’un objet (entité) renferme ou réuni ses propres
attributs et ses méthodes. Les détails de l’implémentation d’un objet sont masqués aux
autres objets du système à objets. On dit qu’il y a encapsulation de données et du
comportement des objets.
 Page |9

On précise trois modes d’accès aux attributs d’un objet.

- Le mode public (+) : avec lequel les attributs seront accessibles directement
par l’objet lui-même ou par d’autres objets. Il s’agit du niveau le plus bas de
protection.
- Le mode private (-) : avec lequel les attributs de l’objet seront inaccessibles à
partir d’autres objets : seules les méthodes de l’objet pourront y accéder. Il
s’agit du niveau le plus fort de protection.
- Le mode protected (#) : cette technique de protection est étroitement associée
à la notion d’héritage.

1.3.2 Abstraction

C’est le fait de se concentrer sur les caractéristiques importantes d’un objet

selon le point de vue de l’observateur. Son objectif principal est de gérer la complexité en
masquant les détails inutiles à l’utilisateur. Cela permet à l’utilisateur d’implémenter une
logique plus complexe sans comprendre ni même penser à toute la complexité cachée.
L’abstraction est un principe qui consiste à ignorer certains aspects d’un sujet
qui ne sont pas importants pour le problème dans le but de se concentrer sur ceux qui le
sont.

1.3.4 Héritage
La notion d’héritage est une relation entre différentes classes permettant de
définir une nouvelle classe en se basant sur les classes existantes. On parle d’héritage
simple lorsqu’une classe fille ne possède qu’une classe mère. La relation entre la classe
mère et fille est « Est un ».
On parle d’héritage multiple lorsqu’une classe fille possède plusieurs classes
filles.

Classe mère

Classe fille
 P a g e | 10

a. Héritage simple

b. Héritage Multiple
1.3.5 Polymorphisme
Le terme polymorphisme issu du grec signifie la faculté de prendre plusieurs
formes. Une entité est polymorphe si à l’exécution elle peut se référer à des instances de
classe différentes.
Exemples :

Le polymorphisme est un mécanisme qui permet à une sous classe de redéfinir une
méthode dont elle a hérité tout en gardant la même signature de
 P a g e | 11

CHAPITRE II
MODELISATION ORIENTEE OBJET AVEC UML

Le développement orienté objet désigne une partie du cycle de vie du

logiciel dont l’analyse, la conception et l’implémentation. L’essence du développement
OO réside dans l’identification et l’organisation des concepts d’une application, et non
dans la façon dont ils seront finalement représentés dans un langage de programmation.

La communauté OO s’est largement focaliser sur les langages de

programmation (C++, Java, C#, …), la littérature mettant beaucoup plus l’accent sur
l’implémentation que sur l’analyse et la conception.

L’approche OO incite les développeurs à travailler et à penser en termes de

l’application tout au long de cycle de vie du logiciel. Ce n’est que lorsque les concepts
propres à l’application sont identifiés, organisés et matérialisés, qu’il est possible de traiter
efficacement les détails des structures de données et des fonctions.

II.1. La méthodologie orientée objet

La méthodologie OO comprend les étapes suivantes :

 Spécification initiale du système. Le développement logiciel commence au

moment où les analystes métier et les utilisateurs élaborent les spécifications d’une
application et expriment des exigences provisoires.
 Analyse. L’analyste étudie et reformule avec rigueur les besoins issus de la
conception du système en construisant des modèles. Il doit collaborer avec les
clients pour comprendre le problème, car son énoncé est rarement complet ou
correct.

Le modèle d’analyse est constitué de deux parties : le modèle du domaine, en

l’occurrence une description des objets du monde réel manipulés dans le
système, et le modèle de l’application, qui décrit les parties du système visibles
par l’utilisateur.
 P a g e | 12

 Conception du système. L’équipe de développement met au point une stratégie de

haut niveau – l’architecture du système – pour résoudre le problème posé par
l’application. Elle établit également des politiques qui serviront par défaut lors
d’étapes de conception ultérieures plus détaillées. Le concepteur du système doit
décider quelles sont les caractéristiques de performances à optimiser, choisir une
manière d’aborder le problème et effectuer des allocations prévisionnelles de
ressources.
 Conception des classes. Le concepteur des classes ajoute des détails au modèle
d’analyse en accord avec la stratégie de conception du système. Il élabore à la fois
les objets du domaine et ceux de l’application en employant les mêmes concepts
OO et la même notation, bien que ces objets existent sur des plans conceptuels
différents. Il se concentre sur les structures de données et les algorithmes
nécessaires pour implémenter chaque classe.
 Implémentation. Les développeurs chargés de l’implémentation transposent les
classes et les relations définies durant la conception en concepts propres à un
langage, à une base de données ou à une plate-forme. La programmation doit être
simple, car toutes les décisions difficiles sont normalement déjà prises.

II.2. Modèles de la programmation orientée objet

Un modèle est une représentation simplifiée d’une partie de la réalité avec un but
spécifique. Une simplification parce que le monde réel est trop complexe.

Il existe trois modèles pour décrire un système à partir de différents points de vue :
le modèle de classes, pour les objets du système et leurs relations, le modèle d’états, pour
retracer l’historique des objets, et le modèle d’interactions, pour les interactions entre
objets.

Le modèle de classes décrit la structure statique des objets d’un système et leurs
relations. Il définit le contexte du développement logiciel – l’univers du discours. Ce
modèle contient des diagrammes de classes. Un diagramme de classes est un graphe dont
les nœuds sont des classes et les arcs des relations entre ces classes.

Le modèle d’états décrit les états successifs d’un objet au cours du temps. Il
spécifie et implémente les aspects de contrôle du système au moyen de diagrammes
 P a g e | 13

d’états. Un diagramme d’états est un graphe dont les sommets sont des états et les arcs des
transitions entre états déclenchés par des événements.

Le modèle d’interactions décrit la façon dont les objets d’un système coopèrent
pour obtenir un résultat. Il commence par les cas d’utilisation, qui sont ensuite détaillés
grâce à des diagrammes de séquence et des diagrammes d’activités. Un cas d’utilisation
est axé sur une fonctionnalité – autrement dit sur ce que le système apporte à ses
utilisateurs. Un diagramme de séquence représente les objets qui interagissent et
l’ordonnancement de leurs interactions. Un diagrammes d’activités détaille les étapes
importantes du traitement.

Nota : Le modèle de classes est le plus fondamental, parce qu’il est nécessaire de décrire
ce qui change ou se transforme avant de décrire quand et comment les changements ont eu
lieu.

II.3. Historique de la modélisation objet

Entre 1970 et 1990, de nombreux analystes ont mis au point des approches
orientées objets, si bien qu’en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3
méthodes ont véritablement émergé :

 La méthode OMT de James Rumbaugh

 La méthode BOOCH’93 de Grady Booch
 La méthode OOSE de Ivar Jacobson

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont uni leurs
efforts pour mettre au point le langage de description UML (Unified Modeling Language),
qui permet de définir un langage standard en incorporant les avantages des différentes
méthodes (ainsi que celles d’autres analystes).

L’UML est un langage visuel pour la modélisation :

 Permettant la spécification, la visualisation, la construction et la

documentation des logiciels
 Facilitant la communication et le travail en équipe
 Ayant différents modèles pour différents points de vues
 P a g e | 14

 Utilisant une approche orientée objet

Ses deux principaux objectifs sont la modélisation de systèmes utilisant les

techniques orientées objet, depuis l’analyse jusqu’à la maintenance, et la création d’un
langage abstrait compréhensible par l’homme et interprétable par les machines.

II.4. Présentation générale des diagrammes UML

UML dans sa version 2 propose treize diagrammes qui peuvent être utilisés
dans la description d’un système. Ces diagrammes sont regroupés dans deux grands
ensembles dont les diagrammes de structure ou diagrammes statiques et les diagrammes
de comportement ou diagrammes dynamiques.

a. Diagrammes de structure ou diagrammes statiques

Ces diagrammes, au nombre de six, ont vocation à représenter l’aspect statique d’un
système (classes, objets, composants …).

 Diagramme de classes : ce diagramme représente la description statique du

système en intégrant dans chaque classe la partie dédiée aux données et celle
consacrée aux traitements. C’est le diagramme pivot de l’ensemble de la
modélisation d’un système.
 Diagramme d’objets : le diagramme d’objets permet la représentation d’instances
des classes et des liens entre instances.
 Diagramme de composants : ce diagramme représente les différents constituants du
logiciel au niveau de l’implémentation d’un système.
 Diagramme de déploiement : ce diagramme d’écrit l’architecture technique d’un
système avec une vue centrée sur la répartition des composants dans la
configuration d’exploitation.
 Diagramme des paquetages : ce diagramme donne une vue d’ensemble du système
structuré en package. Chaque package représente un ensemble homogène
d’éléments du système (classe, composants, …).
 Diagramme de structures composites : ce diagramme permet de décrire la structure
interne d’un ensemble complexe composé par exemple de classes ou d’objets et de
composants techniques.
 P a g e | 15

b. Diagrammes de comportement ou diagrammes dynamiques

Ces diagrammes représentent la partie dynamique d’un système réagissant aux

événements et permettant de produire les résultats attendus par les utilisateurs. Sept
diagrammes sont proposés par UML :

 Diagramme de cas d’utilisation : ce diagramme est destiné à représenter les

besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les
plus structurants dans l’analyse d’un système.
 Diagramme d’états – transitions : ce diagramme montre les différents états des
objets en réaction aux événements.
 Diagramme d’activité : ce diagramme donne une vision des enchaînements des
activités propres à une opération ou à un cas d’utilisation. Il permet aussi de
représenter les flots de contrôle et les flots de données.
 Diagramme de séquence : ce diagramme permet de décrire les scénarios de chaque
cas d’utilisation en mettant l’accent sur la chronologie des opérations en interaction
avec les objets.
 Diagramme de communication : ce diagramme est une autre représentation des
scénarios des cas d’utilisation qui met plus l’accent sur les objets et les messages
échangés.
 Diagramme d’interaction : ce diagramme fournit une vue générale des interactions
décrites dans le diagramme de séquence et des flots de contrôle décrits dans le
diagramme d’activités.
 Diagramme de temps : ce diagramme permet de représenter les états et les
interactions d’objets dans un contexte où le temps a une forte influence sur le
comportement du système à gérer.

I. Modélisation de Classes

A. Diagramme de classes

Le diagramme de classes est considéré comme le plus important de la modélisation

orientée objet. Il est le seul obligatoire lors d’une telle modélisation. La description du
diagramme de classe est fondée sur :
- Le concept d’objet,
 P a g e | 16

- Le concept de classe comprenant les attributs et les opérations,

- Les différents types d’association entre classes.
1. Classe
Une classe se représente à l’aide d’une boîte comprenant le nom de la classe, les
attributs et les opérations.

• Les attributs : Les attributs peuvent avoir

– un type
• type primitif
– montant: Real
– nom: String
– age: Integer
• type complexe
– une autre classe
– dateDeNaissance: Date
– une interface

• Les attributs peuvent avoir

– une valeur par défaut
• administrateur: String = "Simon"
– une liste de valeurs possibles (énumération)
• couleur: enum {gris, noir}
– une multiplicité de valeurs
• adresse: String[1..*]
• numéroDeTéléphone: String[*]
– une portée classe: soulignée
• duréeMaximum
Les opérations
• Les opérations peuvent avoir
– un nom
 P a g e | 17

• déplacer, sélectionner
– un type de retour
• Sélectionner () : Boolean
– des arguments (avec leurs types)
• Sélectionner (p: Point) : Boolean
– une portée classe
• (class scope): soulignée
La visibilité

• Les attributs et opérations ont une visibilité

– publique (+)
• Visible à l’extérieur de la classe
• taille, afficher()
– protégée (#)
• Visible seulement par les descendants
– private (-)
• Visible seulement à l’intérieur de la classe

2. Les Relations entre Classes

Une relation est utilisée afin de montrer comment deux classes sont liées entre
elles en suite elle exprime une connexion sémantique bidirectionnelle entre classes et est
une abstraction des liens qui existent entre les objets, instances des classes associées

1. La multiplicité

La multiplicité spécifie le nombre d’instances d’une classe qui peuvent être liées à
une seule instance d’une classe associée. Différents symboles sont utilisés pour indiquer la
multiplicité à chaque extrémité d’une association.
Merise UML Signification
0,1 0..1 Zéro ou un
1,1 1 un et un seul
0,n 0..* ou * De zéro à plusieurs
1,n 1..* D’un à plusieurs

2. L’étiquetage

Une relation peut être étiquetée afin de rendre explicite la nature de cette relation
 P a g e | 18

3. Type Association

– Une à plusieurs (one-to-many)

• Une entreprise a plusieurs employés
• Un employé ne peut travailler que pour une seule entreprise
• Une entreprise peut n’avoir aucun employé
• Un employé associé à une entreprise travaille pour cette compagnie

– Plusieurs à plusieurs (many – to – many)

• Un(e) secrétaire peut travailler pour plusieurs superviseurs
• Un superviseur peut avoir plusieurs secrétaires
• Les secrétaires peuvent travailler en équipes
• Les superviseurs peuvent avoir recours à un groupe de secrétaires
• Certains superviseurs peuvent n’avoir aucun(e) secrétaires
• Est-il possible qu’un(e) secrétaire puisse se retrouver, ne serait-ce que
temporairement, sans superviseur ?

– Attention aux associations une-à-une injustifiées (one – to – one)

• Un exemple plus complexe

– Une réservation est pour un passager
• Pas de réservations sans passager
• Une réservation ne devrait jamais compter plus d’un passager
 P a g e | 19

– Un passager peut effectuer plusieurs réservations

• Un passager peut aussi n’avoir fait aucune réservation

4. Classes-association

Il arrive, quelques fois, qu’un attribut ne puisse être attaché à aucune des deux
classes d’une association. Mais il peut être attaché à l’association elle-même.
Une classe-association est une association qui est également une classe. Vous
trouverez les classes-associations en recherchant les adverbes dans l’énoncé d’un problème
ou en abstrayant des valeurs connues.

5. Association réfléchie

Une classe peut être associée à elle-même

6. Association directionnelle

Les associations sont, par défaut, bidirectionnelles. Il est toutefois possible de

donner une direction à une association.
 P a g e | 20

7. Généralisation

La généralisation est une relation hiérarchique entre une classe (la super – classe)
et une ou plusieurs variantes de cette classe (les sous-classes). Elle organise les classes en
fonction de leurs similarités et de leurs différences, structurant ainsi la description des
objets. La super – classe contient les opérations, les associations et les attributs communs,
les sous-classes ajoutent des opérations, des associations et attributs spécifiques. On dit que
chaque sous-classe hérite des propriétés de sa super – classe. On qualifie parfois la
généralisation de relation « est-un », parce que chaque instance d’une sous-classe est
également une instance de la super – classe.
Une super – classe se spécialise en sous-classes. Le discriminant (optionnel) est une
étiquette décrivant le critère suivant lequel se base la spécialisation

a. Hiérarchie à plusieurs discriminants

En créant des généralisations à plusieurs niveaux

• En utilisant plusieurs arbres et héritage multiple

 P a g e | 21

b. Généralisation : Éviter les changements de classes

En fait, une instance ne peut jamais changer la classe à laquelle elle appartient

La généralisation a trois objectifs ;

– Prendre en charge le polymorphisme
– Structurer la description des objets
– Permettre la réutilisation du code
Nota : Les termes généralisation, spécification et héritage renvoient tous à des aspects de
la même notion.

8. Agrégation et composition

a. Agrégation

Une agrégation est une forme d’association qui exprime un couplage plus fort entre
classes. Une agrégation peut être utilisée si la relation qu’elle représente est de type :
– maître et esclaves : "appartient-à"
– tout et parties : "est-une-partie-de"
– composé et composant (constitué-constituant) : "est-composé-de"
Lorsque quelque chose contrôle l’agrégat, il contrôle aussi ses parties.
 P a g e | 22

Une agrégation est une forme spéciale d'une association représentant une relation
‘partie-tout’.
• Le ‘tout’ est souvent appelé l’ensemble ou l’agrégat
• Le symbole désignant l’agrégation se place du côté de l'agrégat
Par exemple, une Tondeuse A Gazon est constituée d’une Lame, d’un Moteur, de
plusieurs Roues et d’un Carter. Tondeuse A Gazon est l’assemblage et les autres sont les
constituants.

Les questions suivantes peuvent servir de test pour savoir si une association est une
agrégation ou pas :
 Peut-on utiliser l’expression fait partie de ?
 Les opérations appliquées a l’objet constitué s’appliquent elles
automatiquement à ses constituants ?
 Les valeurs des attributs de l’objet constitué se propagent-elles à tous ses
constituants ou à certains d’entre eux ?
 L’association présente-t-elle une asymétrie intrinsèque, dans laquelle une
classe est subordonnée à une autre ?

b. Composition

La composition est une relation d’agrégation dans laquelle il existe une

contrainte de durée de vue entre la classe « Composant » et la ou les classes « composé ».
Autrement dit la suppression de la classe composée implique la suppression de la ou des
classes composant.
 P a g e | 23

9. Classes abstraites

Une classe abstraite est une classe qui ne peut pas être instanciée en tant que telle
mais dont les sous-classes peuvent l’être. Une classe concrète est, quant à elle,
instanciable et peut donc avoir des instances directes.

Vous pouvez toujours décomposer une classe concrète en sous-classes, la

rendant ainsi abstraite.

10. Associations n-aires

Un programmeur peut connaître un langage et travailler sur un projet. Les

langages de programmation ne permettent pas d’exprimer d’associations n-aires, vous
devez les transformer en classes.
 P a g e | 24

B. Diagramme d’objets

Les diagrammes d’objets

– Représentent un ensemble d’objets et leurs liens, sont des vues statiques des
instances des éléments qui apparaissent dans les diagrammes de classes
– Présentent la vue de conception d'un système, exactement comme les
diagrammes de classes, mais à partir de cas réels ou de prototypes.
 P a g e | 25

II. Modélisation des états

Le modèle d’état décrit la séquence des opérations réalisées en réponse à des

stimuli externes. Ce modèle est constitué de plusieurs diagrammes d'états/transition.
Événements
Un événement est une occurrence ou un fait qui a lieu à un moment donné ; il
s’agit d’une modification intervenue dans l’environnement. Par exemple, l’utilisateur
appuie sur le bouton de gauche ou le vol 123 part de Kisangani.
Les événements correspondent souvent à des participes passés (électricité
allumée, alarme enclenchée) ou au moment où une condition commence à être vérifiée (la
corbeille à papiers devient vide, la température passe en dessous de zéro).
Par définition, un événement se produit instantanément par rapport à l’échelle
temporelle de l’application. Le terme événement est souvent employé de façon ambiguë.
Un événement désigne parfois une instance, d’autres fois une classe.
Plusieurs sortes d’événements existent. Les types les plus courants sont les
signaux, les événements de changement et les événements temporels.

- Événements de signal

Un signal est une transmission d’information explicite et unidirectionnelle

d’un objet à un autre. Il diffère d’un appel de sous-programme qui retourne une valeur.
Un événement de signal est un événement qui consiste à émettre ou à recevoir
un signal. Par exemple, le départ du vol 123 de LAC de Boma le 10 janvier 2008 est une
instance de la classe de signaux DépartDeVol.

- Événements de changement

Un événement de changement est causé par la satisfaction d’une expression

booléenne. L’objectif d’un événement de changement est que l’expression booléenne
correspondante soit testée en permanence : chaque fois que l’expression passe de faux à
vrai, l’événement se produit.
 P a g e | 26

La notation UML de ce type d’événement est le mot-clé when (quand) suivi d’une
expression booléenne entre parenthèses.
Exemples:
1. when (température de la pièce < température de déclenchement du
chauffage)
2. when (pression du pneu < pression minimale)

- Événements temporels

Un événement temporel est causé par l’occurrence d’un temps absolu ou par
l’écoulement d’une durée. La notation UML d’un temps absolu est le mot-clé when suivi
d’une expression temporelle entre parenthèses, tandis que celle d’un intervalle est le mot-
clé after (après) suivi d’une expression temporelle entre parenthèses.

Exemples:
1. when (date = 01/01/2009)
2. after (10 secondes)
États
Un état est une abstraction des valeurs et des liens d’un objet. Des ensembles
de valeurs et de liens sont groupés dans un état conformément au comportement global de
l’objet. Par exemple, l’état d’une banque est solvable ou insolvable, selon que ses actifs
excèdent ou non ses dettes.
Les états correspondent souvent à des participes présents (Attendant,
Numérotant) ou à la stabilité d’une condition (Allumé, InférieurAZéro).

Événements vs État

Les événements représentent des moments précis dans le temps et les états
représentent des intervalles de temps ;

Dans la pratique, on se contente généralement d‘associer des états à des objets.

 P a g e | 27

Transitions et conditions

Une transition est le passage instantané d’un état à un autre. Par exemple,
lorsque vous prenez un appel, la ligne effectue une transition : elle passe de l’état Sonnant
à l’état Connecté. On dit que la transition est franchie lors du passage de l’état source à
l’état cible.

L’origine et la cible d’une transition sont généralement deux états différents,

mais il peut s’agir du même état.

Une condition de franchissement est une expression booléenne qui doit être
vraie pour que la transition soit franchie. Par exemple, quand vous sortez le matin
(événement), si la température est inférieure à zéro (condition), mettez des gants (état
suivant).

A. Diagramme d’états – transitions

Un diagramme d’états est un graphe orienté dont les nœuds sont des états et les
arcs des transitions entre les états. Il spécifie les successions d’états provoqués par des
successions d’événements.
Vous pouvez implémentez les diagrammes d’états en les interprétant
directement ou en convertissant leur sémantique en un code équivalent.

Exemple de diagramme d’états

 P a g e | 28

Résumé de la notation de base des diagrammes d’états

• État. Un état est représenté par une boite aux coins arrondis contenant
optionnellement un nom. UML dispose d’une notation spéciale pour les
états initiaux (un cercle plein) et les états finaux (un cercle contenant un
point ou un x).

• Transition. Une transition est représentée par une ligne allant de l’état
d’origine à l’état cible. Une flèche pointe vers l’état cible. La ligne est
composée d’un ou de plusieurs segments.

• Événement. Un événement de signal est représenté sous forme d’étiquette

accolée à une transition, et peut être suivi d’attributs entre parenthèses. Un
événement de changement est représenté par le mot-clé when (quand) suivi
d’une expression booléenne entre parenthèses. Un événement temporel est
représenté par le mot-clé when suivi d’une expression entre parenthèses
indiquant un moment précis ou par le mot-clé after (après) suivi d’une
expression entre parenthèses exprimant une durée.

• Diagramme d’états. Un diagramme d’états est contenu dans un cadre

rectangulaire, le nom du diagramme figurant dans une petite étiquette
pentagonale située dans le coin supérieur gauche.

• Condition de franchissement. Une condition de franchissement est listée

optionnellement entre crochets après un nom d’événement.

• Effet (voir point suivant). Les effets peuvent être attachés à une transition ou
à un état et sont listés après une barre oblique (/). Les effets multiples sont
séparés par des virgules et exécutés simultanément. (Vous pouvez créer
des états intermédiaires si vous voulez que plusieurs effets soient exécutés
séquentiellement).
 P a g e | 29

B. Diagrammes d’états et comportements

L’utilité des diagrammes d’états serait limitée s’ils se bornaient à décrire des
événements. La description complète d’un objet doit spécifier ce qu’il fait en réponse aux
événements.

Effets et activités

Un effet est une référence à un comportement exécuté en réponse à un

événement. Une activité est le comportement réel qui peut être invoqué par un nombre
quelconque d’effets.
Par exemple, déconnecterLigne pourrait être une activité effectuée en réponse à
un événement raccroché.
Une activité peut être effectuée suite à une transition, à l’entrée ou à la sortie
d’un état, ou suite à un autre événement au sein d’un état.
Les activités peuvent également représenter des opérations de contrôle internes,
comme l’affectation d’une valeur à un attribut ou la génération d’un autre événement. Un
programme peut par exemple incrémenter un compteur interne chaque fois qu’un
événement donné survient.
La figure ci-dessous représente le diagramme d’états d’un menu contextuel sur
une station de travail. Quand le bouton droit est enfoncé, le menu est affiché. Quand il est
relâché, le menu est effacé. Tant que le menu est visible, l’élément de menu sélectionné est
mis en surbrillance en fonction de la position du curseur.

Activités d’entrée et de sortie

Au lieu de représenter des activités sur des transitions, vous pouvez les lier à
l’entrée ou à la sortie d’un état.
 P a g e | 30

La figure ci-dessous représente le même modèle avec des activités à l’entrée dans
les états.

Conseils pratiques
• Abstraire les valeurs dans les états. Ne considérez que les attributs pertinents pour
définir un état. Les diagrammes d’états n’utilisent pas nécessairement tous les
attributs représentés dans un modèle de classes.

• Paramètres. Considérez comme des paramètres les données secondaires qui

n’affectent pas le flux de contrôle.

• Granularité des événements et des états. Considérez les besoins de l’application

quand vous prenez des décisions concernant la granularité des événements et des
états.

• Quand utiliser des diagrammes d’états? Ne construisez de diagrammes d’états que

pour les classes ayant un comportement temporel significatif. Une classe a un
comportement temporel important si elle répond différemment à différents
événements ou si elle a plus d’un état. Toutes les classes ne nécessitent pas un
modèle d’états.
 P a g e | 31

• Activités d’entrée et de sortie. Quand un état a plusieurs transitions entrantes et

qu’elles provoquent toutes l’occurrence de la même activité, utilisez une activité
entrey (entrée) à l’intérieur de l’état au lieu de répéter ladite activité sur chaque
transition. Procédez de même pour les activités exit (sortie).

• Conditions de franchissement. Concevez soigneusement les conditions de

franchissement pour qu’un objet ne reste pas « bloqué » dans un état.

• Conditions de concurrence. Attention aux conditions de concurrence indésirables

dans les diagrammes d’états ! Elles interviennent souvent quand un état peut
recevoir des signaux de plus d’un objet.

Synchronisation des activités concurrentes

Parfois, un objet doit exécuter deux (ou plusieurs) activités concurremment. Les
étapes internes de ces activités ne sont pas synchronisées, mais les deux activités doivent
être achevées avant que l’objet ne puisse passer dans l’état suivant. Par exemple, un
distributeur automatique remet des billets à un utilisateur et lui rend sa carte à la fin de la
transaction. Le distributeur ne doit pas se réinitialiser tant que l’utilisateur n’a pas pris sa
carte et ses billets, mais celui-ci peut les prendre dans un ordre quelconque, voir
simultanément. C’est un exemple de division du contrôle en activités concurrentes et de
synchronisation du contrôle
 P a g e | 32

III. Modélisation des interactions

Le modèle de classes représente les objets et leurs relations. Le modèle d’états

décrit le cycle de vie des objets. Le modèle d’interactions, quant à lui, exprime la façon
dont les objets interagissent pour produire des résultats utiles à l’application.

Niveaux d’abstraction des interactions

• Les cas d’utilisation décrivent comment un système interagit avec les acteurs
extérieurs

– Chaque cas d’utilisation représente une partie des fonctionnalités que le

système fournit à ses utilisateurs.

• Les diagrammes de séquence fournissent plus de détails et représente les

messages que s’échange un ensemble d’objets au fil du temps
– Les messages comportent à la fois les signaux asynchrones et les appels de
procédures
• Les diagrammes d’activités fournissent des détails supplémentaires et représentent
le flux de contrôle entre les étapes d’un traitement
– Ils montrent aussi bien des flux de données que des flux de contrôle. Ils
décrivent également les étapes nécessaires à l’implémentation d’une
opération ou d’un processus métier référencé dans un diagramme de
séquence

A. Diagramme de cas d’utilisation

Définition d’un acteur

Un acteur est un utilisateur externe direct du système : un objet ou un

ensemble d’objets qui communique directement avec le système sans en faire partie.
Exemples
– Un client et un technicien de maintenance sont des acteurs différents d’un
distributeur automatique
– Les acteurs d’une agence de voyage sont voyageurs, agent, compagnie aérienne,
etc
 P a g e | 33

Cas d’utilisation

Un cas d’utilisation est une partie cohérente des fonctionnalités qu’un système
peut fournir en interagissant avec les acteurs.
Par exemple, un client peut acheter une boisson à un distributeur automatique.
Le client insère de la monnaie dans le distributeur, effectue une sélection et reçoit par la
suite une boisson.
Un cas d’utilisation comprend une séquence de messages échangés entre le
système et ses acteurs. Par exemple, dans le cas d’utilisation acheter une boisson, le client
commence par insérer une pièce et le distributeur affiche le montant inséré. Cette séquence
peut se répéter plusieurs fois. Puis, le client appuie sur un bouton pour sélectionner sa
boisson. Le distributeur délivre alors la boisson choisie et il rend la monnaie si cela s’avère
nécessaire.

Résumé des cas d’utilisation d’un distributeur automatique

• Acheter une boisson. Le distributeur délivre une boisson après que le client l’a
sélectionnée et payée.
• Effectuer une maintenance de routine. Un technicien de maintenance effectue sur
le distributeur l’entretien périodique nécessaire pour le maintenir en bon état de
fonctionnement.
• Effectuer une réparation. Un technicien de maintenance effectue sur le
distributeur le service ponctuel nécessaire pour réparer un dysfonctionnement.
• Recharger des articles. Un employé au stock ajoute dans le distributeur des articles
pour réapprovisionner son stock de boissons.

Description de cas d’utilisation

Un cas d’utilisation rassemble tous les comportements significatifs pour une

fonctionnalité donnée du système. Il inclut le comportement principal standard et ses
variantes possibles, les exceptions, les conditions d’erreur et les abandons.
Les étapes ci-dessous donnent un exemple de la description du cas d’utilisation,
nommé Acheter une boisson.
Cas d’utilisation : Acheter une boisson.
Résumé : Le distributeur délivre une boisson après que le client l’a sélectionnées et payée.
Acteurs : Client
 P a g e | 34

Préconditions : Le distributeur est en attente de l’insertion de pièces.

Description : Le distributeur commence dans l’état « en attente » dans lequel il affiche le
message « Insérez de la monnaie ». Un client insère des pièces dans le
distributeur. Le distributeur affiche le montant total inséré et allume les
boutons correspondant aux articles pouvant être achetés avec ce montant. Le
client appuie sur un bouton. Le distributeur délivre l’article correspondant et
rend la monnaie si le coût de la boisson est inférieur au montant inséré.
Exceptions :
Annulation : Si le client appuie sur le bouton Annulation avant de sélectionner un article,
le montant qu’il a inséré lui est rendu et le distributeur se remet dans l’état
« en attente ».
Épuisé : Si le client appuie sur le bouton d’un article épuisé, le message « Article
momentanément indisponible » est affiché. Le distributeur continue à accepter
des pièces ou une sélection.
Somme insuffisante : Si le client appuie sur le bouton d’un article dont le montant est plus
élevé que la somme insérée, le distributeur affiche le message « Vous
devez insérer nn,nn € de plus », où nn,nn est le montant manquant. Le
distributeur continue à accepter des pièces ou une sélection.
Pas de monnaie : Si le client a inséré suffisamment de pièces pour acheter l’article et que
la machine ne soit pas en mesure de rendre la monnaie correcte, le
message « Impossible de rendre la monnaie » est affiché et le distributeur
continue à accepter des pièces ou une sélection.
Post conditions : Le distributeur est en attente de l’insertion de pièces.
 P a g e | 35

2.4.2.4. Diagramme du cas d’utilisation d’un distributeur automatique

UML propose une notation graphique des cas d’utilisation. Un rectangle contient
les cas d’utilisation d’un système, les acteurs étant listés à l’extérieur. Un nom dans une
ellipse représente un cas d’utilisation. L’icône d’un « bonhomme en fil de fer » représente
un acteur, dont le nom peut être placé à côté ou en dessous de l’icône. Des lignes pleines
connectent les cas d’utilisation aux acteurs qui y participent.

Conseils pratiques

Voici quelques conseils pour bien construire les modèles de cas d’utilisation :

• Limites du système à déterminer avant tout. Il est impossible d’identifier les

acteurs ou les cas d’utilisation si les limites du système ne sont pas clairement
fixées
• Identification des acteurs. Chaque acteur doit avoir un objectif unique et cohérent.
Si un objet du monde réel a plusieurs objectifs, capturez-les dans des acteurs
séparés
• Cas d’utilisation complet. Un cas d’utilisation doit représenter une transaction
complète, qui apporte une valeur aux utilisateurs. Il ne doit pas être défini trop
étroitement
• Lien entre acteurs et les cas d’utilisation. Chaque cas d’utilisation doit posséder au
moins un acteur et chaque acteur doit participer à au moins un cas d‘utilisation. Un
cas d’utilisation peut impliquer plusieurs acteurs et un acteur peut participer à
plusieurs cas d’utilisation
 P a g e | 36

• Cas d’utilisation informels. Ne soyez pas obsédé par le formalisme lorsque vous
spécifiez des cas d’utilisation. Ne les considérez pas comme un outil de
modélisation formel mais plutôt comme un moyen d’identifier et d’organiser les
fonctionnalités du système d’un point de vue centré sur l’utilisateur. Il est
acceptable qu’ils soient tout d’abord un peu vagues : vous les préciserez plus tard
lorsque vous les détaillerez et implémenterez
• Cas d’utilisation structurés. Pour de nombreuses applications, vous élaborerez des
cas d’utilisation complètement distincts, mais si vous modélisez un grand système,
vous pouvez les construire à partir de fragments plus petits en employant des
relations

Relations entre cas d’utilisation

1. Relation include

La relation include insère un cas d’utilisation dans la séquence de comportements

d’un autre cas d’utilisation. Un cas d’utilisation inclus est comparable à une sous-routine :
il représente un comportement qu’il faudrait sinon décrire à plusieurs reprises.
La figure ci-dessous présente un exemple issu d’un système de courtage en ligne.
Une partie de l’établissement d’une session sécurisée est constituée par la validation du
code secret de l’utilisateur. Le système valide aussi le mot de passe pour chaque achat ou
vente d’actions. Les cas d’utilisation sécuriser session et réaliser transaction incluent tous
deux le cas d’utilisation valider code secret.
 P a g e | 37

2. Relation extend

La relation extend ajoute un comportement incrémental à un cas d’utilisation. Elle

est comparable à une relation include du côté opposé, dans laquelle l’extension s’ajoute à
la base au lieu que la base incorpore explicitement l’extension.

La figure ci-dessous présente le cas de base négocier des actions d’un système de
courtage. Le mot-clé « extend » accompagne la flèche. Le cas d’utilisation de base permet
simplement d’acheter et de vendre des actions au prix du marché. Le système de courtage
ajoute trois possibilités : acheter une action sur marge, vendre une action à découvert et
imposer une limite au montant d’une transaction (ordre à cours limité). Le cas d’utilisation
négocier des options a également une extension qui impose une limite au montant de la
transaction.

3. Généralisation

La généralisation permet de représenter les variantes spécifiques d’un cas

d’utilisation général, de façon analogue à la généralisation de classes. Un cas d’utilisation
parent représente une séquence de comportements générale. Les cas d’utilisation enfants
spécialisent le parent en insérant des étapes supplémentaires ou en affinant certaines
étapes.
Les cas d’utilisation peuvent également illustrer le polymorphisme – un cas
d’utilisation enfant peut se substituer à un parent, par exemple en tant qu’inclusion dans un
autre cas d’utilisation.
Par exemple, à la figure ci-dessous, le cas d’utilisation réaliser une transaction est
spécialisé en négocier des actions, négocier des obligations et négocier des options. Le cas
d’utilisation parent effectue les opérations nécessaires à tout type de transaction, comme la
 P a g e | 38

saisie du code secret. Chaque cas d’utilisation enfant contient les étapes supplémentaires
spécifiques à un type de transaction donné, comme la saisie de la date d’inspiration d’une
option.

2.4.5.4. Relations entre cas d’utilisation

Un seul diagramme peut combiner plusieurs types de relations entre cas

d’utilisation. La figure ci-contre présente un diagramme de cas d’utilisation d’un système
de courtage. Le cas d’utilisation sécuriser session inclut le comportement des cas
d’utilisation valider code secret, réaliser une transaction et gérer un compte. Réaliser une
transaction est un parent abstrait qui a trois enfants : négocier des actions, négocier des
obligations et négocier des options. Le cas d’utilisation réaliser une transaction inclut
également le comportement de valider code secret. Le système valide le code secret une
fois par session et une fois par transaction.
Le cas d’utilisation effectuer une opération sur marge étend à la fois négocier des
actions et négocier des obligations : un client peut acheter des actions et des obligations
sur marge, mais pas des options. Le cas d’utilisation placer un ordre à cours limité étend le
cas d’utilisation abstrait réaliser une transaction : les ordres à cours limité s’appliquent
aussi bien aux actions qu’aux obligations et aux options. Nous supposons qu’une vente à
découvert est permise pour les actions, mais pas pour les obligations ni pour les options.
 P a g e | 39

2.4.5.5. Conseils pratiques

• Généralisation. Si un cas d’utilisation présente plusieurs variantes, modélisez le

comportement commun dans un cas d’utilisation abstrait puis spécialisez-le en
créant des variantes. N’utilisez pas la généralisation uniquement pour partager un
fragment de comportement ; en ce cas, employez une relation include

• Inclusion. Si un cas d’utilisation comprend un fragment de comportement bien

défini susceptible d’être utile dans d’autres situations, définissez un cas
d’utilisation pour ce fragment de comportement et incluez-le dans le cas
d’utilisation d’origine. Dans la plupart des cas, vous devez considérer le cas
d’utilisation inclus comme une activité significative, non comme une fin en soi. Par
exemple, la validation d’un code secret est significative pour un utilisateur mais n’a
de finalité que dans un contexte plus large

• Extension. Si vous pouvez définir un cas d’utilisation significatif ayant des

caractéristiques optionnelles, modélisez le comportement de base comme un cas
d’utilisation et ajoutez des fonctionnalités avec la relation extend. Cette pratique
permet de tester et de déboguer le système sans les extensions, qui pourront être
ajoutées ultérieurement. Utilisez une relation extend lorsqu’un système est
 P a g e | 40

susceptible d’être déployé sous plusieurs configurations, certaines avec les

fonctionnalités supplémentaires et d’autres sans

• Relation extend vs relation include. extend et include peuvent toutes deux

factoriser le comportement en unités plus restreintes. Toutefois, la relation include
implique que le comportement inclus fait nécessairement partie d’un système
configuré (même si le comportement n’est pas déclenché à chaque fois) alors que la
relation extend sous-entend qu’un système dépourvu du comportement ajouté serait
toujours significatif (même s’il n’y a pas de raison de le configurer de cette
manière).

B. Diagramme de séquence

Un modèle de séquence précise les thèmes fonctionnels introduits par les cas
d’utilisation. Deux types de modèles de séquence existent : les scénarios et un format plus
structuré nommé diagramme de séquence.
Un diagramme de séquence représente les participants à une interaction et la
séquence des messages qu’ils échangent. Il montre comment un système et ses acteurs
interagissent afin d’exécuter tout ou partie d’un cas d’utilisation.
La description du comportement de chaque cas d’utilisation nécessite plusieurs
diagrammes de séquence. Chacun d’eux représente une séquence de comportements
particulière du cas d’utilisation. Mieux vaut représenter une portion spécifique d’un cas
d’utilisation et de ne pas essayer d’être trop général.
 P a g e | 41

2.4.3.3. Conseils pratiques

• Au moins un scénario par cas d’utilisation. Les étapes d’un scénario doivent être
des commandes logiques, non de simples clics sur un bouton. Plus tard, lors de
l’implémentation, vous pourrez spécifier la syntaxe exacte d’entrée. Commencez
par l’interaction principale la plus simple: pas de répétition, une activité principale
et des valeurs types pour tous les paramètres. Si des interactions principales
substantiellement différentes existent, écrivez un scénario pour chacune d’entre
elles.

• Scénarios synthétisés sous forme de diagrammes de séquence. Il est important de

séparer la contribution de chaque acteur et de la représenter sous forme de
diagramme de séquence car c’est le prélude à l’organisation du comportement des
objets

• Interactions complexes subdivisées. Décomposez les interactions de grande taille

en sous-tâches et tracez un diagramme de séquence pour chacune d’elles.

• Un diagramme de séquence par condition d’erreur. Représentez la réponse du

système à la condition d’erreur.

C. Diagramme d’activités
 P a g e | 42

Un diagramme d’activités représente la suite d’étapes qui constituent un processus

complexe, par exemple un algorithme ou un workflow (flux de travaux). Il exprime le flux
de contrôle, comme un diagramme de séquence, mais en se concentrant sur les opérations
plutôt que sur les objets.
Les diagrammes d’activités sont particulièrement utiles durant les premiers stades
de la conception des algorithmes et des workflows.
La figure ci-dessous présente un diagramme d’activités du traitement d’ordre de
transaction reçu par un système de courtage en ligne. Les boîtes aux coins arrondis
représentent les activités et les flèches leur séquencement. Le losange indique un point de
décision et les barres en gras représentent la scission ou la fusion de fils d’exécution
(threads) concurrents.
Le système de courtage en ligne commence par vérifier que l’ordre est compatible
avec le compte du client, puis il l’exécute. Si l’ordre est exécuté avec succès, le système
réalise simultanément trois opérations : envoyer un courrier de confirmation au client,
mettre à jour le portefeuille en ligne pour qu’il reflète les résultats de la transaction et
conclure la transaction auprès de l’autre partie en transférant des liquidités ou des actions.
Quand tous les fils d’exécution concurrents se terminent, le système fusionne le
contrôle dans un seul fil et il clôture l’ordre. Si l’exécution de l’ordre échoue, le système
envoie une notification d’échec au client et il clôture aussi l’ordre dans ce cas.
 P a g e | 43

2.4.4.1. Les activités

Les étapes d’un diagramme d’activités sont des opérations, plus spécifiquement les
activités décrites dans le modèle d’états. L’objectif d’un diagramme d’activités est de
représenter les étapes d’un processus complexe et les contraintes de séquencement.

2.4.6. Modèles de séquence procédurale

2.4.6.1. Diagrammes de séquence avec objets passifs

Un objet demeure actif après avoir envoyé un message et peut répondre à d’autres
messages sans attendre de réponse. Cette représentation est appropriée pour les modèles de
haut niveau. En revanche, la plupart des implémentations sont procédurales et limitent le
nombre d’objets qui peuvent effectuer des tâches simultanément.

La syntaxe UML des diagrammes de séquence dispose d’une notation dédiée qui
permet d’illustrer des appels de procédures

Dans un code procédural, tous les objets ne sont pas constamment actifs. La plupart
d’entre eux sont passifs et n’ont pas leur propre thread. Un objet passif n’est pas activé tant
que l’un de ses comportements n’a pas été déclenché. Une fois que l’exécution d’une
opération se termine et que le contrôle retourne à l’appelant, l’objet passif devient inactif.

La figure ci-dessous présente le calcul d’une commission pour une transaction

boursière. L’objet transaction reçoit une requête de calcul de sa commission. Il obtient le
niveau de service du client de la table des clients puis demande à la table des taux de
calculer la commission en fonction du niveau de service, après quoi il retourne la valeur de
la commission à l’appelant.

UML représente une période de temps pour l’exécution d’une opération d’un objet
par un étroit rectangle. C’est ce que l’on nomme activation ou période d’activation. Une
activation représente la période pendant laquelle un appel de méthode est traité, y compris
le moment où la méthode appelée a invoqué une autre opération. La période pendant
laquelle un objet existe mais n’est pas actif est indiquée par une ligne pointillée. La période
 P a g e | 44

entière durant laquelle l’objet existe est appelée ligne de vie, puisqu’elle montre la durée
de vie de l’objet.

2.4.6.2. Conseils pratiques

• Objets actifs vs objets passifs. Différenciez les objets actifs des objets passifs. La
plupart des objets sont passifs et n’ont pas leur propre thread de contrôle. Par
définition, les objets actifs sont toujours activés et possèdent leur propre période
d’activation
 P a g e | 45

• Notation avancée. Des éléments de notation avancés peuvent illustrer

l’implémentation des diagrammes de séquence. Soyez prudent avec ces éléments
avancés. Ne représentez les détails d’implémentation que pour les diagrammes
difficiles ou particulièrement importants
 P a g e | 46

3.6.2. Langages orientés objets

Il est relativement aisé d’implémenter une conception OO avec un langage OO

depuis que les éléments des langages sont similaires aux éléments de conception.

3.6.2.1. Implémentation de la structure

La première étape de l’implémentation d’une conception OO consiste à mettre en
œuvre la structure spécifiée par le modèle de classes.

Les tâches suivantes doivent être réalisées: implémenter les types de données;
implémenter les classes; implémenter le contrôle d’accès; implémenter les généralisations;
Implémenter les associations.

3.6.2.1.1. Types de données

 P a g e | 47

Si vous n’avez pas encore affecté les types de données aux attributs, il est temps de
le faire maintenant. Certains types de données méritent une attention particulière
Types primitifs

Les nombres à virgule flottante, les entiers, les caractères et les booléens peuvent
exprimer des valeurs simples. Lorsque c’est possible, employez des valeurs numériques
plutôt que des chaînes de caractères. Les types numériques permettent une meilleure
efficacité du point de vue de l’espace mémoire et du traitement et facilitent la maintenance
de l’intégrité des attributs.

Types objet

Vous pouvez utiliser des objets pour regrouper et organiser des valeurs d’attribut en
types plus riches.
Les structures de C++ ne sont pas techniquement différentes des classes, hormis le
fait que tous les membres sont publics par défaut.

struct adresse {
string rue;
string ville;
string departement;
adresse() : rue(’’ ’’), ville(’’ ’’), departement(’’ ’’) {}
};
class Client {
string nom;
adresse adr; //attribut objet
float montantTemp;
public:
//…
string ville() { return adr.ville; } // utilise la délégation
};

Vous pouvez appliquer une stratégie similaire en Java, bien que l’initialisation ou le
constructeur de l’objet hôte doive créer explicitement l’instance de l’attribut objet. L’accès
 P a g e | 48

package par défaut permet l’accès aux membres qui sont des attributs objet à l’intérieur de
la classe utilisatrice.

class Adresse {
String rue=’’ ’’;
String ville=’’ ’’;
String departement= ’’ ’’»;
};
public class Client {
private String nom;
// notez la construction explicite de l’attribut
private Adresse adr = new Adresse(); // attribut objet
private float montantTemp;
//…
String ville() { return adr.ville; } // utilise la délégation
};

Types références

Vous pouvez employer des références d’objets en Java, et des références et des
pointeurs en C++ pour implémenter les associations.

3.6.2.1.2. Classes

Les langages de programmation OO prennent directement en charge

l’implémentation des objets. Vous devez déclarer chaque attribut et chaque méthode d’un
modèle de classe dans la classe C++ ou Java correspondante. Il est également nécessaire
d’ajouter les attributs et les méthodes destinés à l’implémentation des associations. Une
bonne pratique consiste à conserver les noms du modèle de conception.
Pour l’étude de cas du GAB, nous placerions chacune des classes dans un fichier
séparé. Par exemple, le fichier source Banque.java contiendrait:
package infoBanque;
public class Banque {…}

Et le fichier Client.java contiendrait:

 P a g e | 49

package infoBanque;
public class Client {…}

Les fichiers Banque.java, Client.java, et ceux des autres classes du package

infoBanque doivent se situer dans un répertoire nommé infoBanque. Pour que Banque et
Client soient visibles de la classe SessionGAB, qui ne fait pas partie du package
infoBanque, le fichier source SessionGAB.java doit débuter par:
import infoBanque;
public class SessionGAB {…}

L’instruction import permet à l’implémentation de SessionGAB de voir et d’utiliser

les méthodes publiques des classes publiques situées dans le package infoBanque.

3.6.2.1.3. Généralisation

L’implémentation de l’héritage est réalisée par le mot-clé extends.

class Compte {
private float solde;
public void Enregistrer(float montant) {..}
public float Solde() {return solde;}
}
class CompteEpargne extends Compte {
private float taux; // ajout de l’attribut taux d’intérêt
float CalculInterets() {
// calcul des intérêts dûs non payés
}
}

3.6.2.1.4. Association
 P a g e | 50

Si nous n’avons pas besoin de retrouver la collection des employés d’une société,
un pointeur de Personne vers Société s’avérera suffisant. En Java, la classe Personne peut
simplement contenir un champ de type Société.
public class Societe {}
public class Personne {
private Societe employeur;
…
}

Les associations bidirectionnelles entraînent la maintenance des liens pour les deux
extrémités de l’association. Par exemple, si un client peut avoir plusieurs comptes et qu’on
veuille être en mesure de naviguer dans les deux directions de l’association.

public class Compte {

private Client client; // l’extrémité un de un-a-plusieurs
…
}

Import java.util.*; // pour pouvoir accéder à la classe HashSet

public class Client {
// liste de références de comptes
private HashSet comptes = new HashSet();
…
}

3.6.2.2. Implémentation des fonctionnalités

Après avoir mis en place la structure, vous pouvez commencer à implémenter les
méthodes. Pour chaque classe, spécifiez la signature des méthodes (nom de la méthode,
paramètres, type de retour).
Des méthodes peuvent aussi résulter d’attribuer dérivés, du modèle d’états et du modèle
d’interactions.

3.6.3. Bases de données

 P a g e | 51

Le paradigme OO est adaptable et s’applique aussi bien aux bases de données qu’à
la programmation. Cela peut vous surprendre, mais vous pouvez implémenter des modèles
UML non seulement avec les bases de données OO mais aussi avec des bases de données
relationnelles. Les bases de données résultantes sont performantes, cohérentes et
extensibles.

Il est facile de traduire le modèle de classes en code SQL. De nombreux outils en

sont capables, mais vous devez néanmoins connaître les règles.
3.6.3.1. Implémentation des classes

Normalement, vous devez faire correspondre chaque classe à une table et chaque
attribut à une colonne. Vous pouvez ajouter des colonnes pour un identifiant d’objet et
pour les associations.

3.6.3.2. Implémentation des associations

Les règles d’implémentation des associations dépendent de la multiplicité.

 Associations de multiplicité plusieurs-à-plusieurs. Implémentez l’association par
une table, la clé primaire de l’association étant une combinaison des clés primaires
des classes. Si l’association a des attributs, ils deviennent des colonnes
supplémentaires de la table.
 Associations de multiplicité un-à-plusieurs. Chaque association devient une clé
étrangère encapsulée dans la table de la classe située à l’extrémité « plusieurs ». si
l’extrémité « un » de l’association avait un nom, nous l’utiliserions comme nom de
la clé étrangère.
 Associations de multiplicité un-à-un. Elles se produisent rarement. Vous pouvez
les gérer en encapsulant une clé étrangère dans l’une ou l’autre table.
 P a g e | 52

 Associations n-aires. Elles sont également rares. Vous pouvez les traitées comme
des associations de multiplicité plusieurs-à-plusieurs et créer une table pour
l’association. Généralement, la clé primaire d’une association n-aire combine les
clés primaires des tables associées.
P a g e | 53
 P a g e | 54

Références

Michael Blaha & James Rumbaugh. Modélisation et conception orientées objet avec UML
2. Pearson Education, 2e édition, 2005.

Patrick Longuet. Java: Livre d’or. Sybex, 1996.

Kris Jamsa, C/C++/C# La Bible du programmeur, Ed. Reynald Goulet inc., 2004.

Tom Mens. Génie Logiciel Orienté Objet. Université de Mons-Hainaut Service de Génie
Logiciel, 2006.

Intégrer UML dans vos projets.