Introduction à UML

Shebli Anvar – DSM/DAPNIA – CEA Saclay

François Terrier, Sébastien Gérard DRT/LIST – CEA/Saclay

F-91191 Gif sur Yvette Cedex France

Francois.Terrier@cea.fr ; Sebastien.Gerard@cea.fr ;
Shebli.Anvar@cea.fr
Définitions

UML = Unified Modeling Language

n Langage unifié pour la modélisation objet
n Langage de modélisation des applications construites à l’aide
d’objets, indépendant de la méthode utilisée
Différence Langage – Méthode
n Langage de modélisation = notations, grammaire, sémantique
n Méthode : comment utiliser le langage de modélisation
(recueil des besoins, analyse, conception, mise en œuvre,
validation…)
Objet = représentation du problème basée sur des
entités (concrètes ou abstraites) du monde réel

2
La complexité des logiciels

Le logiciel est complexe par nature à gérer

cette complexité
Les systèmes peuvent être décomposés selon
n ce qu’ils font (approche fonctionnelle)
n ce qu’ils sont (approche objet)
L’approche objet gère plus efficacement la
complexité

3
Historique des langages OO
Langages de programmation orientés objets
n Simula (1967)
n Smalltalk (1970)
n C plus Classes (1980)
n C++ (1985)
n Eiffel (1988)
n Java (1995)
SGBD orientés objets
n Utilisation des objets avec un langage OO
Genèse des méthodes d’analyse
n Implémentation
n Conception (solution informatique)
n Analyse (comprendre et modéliser le problème)
n …
4
Les méthodes d’analyse
Méthodes orientées comportement
n on s’intéresse à la dynamique du système
ex : réseaux de Pétri
Méthodes fonctionnelles :
n s’inspirent de l’architecture des ordinateurs
n on s’intéresse aux fonctions du système
ex : SADT
Méthodes orientées données :
n on ne s’intéresse pas aux traitements
ex : MERISE
Méthodes orientées objets :
n on ne sépare pas les données et les traitements
ex : Booch, OMT

5
L’unification

des méthodes
n La guerre des méthodes ne fait plus avancer la
technologie des objets
n Recherche d’un langage commun unique
w Utilisable par toutes les méthodes
w Adapté à toutes les phases du développement
w Compatible avec toutes les techniques de réalisation

sur plusieurs domaines d’applications

n Logiciels à Ingénierie des logiciels
n Logiciels et matériels à Ingénierie des systèmes
n Personnes à Ingénierie des affaires

6
 Intérêt d’un standard de modélisation
universel
OMT
Passer de l’artisanat à la production industrielle
Booch
n Modélisation haut niveau
OOSE
n Développement basé sur composants
Fusion
n Intégration de procédés de modélisations complémentaires
Classe-Relation
n Notation unifiée pour toutes les méthodologies OO
ROOM

HOOD

etc.
> 150 fin 1990
Rational OMG UML 2.0
1995 1996 …
UML 1.4
OMT
(Rumbaugh et al.) Unified Method Fin 200
20011
0.8 UML 1.3

Booch UML 1.1 Juin 1999

OOSE UML 0.9
(Jacobson et al.)
Nov. 1997

Catalysis ROOM etc.

7
Unified Modeling Language

Langage = syntaxe + sémantique

n Syntaxe
w Règles selon lesquelles les éléments du langage (ex. les
mots) sont assemblés en des expressions (ex. phrases,
clauses).
n Sémantique
w Règles permettant d’attribuer une signification aux
expressions syntactiques

è UML
è UML Notation
Notation Guide
Guide

è UML
è UML Semantics
Semantics

8
Objectifs

Représenter des systèmes entiers

Choisir la granularité de la description
Établir un couplage explicite entre concepts et artefacts
exécutables
Programmation sans programmer :
créer un langage de modélisation utilisable à la fois par
les humains et les machines

11
Caractéristiques du langage de
modélisation UML
Générique et Expressif
Syntaxe et sémantique définis
Flexible (configurable, extensible)
n Définition du Métamodèle
n Norme non figée
n On peut adapter le langage à des domaines
particuliers sans ajouter de nouveaux types de
diagrammes
n Introduction d’une nouvelle notion en la définissant
comme particularisme d’une notion existante

12
Portée

Formalisme unique pour tout type d’application

n gestion, scientifique, temps réel, industrielle,
multimédia…
Reste au niveau d’un langage
n ne propose pas un processus de développement
n ni ordonnancement des tâches,
n ni répartition des responsabilités,
n ni règles de mise en œuvre
(Certains ouvrages et AGL basés sur UML ajoutent
cet aspect fondamental en méthodologie)

13
Démarche

Ensemble de point de vues complémentaires

Développement par raffinages successifs

14
Des modèles complémentaires
Des règles de cohérence pour une modélisation non ambiguë
Des vues complémentaires pour un modèle complet
L’analyse formelle du modèle devient possible
 Des modèles de plus en plus détaillés
UML Use Case UML Interaction UML Class UML Statechart
Diagrams Diagrams Diagrams Diagrams
Design Analysis

obj 1 obj 1 obj 1 Control Techno

Func 1
state 1

Func 2 state 3 state 2

Train Circuit
Real-timeObject

obj 1 obj 1 obj 1 Control Techno

state 1

state 3 state 2
Train Circuit
Design

obj 1 obj 1 obj 1 Control Techno

state 1 state 1

state 3 state 2 state 3 state 2

Train Circuit

UML Activity
Diagrams
En résumé

UML est un langage de modélisation objet

UML est une notation, pas une méthode
UML convient pour toutes les méthodes objet
UML est dans le domaine public

UML
UML est
est la
la notation
notation standard
standard pour
pour documenter
documenter
les
les modèles
modèles objets
objets

17
L’état

L’état regroupe les valeurs instantanées de tous

les attributs d’un objet
L’état évolue au cours du temps
L’état d’un objet à un instant donné est la
conséquence de ses comportements passés
L’état conditionne son comportement futur

19
Le comportement

Décrit les actions et les réactions d’un objet

n du point de vue externe (opérations)
n Du point de vue interne (méthodes)
L’état et le comportement sont liés
n Le comportement dépend de l’état
n L’état est modifié par le comportement

20
L’identité

Tout objet possède une identité qui lui est

propre et qui le caractérise
L’identité permet de distinguer tout objet
de façon non ambiguë, indépendamment de
l’état
L’identité d’un objet est immuable tout au long
de sa vie

21
Communication entre objets

Application = société d'objets collaborant

Les objets travaillent en synergie
afin de réaliser les fonctions de l’application
Le comportement global d’une application
repose sur la communication entre les objets
qui la composent

22
Les classes

La classe est une description abstraite d’un

ensemble d’objets « de même type »
La classe peut être vue comme la factorisation
des descriptions communes à un ensemble
d’objets
La classe est également un espace de
nommage (Namespace)

23
Les 9 diagrammes

Besoins des utilisateurs Diagramme des cas

d’utilisation
Structure statique Diagramme de classes
Diagramme objet
Dynamique des objets Diagramme états-transition
Diagramme d’activités
Interactions entre objets Diagramme de séquence
Diagramme de collaboration

Réalisation et déploiement Diagramme de composants

Diagramme de déploiement

24
Points de vues de modélisation

Spécifier le système
Modéliser des objets communicants
Modéliser la structure de l’application
Modéliser le comportement des objets
Modéliser les traitements
Modéliser l’instanciation de l’application

25
Points de vues de modélisation

Spécifier le système
Modéliser des objets communicants
Modéliser la structure de l’application
Modéliser le comportement des objets
Modéliser les traitements
Modéliser l’instanciation de l’application

26
 Use case diagram
use case system actor
= main function
Speed Regulator

regulate speed SpeedSensor

relation
« include »

display status Motor

« include »

start regulating RegulatorDisplay

Regulator « include »
On/Off
stop regulating

environment system border

27
Instances, liens, messages
On identifie et nomme les objets (instances) qui
interviennent dans le système
D’abord, les objets « physiques » puis les objets plus
abstraits
On spécifie les liens entre objets, puis les messages
transitant par ces liens

Instance diagram
Collaboration diagram
deltaTorque
calculate()
:= calculate()
regulator regLaw

update() getSpeed()

display speedSensor

29
Mécanisme de communication

Communication: uniquement par messages

n Message = une action + un événement
w En général point à point
w Possibilité d’un ensemble de cibles

Deux types d’envoi de message

n Appel d’opération (CallAction + CallEvent)
w Synchrone/asynchrone, paramètres input et output
n Signal (SendAction + SignalEvent)
w Asynchrone, paramètres input seulement

30
 Sequence diagram active instance

regulator regLaw speedSensor display

instance
synchronous message
calculate() getSpeed()
deltaTorque life line timing spec
sp
response
update(info)
< 2s
asynchronous message
Time ä

regulator regulator regLaw

guard on message

[launch=true] create()
regLaw [launch=false] delete()

create message deleting message

31
Points de vues de modélisation

Spécifier le système
Modéliser des objets communicants
Modélisation la structure de l’application
n Diagrammes de classes
n Paquetages
Modéliser le comportement de l’objet
Modéliser les traitements
Modéliser l’instanciation de l’application

32
 Class diagram

classe rôle association

regLaw << active >>

RegulatingLaw Regulator
0..*

composition
arité /
cardinalité
navigabilité généralisation
sps 0..*
(spécialisation)
active objects
classe active
SpeedSensor

Regulator_S
compartiment des attributs tgSpeed: integer
compartiment des opérations maintainSpeed()

33
Indication de type d’instance
Collaboration diagram

regLaw
RegulatingLaw Regulator
0..*

sps 0..*

SpeedSensor

Instance / role diagram

regLaw
rl/regLaw:RegulatingLaw reg:Regulator

/sps:SpeedSensor

34
 Interfaces interface
Interface

<< interface >>

SpeedDispl RegDisplay RegulatorDispl
display 0..1
displSpeed() displSpeed() displStatus()
implantation
displStatus() des interfaces
0..1 display

regLaw
RegulatingLaw Regulator
0..*

sps 0..*
Regulator_S
SpeedSensor
tgSpeed: integer
maintainSpeed()

35
Packages Graphics
SpeedDispl
RegDisplay

package RegulatorDispl
displSpeed()
displStatus()
0..1 display
Core

LawImpl Main
regLaw
RegulatingLaw Regulator
0..*

Regulator_S
sps 0..*

SpeedSensor tgSpeed: integer

maintainSpeed()
dépendance

36
Packages

Graphics

Core

LawImpl Main

37
Packages

<<subsystem>>

Graphics
<<model>>
Core

LawImpl Main

38
Automate

Une machine dont le comportement en output

résulte de
n Les inputs courants
n Les inputs passés
Caractérisée par un état interne représentant
son passé

ON ON

OFF

40
Statechart Diagram
on

Lamp On

on

off
off
Lamp Off

41
Outputs et Actions

Le changement d’état peut générer des outputs

on on
Lamp Lamp On
On print(”on”)

on/print(”on”) on

off off
off off
Lamp Lamp
Off Off

Mealy automaton Moore automaton

42
Machine d’états étendue

Addition de variables (“extended state”)

on
ctr
ctr :: Integer
Integer Lamp On

on/ctr := ctr + 1
off
off
Lamp Off

43
Basic UML Statechart Diagram
Etat
Etat
englobant
englobant (top)
(top) Etat
Etat
Pseudo -état
Pseudo-état
Initial
Initial top
top Réception
Réception
événement
événement
Ready
Transition
Transition

stop /ctr := 0 ^bip

Emission
Emission
Done événement
événement
Etat
Etat Final
Final
stop
Action
Action

44
Comportement “Event-Driven”

Evénement = un type d’occurrence observable:

n Interactions:
w Appel d’opération synchrone (call event)
w Réception de signal asynchrone (signal event)
n Evénements temporels (time event)
w Expiration d’un délai (after(x))
w Survenance d’une date (when(x))
n Changement de valeur d’une entité (change event)
Une instance d’événement survient à un instant
donné et n’a en lui-même aucune durée

45
A quelle entité le comportement est-il attaché?

En principe, tout ce qui manifeste un

comportement “event-driven”
En pratique, une machine d’état est attachée à
une classe, afin de contraindre:
n le comportement interne de ses instances
n les interactions entre objets
L’intérêt principal de la machine d’état en UML
apparaît dans le cas des objets actifs

46
Modèle général du comportement d’un objet actif

Modèle serveur simple Initialisation

Initialisation
de
del’objet
l’objet

Attente
Attentede
de
requête
requête

Traitement
Traitement
de
derequête
requête

Destruction
Destruction
de
del’objet
l’objet

47
Modèle général du comportement d’un objet actif

Mapping machine d’états ⇔ simple serveur

on
Initialisation
Initialisation
de
del’objet
l’objet Lamp On
Attente de
requête on/print(”on”)
Traitement
Traitement off
de
derequête
requête off
Lamp
Off
Destruction
Destruction
de
del’objet
l’objet
stop
48
Objets et fils d’exécution

Objet passif : activation dépend d’un fil externe

Objet actif : possède son propre fil d’exécution

Initialize
Initialize Initialize
Initialize
Object
Object Object
Object

Wait
Waitfor
for Wait
Waitfor
for
Request
Request Request
Request

Handle
Handle Handle
Handle
Request
Request Request
Request

Terminate
Terminate Terminate
Terminate
Object
Object Object
Object

49
Dynamique d’un objet passif
Initialize
Initialize
Object
Object

Wait
Waitfor
for
Request
Request

Handle
Handle
Request
Request

Terminate
Terminate
Object
Object

L’encapsulation ne protège pas des conflits de

concurrence !
⇒ Synchronisation explicite nécessaire
50
Objets actifs et machines d’états
L’objet encapsule son propre fil d’exécution
(n’exporte que des opération de requêtes)
anActiveObject

#currentEvent : Eventpoll/defer
created

+ start ( )
start start/^master.ready() ready
+ poll ( )
+ stop ( )
ready
stop/

poll/^master.ack()

51
Dynamique d’un objet actif
activeObject

Modèle “exécution jusqu’à complétion”:

n traitement sérialisé des événements
n élimination des accès concurrents internes
n minimisation du “context-switching”
52
 Statechart diagram
root state Event:
• CallEvent
• SignalEvent
• ChangeEvent
Regulator • TimeEvent
Off
guard
OnOff OnOff [speed>30] /
group startRegulating(); List of actions
transition On ++speed;

non-developed
composite state

53
 Etat composite

Regulator
Off

OnOff OnOff [speed>30] /

startRegulating();
On ++speed;
On
/maintainSpeed()

Running

suspend resume

Suspended
simple state composite state

54
Etats concurrents

RegulatorRegulator
regulating monitoring
compound
Off transition OK

OnOff [speed>30]
OnOff
/ startRegulating(); ++speed;
[¬ error] scan
reset
On
pseudo-state =>
Choice [error]
damaged

concurrent states
state
(è regions)

55
 Transitions d’états concurrents

S1

S10
S0 S2

S11

Fork pseudo-state

Join pseudo-state

56
Actions Ordre des actions :
Regulator 2- transition…
Off
OnOff [speed>30] / startRegulating(); ++speed;
3- entry
(récursion depuis « top »)
OnOff
4- do…
On
/maintainSpeed() G Etat indéfini entre le 1er
entry/actions1
exit et le dernier entry
Running
entry/actions1_1
Ø Récursion des actions
do/actions2_1 « do » dans les états
do/actions2 imbriqués
exit/actions3_1 ⇒ possibilité de // …

suspend resume
exit/actions3
Suspended

57
Actions Ordre des actions :
1- exit (récursion depuis down)
Regulator 2- transition…
Off
OnOff [speed>30] / startRegulating(); ++speed;
3- entry
(récursion depuis « top »)
OnOff
4- do…
On
entry/actions1
/maintainSpeed() G Etat indéfini entre le 1er
exit et le dernier entry
Running
entry/actions1_1
Ø Récursion des actions
do/actions2_1 « do » dans les états
do/actions2 imbriqués
exit/actions3_1 ⇒ possibilité de // …

Ø Fin d’action « do » génère:

suspend resume completion event
exit/actions3 ⇒ completion transitions
Suspended

58
Actions Ordre des actions :
1- exit (récursion depuis down)
Regulator 2- transition…
Off
OnOff [speed>30] / startRegulating(); ++speed;
3- entry
(récursion depuis « top »)
OnOff
4- do…
On
entry/actions1
/maintainSpeed() G Etat indéfini entre le 1er
exit et le dernier entry
Running
entry/actions1_1
Ø Récursion des actions
do/actions2_1 « do » dans les états
do/actions2 imbriqués
exit/actions3_1 ⇒ possibilité de // …

Ø Fin d’action « do » génère:

suspend resume completion event
exit/actions3 ⇒ completion transitions
Suspended
Ø Tout événement interrompt
les actions « do » en cours

59
Variabilité des Machines d’états UML

Choix de la (des) politique de livraison des

événement
n Le plus répandu = FIFO
Une tâche par défaut est définie (celle qui lit
implante la politique de livraison des
événements)
n Mais il est possible d’en avoir plusieurs, par exemple:
une tâche par région concurrente
Héritage de machine d’état: non défini
…
60
Points de vues de modélisation

Spécifier le système
Modéliser des objets communicants
Modélisation la structure de l’application
Modéliser le comportement de l’objet
Modéliser les traitements
n Diagramme d’activité
Modéliser l’instanciation de l’application

61
Eléments de base
État d’action simple

SpeedSensor

spSensor.getSpeed()
+getSpeed()

CalculateDeltaTorque CalculateDeltaTorque

CalculateDelta Speed

RegLaw.calcDeltaTorque()

État d’action composite

63
Flux d’objet: représente la disponibilité d’un objet

spSensor.getSpeed()

[curSp > 30]

CalculateDeltaTorque
data

displ.dispSpeed()
eng.setCommand()

displ.dispCommand()

66
Points de vues de modélisation

Spécifier le système
Modéliser des objets communicants
Modélisation la structure de l’application
Modéliser le comportement de l’objet
Modéliser les traitements
Modéliser l’instanciation de l’application

67
Diagrammes d’implantation

Diagrammes de composants: organisation et

dépendances des composants de l’application
n code source, binaires, exécutables, procédures,
documents, etc.
Diagrammes de déploiement: configuration de
distribution des composants

68
Component Diagram

SpeedAcquisition SpAcqSyst

RegulationSystem
SignalCom
RegulatorSyst

rl:RegulatingLaw

69
Composants (classes résidentes)

RegulationSystem

<< reside >> << reside >>

RegulatingLaw Regulator

70
Deployment Diagram

Intel-Linux

TCP/IP

FrontEndProcessor Level2Acquisition
SpeedAcquisition RegulationSystem

71
Modèle en 4 couches
instanceOf

Meta Meta Model (M3)

MOF Metaclass

instanceOf
...

Meta Model (M2)

Class
UML Autres
standards
instanceOf

Car
Model (M1)
instanceOf

Objects (M0) a106

72
Extensions Métier d’UML
Meta Meta Model (M3)
MOF

...
Meta Model (M2)
UML …
...
Standard profile (M2)
Real Time ActionLanguage

ACCORD/UML MORDICUS End-user specific Profile (M2)

Model (M1)

Objects (M0)

73
 Exemples de Métaclasses Personne
age:integer
ModelElement
name:Name

feature
Feature Namespace
* {ordered}

StructuralFeature 0..1 owner

type
multiplicity:Multiplicity * Classifier
1

Attribute Class

74
Mécanismes d’extension UML

Stereotype
n Méta-classe spécialisée (ex: « real-time »)
n Ajout de nouveaux stéréotypes à extension
Tagged value
n méta-attribut (ex: {abstract})
n Ajout d’un nouveau méta-attribut à extension
Constraint
n Règle de formation d’expression (ex: {ordered})
n Nouvelles contraintes sur le méta-modèle à extension

75
Notion de profil UML
(Cf. http://www.objecteering.com/us/smot_uml_white.htm)
Standardisation d’un méta-modèle étendu
d’UML
Adapté à un domaine métier ou middleware
Un profil UML peut contenir
n Les éléments sélectionnés dans la méta-modèle de
référence
n Des extensions utilisant les différent mécanismes
d’extension
n Descriptions sémantiques des extensions
n Notations supplémentaires
n Règles de validation, présentation, transformation

76