Le langage UML

Introduction

MP Nachouki
 Au sommaire

Introduction

Historique UML

Les concepts de base de l’approche objet

Principes de modélisation

Notation UML

Plan du cours

Règles de bonne pratique

Pour aller plus loin

2
Introduction
Qu’est ce que la Modélisation ?

La modélisation est :
√
une technique d’ingénierie permettant de représenter un
système ;
√
qui s’appuie sur l’établissement de modèles

3
Qu’est ce qu’un Modèle ?

Un Modèle est une description abstraite d’un système ou

d’un processus, une représentation simplifiée qui permet de
comprendre et de simuler. C’est une vue subjective mais
pertinente de la réalité

4
Qualités d’un modèle :

Les principales qualités d’un modèle sont les suivantes :

1. fidélité : représentation sans déformation de la réalité ;

2. cohérence : représentation sans contradiction ;
3. complétude : description de tous les phénomènes
pertinents par rapport aux objectifs de modélisation.

5
L’approche cartésienne

Démarche dite analytique ; résolution des problèmes un à un

1. années 1970
2. analyse des fonctions que doit remplir le système
3. approche hiérarchique (du général au particulier)
4. décomposer les problèmes en sous-problèmes
jusqu’à trouver un niveau où l’expérimentation ou
l’observation permettent de valider les hypothèses

6
Exemple : La méthode SADT (Structured Analysis
and Design Technic)

Principale limite : redondances sur les données

7
L’approche systémique

1. dans le courant des années quatre-vingt

2. approche systémique

Définition du système :
Un système peut être défini comme ensemble d’éléments :
√
en interaction dynamique
√
organisés et coordonnés
√
en vue d’atteindre un objectif, qui évolue dans un
environnement

8
l’approche systémique

L’entreprise est un système constitué de sous-systèmes

Trois principaux sous-systèmes :

1. le sous-système de décision (ou de pilotage)

2. le sous-système d’information
3. les sous-systèmes opérationnels

9
Exemple : La méthode Merise (Méthode d’Etude et
de Réalisation Informatique pour les Systèmes d’En-
treprises)

Principale limite : non-prise en compte des aspects dynamiques.

10
L’approche objet

1. années quatre-vingt-dix.
2. Modéliser un système d’un point de vue structurel,
fonctionnel et dynamique.
3. un langage commun qui permet de représenter des
concepts (vocabulaire) et des règles (grammaire).
4. Exemple : OMT, Booch, OOSE, Classe-Relation,Fusion,
HOOD, OOA, OOD, OOM, ...)

Principale limite de cette approche : son succès => une

cinquantaine de méthodes différentes ont été développées
selon les principes objet.

11
UML

Proposé par l’OMG (Object Management Group), cette

approche est devenue un standard international en 1997.
Le formalisme d’UML emprunte aux différentes approches
objets . Le méta-langage UML s’organise en diagrammes qui
permettent de visualiser un système sous différentes
perspectives (diagrammes de cas d’utilisation, de classes,
d’états-transitions, d’activités, etc.) et en vues (" vue
utilisateur ", " vue statique ", " vue dynamique ").
La démarche est globale, itérative et incrémentale ; elle est
essentiellement guidée par les besoins des utilisateurs.

12
Historique UML
Paternité d’UML

13
la genèse d’UML

1990 : émergence des méthodes orientées objet

1991 : première édition de Modélisation et conception orientées objet basée
sur OMT, Object Modeling Technique, issue de la R & D de General
Electric.
1994 : James Rumbaugh rejoint Rational et travaille avec Grady Booch
à la fusion des notations OMT et Booch.
1995 : Ivar Jacobson rejoint Rational et intègre OOSE au travail
d’unification.
1997 : l’OMG (Object Management Group) accepte UML, proposé par
Rational, comme standard de modélisation objet.
2001 : révision par l’OMG d’UML 1.
2004 : adoption d’UML 2.0

14
OMG
L’OMG (Object Management Group) est un orga-
nisme de normalisation international qui a pour mis-
sion la standardisation des technologies objets pour
une meilleure interopérabilité des solutions logicielles.

15
OMG I

L’OMG regroupe plus de 1000 membres, qui sont :

√
éditeurs de logiciels (comme SOFTEAM, Oracle,
Microsoft, ...),
√
constructeurs (SUN, IBM, ...),
√
ou utilisateurs (France Télécom, ...).

On doit à l ’OMG un certain nombre de standards objets dont

notamment :

16
OMG II

√
Corba : bus pour la constitution d’applications d’objets
distribués,
√
ODMG : persistance des objets sur bases de données
objets,
√
UML : Unified Modeling Language= ensemble de
notations graphiques (modèles) qui s’appuient sur une
syntaxe (méta modèle).

17
L’unification des méthodes

18
Principaux objectifs d’UML
√
Proposer un langage visuel de modélisation
• Utilisable par toutes les méthodes
• Adapté à toutes les phases du développement
• Compatible avec toutes les techniques de réalisation
√
Proposer des mécanismes d’extension et de spécialisation
pour pouvoir étendre les concepts de base
√
être indépendant des langages particuliers de
programmation
√
Proposer une base formelle pour comprendre le langage
de modélisation
√
Encourager l’application des outils Orientés Objet

19
UML : Principales influences

Booch catégories et sous-systèmes

Embley classes singletons et objets composites
Fusion description des opérations, numérotation des messages
Gamma frameworks, patterns et notes
Harel automates (statecharts)
Jacobson cas d’utilisation (use cases)
Meyer pré et post conditions
Odell classification dynamique, éclairage sur les événements
OMT Associations
Shlaer-Mellor cycle de vie des objets
Wirfs-Brock responsabilités
...

20
UML pour :

√
Montrer les limites d’un système et ses fonctions principales (pour les
utilisateurs) à l’aide des cas d’utilisation,
√
Illustrer les réalisations de cas d’utilisation à l’aide de diagrammes d’interaction
√
Modéliser la structure statique d’un système à l’aide de diagrammes de classes,
√
Modéliser la dynamique, le comportement des objets à l’aide de diagrammes
d’états
√
Décrire l’implantation physique de l’architecture avec des diagrammes de
composants et de déploiement
√
Pouvoir étendre les fonctionnalités du langage avec des stéréotypes
√
Permettre la génération automatique de code, et la rétro-ingénierie

21
Les concepts de base de
l’approche objet
Objet : 3 principes

1. principe de distinction
Un objet a une identité.
2. principe de permanence
Un objet a un état qui peut évoluer dans le temps sans
remettre en cause son identité.
3. principe d’activité Un objet peut accomplir ou subir des
traitements : il possède un comportement

22
Objet

Unité formée de l’union d’un état interne (des at-

tributs) et d’un comportement (des opérations) qui a
une origine dans le monde réel et a sa propre identité.
L’objet est l’abstraction, faite par l’analyste, du
phénomène réel observé.
Cette abstraction est ensuite modélisée en utilisant
les concepts appropriés.
Exemple :

23
Classe
Regroupe les objets qui se ressemblent (abstrac-
tion)
Identification des caractéristiques : (structure
et comportement) communes à un
ensemble d’éléments.
Description condensée de ces caractéristiques :
décrit le domaine de définition et les
propriétés des instances de cette classe
(notion de type dans les langages de
programmation classiques).
Chaque objet est une instance d’une classe.
Le mécanisme d’instanciation permet de générer
des objets (instance) d’une classe.
24
Classe

Exemple :

25
Relations entre les classes

association Connexion sémantique bidirectionnelle entre

classes. Abstraction des liens qui existent entre les
objets instances des classes associées.
agrégation Connexion bidirectionnelle dissymétrique

26
Modularité

Les objets forment des modules compacts et cohérents

regroupant des données et des opérations.
Un module est un élément de petite taille (un ou plusieurs
sous-programmes) , contribuant par assemblage à la
construction de logiciels. Il doit être cohérent et autonome.
La conception orientée objet facilite l’effort de localisation et
de correction des anomalies.

27
Encapsulation et interface
L’encapsulation consiste à masquer les détails d’implémentation d’un
objet en définissant une interface. L’interface est la vue externe d’un
objet. Elle définit les services accessibles (offerts) aux utilisateurs de
l’objet.
Exemple :

Intérêt :
√
Facilite l’évolution d’une application : on peut modifier l’implémentation des
attributs d’un objet sans modifier son interface.
√
Garantit l’intégrité des données car elle permet d’interdire l’accès direct aux
attributs des objets . 28
Héritage

L’héritage est un mécanisme de transmission des propriétés

d’une classe (ses attributs et ses méthodes) vers une
sous-classe.
√
Une classe peut être spécialisée en d’autres classes pour y
ajouter des caractéristiques spécifiques ou en adapter
certaines.
√
Plusieurs classes peuvent être généralisées en une classe
qui les factorise. Cela permet de regrouper les
caractéristiques communes d’un ensemble de classes.

29
Héritage

Exemple :

L’héritage est un mécanisme qui résulte du mécanisme de spécialisation : si une classe résulte de la spécialisation
de plusieurs classes générales, elle hérite de l’ensemble de ces dernières.
30
Héritage

L’héritage peut être simple ou multiple.

Exemple :

31
Polymorphisme

Type particulier d’héritage, le polymorphisme est la capacité

donnée à une opération de s’exécuter différemment selon le
contexte dans lequel elle se trouve.
Une opération définie dans la super-classe pourra ainsi
s’exécuter différemment selon la sous-classe où elle est héritée.
Exemple :

32
Principes de modélisation
Principes de base

UML est fondé sur un méta-modèle, qui définit

√
les éléments de modélisation (les concepts manipulés par
le langage et leur syntaxe),
√
la sémantique de ces éléments (leur définition et le sens
de leur utilisation).

Le méta-modèle UML est lui-même décrit par un

méta-méta-modèle (OMG-MOF :
http : //www .[Link]/uml).

33
UML est un langage graphique

√
Il permet principalement de :
• concevoir des logiciels informatiques ,
• communiquer sur des processus logiciels ou d’entreprise,
• présenter sous forme détaillée, l’analyse d’un système ou
les pré requis le concernant.,
• documenter un système, un processus ou une
organisation existant.
• proposer un langage abstrait compréhensible par
l’homme et interprétable par la machine
√
L’élément fondamental de modélisation UML est le
diagramme.

34
Modèles, vue et diagrammes UML

Modèle : abstraction d’un système composée d’un

ensemble d’éléments de modèle ce qui est
construit par et ce qui est perçu au travers des
diagrammes (par le concepteur, le lecteur)
conforme au méta-modèle UML
Vue : projection d’un modèle suivant une perspective
qui omet les éléments non pertinents pour cette
perspective. Elle s’exprime dans des diagrammes
ex. : vue statique, vue fonctionnelle
Diagramme : présentation graphique d’éléments de
visualisation représentant des éléments de modèle
(graphe) ex. : diagramme de classes, de séquences
35
Les diagrammes structurels I

diagramme de classes : décrit au travers de classes et

d’interfaces, les entités constituant le système
à modéliser et les relations statiques entre
celles-ci.
diagrammes de composants : décrivent l’organisation et
les dépendances entre les composants intervenant
dans l’implémentation du système.

36
Les diagrammes structurels II

diagrammes de structures composites : Nouveauté

UML2, permettent d’établir des liens entre les
diagrammes de classes et les diagrammes de
composants.
diagrammes de déploiement : décrivent comment les
composants du système sont configurés lors de
l’exécution du système.

37
Les diagrammes structurels III

diagrammes de paquetage : constituent une sous catégorie

des diagrammes de classes. Ils permettent de
montrer comment les classes et les interfaces sont
regroupées.
Diagrammes d’objets : Montrent les liens entre des
instances réelles de classes à un moment précis
de l’exécution du système.

38
Les diagrammes comportementaux I

diagrammes d’activité : permettent d’identifier les flux

entre deux activités successives
diagrammes de communication : constituent des sortes de
diagrammes d’interaction mais se focalisent sur
les composants impliqués dans un comportement
particulier ainsi que sur les messages échangés par
les composants.

39
Les diagrammes comportementaux II

diagrammes d’interaction d’ensemble : Versions simplifiés

des diagrammes d’activité, ils ont pour but de
mettre en évidence les éléments intervenant dans
la réalisation d’une activité.
diagrammes de séquence : Mettent en évidence le type et
l’ordre des messages échangés entre composants
d’un système tout au long de son exécution.
diagrammes de machines d’état : mettent en évidence les
transitions d’état interne à un élément.

40
Les diagrammes comportementaux III

diagrammes de chronométrage : décrivent des

spécifications temporelles pour des messages
diagrammes de cas d’utilisation : fournissent une vue
indépendante de l’implémentation des
fonctionnalités d’un système.

41
Les diagrammes en résumé

42
Les diagrammes en résumé

43
Les vues

44
Les vues

1. Vue du concepteur
2. Vue de déploiement
3. Vue d’implémentation
4. Vue de processus
5. Vue de cas d’utilisation

45
Vue du concepteur

Définit les classes, les interfaces et les structures permettant

de représenter les éléments à traiter.
Elle peut utiliser les diagrammes de classe, , d’objets, de
structures composites et de séquence pour cerner l’ensemble
de la conception du système.

46
Vue de déploiement

Permet de définir la façon dont un système sera configuré,

installé et exécuté.
Elle peut utiliser les diagrammes de composants, de
déploiement et d’interaction.

47
Vue d’implémentation

A pour but de définir les composants, les fichiers et les

ressources utilisés par un système
Elle peut utiliser les diagrammes de composants, et
éventuellement, d’interaction, d’état et de structures
composites.

48
Vue de processus

Formalise toute l’information relative à la cohérence, la

performance et l’ évolutivité du système.
Elle peut utiliser les diagrammes d’interaction et d’activité
pour décrire le comportement à l’exécution du système.

49
Vue de cas d’utilisation

Permet de définir les fonctionnalités requises par l’utilisateur

final.
Elle peut utiliser les diagrammes de cas d’utilisation mais aussi
des diagrammes d’interaction.

50
3 principaux modes d’utilisation

1. Mode esquisse :
pour présenter des solutions, communiquer des idées et
documenter les points essentiels d’un système
sélectivité et non exhaustivité
2. mode plan :
pour décrire de façon exhaustive le résultat de la
conception (spécification complète)
3. mode langage de programmation :
description fine et précise des spécifications (vision MDA
Model Driven Architecture : prise en charge par un
automate de la traduction dans un code informatique)

51
Les différentes utilisations d’UML

UML peut être utilisé pour définir de nombreux modèles :

Modèles descriptifs vs prescriptifs

1. Descriptifs ; Décrire l’existant (domaine, métier)

2. Prescriptifs ; Décrire le futur système à réaliser

Modèles destinés à différents acteurs

1. Pour l’utilisateur ; Décrire le quoi

2. Pour les concepteurs/développeurs ; Décrire le comment

Les modèles sont décrits par des diagrammes (des graphes) ;

Chaque diagramme donne un point de vue différent sur le
système
52
Notation UML
Note

Elément générique permettant d’intégrer une information au

sein du diagramme.
Le symbole d’une note est un rectangle écorné dans le coin
supérieur droit, éventuellement complété par une ligne en
pointillé permettant de lier le commentaire à un élément du
diagramme.

53
Classificateur et décoration I

L’élément de base en modélisation par UML est le

classificateur. Un classificateur, dans le contexte UML est un
groupe d’objets possédant des propriétés communes.
Un classificateur peut posséder différents types d’informations
complémentaires qui lui sont attachés via un mécanisme
d’UML appelé décoration.

54
Classificateur et décoration II

55
Stereotypes

Un stéréotype constitue un type particulier de décoration. Il

donne au lecteur une information sur ce que représente un
classificateur particulier.

56
Contraintes

Relation sémantique quelconque

√
concernant un ou plusieurs éléments du modèle
√
définissant des propositions devant être maintenues
à Vrai pour garantir la validité du système modélisé

Notation : contrainte contenu formel ou informel Certaines

contraintes sont prédéfinies ; d’autres créées par l’utilisateur (
langue naturelle, pseudo-code, OCL, ...)

57
Contraintes

58
Plan du cours
Plan du cours I

1. Diagrammes de cas d’utilisation

2. Diagrammes de classes
3. Diagrammes objets
4. Diagrammes de paquetage
5. Diagrammes d’interaction
6. Diagrammes d’état
7. Diagrammes d’activité
8. Diagrammes de composants
9. Diagrammes de déploiement
10. Mise en oeuvre des diagrammes

59
Règles de bonne pratique
Règles de bonne pratique

√
Avec UML, pratiquement tout est optionnel,
√
Les modèles UML sont rarement complets
√
UML a été pensé pour être ouvert à toute interprétation
√
UML est destiné à être étendu

60
Pour aller plus loin
Pour aller plus loin

G Booch
Conception orientée objet et applications
Addison-Wesley, 1992
P-A Muller
Modélisation objet avec UML
Eyrolles, 1997
I Jacobson, G Booch, J Rumbaugh
UML en action
Addison Wesley 1999
P. Roques , F Vallee,
UML en action
Eyrolles , 2004
D Pilon, N Pitman