Notation UML

Sommaire
N
O • Historique
T
A
T
• La Modélisation
I
O
• Axe Statique
N
• Axe Dynamique
U
M • Références
L
Historique
 Les Principales Méthodes Objet

BOOCH
• Pionnier de l ’Orienté-Objet
– Article en 1981: ‘ Object Oriented Development ’
N – Au début, méthode pour le développement
O d ’applications en Ada pour le ‘ Department of
T Défense ’
A – Etendue au C++
T • Distingue 2 niveaux:
I
– Logique
O Grady Booch
• Diagrammes de classes
N
• Diagramme d’instance
U • Diagramme états/transitions
M – Physique
L • Diagrammes de modules (principe des packages)
• Diagramme de processus

Historique
 Les Principales Méthodes Objet

OMT
• Object Modeling Technique
– Livre de James Rumbaugh (1991)
N
O • 3 axes
T – Statique
A
– Dynamique
T
I – Fonctionnel
O James Rumbaugh
N

U
M
L

Historique
 Les Principales Méthodes Objet

OOSE
• Object Oriented Software Engineering
– Souvent appelée Objectory
N • 5 modèles
O – Besoins
T – Analyse
A
– Conception
T
I – Implantation
O – Test Ivar Jacobson
N • 3 types d ’objets (MVC en Design Paterns)
– entités
U
M – contrôles
L – interfaces
• Notion de Cas d’Utilisation: Use Cases

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-
N Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,
O COMMA, HOOD, Ooram, DOORS...
T • Les notations graphiques sont toutes différentes
A • L’industrie a besoin de standards
T
I
O
N

U
M
L

Historique
 La Convergence vers UML

Naissance d’UML
• 1993-1994: Booch’93, OMT-2
– Les 2 méthodes sont leaders sur le marché
N – Elles sont de plus en plus proches
O • Octobre 1994
T – J. Rumbaugh (OMT) rejoint G. Booch chez Rational
A
– Annonce de l’unification des deux méthodes
T
I • Octobre 1995: Méthode Unifiée v0.8
O • Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint à son tour
N Rational
U • Janvier 97 : Soumission à l’OMG de la version UML 1.0
M – OMG: Object Management Group
L • Organisme à but non lucratif fondé en 1989
• Plus de 700 entreprises y adhèrent
• Connu pour la norme CORBA
• Septembre 97 : UML 1.1

Historique
 La Convergence vers UML

Conclusion
• UML: Prendre le meilleur de chacune des
méthodes
N – OOSE (Jacobson): Use Cases
O – OMT (Rumbaugh): Analyse
T – Booch: Conception, Architecture
A • UML est dans le domaine public
T
I • Soutenu par le marché
O – Microsoft, HP, Oracle, IBM...
N

U
M
L

Historique
La Modélisation
 Définition

UML ?
• Est une notation, pas une méthode
• Est un langage de modélisation objet
N • Convient à tous les langages objets
O – C++ (Héritage multiple, Template)
T
– Java (Interface)
A
T – SmallTalk
I
O
N

U
M
L

La Modélisation
 Cycle de développement

Axe de Modélisation
Statique
Diagramme de Classes
N Diagramme d’Objets
O Diagramme de Composants
T Diagramme de Déploiement
A Diagramme de Use Case
T
I
O
N

U Fonctionnel Dynamique
M Diagramme de Use Case
L Diagramme d'Etats-Transitions
Diagramme d'Activité
Diagramme de Séquence

La Modélisation
 Cycle de développement

Les 4+1 Vues

• Classes
• Interfaces • Composant
• Collaboration • Fichiers Source
N => Les services du systèmes => Configuration du systme
O
T
A Vue logique Vue des composants
T
I
Besoins des utilisateurs => Comportement du système
O
N

U Vue des processus Vue de déploiement

M
• Thread • Architecture
L
• Process • Hardware
• Concurrence • Distribution
• Synchronisation => Topologie du système
=> Performance du système

La Modélisation
La modélisation des
besoins
 Diagramme de uses cases

- Acteur : entité externe qui agit sur le système (opérateur, composant interne…).

- Use case : ensemble d’actions réalisées par le système, en réponse à une action d’un
acteur. L’ensemble des uses cases décrit les objectifs (le but) du système.
N
O
T
A
T
I
O - Les relations de base entre cas d’utilisation et acteurs
N

U
« include » « include »

M
L « extends » « extends »

héritage
La représentation des
scénarios
 Diagramme de Séquence

Scénario
• Il y a autant de diagrammes de séquence qu’il y a de scénarios
• Un Scénario montre une séquence particulière d’interactions entre
N objets, dans un seul contexte d’exécution du système
O • Un scénario peut être vu comme une réponse à un besoin ou une partie
T d ’un besoin du diagramme des Uses Cases.
A
T • On y fait intervenir des objets, des messages et des événements
I
O Objets de type Classe Message synchrone
N

U objet1 : Classe objet2 : Classe

M
L

Message asynchrone
 Diagramme de Séquence

Notation Graphique Objet

Appelant: Ligne téléphonique: Appelé:

N
O décroche()
T
A tonalité
T numérotation()
I
O indication sonnerie
N indication sonnerie()
décroche
U
M
L
L ’axe statique
 Classes et Objets

Notation de base Classe

• Classe
– Une description d’un ensemble d’objets
N qui partage les mêmes attributs, opérations,
O méthodes, relations et contraintes
T
A
T
I
O • Objet
Objet de type Classe
N – Une entité avec une limite et une identité
bien définies qui encapsule de l'état et du
U comportement. L’état est représenté par
M des attributs et des relations, le
L comportement est représenté par des
opérations et des méthodes. Un objet est
une instance d’une classe.

L ’Axe Statique
 Classes et Objets

Attribut
• Attribut = propriété nommée d ’une classe
• Syntaxe
N – visibilité nom : type = valeur initiale
O • Visibilité
T
– + public
A
T – # protégé
I – - privé
O – package
N • Attribut de classe
U – la portée standard d’un attribut est limité à un objet
M – quand cette portée s’applique à la classe elle même, on parle d’attribut de
L classe (représenté par le symbole $ ou souligné)
• Attribut dérivé
– attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté
par le symbole /)

L ’Axe Statique
 Classes et Objets

Méthode
• Méthode = service que l ’on peut demander à un objet pour réaliser un
comportement
N • Syntaxe
O – visibilité nom (paramètres) : type retour
T • Mêmes notions que l’attribut
A
– visibilité
T
I – méthode de classe
O
N

U
M
L

L ’Axe Statique
 Classes et Objets

Notation Complète
Nom de la Classe
Initialisation
N Fenetre
O Visibilité + taille : Rectangle = 100,100
- visible : Boolean = true

}
T
A couleur : Color = blue Attributs
T #$ tailleMax : Rectangle
I Static #$ tailleMin : Rectangle
O /#$ tailleMoyenne : Rectangle
N

U
M
L
Dérivé + afficher() : Position
+ cacher()
# setTaille(taille : Rectangle)
} Méthodes

Retour
Paramètre

L ’Axe Statique
 Associations

Définition
• Association
– Exprime une connexion sémantique bi-directionnelle entre classes
N – Abstraction des liens qui existent entre objets
O – Le sens d ’une association peut-être précisé par une flêche
T • Association binaire = Association entre 2 classes. Cas particulier
A d ’association n-aire
T
I • Rôle = rôle joué par une classe dans une association
O • Multiplicité = indique le nombre d’instances d ’une classe qui peut être
N mise en relation avec une seul instance de la classe associée
– 1 : obligatoire
U
M – 0..1 : optionnel
L – 0..* ou * : quelconque
– 1..* : au moins 1
– 1..5, 10 : entre 1 et 5, ou 10

L ’Axe Statique
 Associations

Exemple

Rôle
N
O
T Personne Nom Entreprise
A -employé emploie -employeur
Nom Raison Sociale
T Activité
Prénom
I 1..* 0..1
O
N Sens

U
M
L Classe
Multiplicité

L ’Axe Statique
 Associations

Sémantique

N Mari 1 m arié avec 1 Epous e

O
T
A
T
I Hom m e 1 m arié avec 1 Fem m e
O m ari épous e
N

U
M Hom m e 0..* a été m arié avec 0..* Fem m e
L

L ’Axe Statique
 Associations

Note
• Note = Commentaire placé sur un diagramme

N
O Commentaire sur
T une association
A
T
I
O Personne Entreprise
N

U
M
L
Commentaire
sur une classe

L ’Axe Statique
 Associations

Classe d’Association
• Classe d’association = Elément ayant à la fois les propriétés d ’une
classe et d ’une association
N
O
Société
T Pers onne
nom
A nom travaille capital
age
T
0..* 0..* em baucher( )
I prendre retraite( dépos er bilan(
O
N Contrat de Travail
date Convention Collective
s alaire respecte - référence
U 1..1
1..*
M augm enter( ) + renégocier( )
rés ilier( )
L

Classe

L ’Axe Statique
 Associations

Association n-aire
• Association n-aire = Une association parmi 3 classes ou plus. Chaque
instance de l’association est un n-tuple de valeurs des classes respectives.
N
O
T Salle
A
lieu 1
T
I
O Cours
N Professeur 1 Elève
1..*

U
M
L

Heure de début
Heure de fin

L ’Axe Statique
 Agrégation et Composition

Définitions
• Agrégation = association particulière spécifiant une relation ‘tout -
partie’ entre l’agrégat et un composant
N – Inclusion
O – Propagation
T
A
T Livre Chapitre Mot
I 1..* 1..*
O
N
• Composition = forme forte d’agrégation avec un cycle de vie des
U parties lié à celui du composite
M
L

L ’Axe Statique
 Agrégation et Composition

Exemples
Voiture Multiplicité
Agrégation
N
O 1..1 1..1 4 2,3,4,5
T Moteur Chassis Roue Porte
A
T
I
O
N
Composition
U
M
L

L ’Axe Statique
 Généralisation, Spécialisation

Définitions
• Généralisation = relation ente un élément plus général et un élément
plus spécifique qui est entièrement conforme avec le premier élément, et
N qui ajoute de l ’information supplémentaire
O • Spécialisation = mécanisme par lequel des éléments plus spécifiques
T incorporent la structure et le comportement d’éléments plus généraux
A (notion d’héritage).
T
I
O Avion Discriminant
N Généralisation

U m otoris ation m otoris ation rayon d'action rayon d'action

M Planeur AvionAMoteur MoyenCourrier LongCourrier
L

A320
Spécialisation
Héritage multiple

L ’Axe Statique
 Généralisation, Spécialisation

Interface
• Notations
Stéréotype
<<Interface>>
N
O
T
A
T • Hériter d’une interface
I
O <<Interface>> <<Interface>>
Wind Listener Avion Missile_Listener
N

U
M
L
Implements
Planneur
AvionDeChasse
Extends

L ’Axe Statique
 Généralisation

Contraintes
• Les seules contraintes pré-définies en UML pour la généralisation sont :
– disjoint (un moyen courrier ne peut être long courrier) / overlapping
N – complete (liste éxhaustive de classe) / incomplete
O
T
A Avion
T
I
O
N
{incomplete} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - {disjoint}
U
M Planeur AvionAMoteur MoyenCourrier LongCourrier
L

L ’Axe Statique
 Généralisation

Classe Abstraite
• Classe Abstraite = classe que l ’on ne peut pas instancier

N • Notation :
O
T
A
T Avion Ou Avion
{abstract}
I
O
N

U Italic Contrainte
M
L

L ’Axe Statique
 Package

Pour Structurer
• Package = Regroupement d’éléments de modèle
• Les Packages divisent et organisent les modèles de la même manière que
N les répertoires organisent les systèmes de fichiers
O • Les Packages eux-mêmes peuvent être imbriqués à l ’intérieur d ’autres
T Packages
A
T
I Package Parent
O
N
Package Enfant 1 Package Enfant 2
U
M
L

L ’Axe Statique
 Diagramme de Classes

Notation

N
O
T
A
T
I
O
N

U
M
L

L ’Axe Statique
 Diagramme des composants

N
O
T
A
T Diagramme des composants
I
O
N

U
M
L

L ’Axe Statique
 Diagramme des composants

Permet de définir des composants logiciels en terme de

N
constitution et de dépendance.
O
T
A
T
I Classe1.h
O
N

U Classe1.cpp
M
L

L ’Axe Statique
 Diagramme de déploiement

.
N
O
T
A
T Diagramme de déploiement
I
O
N

U
M
L

L ’Axe Statique
 Diagramme de déploiement

Décrit les ressources matérielles et la répartition

. du logiciel dans ces ressources
N
O
T
A
T TX serveur
I
O
N TCP IP
Serveur SGBD
U RNIS
M
L PC

L ’Axe Statique
L ’Axe Dynamique
 Introduction

Que représente-t-on dans le modèle dynamique ?

• Le modèle dynamique représente les séquences d’événements, d’états
et de réactions qui doivent survenir dans le système.
N • Il est intimement lié au modèle objet et décrit les aspects de contrôle
O d’un système en prenant compte du temps, du séquencement des
T opérations et des interactions entre objets
A • Deux diagrammes fondamentaux :
T
I – Diagramme d ’activités
O – Diagramme Etats-Transitions
N

U
M
L

L ’Axe Dynamique
 Diagramme Etats-Transitions

Définition
• Un diagramme Etats-Transitions (ou Automate) :
– décrit l’évolution au cours du temps d’une instance d’une classe en réponse
N aux interactions avec d’autres objets
O – est forcément associé à une classe, mais toutes les classes n’en ont pas
T besoin
A – est un graphe orienté d’états (noeuds) connectés par des transitions (arc
T orientés)
I • Source: Les Statecharts de David Harel
O
N

U
M
L

David Harel

L ’Axe Dynamique
 Diagramme Etats-Transitions

Etats
• Chaque objet est à un moment donné dans un état particulier :
– Etat Initial : état d’une instance juste après sa création (un seul état initial)
N – Etat Intermédiaire : un objet est toujours dans un état donné pour un certain
O temps
T – Etat Final : état d’une instance juste avant sa destruction (un automate
A infini peut ne pas avoir d’état final)
T
I
O
N

état initial état intermédiaire état final

U
M
L

L ’Axe Dynamique
 Diagramme Etats-Transitions

Transition, Condition
• Transition : relation entre 2 états indiquant qu’un objet dans le premier
état va exécuter une action et entrer dans le deuxième état quand un
N événement apparaîtra
O • Condition : expression booléenne devant être vérifiée pour permettre la
T transition
A
T Etat initial Etat final
I
O
N
Condition
Evénement
U
M
L annivers s aire [age=18 ans ]
Mineur Majeur

Transition
L ’Axe Dynamique
 Diagramme Etats-Transitions

Action, Activité
• Action : opération atomique (non interruptible) déclenchée par une
transition
N • Activité : opération qui dure un certain temps (interruptible) dans un
O état particulier
T – entry : action exécutée chaque fois que l’on rentre dans l’état
A – exit : action exécutée chaque fois que l’on quitte l’état
T
I
O
N
Arret Appui bouton étage( N° )[ N°!=étage courant ] Marche
U
/dém arrer m oteur entry: tourner moteur
M
L

Action Activité

L ’Axe Dynamique
 Diagramme Etats-Transitions

Notation Complète
• Exemple : fonctionnement d’une montre digitale

N Evénement
O Appui bouton avance / avancer m inute
T Etat initial
A
T
Affichage heure Mofication m inute
I Appui bouton m ode entry: clignoter m inute
O
N
Appui bouton m ode
Appui bouton m ode
U
M
Appui bouton avance / avancer heure
Activité
L

Modification heure
entry: clignoter heure
Action

L ’Axe Dynamique
 Diagramme Etats-Transitions

Généralisation d’états
• Dans le cas d’un comportement dynamique complexe, les diagrammes
d’états sur un niveau deviennent rapidement illisibles
N • Pour éviter ce problème, il est nécessaire de structurer les diagrammes
O d’états en:
T – super-états : états généraux
A – sous-états : héritent des caractéristiques des états généraux
T
I
O E1
A B E1
N A B

E2 E2
U
M E2
C
L
= C

Même evt Super-état Sous-état

L ’Axe Dynamique
 Diagramme Etats-Transitions

Notation Complète
• Exemple : transmission d’une automobile

N R enclenché
O Point Mort (N) Marche arrière (R)

T N enclenché
A
T F enclenché
N enclenché
I
O
N Marche avant (F)

rapport s up rapport s up
U
Prem ière Seconde Trois ièm e
M
L rapport inf rapport inf

Super-état Sous-état
L ’Axe Dynamique
 Diagramme Etats-Transitions

Historique
• Par défaut, un automate n’a pas de mémoire
• La notation H offre un mécanisme pour mémoriser le dernier sous-état
N qui l’englobe
O • Exemple : cycle de lavage d’un lave vaisselle
T
A
T Rinçage Lavage Séchage
I
O
N
H

U Porte ouverte
M Porte ferm ée
L
Attente

Historique

L ’Axe Dynamique
 Diagramme d ’activités

N
O
T
A
T Diagramme d ’activités
I
O
N

U
M
L

L ’Axe Dynamique
 Diagramme d ’activités

* Utilisé pour étiqueter les autres diagrammes (traitements

associés aux messages des diagrammes de séquences,
N transitions des diagrammes d’états-transitions, activité d’un
O état…)
T
A * Sert à spécifier un traitement à priori séquentiel en offrant
T un pouvoir d’expression très proche des algorithmes.
I
O
N * Branche conditionnelle
U
M Activité1

L
[else]
[condition1]

Activité2 Activité3

L ’Axe Dynamique
 Diagramme d ’activités

* Barre de synchronisation

Refroidir
N
O
T Arrêter le chauffage Aérer
A
T
I
O * Couloir d ’activités
N
Couloir 1: Couloir 2:
U
M Act ivit é 1

L
Act ivit é 2

L ’Axe Dynamique
 Diagramme d ’activités

* Flux d ’objets

N
O
T
A
T
* Signal
I
O
N

U
M
L

L ’Axe Dynamique
 UML 2

N
O

Les apports d ’UML 2

T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences

- Fragment “ Alternatif ” (IF - THEN - ELSE)

N
O
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences

- Fragment “ break ” utilisé pour représenter des scénarios

N
O
d’exceptions.
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences

Fragment “ Parallel ” utilisé pour représenter

N
des interactions en parallèle.
O
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences

Fragment “ Loop ” utilisé pour décrire un ensemble

N d’interactions qui s’exécutent en boucle.
O
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences

Références: un pointeur ou un raccourci vers un

N autre diagramme de séquences existant.
O
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de séquences
Etat précise l’état dans lequel doit se trouver
N l’instance de classe concernée.
O
T
A
T
I
O
N

U
M
L
 UML 2

Diagramme de structure composite

spécifier la connectique interne et externe entre ces

N classes
O
T
A
T
I
O
N

U
M
L
Références
 Pour en Savoir Plus

Livres
• The Unified Modeling Language User Guide , G. Booch, J. Rumbaugh,
I. Jacobson, 1999, Addison Wesley
N • Object-Oriented Modeling and Design, J. Rumbaugh, 1991, Prentice-
O Hall
T • Object Solution, G. Booch, 1996, Addison-Wesley
A
T • Object-Oriented Software Engineering: A Use Case Driven Approach, I.
I Jacobson, 1992, Addison-Wesley
O • Modélisation Objet avec UML, P. A. Muller, 1997, Eyrolles
N • UML Distilled, M. Fowler, 1997, Addison-Wesley
U • UML La notation unifiée de modélisation objet, M. Lai, Masson
M • Designing Object Systems: Object-Oriented Modeling with Syntropy, S.
L Cook, J. Daniels, 1994, Prentice-Hall

Références
 Pour en Savoir Plus

Articles
• Getting started: using use case to capture requirements, J. Rumbaugh,
Sept 1994, JOOP
N • Formalizing use-case modeling, I. Jacobson, Juin 1995, JOOP
O • OMT: The object model, J. Rumbaugh, Jan 1995, JOOP
T
• A search values: Attributes and associations, J. Rumbaugh, Juin 1996,
A
T JOOP
I • A matter: How to define subclasses, J. Rumbaugh
O • The life of an object model: How the object model changes during
N development, J. Rumbaugh, Mars 1994, JOOP
U • Statecharts: a visual Formalism for Complex Systems, D. Harel, 1987,
M Science of Computer Programming vol 8
L • Executable Object Modeling with Statecharts, D. Harel, Juillet 1997,
Computer
• OMT: The dynamic model, J. Rumbaugh, Fev 1995, JOOP

Références