Cours de UML

Méthode de conception Orientée Objet UML
Méthode de conception Orientée Objet

UML
Bennani Mohamed Taj
Faculté des sciences Dhar El Mahraz Fes 1/122
2020/2021
Bennani Mohamed Taj Faculté des sciences Dhar El Mahraz Fes 1/122
1 Section I : Introduction
2 Section II : Le génie logiciel
Présentation
Les objectifs du génie logiciel
Les étapes de réalisation d’un logiciel
Autres modèles de développements logiciels
3 Section III : Méthode de conception orienté objet UML
Introduction à l’UML
Les diagrammes de UML
La partie structurelle
La partie comportementale
Notion d’objet
Les cas d’utilisation
Le diagramme de classe
Les diagrammes de séquence
Section I : Introduction
Contexte
L’appréhension d’une problématique complexe telle que

le développement d’applications repose de plus en plus sur
le recours à la modélisation informatique.
L’accélération du renouvellement des technologies conjuguée
avec la pression économique et concurrentielle qui s’exerce
sur les entreprises, obligent les acteurs du monde informa-
tique à produire des solutions de plus en plus rapidement,
dans un contexte d’amélioration continue de la qualité et de
la performance des systèmes d’information.
Internet a été un vecteur favorisant le développement de très
nombreuses applications dont une grande partie utilise des
solutions à base de langage de programmation objet comme
Java, C++ ou C#.
Objectif
Depuis longtemps, le langage UML (Unified Modelling Lan-

guage) est développé pour formaliser des besoins clients aux
programmes qu’ils réalisent.
Cette méthode est proposé comme moyen de communication
entre modélisateurs ou informaticiens et les autres métiers
indépendamment des disciplines et de la technique informa-
tique.
UML a apporté tout naturellement le support méthodologique
qui manquait à tous les concepteurs et développeurs, qui
voulaient formaliser l’analyse et la conception technique de
leur logiciel.
Spécifications
Depuis plus de 30 ans, la conception des bases de données

est réalisée à l’aide du modèle entité-association. Ce modèle
a fait ses preuves et la plupart des outils informatiques de
conception l’utilisent encore aujourd’hui.
La notation UML s’est imposée depuis quelques années pour
la modélisation et le développement d’applications écrites
dans un langage objet (C++ et Java principalement).
Initialement, UML n’a pas été conçue pour les bases de
données. Cependant, elle offre un même formalisme aux concep-
teurs d’objets métiers et aux concepteurs de bases de données.
UML s’est imposée en tant que langage graphique de modélisation
puisqu’il répond à un véritable besoin et devenu un standard
car il s’appuie sur une norme très structurante.
Historique de l’UML
Il hérite principalement des méthodes objets de Booch ,
OMT (Object Modeling Technique en français Technique de
modélisation objet) et OOSE (Object Oriented Software En-
gineering) inventées respectivement par Grady Booch, Rum-
baugh et Jacobson.
UML est une fusion de OOA/OOSE/OMT.
Adopté par l’ OMG en Novembre 1997 devient un standard.
Section II : Le génie logiciel
Présentation
Présentation du génie logiciel
Définition d’un logiciel

Un logiciel est un ensemble d’appels de sous-programmes.
Génie logiciel
Un Ensemble de méthodes, de techniques et d’outils dédiés à la
conception, au développement et à la maintenance des systèmes
informatiques.
Les objectifs du génie logiciel
Objectifs du génie logiciel

Avoir des procédures systématiques pour créer des logiciels de
grande taille qui respectent les règles imposées par CQFD :
Coûts : les coûts alloués à la réalisation soient respectés
Qualité : il doit respecter les qualités suivantes :
Validité : capacité à exécuter les tâches pour lesquelles il a
été créé.
Fiabilité : capacité de fournir les résultats attendus.
Extensibilité : capacité d’ajouter de nouvelles fonctionnalités.
Compatibilité : capacité de coopérer avec d’autres logiciels.
Efficacité : capacité de fournir de bon résultats dans les délais
prévus.
Portabilité : capacité d’être porté sur d’autre OS.
Fonctionnalités : La spécification doit correspondre aux be-
soins réels du client.
Délais : le délais ne doit pas être dépassé.
Les phases de réalisation d’un logiciel
La réalisation d’un logiciel se résume en 6 phases :

1 La phase d’analyse.
2 La phase de conception.
3 La phase de réalisation.
4 La phase de mise en place.
5 La phase d’exploitation et maintenance.
6 La phase de démontage.
La phase d’analyse
Pour créer un nouveau logiciel, On effectue l’étude de faisabilité

qui consiste à déterminer :
Les avantages.
Les inconvénients.
Elle est destinée aux décideurs qui :
Valident les orientations.
Chiffrent l’effort, coût de réalisation, gestion des délais, temps
de formation des utilisateurs, coûts d’achat de nouveaux
matériels, récupération des anciennes données.
La phase d’analyse
Le Cahier des charges est une phase importante qui permet de :

Faire une étude de l’existence des logiciels.
Est un guide qui permet de définir les logiciels dans ses
grandes lignes (pas trop techniques).
Indique ce qui doit être fait mais sans dire vraiment com-
ment.
Permettra au concepteur de valider chaque étape de la réalisation
du logiciel.
Indique les spécifications du projet.
La phase de conception
C’est la phase la plus importante, elle définit l’architecture du
logiciel (son squelette, son comportement, etc.). Il y’a 2
architectures :
L’architecture global du logiciel : qui consiste à faire une
représentation globale du logiciel (décrire le logiciel de façon
global).
L’architecture détaillée : décrit les composants du logiciel et
le lien entre les différents composants du logiciel.
L’architecture d’un logiciel concerne 2 aspects :
L’aspect statique : décrit les parties non variables du logiciel
une fois validé .
L’aspect dynamique : décrit le comportement du logiciel de
façon globale et de chaque composant du logiciel.
La phase de réalisation
Une fois la conception terminée et validée, la réalisation du

logiciel doit être effective.
Il s’agit de transformer le schéma du logiciel en un produit
(exécutable).
Cette phase consiste à conduire le logiciel.
La spécification consiste à décrire toutes les spécifications :

Fonctionnelles : ce que doit réaliser le logiciel (sous- pro-
grammes / traitements à réaliser).
Non fonctionnelles : contraintes d’environnements, perfor-
mance, sécurité.
La conception consiste à apporter une réponse à l’étape
Précédente :
Architecture (modules, objets, classes, fonctions).
Matériel (environnement de développement, application ex-
ternes utilisées).
L’implantation ( implémentation ou codage) consiste à coder
les données.
La validation sert à vérifier chaque module.
Il faut garder la trace de ce qui a été fait.
La phase de mise en place
Maintenant que le logiciel est réalisé (l’exécutable obtenu),

il faut passer à sa mise en œuvre.
Mettre en œuvre un logiciel veut dire le déployer :
Installer le logiciel dans l’environnement de production.
Dès le début de la phase de réalisation, il faudrait pouvoir
disposer d’une machine dans l’environnement de production.
Le déploiement d’un logiciel exige la préparation de son en-
vironnement de production.
Interconnecter tous les systèmes et processus devant com-
muniquer avec le logiciel.
Transfert de données et conversion dans un nouveau format
(Récupération).
La phase d’exploitation
Une fois le logiciel est en place, son exploitation devient fon-

damentale.
Cette phase résume deux tâches qui doivent se réaliser depuis
la mise en place du logiciel jusqu’à sa fin.
Pour commencer l’exploitation du logiciel, on fait le paramétrage
du logiciel (l’insertion des données).
Ensuite faire le traitement de données (tester le logiciel) pour
détecter les erreurs s’ils y existent.
La phase de maintenance
Une fois les erreurs détectées, il faut passer à la correction

(la maintenance du logiciel).
La maintenance doit se tenir régulièrement.
Il existe 3 types de maintenance :
Corrective : consiste à corriger les erreurs détectées lors de
l’exploitation. Bugs qui apparaissent.
Adaptative : consiste à adapter le logiciel à un besoin ou à
un environnement : Besoins exprimés par les utilisateurs pour
faciliter leurs travail.
Perfective : le logiciel satisfaisant toutes les exigences du ca-
hier des charges, il est nécessaire de penser à son évolution.
Il s’agit de le rendre plus performant. Mise en place d’un
système de traçage des bugs (date/conditions de reproduc-
tion/solution et correction).
La phase de démontage
Malgré toutes les maintenances réalisées, le logiciel ne peut

plus satisfaire les besoins du client , donc révolue : c’est la
fin de vie du logiciel, on parle alors de démontage.
Un logiciel est qualifié de révolue lorsque :
Il ne satisfait plus les besoins des utilisateurs et aucune main-
tenance ne peut palier au problème.
Il est dépassé par la technologie.
Le client n’a plus besoin du logiciel.
Le démontage du logiciel est assimilé comme la fin de vie du
logiciel.
Il faut donc supprimer les exécutables, les drivers et les
données.
Le modèle en cascade
Le modèle en V
Section III : Méthode de conception orienté objet UML
Présentation de UML
UML (Unified Modeling Language) est normalisé par l’OMG

(Object Management Group).
http://www.omg.org/spec/UML/
Dernière version : 2.5.1 (Décembre 2017)
UML est une notation standard pour la modélisation d’ap-
plications à base d’objets (et de composants depuis la version
2).
UML est utilisable dans de nombreux autres contextes de
conception ou spécification.
Exemple : schéma de BDD.
UML est un langage utilisant une notation graphique.
Le modèle(diagramme)
Un modèle est une représentation partielle de la réalité.

Abstraction de ce qui est intéressant pour un contexte donné.
Vue subjective et simplifiée d’un système.
Avec UML, on va s’intéresser principalement aux modèles
d’applications informatiques :
Un modèle UML = des diagrammes UML
L’utilité des modèles
Faciliter la compréhension d’un système :

Permettre également la communication avec le client.
Vision de communication, de documentation.
Définir voire simuler le fonctionnement d’un système :
Dans ce cas, on se doit d’être le plus précis possible dans le
contenu des modèles pour s’approcher du code.
Vision de développement, de production.
Introduction
Afin d’assurer un bon niveau de cohérence et d’homogénéité

sur l’ensemble des modèles, UML propose :
D’une part un certain nombre de règles d’écriture ou de
représentations graphiques normalisées.
Et d’autre part des mécanismes ou des concepts communs
applicables à l’ensemble des diagrammes.
Certains éléments, comme les stéréotypes, sont spécifiquement
prévus pour assurer une réelle capacité :
D’adaptation.
Et d’évolution.
La notation pour prendre en compte les particularités des
différentes situations à modéliser.
Les différents types de diagrammes
UML, dans sa version 2, propose 13 diagrammes qui peuvent

être utilisés dans la description d’un système.
Les diagrammes sont regroupés dans deux grands ensembles.
Les diagrammes Structurels.

Les diagrammes comportementaux.
Les diagrammes d’interactions.
Diagrammes selon les axes de modélisation
Hiérarchie des diagrammes UML
Les 5 vues de Kruchten
Les diagrammes structurelles
Ces diagrammes, au nombre de six, ont vocation à représenter

l’aspect statique d’un système (classes, objets, composants. . . ).
Diagramme de classes : représente la description statique
du système en intégrant dans chaque classe la partie dédiée
aux données et celle consacrée aux traitements. C’est le dia-
gramme pivot de l’ensemble de la modélisation d’un système.
Diagramme d’objets : permet la représentation d’instances
des classes et des liens entre instances.
Diagramme de composant (modifié dans UML 2) : représente
les différents constituants du logiciel au niveau de l’implémentation
d’un système.
Les diagrammes structurelles
Diagramme de déploiement (modifié dans UML 2) : décrit

l’architecture technique d’un système avec une vue centrée
sur la répartition des composants dans la configuration d’ex-
ploitation.
Diagramme de paquetage (nouveau dans UML 2) : donne
une vue d’ensemble du système structuré en paquetage. Chaque
paquetage représente un ensemble homogène d’éléments du
système (classes, composants. . . ).
Diagramme de structure composite : permet de décrire la
structure interne d’un ensemble complexe composé par exemple
de classes ou d’objets et de composants techniques. Ce dia-
gramme met aussi l’accent sur les liens entre les sous en-
sembles qui collaborent.
Les diagrammes comportementaux
Ces diagrammes représentent la partie dynamique d’un système

réagissant aux événements et permettant de produire les
résultats attendus par les utilisateurs. Sept diagrammes sont
proposés par UML :
Diagramme des cas d’utilisation : est destiné à représenter les
besoins des utilisateurs par rapport au système. Il constitue
un des diagrammes les plus structurants dans l’analyse d’un
système.
Diagramme d’état-transition (machine d’état) : montre les
différents états des objets en réaction aux événements.
Les diagrammes comportementaux
Diagramme d’activités (modifié dans UML 2) : donne une vi-

sion des enchaı̂nements des activités propres à une opération
ou à un cas d’utilisation. Il permet aussi de représenter les
flots de contrôle et les flots de données.
Diagramme global d’interaction (nouveau dans UML 2) :
fournit une vue générale des interactions décrites dans le
diagramme de séquence et des flots de contrôle décrits dans
le diagramme d’activités.
Diagramme de temps (nouveau dans UML 2) : permet de
représenter les états et les interactions d’objets dans un contexte
où le temps a une forte influence sur le comportement du
système à gérer.
Notion d’objet
Introduction
On construit des modèles de systèmes complexes parce que nous

ne pouvons pas comprendre un système dans sa totalité. Des
techniques de modélisation performantes sont nécessaires face à
l’augmentation de la complexité des systèmes. Il y a de
nombreux facteurs à la réussite d’un projet et avoir une
méthodologie rigoureuse est un facteur essentiel. Un langage de
modélisation doit comprendre :
Les éléments du modèle : des concepts de modélisation fon-
damentaux et une sémantique.
Une notation : une interprétation visuelle des éléments du
modèle .
Notion d’objet
Les objets en UML
La description d’un objet est une abstraction ayant des limites

claires et un sens précis dans le contexte du problème étudié.
Un objet possède une identité et peut être distingué des autres
Objet = Etat + Comportement + Identité
Notion d’objet
Objets et classes en informatique
Notion d’objet
Objets et classes en UML
Un objet : Se présente sous la forme d’un rectangle. Dans la

première cartouche se présente figure le nom de l’objet. Dans la
deuxième cartouche se trouve les attributs et leurs valeurs.
Un attribut : Est est constitué d’un couple (nom, valeurs). Les
valeurs prisent par les attributs et les associations qui les relient
déterminent l’état d’un objet a un moment donnée.
Le comportement : Se sont les compétences d’un
objet(Messages envoyées par un autre objet).
Notion d’objet
Les classes en UML
Une classe : Une classe définit les caractéristiques et le

comportement communs à un ensemble d’objets (les instances
de la classe).
Une classe est une abstraction et une encapsulation des
caractéristiques communes de cet ensemble d’objets. Une classe
précise :
Les propriétés (attributs) des instances.
Le comportement (méthodes) des instances.
Notion d’objet
Une instance en UML
Une instance est la concrétisation d’une classe .
Notion d’objet
Les messages en UML
La communication entre objets s’effectue au moyen de messages.
Notion d’objet
Notion de synchronisation
présentation des cas d’utilisation
Un diagramme de cas d’utilisation capture le comportement

d’un système, d’un sous-système, d’une classe ou d’un
composant tel qu’un utilisateur extérieur le voit. Il scinde la
fonctionnalité du système en unités cohérentes, les cas
d’utilisation, ayant un sens pour les acteurs. Les cas
d’utilisation permettent d’exprimer le besoin des utilisateurs
d’un système, ils sont donc une vision orientée utilisateur de ce
besoin au contraire d’une vision informatique.
Il ne faut pas négliger cette première étape pour produire un
logiciel conforme aux attentes des utilisateurs. Pour élaborer les
cas d’utilisation, il faut se fonder sur des entretiens avec les
utilisateurs.
présentation des cas d’utilisation
Les acteurs
Un acteur est un type stéréotypé représentant une abstraction

qui réside juste en dehors du système à modéliser.
Un acteur représente un rôle joué par une personne ou une
chose qui interagit avec le système. (la même personne physique
peut donc être représentée par plusieurs acteurs en fonction des
rôles qu’elle joue).
Les acteurs
Il existe 4 types d’acteurs :

les acteurs principaux : les personnes qui utilisent les fonc-
tions principales du système.
les acteurs secondaires : les personnes qui effectuent des
tâches administratives ou de maintenance , ou encore qui
réagissent aux taches initiés par las acteurs principaux.
le matériel externe : les dispositifs matériels incontournables
qui font partie du domaine de l’application et qui doivent
être utilisés.
les autres systèmes : les systèmes avec lesquels le système
doit interagir.
Le cas d’utilisation
Le cas d’utilisation (ou use case) correspond à un objectif du

système, motivé par un besoin d’un ou plusieurs acteurs.
L’ensemble des use cases décrit les objectifs (le but) du système.
La relation
Elle exprime l’interaction existant entre un acteur et un cas
d’utilisation.
Relation de multiplicité
Les acteurs et les cas d’utilisation sont reliés par des associations
qui peuvent être primaires ou secondaires.
L’association primaire est réservée à l’acteur primaire pour
lequel la fonctionnalité est produite et l’association secondaire
est utilisée pour le ou les acteurs secondaires utilisés par le
système pour réaliser la fonctionnalité.
L’utilisation des multiplicités est possible pour définir le nombre
(0..1, 1, 1..*, 0..*, n, n..m, *) d’utilisations possibles du cas d’uti-
lisation. Cette multiplicité ne donne aucune indication de simul-
tanéité.
La relation
Il existe 3 types de relations entre cas d’utilisation :

La relation de généralisation.
La relation d’extension.
La relation d’inclusion.
La relation de généralisation
Dans une relation de généralisation entre 2 cas d’utilisation, le

cas d’utilisation enfant est une spécialisation du cas d’utilisation
parent.
La relation de généralisation entre acteurs

Un acteur peut également participer à des relations de généralisation
avec d’autres acteurs. Les acteurs enfant seront alors capables
de communiquer avec les mêmes cas d’utilisation que les acteurs
parents .
Le stéréotype include l’inclusion

Elle indique que le cas d’utilisation source contient aussi le com-
portement décrit dans le cas d’utilisation destination. L’inclusion
a un caractère obligatoire, la source spécifiant à quel endroit le cas
d’utilisation cible doit être inclus. Cette relation permet ainsi de
décomposer des comportements et de définir des comportements
partageables entre plusieurs cas d’utilisation.
Pour réaliser l’objectif virement , on utilise obligatoirement

Bennani identification .
Mohamed Taj Faculté des sciences Dhar El Mahraz Fes 52/122
Le stéréotype extendou l’extension
Elle indique que le cas d’utilisation source ajoute son comporte-

ment au cas d’utilisation destination. L’extension peut être sou-
mise à condition. Le comportement ajouté est inséré au niveau
d’un point d’extension défini dans le cas d’utilisation destination.
Cette relation permet de modéliser les variantes de comporte-
ment d’un cas d’utilisation (selon les interactions des acteurs et
l’environnement du système).
Le stéréotype extendou l’extension
Dans cet exemple le Virement peut parfois utiliser la vérification

du solde. Cependant, c’est pas une obligation.
Exemple d’application
Dans un établissement scolaire, on désire gérer la réservation des

salles de cours ainsi que du matériel pédagogique (ordinateur
portable ou/et Vidéo projecteur). Seuls les enseignants sont ha-
bilités à effectuer des réservations (sous réserve de disponibilité
de la salle ou du matériel). Le planning des salles peut quant à
lui être consulté par tout le monde (enseignants et étudiants).
Par contre, le récapitulatif horaire par enseignant (calculé à par-
tir du planning des salles) ne peut être consulté que par les en-
seignants. Enfin, il existe pour chaque formation un enseignant
responsable qui seul peut éditer le récapitulatif horaire pour l’en-
semble de la formation.
Modéliser cette situation par un diagramme de cas d’utilisation.
Correction de l’exemple d’application
Introduction
Le diagramme de classes est un schéma utilisé en génie logiciel

pour présenter les classes et les interfaces des systèmes ainsi que
les différentes relations entre celles-ci. Ce diagramme fait partie
de la partie statique d’UML car il fait abstraction des aspects
temporels et dynamiques.
Une classe décrit les responsabilités, le comportement et le type
d’un ensemble d’objets. Les éléments de cet ensemble sont les
instances de la classe.
Une classe est un ensemble de fonctions et de données (attributs)
qui sont liées ensemble par un champ sémantique. Les classes sont
utilisées dans la programmation orientée objet. Elles permettent
de modéliser un programme et ainsi de découper une tâche com-
plexe en plusieurs petits travaux simples.
Introduction
Le diagramme de classes comporte 6 concepts :

Classe.
Attribut.
Identifiant.
Relation.
Opération.
Généralisation / spécialisation.
Exemple d’un diagramme de classe
Présentation d’une classe
Présentation d’une classe
Les attributs : Les attributs définissent des informations qu’une

classe ou un objet doivent connaı̂tre. Ils représentent les données
encapsulées dans les objets de cette classe. Chacune de ces infor-
mations est définie par un nom, un type de données, une visibilité
et peut être initialisée. Le nom de l’attribut doit être unique dans
la classe.
Les méthodes : Une méthode est le coté dynamique des classes.

Ils présentent des actions a exécuter.
Identifiant des attributs
Il ne doit pas comporter d’espaces, de signes de ponctuation

ou d’accents. Pour remplacer les espaces, plusieurs conventions
existent : on peut intercaler un symbole entre les mots ou uti-
liser la méthode CamelCase qui consiste à mettre la première
lettre de chaque mot en capitale (par exemple, nom de l’objet
peut devenir : nom objet ou NomObjet).
Portée des attributs et des méthodes
La notion de visibilité indique qui peut avoir accès à l’attribut.

Elle ne peut prendre que 4 valeurs possibles :
La notion de relation
S’il existe des liens entre objets, cela se traduit nécessairement

par des relations qui existent entre leurs classes respectives. Les
liens entre les objets doivent être considérés comme des
instances de relations entre classes. Il existe plusieurs types de
relations entre classes :
L’association.
La généralisation/spécialisation.
La dépendance.
La multiplicité indique le nombre de valeur que l’attribut peut

contenir (l’attribut est souvent un tableau de valeurs, statique
ou dynamique). La multiplicité se note entre crochets après le
type de valeur que contient l’attribut. Voici la signification des
cardinalitées suivantes :
0..1 Zéro ou une fois.

1..1 (ou 1) Une et une seule fois.
0..* (ou *) De zéro à plusieurs fois.
1..* De une à plusieurs fois.
m..n Entre m et n fois.
n..n (ou n) n fois.
N ou * N Entier naturel.
La multiplicité ou cardinalité
La multiplicité peut également s’exprimer par des symboles :
La multiplicité ou cardinalité
Quand il y’a une relation entre deux ou plusieurs objets, On peut

utiliser les cardinalités pour exprimer la fréquence d’utilisation
entre les objets concernés.
Dans cet exemple une voiture a un seule conducteur et un conduc-

teur peut conduire plusieurs voitures.
L’association
L’association est la relation la plus courante et la plus riche du

point de vue sémantique. Une association est une relation sta-
tique n-aire (le plus souvent : elle est binaire) : c’est-àdire qu’elle
relie plusieurs classes entre elles.
L’association existe entre les classes et non entre les instances :
elle est introduite pour montrer une structure et non pour mon-
trer des échanges de données. Il existe plusieurs types d’associa-
tions :
Réflexive.
Association Binaire.
Association N-aire.
L’association
La navigabilité dans l’association
La navigabilité n’a rien à voir avec le sens de lecture de l’associa-

tion. Une navigabilité placée sur une terminaison cible indique si
ce rôle est accessible à partir de la source.
Par défaut les associations sont navigables dans les 2 sens. Dans
certains cas, une seule direction de navigation est utile : l’extrémité
d’association vers laquelle la navigation est possible porte alors
une flèche.
La navigabilité dans l’association
Dans l’exemple ci-dessus, les instances de A voient les instances

de B mais les instances de B ne voient pas les instances de A.
Les classes-association
Les attributs d’une classe dépendent fonctionnellement de l’iden-

tifiant de la classe. Parfois, un attribut dépend fonctionnellement
de 2 identifiants, appartenant à 2 classes différentes. Par exemple,
l’attribut quantité commandée dépend fonctionnellement du
numéro de commande et du code produit. On va donc placer l’at-
tribut quantité commandée dans l’association comporter
.
Dans ce cas, l’association est dite porteuse d’attributs .

Une association porteuse d’attributs est appelée classe-association.
Toute classe-association peut être remplacée par une classe in-

termédiaire et qui sert de pivot pour une paire d’association.
De même, toute association (qui ne contient pas d’attributs) im-

pliquant 3 classes ou plus peut donner lieu à une décomposition
avec une classe intermédiaire.
Association n-aire
Une association qui lie plus de 2 classes entre elles, est une asso-
ciation n-aire. L’association n-aire se représente par un losange
d’où part un trait allant à chaque classe. L’association n-aire est
imprécise, difficile à interpréter et souvent source d’erreur, elle
est donc très peu utilisée. La plupart du temps nous nous en ser-
vons que pour esquisser la modélisation au début du projet, puis
elle est vite remplacée par un ensemble d’associations binaires
afin de lever toute ambiguı̈té.
Association n-aire
Association n-aire
Association réflexive
Imaginons que nous voulions ajouter une association Supérieur

de dans le diagramme suivant pour préciser qu’une personne
est le supérieur d’une autre personne. On ne peut simplement
ajouter une association réflexive sur la classe Personne. En effet,
une personne n’est pas le supérieur d’une autre dans l’absolu.
Une personne est, en tant qu’employé d’une entreprise donnée, le
supérieur d’une autre personne dans le cadre de son emploi pour
une entreprise donnée (généralement, mais pas nécessairement,
la même). Il s’agit donc d’une association réflexive, non pas sur
la classe Personne, mais sur la classe-association Emploie.
Association réflexive
L’agrégation
Dans UML, l’agrégation n’est pas un type de relation mais une

variante de l’association. Une agrégation représente une associa-
tion non symétrique dans laquelle une des extrémités joue un
rôle prédominant par rapport à l’autre extrémité. L’agrégation ne
peut concerner qu’un seul rôle d’une association. L’agrégation se
représente toujours avec un petit losange du côté de l’agrégat.Le
choix d’une association de type agrégation traduit la volonté de
renforcer la dépendance entre classes. C’est donc un type d’as-
sociation qui exprime un couplage plus fort entre les classes.
L’agrégation permet de modéliser des relations de type maı̂tre et
esclaves. L’agrégation permet de modéliser une contrainte d’intégrité
et de désigner l’agrégat comme contrainte.
L’agrégation
L’exemple ci-dessus montre que l’on veut gérer une classification

de véhicules. Chaque véhicule est classifié selon son type. En
conséquence, il sera possible de prendre connaissance pour un
véhicule de l’ensemble des caractéristiques du type de véhicule
auquel il est associé.
L’agrégation
un agrégat peut être multiple. Dans l’exemple ci-dessous, un
véhicule peut appartenir à plusieurs types.
On peut avoir des cas d’agrégation réflexive dès que l’on modélise
des relations hiérarchiques ou des liens de parenté par exemple.
La composition
La composition est un cas particulier de l’agrégation dans laquelle

la vie des composants est liée à celle des agrégats. Elle fait sou-
vent référence à une contenance physique. Dans la composition
l’agrégat ne peut être multiple.
La composition implique, en plus de l’agrégation, une coı̈ncidence
des durées de vie des composants : la destruction de l’agrégat (ou
conteneur) implique automatiquement la destruction de tous les
composants liés.
La composition
La généralisation / spécialisation
Le principe de généralisation / spécialisation permet d’identifier

parmi les objets d’une classe (générique) des sous-ensembles d’ob-
jets (des classes spécialisées) ayant des définitions spécifiques. La
classe plus spécifique (appelée aussi classe fille, classe dérivée,
classe spécialisée, classe descendante . . . ) est cohérente avec la
classe plus générale (appelée aussi classe mère, classe générale
. . . ), c’est-à-dire qu’elle contient par héritage tous les attributs,
les membres, les relations de la classe générale, et peut contenir
d’autres.
La généralisation / spécialisation
Les relations de généralisation peuvent être découvertes de 2

manières :
La généralisation : il s’agit de prendre des classes existantes
déjà mises en évidences) et de créer de nouvelles classes
qui regroupent leurs parties communes ; il faut aller du plus
spécifique au plus général.
La spécialisation : il s’agit de sélectionner des classes exis-
tantes (déjà identifiées) et d’en dériver des nouvelles classes
plus spécialisées, en spécifiant simplement les différences.
Ces 2 démarches, même si elles sont fondamentalement différentes,
mènent au même résultat, à savoir la constitution d’une hiérarchie
de classes reliées par des relations de généralisation.
La généralisation
La relation de généralisation est très puissante car elle permet

de construire simplement de nouvelles classes à partir de classes
existantes. Cependant, elle est très contraignante dans le sens
où elle définit une relation très forte entre les classes. Ainsi,
l’évolution d’une classe de base entraı̂ne une évolution de toutes
les classes qui en dérivent. Cet effet boule de neige peut avoir des
conséquences aussi bien positives (quand c’est l’effet recherché)
que négatives.
La généralisation
La spécialisation multiple
Les classes peuvent avoir plusieurs superclasses ; dans ce cas, la

généralisation est dite multiple et plusieurs flèches partent de la
sous-classe vers les différentes superclasses. La généralisation
multiple consiste à fusionner plusieurs classes en une seule
classe.
La spécialisation multiple
La classe client spécial est une spécialisation de client et de

salarié. Ce modèle permet d’indiquer que l’on accorde des tarifs
préférentiels aux salariés.
L’interface
Une interface définit le comportement visible d’une classe. Ce

comportement est défini par une liste d’opérations ayant une vi-
sibilité public . Aucun attribut ou association n’est défini
pour une interface. Une interface est en fait une classe parti-
culière (avec le stéréotype interface ). UML représente
les interfaces :
Soit au moyen de petits cercles reliés par un trait à l’élément

qui fournit les services décrits par l’interface.
Soit au moyen de classes avec le mot clé interface .
Cette notation permet de faire figurer dans le compartiment
des opérations la liste des services de l’interface.
Relations sur une interface
La fourniture
Cette relation spécifie qu’une classe donnée fournit l’interface à

ses clients : c’est-à-dire que la classe possède cette interface. Une
classe peut fournir plusieurs interfaces à ses clients et chaque in-
terface définit un des services de la classe. Cette technique permet
de réduire la visibilité d’une classe. En effet, une classe qui expose
ses opérations publiques les expose à toutes les autres classes du
modèle. Le concept d’interface permet à une classe de définir plu-
sieurs profils en permettant à chaque classe de n’utiliser que le
profil qui l’intéresse. Une classe peut ainsi être vue avec plusieurs
perspectives différentes en fonction de la classe qui l’utilise, ce
qui augmente la réutilisabilité.
L’utilisation
Cette relation concerne toute classe client qui souhaite accéder

à la classe interface de manière à accéder à ses opérations. C’est
une relation d’utilisation standard.
La réalisation
Cette relation n’est utilisée que pour les interfaces. Une réalisation
est une relation entre une classe et une interface. Elle montre que
la classe réalise les opérations offertes par l’interface.
Introduction
Le diagramme de séquence fait parties des diagrammes

comportementaux (dynamique) et plus précisément des
diagrammes d’interactions.
Il permet de représenter des échanges entre les différents
objets et acteurs du système en fonction du temps.
A moins que le système à modéliser soit extrêmement simple,
nous ne pouvons pas modéliser la dynamique globale du
système dans un seul diagramme. Nous ferons donc appel à
un ensemble de diagrammes de séquences chacun correspon-
dant à une sous fonction du système, généralement d’ailleurs
pour illustrer un cas d’utilisation.
Exemple de diagramme de séquence
Les catégories de messages
Les principales catégories de messages sont :
- Message synchrone : L’émetteur est bloqué pendant le traite-

ment du message par le récepteur (Il attend un message de re-
tour). L’appel de méthodes (Si un objet A invoque une méhode
d’un objet B, A reste bloqué tant que B n’est pas terminé).
- Message asynchrone : Non bloquant(Le message envoyé peut

être pris par le récepteur à tout moment ou ignoré).
- Message de retour : On peut associer aux mesages d’appel de

méthodes un message de retour(pointillé) marquent la reprise du
contrôle par l’objet émetteur du message synchrone.
Correspondances messages/opérations
Les messages synchrones correspondent à des opérations dans

le diagramme de classes.
Envoyer un message et attendre la réponse pour poursuivre
son activité revient à invoquer une méthode et attendre le
retour pour poursuivre ses traitements.
Les messages de retour

Le récepteur d’un message synchrone rend la main à l’émetteur
du message en lui envoyant un message de retour.
Les messages de retour sont optionnels : la fin de la période
d’activité marque également la fin de l’exécution d’une méthode.
Ils sont utilisés pour spécifier le résultat de la méthode in-
voquée.
Message de création/Destruction
Un message peut entraı̂ner la création ou la destruction
d’objets.
La création d’un objet est matérialisée par une flèche qui
pointe sur le sommet d’une ligne de vie (On peut aussi
utiliser un message asynchrone ordinaire portant le nom
create).
La destruction d’un objet est matérialisée par une croix qui

marque la fin de la ligne de vie de l’objet.
Les messages trouvés et perdus
Message trouvé (Found message) :

Message dont on ignore la provenance.
Message en dehors du cadre décrit par le Diagramme de
Séquence.
perdu (Lost message) : Message envoyé, mais jamais reçu.
Message réflexif
Un objet peut s’envoyer des messages

Un appel à une autre méthode de l’objet.
Un appel récursif.
Durée et contraintes temporelles
C’est une représentation des délais de transmission.
Durée et contraintes temporelles
Exemple de diagramme de séquence
Fragments d’interactions combinés

Un fragment d’interactions est une partie du diagramme de séquence
(délimitée par un rectangle) associée à une étiquette (dans le
coin supérieur gauche). L’étiquette contient un opérateur d’in-
teraction qui permet de décrire des modalités d’exécution des
messages à l’intérieur du cadre.
Fragments d’interactions combinés
Les opérandes d’un opérateur d’interaction sont séparés par une

ligne pointillée. Les conditions de choix des opérandes (éventuels)
sont données par des expressions booléennes entre crochets ([ ]).
Les principales modalités sont les boucles, les branchements condi-
tionnels, les alternatives, les envois simultanés, etc.
Fragments d’interactions combinés : opt
L’opérateur option (opt) comporte un opérande et une condition

de garde associée. Le sousfragment s’exécute si la condition de
garde est vraie et ne s’exécute pas dans le cas contraire.
Fragments d’interactions combinés : opt
Fragments d’interactions combinés : alt
L’opérateur alternatives (alt) est un opérateur conditionnel possédant

plusieurs opérandes séparés par des pointillés. C’est l’équivalent
d’une exécution à choix multiples. Chaque opérande détient une
condition de garde. Seul le sous-fragment dont la condition est
vraie est exécuté. La condition else est exécutée que si aucune
autre condition n’est valide.
Fragments d’interactions combinés : loop

L’opérateur de boucle (loop) exécute une itérative dont la
séquence qu’elle contient est exécutée tant que la garde qui lui
est associée est vraie.
- La garde s’écrit de la façon suivante :
loop [min, max, condition] : Chaque paramètre (min, max et
condition) est optionnel.
Le contenu du cadre est exécuté min fois, puis continue à s’exécuter
tant que la condition et que le nombre d’exécution de la boucle
ne dépasse pas max fois.
- Exemple de gardes :

loop[3] La séquence s’exécute 3 fois.
Loop[1, 3, code=faux] La séquence s’exécute 1 fois puis un maxi-
mum de 2 autres fois si code=faux.
Fragments d’interactions combinés : par
Un fragment d’interaction avec l’opérateur de traitements pa-

rallèles (par) contient au moins deux sous fragments (opérandes)
séparés par des pointillés qui s’exécutent simultanément (traite-
ments concurrents).
Fragments d’interactions combinés : par
Fragments d’interactions combinés : ref
Réutiliser une interaction consiste à placer un fragment portant

la référence ” ref ” là où l’interaction est utile.
On spécifie le nom de l’interaction dans le fragment.
Autres Fragments d’interactions combinés

Il existe en réalité 13 au total, ci-dessous la liste des 8 autres :
ignore et considere : pour les fragments facultatifs ou obli-
gatoires.
critical : pour les fragments qui doivent se dérouler sans être
interrompus.
break : pour les fragments représentants des scenarii excep-
tionnels ou de ruptures (ex appui sur la touche Esc ). Le
scénario de rupture est exécuté si une condition de garde est
satisfaite.
assert : Pour les fragments dont on connaı̂t à l’avance les pa-
ramètres du message (exemple : après la saisie des 4 chiffres
d’un code, la saisie suivante sera obligatoirement la touche
Entrée ).
Autres Fragments d’interactions combinés
seq : indique que le fragment est composé de plusieurs sous

fragments qui peuvent s’exécuter dans n’importe quel ordre
(mais pas en même temps).
strict : pour les fragments dont les messages doivent se dérouler
dans un ordre bien précis.
neg : pour indiquer que la séquence à l’intérieur du fragment
n’est pas valide.

Cours de UML

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours de UML

Transféré par

Droits d'auteur :

Formats disponibles

Méthode de conception Orientée Objet UML

Méthode de conception Orientée Objet

Bennani Mohamed Taj

Faculté des sciences Dhar El Mahraz Fes 1/122

L’appréhension d’une problématique complexe telle que

Depuis longtemps, le langage UML (Unified Modelling Lan-

Depuis plus de 30 ans, la conception des bases de données

Présentation du génie logiciel

Définition d’un logiciel

Objectifs du génie logiciel

Les phases de réalisation d’un logiciel

La réalisation d’un logiciel se résume en 6 phases :

Pour créer un nouveau logiciel, On effectue l’étude de faisabilité

Le Cahier des charges est une phase importante qui permet de :

Une fois la conception terminée et validée, la réalisation du

La spécification consiste à décrire toutes les spécifications :

La validation sert à vérifier chaque module.

Il faut garder la trace de ce qui a été fait.

La phase de mise en place

Maintenant que le logiciel est réalisé (l’exécutable obtenu),

Une fois le logiciel est en place, son exploitation devient fon-

Une fois les erreurs détectées, il faut passer à la correction

Malgré toutes les maintenances réalisées, le logiciel ne peut

UML (Unified Modeling Language) est normalisé par l’OMG

Un modèle est une représentation partielle de la réalité.

L’utilité des modèles

Faciliter la compréhension d’un système :

Afin d’assurer un bon niveau de cohérence et d’homogénéité

Les différents types de diagrammes

UML, dans sa version 2, propose 13 diagrammes qui peuvent

Les diagrammes Structurels.

Diagrammes selon les axes de modélisation

Hiérarchie des diagrammes UML

Les 5 vues de Kruchten

Les diagrammes structurelles

Ces diagrammes, au nombre de six, ont vocation à représenter

Les diagrammes structurelles

Diagramme de déploiement (modifié dans UML 2) : décrit

Les diagrammes comportementaux

Ces diagrammes représentent la partie dynamique d’un système

Les diagrammes comportementaux

Diagramme d’activités (modifié dans UML 2) : donne une vi-

On construit des modèles de systèmes complexes parce que nous

Les objets en UML

La description d’un objet est une abstraction ayant des limites

Objets et classes en informatique

Objets et classes en UML

Un objet : Se présente sous la forme d’un rectangle. Dans la

Les classes en UML

Une classe : Une classe définit les caractéristiques et le

Une instance en UML

Une instance est la concrétisation d’une classe .

Les messages en UML

La communication entre objets s’effectue au moyen de messages.

présentation des cas d’utilisation

Un diagramme de cas d’utilisation capture le comportement

présentation des cas d’utilisation

Un acteur est un type stéréotypé représentant une abstraction

Il existe 4 types d’acteurs :

Le cas d’utilisation (ou use case) correspond à un objectif du

Il existe 3 types de relations entre cas d’utilisation :

Dans une relation de généralisation entre 2 cas d’utilisation, le

La relation de généralisation entre acteurs

Le stéréotype include l’inclusion

Pour réaliser l’objectif virement , on utilise obligatoirement

Dans ce cas, l’association est dite porteuse d’attributs .

La classe client spécial est une spécialisation de client et de