A.U.

: 2022-2023

Unified Modeling Language

*** UML2 ***

Chapitre 1

Introduction

R. Beltaifa SEIOT2/GLSI2
 Sommaire

• Introduction

• Historique

• La Modélisation

• Les Diagrammes UML

2
Introduction

3
 Introduction
Notion de système d’information (SI)

Définition :
un ensemble organisé de ressources (personnel, données, matériel, logiciel, …)
permettant d’acquérir, de stocker, de structurer et de communiquer des
informations sous forme de texte, images sons ou des données codées dans des
organisations)

D'autres composants peuvent être inclus dans un système d'information :

Applications métiers,
Bases de données de l’entreprise,
Dispositifs de sécurité,
infrastructure réseau,
postes de travail informatique,
serveurs d’application,
serveurs de données, …

4
 Introduction
Génie logiciel
Processus de développement de logiciel

Etapes principales du cycle de vie de logiciel (CVL):

 Analyse et spécification des besoins

 Conception architecturale et détaillée
 Programmation
 Intégration
 Maintenance

Validation et vérification 5
 Introduction
Génie logiciel
Processus de développement de logiciel

 Modèles de CVL: Cascade, Spirale, V, W, …

 Processus unifié

 Méthodes classiques Vs Méthodes agiles : processus

scrum, MERISE, …

6
 Les diagrammes UML
Cahier des charges :

 Contrat entre le client et le développeur

 Contient principalement :

 Besoins (Exigences) fonctionnels:

 à quoi sert le système

 ce que doit faire le système, les fonctions utiles

 Besoins (Exigences) non fonctionnels :

 performance, sûreté, confidentialité, portabilité, etc.

 chercher des critères mesurables 7
 Introduction
Les approches de développement (modélisation, programmation)

•Approches cartésiennes (première génération)

•Approches systémiques (deuxième génération)

•Approches objet (troisième génération)

8
 Introduction
Les approches de modélisation
Approches cartésiennes (première génération)

• Approche cartésienne : décomposition d'un problème en sous-

problèmes

• Méthodes d'analyse fonctionnelles

– décomposition d'une fonction en sous-fonctions jusqu'à
atteindre un niveau facile à coder

• Méthodes: méthodes de programmation structurée, SADT, …

9
 Introduction
Les approches de modélisation
Approches cartésiennes (première génération)

• Points forts:
– simplicité
– adéquation à capturer les besoins des utilisateurs
– capacité à produire des solutions à plusieurs niveaux d'abstraction

• Points faibles:
– effort sur les fonctions au détriment des données
– règles de décomposition non explicites
– Réutilisation difficile

10
 Introduction
Les approches de modélisation
Approches systémiques (deuxième génération)

•SI = structure + comportement

•Modélisation des données et des traitements

•Méthodes: Merise, …

11
 Introduction
Les approches de modélisation
Approches systémiques (deuxième génération)

• Points forts:
– grande cohérence des données
– niveaux d'abstraction bien définis :
• niveau externe, niveau conceptuel, niveau interne

• Points faibles:
– manque de cohérence entre données et traitements
– faiblesse de la modélisation des traitements, mélange des contraintes
et des contrôles

12
 Introduction
Les approches de modélisation
Approches objet (troisième génération)

•Évolution de l'approche systémique vers une plus grande cohérence

entre les objets et leurs comportements

•Vision du SI comme un ensemble d'objets avec leurs opérations

•Méthodes: OMT, OOD, OOSE, …

13
 Introduction
Les approches de modélisation
Approches objet (troisième génération)

• Points forts:
– capacité à modéliser des objets complexes
– réduire les distorsions entre système informatique et monde réel
– intégration des traitements aux données
– Encapsulation

• Points faibles
– aspect fonctionnel mal représenté
– aspect procédural des opérations

14
 Introduction
Concepts et notions de base de l’approche orientée objet

•Objet & classe

•Abstraction

•Encapsulation

•Héritage

•Polymorphisme

15
 Introduction
Concepts et notions de base de l’approche orientée objet

Les objets sont une représentation de l’univers du discours du domaine

d’application.

Ils sont identifiables et entretiennent des relations entre eux

Un objet est un concept, une abstraction ou une chose qui est

significative pour le domaine concerné

Objet = Identité + Comportement + État

16
 Introduction
Concepts et notions de base de l’approche orientée objet

L’État regroupe les valeurs des différents attributs

qui caractérisent un objet
• peut évoluer ou être constant

Comportement regroupe toutes les compétences

d’un objet et décrit les actions et les réactions de cet
objet
• Ce comportement est appelé opération (méthode)

17
 Introduction
Concepts et notions de base de l’approche orientée objet

Une classe est la description d’une collection d’objets

ayant la même structure, le même comportement,
les mêmes relations et la même sémantique

L’instanciation est la relation entre un objet et sa classe

18
 Introduction
Concepts et notions de base de l’approche orientée objet

Abstraction

Permet de s’attacher aux aspects essentiels sans entrer

dans les détails, autrement dit de se concentrer sur ce
que représente l’objet et sur son comportement avant
de décider de la façon de l’implémenter.

19
 Introduction
Concepts et notions de base de l’approche orientée objet

Encapsulation (masquage de l’information)

Sépare les aspects externes d’un objet, accessibles aux

autres objets, des détails d’implémentation internes, qui
leur sont cachés.

20
 Introduction
Concepts et notions de base de l’approche orientée objet

Généralisation

• C’est une relation entre une classe (la super-classe)

et une ou plusieurs variations de cette classe (les
sous-classes)

21
 Introduction
Concepts et notions de base de l’approche orientée objet

Héritage

• C’est le mécanisme qui, basé sur la généralisation,

permet aux sous-classes d'hériter, c'est à dire, d'avoir
les mêmes attributs, opérations et associations que
la super-classe

22
 Introduction
Concepts et notions de base de l’approche orientée objet

Polymorphisme

• Le polymorphisme décrit la caractéristique d’un

élément qui peut prendre plusieurs formes.

23
 Introduction
Concepts et notions de base de l’approche orientée objet

On distingue généralement trois types de polymorphisme :

– Le polymorphisme ad hoc (également surcharge ou en

anglais overloading)

– Le polymorphisme paramétrique (également généricité

ou en anglais template)

– Le polymorphisme d'héritage (également redéfinition,

spécialisation ou en anglais overriding)
24
Historique

25
 Historique
Les Principales Méthodes Objet
BOOCH
• Pionnier de l ’Orienté-Objet
– Article en 1981: ‘ Object Oriented Development ’
– Au début, méthode pour le développement
d’applications en Ada pour le ‘ Department of
Defense ’
– Etendue au C++
• Distingue 2 niveaux: Grady Booch
– Logique
• Diagrammes de classes
• Diagramme d’instances
• Diagramme états/transitions
– Physique
• Diagrammes de modules (principe des packages)
• Diagramme de processus

26
 Historique
Les Principales Méthodes Objet

OMT
• Object Modeling Technique
– Livre de James Rumbaugh (1991)

• 3 axes
– Statique : identifie les propriétés des objets et leurs
liaisons avec les autres objets James Rumbaugh
– Dynamique : définit le cycle de vie des objets :
comportement des objets, les différents états par
lesquels ils passent, et les événements déclanchant
ces changements d’états
– Fonctionnel : précise les fonctions réalisées par les
objets par l’intermédiaire des méthodes.

27
 Historique
Les Principales Méthodes Objet

OOSE

• Object Oriented Software Engineering

– Souvent appelée Objectory
• 5 modèles
– Besoins
– Analyse
Ivar Jacobson
– Conception
– Implantation
– Test
• 3 types d ’objets
– entités
– contrôles
– interfaces
• Notion de Cas d’Utilisation: Use Cases
28
 Historique
Les Principales Méthodes Objet

Méthodes Objets
• En 1994, plus de 50 méthodes OO
– Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-
Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,
COMMA, HOOD, Ooram, DOORS...
• Les notations graphiques sont toutes différentes
• L’industrie a besoin de standards

29
 Historique
Naissance d’UML

• 1993-1994: Booch’93, OMT-2

– Les 2 méthodes sont leaders sur le marché
– Elles sont de plus en plus proches
• Octobre 1994
– J. Rumbaugh (OMT) rejoint G. Booch
– Annonce de l’unification des deux méthodes
• Octobre 1995: Méthode Unifiée v0.8
• Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint
à son tour J. Rumbaugh et G. Booch
• Janvier 97 : Soumission à l’OMG de la version UML 1.0
– OMG: Object Management Group
• Organisme à but non lucratif fondé en 1989
• Plus de 700 entreprises y adhèrent
• Septembre 97 : UML 1.1
30
 Historique
La Convergence vers UML

Conclusion
• UML: Prendre le meilleur de chacune des méthodes
– OOSE (Jacobson): Use Cases
– OMT (Rumbaugh): Analyse
– Booch: Conception, Architecture

• UML est dans le domaine public

• Mars 2000 : Version UML 1.3

• …
• Depuis juin 2015 : Version UML 2.5

31
La Modélisation

32
 La Modélisation
Définition

UML ?

• Est une notation, pas une méthode

• Est un langage de modélisation objet
• Convient à tous les langages objets
– C++ (Héritage multiple, Template)
– Java (Interface)
– SmallTalk

33
 La Modélisation
A quoi sert la modélisation?

Un modèle permet de :

– mieux comprendre le système à développer,

– visualiser le système comme il est ou comme il devrait
l'être,
– valider le modèle vis à vis des clients,
– spécifier les structures de données et le comportement
du système,
– fournir un guide pour la construction du système,
– documenter le système et les décisions prises.

34
 La Modélisation
A quoi sert la modélisation?

Qu’apporte la modélisation objet?

• plus grande indépendance du modèle par rapport

aux fonctionnalités demandées

• des fonctionnalités peuvent être rajoutées ou

modifiées sans que le modèle objet change

• plus proche du monde réel

35
 La Modélisation
Objectifs d’UML

Pourquoi UML?

•Représenter des systèmes entiers,

•Créer un langage de modélisation utilisable à la fois par les

humains et les machines,

•Rechercher un langage commun qui est utilisable par toutes

les méthodes et adapté à toutes les phases du développement

36
 La Modélisation
UML ?

UML n’est pas une méthode

UML est un langage de modélisation objet
UML est adopté par toutes les méthodes objet
UML est une norme dans le domaine public

Utilisé Utilisé
•S.I des entreprises
•visualiser •Banques et les services financiers
•spécifier pour dans •Télécommunications
•construire •Transport
•documenter •Défense et aérospatiale
•Scientifique
•Applications distribuées par le WEB
37
 La Modélisation
Architecture 4+1

• Vue des cas d'utilisation (utilisateur): c'est la description du

modèle « vue » par les acteurs du système. Elle correspond aux
besoins attendus par chaque acteur (c'est le QUOI et le QUI).
38
 La Modélisation
Architecture 4+1

•Vue logique : c'est la définition du système vu de l'intérieur. Elle

explique comment satisfaire les besoins des acteurs (c'est le
COMMENT).

•Vue d'implémentation : cette vue définit les dépendances entre

les modules.

•Vue des processus (comportement) : c'est la vue temporelle et

technique, qui met en œuvre les notions de tâches concurrentes,
stimuli, contrôle, synchronisation, etc.

•Vue de déploiement : cette vue décrit la position géographique

et l'architecture physique de chaque élément du système (c'est le
OÙ).
39
 La Modélisation
Cycle de Développement

Axes de Modélisation avec UML

Statique
Diagramme de Classes
Diagramme d’Objets
Diagramme de Composants
Diagramme de Déploiement
Diagramme de paquetages
Diagramme de structure composite (UML 2.x)

Fonctionnel Dynamique
Diagramme de Séquence
Diagramme de Use Case Diagramme de communication (UML 2.x)
Diagramme global d’interaction (UML 2.x)
Diagramme de temps (UML 2.x)
Diagramme d'Etats-Transitions 40
Diagramme d'Activité
 La Modélisation
Modélisation fonctionnelle

• Diagramme des cas d'utilisation (use-cases) (Use Case

Diagram) : il permet d'identifier les possibilités d'interaction
entre le système et les acteurs (intervenants extérieurs au
système), c'est-à-dire toutes les fonctionnalités que doit fournir le
système.

41
 La Modélisation
Modélisation statique

•Diagramme de classes : il représente les classes intervenant dans

le système.

•Diagramme d'objets : il sert à représenter les instances de classes

(objets) utilisées dans le système.

•Diagramme de composants : il permet de montrer les composants

du système d'un point de vue physique, tels qu'ils sont mis en œuvre
(fichiers, bibliothèques, bases de données...)

•Diagramme de déploiement : il sert à représenter les éléments

matériels (ordinateurs, périphériques, réseaux, systèmes de
stockage...) et la manière dont les composants du système sont
répartis sur ces éléments matériels et interagissent entre eux.
42
 La Modélisation
Modélisation statique

•Diagramme des paquetages : un paquetage étant un conteneur

logique permettant de regrouper et d'organiser les éléments dans le
modèle UML, le Diagramme de paquetage sert à représenter les
dépendances entre paquetages, c’est-à-dire les dépendances entre
ensembles de définitions.

•Diagramme de structure composite (UML 2.x) : permet de

décrire sous forme de boîte blanche les relations entre composants
d'une classe.

43
 La Modélisation
Modélisation dynamique

•Diagramme de séquence : représentation séquentielle du

déroulement des traitements et des interactions entre les éléments du
système et/ou de ses acteurs.

•Diagramme de communication (UML 2.x) : représentation

simplifiée d'un diagramme de séquence se concentrant sur les
échanges de messages entre les objets.

•Diagramme global d'interaction (UML 2.x) : permet de décrire

les enchaînements possibles entre les scénarios préalablement
identifiés sous forme de diagrammes de séquences (variante du
diagramme d'activité).

44
 La Modélisation
Modélisation dynamique

• Diagramme de temps (UML 2.x) : permet de décrire les

variations d'une donnée au cours du temps.

•Diagramme états-transitions : permet de décrire sous forme de

machine à états finis le comportement du système ou de ses
composants.

• Diagramme d'activité : permet de décrire sous forme de flux ou

d'enchaînement d'activités le comportement du système ou de ses
composants.

45
 UML
Formalisme et différentes vues

Objets du Objets du Objets du

monde réel logiciel langage

De quoi parle-t-on? Comment (logique)? Comment (physique)?

Analyse Conception Code

46
 UML
Notation semi-formelle

 Spécification informelle :
- Le problème est décrit en langage naturel.
- La description conserve éventuellement quelques
imprécisions, ambiguïtés
- La spécification est souvent incomplète

 Spécification semi-formelle :
- basée sur des concepts (classe, entité, …)(UML, …)

 Spécifications formelles
- exprimée dans un langage dont le vocabulaire, la syntaxe et
la sémantique sont définis de manière formelle.

UML est un langage de modélisation semi-formel

47
 UML
Notations de précision

UML définit un petit nombre de mécanismes communs qui

assurent l’intégrité de la notation:

 Stéréotype : << nom_du_stéréotype>>

Exemple : << actor>>

 Notes :

 Contraintes : {la_contrainte} : exprimée avec OCL

 Relation de dépendance entre 2 éléments :

> 48