Unified Modeling Language

Langage unifié pour la modélisation objet

INTRODUCTION
USTHB – Cycle Ingénieur
Cours 5ème Année 2010-2011

Présenté par
Dr. Kamel Boukhalfa
Dr. Latifa Mahdaoui
1 2

Des Modèles plutôt que du Code Comment Modéliser ?

 Un modèle est la simplification/abstraction de la  Le choix de quel modèle faut-il créer a une profonde

réalité influence sur quelle manière le problème est traité et la

solution obtenue
 Nous construisons donc des modèles afin de mieux
 Chaque model doit être exprimé à différents niveaux de
comprendre les systèmes que nous développons
précision
 Nous modélisons des systèmes complexes parce que
 Les meilleurs modèles sont ceux qui sont connecté à la
nous somme incapables de les comprendre dans leur
réalité
totalité
 Un seul modèle est souvent insuffisant. Un système
 Le code ne permet pas de simplifier/abstraire la réalité complexe est représenté par un ensemble de petits
modèles.
3
Notation & Méthode 4
 Des Méthodes de modélisation Trop de Méthodes
 L’apparition du paradigme objet à permis  Entre 89 et 94 : le nombre de méthodes orientées

la naissance de plusieurs méthodes de objet est passé de 10 à plus de 50

modélisation  Toutes les méthodes avaient pourtant d’énormes

points communs (objets, méthode, paramètres, …)
◦ OMT, OOSE, Booch, Fusion, …
 Au milieu des années 90, G. Booch, I. Jacobson et J.
 Chacune de ces méthodes fournie une
Rumbaugh ont chacun commencé à adopter les
notation graphique et des règles pour
idées des autres. Les 3 auteurs ont souhaité créer
élaborer les modèles
un langage de modélisation unifié
 Certaines méthodes sont outillées
5 6

Principales étapes de la définition d’UML Principales influences

 Booch - catégories et sous-systèmes
UML 2
 Embley - classes singletons et objets composites
Soumission OMG UML 1.3 juin 1999
 Fusion - description des opérations, numérotation des messages
UML 1.2 juin 1998  Gamma - frameworks, patterns et notes
Standardisation OMG
Soumission OMG UML 1.1 Novembre 1997  Harel - automates (statecharts)
Septembre 1997
Soumission OMG
UML 1.0
 Jacobson - cas d’utilisation (use cases)
Janvier 1997
 Meyer - pré et post conditions
OOPSLA ‘ 96 UML 0.9
Juin 1996  Odell - classification dynamique, éclairage sur les événements
OOPSLA ‘ 95 Méthode Unifiée 0.8 Octobre 1995  OMT - associations

 Shlear-Mellor - cycle de vie des objets

Booch ’93 OMT-2
 Wirfs-Brock - responsabilités (CRC)
Autres Booch ’91 OMT-1 Objectory Partenaires
méthodes 7 8
 UML ? Objectifs d’UML
 Proposer un langage visuel de modélisation
 C’est:
 Utilisable par toutes les méthodes

◦ Une notation, un langage de modélisation  Adapté à toutes les phases du développement

 Compatible avec toutes les techniques de réalisation

objet
 Proposer des mécanismes d’extension et de spécialisation pour pouvoir
◦ Une description complète, évolutive, publique étendre les concepts de base

Être indépendant des langages particuliers de programmation

◦ Un standard, utilisé par des AGL


 Proposer une base formelle pour comprendre le langage de modélisation

 Ce n’est pas :  Encourager l’application des outils OO

◦ Une méthodologie  Supporter les concepts de développement de haut-niveau tels que les
frameworks, les patterns et les composants
◦ Un langage de programmation  Intégrer les résultats de la pratique
9 10

Diagrammes d’UML Diagrammes UML et vues

Diagramme

Diagrammes de classes
Diagrammes d'objets Diagrammes de composantes
Composants Classes Séquence Activités Objets
Diagrammes d'états Diagramme des cas
Diagrammes d'activités
Déploiement Cas d’utilisation Etats-Transitions Collaboration Diagrammes de déploiement
Diagrammes de séquence
Diagrammes de collaboration

11 12
 Processus d'ingénierie sous-jacent Relations entre diagrammes et étapes du processus

Découverte des besoins

Modèle
des cas
d’utilisation
 Diagramme de cas d’utilisation: décrit les fonctions du
spécialisé par
Modèle réalisé par système selon le point de vue de ses utilisateurs futurs
d’Analyse

Modèle de distribué par

Conception  Diagramme de séquence: représentation des
réalisé par
Modèle de
Déploiement
interactions temporelles entre objets dans la réalisation
vérifié par
Modèle de
Réalisation d'une interaction homme-système
Modèle de
Test

13 14

Relations entre diagrammes et étapes du processus Relations entre diagrammes et étapes du processus

Analyse
 Diagramme de classes : structure des données du système
définie comme un ensemble de relations entre classes
 Diagramme d’objets : illustration des objets et de leurs
relations
 Diagramme de collaboration : représentation des interactions
entre objets
 Diagramme d’états-transitions : représentation du
comportement des objets d'une classe en termes d’états et de
transitions d'états
 Diagramme d’activités : structure d'une opération en actions
15
Conception :
 Diagramme de séquence: représentation des
interactions temporelles entre objets dans la
réalisation d'une opération
 Diagramme de déploiement : description du
déploiement des composants sur les dispositifs
matériels
 Diagrammes de composants : architecture des
composants physiques d'une application
16
 Définition
 Un diagramme de cas présente un
ensemble d'acteurs et de cas d'utilisation
avec leurs relations.
DIAGRAMMES DES CAS
D’UTILISATION

1
8
17 18

Acteur Représentation graphique d'un acteur

 Un acteur est la description d'un ensemble
cohérent de rôles qu'un utilisateur
(personne ou système) joue lorsqu'il
interagit avec le système.
 Exemple :
 Un acteur est une classe stéréotypée
représentée par un rectangle avec le
stéréotype «acteur» ou par une icône.
<<acteur>>
Bibliothéquaire
Client

<<acteur>>
Bibliothéquaire
Client
19 20
 Nommer un acteur Généralisation entre acteurs
 Chaque acteur doit avoir un nom qui le distingue des  Les acteurs peuvent avoir des associations
autres acteurs.
de généralisation
 En pratique les noms de acteurs sont des noms pris dans
le vocabulaire du domaine.  Exemple :
 Il est d'usage de capitaliser la première lettre de chaque Client

mot.

<<acteur>>
ClientBanque PréposéBanque Particulier Entreprise

21 22

Cas d'utilisation Représentation graphique d'un cas

 Un cas est est une classe qui représente un  Un cas est représenté par une ellipse
ensemble de fonctions ou de  un ensemble de cas peut être placé dans
comportements fournis par un système à un rectangle qui symbolise le système
un ou des acteurs.
 Exemple :
Signer Contrat Assurance

Acheter Automobile

23 24
Nommer un cas Généralisation
 Chaque cas doit avoir un nom qui le distingue  L'association de généralisation entre cas
des autres cas - Unicité du nom complet (noms d'utilisation a la même sémantique que
des packages englobant + le nom du cas).
pour les classes
 En pratique les noms de cas sont des verbes pris
dans le vocabulaire du domaine. Valider usager

Emprunter Livre
Vérifier Scanner
Accorder Crédit mot de passe rétine
25 26

« communique » « étend »
 La relation communique permet de  La relation étend permet de modéliser un
modéliser les échanges de messages entre comportement exceptionnel d'un cas
acteurs et cas d'utilisation d'utilisation

<<étend>>
Traiter une
<<communique>> Traiter une
commande
Cas commande
urgente
Acteur

27 28
 « inclut »
 La relation inclut permet de modéliser
l'inclusion de cas d'utilisation pour éviter
les répétitions
DIAGRAMMES DE CLASSES
<<inclut>>
ET DIAGRAMMES D'OBJETS
Valider Traiter une
Utilisateur commande

29 30

Diagrammes de classes et d'objets Classe

Un diagramme de classes représente la structure du système Une classe est une description abstraite d’un ensemble

en termes de classes et de relations entre ces classes; Un d’objets ayant des propriétés similaires, un comportement

diagramme d'objets illustre les objets et leurs relations commun, des relations communes avec d’autres objets et
des sémantiques communes
Instance de
Classe Objet
* * Nom de classe Nom de classe
attributs

Relie Relie opérations

Exemples:
* * Personne Personne
Relation Instance de Lien Nom
Poste de travail Prénom
Date naissance
Diagramme de classes Diagramme d’objets Département
31 Age() 32
 Attributs de classe Opérations de classe
Un attribut définit une propriété commune aux Une opération définit une fonction appliquée à des objets d’une
objets d’une classe classe
Nom de classe
Nom de classe
Nom d’attribut: type = valeur initiale Nom d’opération( liste_arguments) : type_retour

Personne
Objet Géométrique
Personne Film Personne nom : string
couleur : string
nom : string adresse : string
titre : string Id_pers : integer position : integer
prénom : string date_naiss : date
réalisateur : string nom : string
date_naiss : date date_production : date prénom : string déplacer (deltat:Vecteur)
age ()
date_sortie : date date_naiss : date sélectionner (p:Point):Booléen
change_adresse ()
La syntaxe de description d'une opération est la suivante:
 Les noms d'attributs d' une classe sont uniques
 Chaque objet, instance d'une classe a sa propre identité indépendante des Nom_opération (Nom_Argument : Type_Argument =
valeurs de ses attributs. L'identification d'un objet est donc facultative 33
Valeur_Par_Défaut, …): Type_Retourné
34

Attributs dérivés Association

Une association représente une classe de
Les attributs dérivés ont des valeurs calculées à partir de celles d’autres
propriétés relations structurelles entre classes d’objets
Exemple:

Classe A Classe B

Rectangle Rectangle
Longueur Longueur
En conception Société Personne
Largeur Largeur
/Surface
Surface( )

Analyse Voiture Personne

35 36
Classe association Association n-aire
 Une association peut être représentée ( réifiée) par une
Salle
classe appelée classe associative ou classe-association.
Utile par exemple, lorsuqe l'association a des attributs ou
Étudiant Enseignant
bien qu'on souhaite lui attacher des opérations. La
notation utilise une ligne pointillée pour attacher une Cours
classe à une association Début
Fin
A B

D
L' association ternaire entre salle, étudiant et enseignant est
C réifiée comme une classe cours ayant deux attributs, Début
attributs et Fin
opérations() 37 38

Nommage des associations Nommage des rôles

 Le nom d’une association apparaît en Italique au milieu
de la ligne qui symbolise l’association
 L’usage recommande de nommer les associations par une
forme verbale, soit active, soit passive
 Chaque association binaire possède 2 rôles
 Le rôle décrit comment une classe
intervient dans une association

A Nom B  Le nommage des associations et le

nommage des rôles ne sont pas exclusifs
Personne Travaille pour > Société
l’un de l’autre
Employé
Personne Société
Personne Est employée par > Société Employeur

39 40
 *
Nommage des rôles Association réflexive
 Le nommage des rôles prend tout son intérêt lorsque il y
a plusieurs associations entre les deux mêmes classes.

Parents Personne
Pilote
Avion Personne 2

Passagers
* Enfants

 La présence d’un grand nombre d’associations entre 2 classes est

suspecte. Est souvent le signe d’une mauvaise modélisation Le nommage des rôles est indispensable
Exemple : à la clarté du diagramme

Personne Conduire Voiture

Démarrer
Laver
Arrêter
41 42

Multiplicité des associations Multiplicité des associations

 La multiplicité est une information portée par le
rôle, qui quantifie le nombre de fois où un objet
 Les valeurs de multiplicité expriment des
participe à une instance de relation
contraintes à un instant donné
1 Un et un seul Employé 1
Personne Société
0..* Employeur
0 .. 1 Zéro ou un

M .. N De M à N (entiers naturels)
Chaque personne travaille pour une seule société,
* De zéro à plusieurs chaque société emploie zéro ou plusieurs personnes

0 .. * De zéro à plusieurs

1 .. * De un à plusieurs 43 44
Contraintes sur les associations Contraintes sur les associations
 Les contraintes sont représentées sur les  La contrainte {Sous-ensemble} indique qu’une

diagrammes par des expressions placées collection est incluse dans une autre collection
Parents d’élèves
entre accolades Classe Personne
{Sous-ensemble} *

 La contrainte {ordonnée} placée sur le rôle Délégués *

définit une relation d’ordre sur les objets  La contrainte {Ou-exclusif} précise que, pour un objet donné,
une seule association parmi un groupe d’associations est valide
de la collection
Enseignants
Université Personne
Personne Compte {Ou-exclusif}
1 0..*
Étudiants
{Ordonnée} 45 46

Restriction des associations Restriction des associations

 La restriction (qualification pour UML) d’une association consiste à  Une restriction réduit le nombre d’instances qui
sélectionner un sous-ensemble d’objets parmi l’ensemble des objets
participent à une association
qui participent à une association
:B
 Réalisée au moyen d’une clé, ensemble d’attributs particuliers et :B :B
:B
utilisé avec un objet de la classe de départ. La clé appartient à Sans clé
:B :B
l’association et non aux classes associées
:A
 Chaque instance de la classe A accompagnée de la valeur de la clé,
 La restriction peut être opérée en combinant les valeurs
identifie un sous-ensemble des instances de B qui participent à Avec clé
l’association
des différents attributs qui forment la clé

A Clé B
Ligne Case
Échiquier Colonne
Université N°Etudiant Etudiant 47 1 48
Agrégation Agrégation
Une agrégation représente une association non symétrique dans
 L’agrégation peut être multiple, comme
laquelle une des extrémités joue un rôle prédominant par rapport à
l’autre l’association
 Les propriétés suivantes suggèrent une agrégation: Personne 1..* Immeuble
Propriétaire 0..*
◦ une classe B 'fait partie' d’une classe A

◦ les valeurs d’attributs de la classe B se propagent dans les valeurs

d’attributs de la classe A En tant que 'propriétaire' une personne est un agrégat d'immeubles!
Les immeubles dont elle est propriétaire font 'partie de' la description
◦ une action sur la classe A implique une action sur une la classe B; d'une personne

◦ les objets de la classe B sont subordonnés aux objets de la classe

A
A Une agrégation B

49 50

Composition Composition
La composition est une forme particulière d'agrégation  La composition peut être modélisée au moyen d'

Le composant est physiquement contenu dans l’agrégat attributs

 La composition implique une contrainte sur la valeur de  La notation par composition doit être retenue lorsqu’un

la multiplicité du côté de l’agrégat: elle ne peut prendre attribut participe à d’autres relations dans le modèle

que les valeurs 0 ou 1

Voiture
Voiture Moteur
 La valeur 0 du côté du composant correspond à un Moteur 
attribut non renseigné

0..1
Agrégat Composant
Cylindre Carburateur
* ...
51 52
 Généralisation Généralisation multiple
 Dans le cas des classes, la relation de
Véhicule
généralisation signifie est un ou est une Tapis

sorte de
X
Terrestre Aérien
Animal

A B C

Tapis volant

Chat Chien Vache

53 54

Généralisation Contraintes de généralisation

 Une classe peut être spécialisée selon plusieurs critères  La contrainte {Disjoint} ou {Exclusif} indique la
 Différentes contraintes peuvent être appliquées aux participation exclusive d'un objet à l'une des collections
relations de généralisation spécialisées
Champignon
 Par défaut, la généralisation symbolise une
décomposition exclusive {Exclusif}

Véhicule Agaricus Boletus

Motorisation Milieu

A voile A moteur Terrestre Marin Pied bleu Bolet de loup

55 56
 Contraintes de généralisation
Contraintes de généralisation
 La contrainte {Chevauchement} ou {Inclusif} indique  La contrainte {Complète} indique que la généralisation
qu'un objet peut appartenir à plusieurs collections est terminée et qu'il n'est pas possible de rajouter des
spécialisées . sous-classes. Inversement, la contrainte {Incomplète}
Véhicule
désigne une généralisation extensible

Motorisation {Inclusif} Milieu Cours

A voile A moteur Terrestre Marin

{Incomplète}

Maths Français Géographie

Pétrolette

57 58

Diagramme d'objets Diagramme d'objets

 Permet de visualiser la structure du système au niveau  On peut faire apparaître des valeurs d'attributs dans un
des instances objet

 Facilite la compréhension des structures de données  ainsi que les liens entre objets
complexes
:Voiture
 Trois possibilités de représentation : Couleur = rouge

Voiture Moteur :Voiture :Moteur

1 1
:Roue
Nom de l'objet Nom de l'objet : Classe : Classe 1
4 :Roue :Roue :Roue
Roue
59 60
 Liens entre les objets Liens entre les objets
 On peut illustrer les liens d'arité supérieure à 2 et la
muliplicité *
 Les liens instances des associations réflexives peuvent relier un
Professeur
objet à lui-même
1..*

1..* 1..*
Salle Etudiant
Collaborateur Patron
* Jean-Luc: Personne Pierre: Personne
Personne

Patron 1
Patron : Professeur
Denis: Personne

: Salle : Etudiant

61 62

Objet composite Illustration de structures complexes

 Les objets composés de sous-objets peuvent être  Les diagrammes d'objets facilitent la
visualisés
compréhension des diagrammes de classes
Un composite

: Partie : Partie : Partie

Passagers * Passagers
Bus Personne : Personne
 Les objets composites sont instances de classes composites: : Bus
Conducteur 1 Conducteur

Fenêtre Ascenseur : Fenêtre : Personne

1 1
2
: Zone de dessin : Ascenseur Destination : Destination
1

1
Zone de dessin : Ascenseur

63 64
Illustration de structures complexes Packages
 Un package permet de grouper des
Parent
Personne Prénom
1
éléments
Mère/Père
Enfant 0..1  Un package sert d’espace de désignation
 Un package peut inclure d’autres package
Jonathan
Lara
Mère Père
Roxane  Un package peut importer d’autres
Mère Père Mère Père
package
Anne Pierre-Alain  L’héritage entre package est possible
65 66

Packages Diagramme de Classe - Fin

 Les diagrammes de classes sont les
diagrammes les plus utilisés
◦ Ils permettent la décrire des programmes objet
◦ Ils permettent de décrire le schéma logique de
bases de données
◦ Ils permettent de décrire des relations de concepts
(modèle métier)

 Les diagrammes de classes peuvent être de

différents niveaux d’abstraction
67 68
 Diagramme de collaboration

Il décrit le comportement collectif d'un ensemble d'objets dans le cadre d'une

opération en illustrant leurs interactions par des envois de messages

Collaboration 0..1
DIAGRAMMES DE *
Interaction
Modèle : Booléen
COLLABORATION D'OBJETS Opération 0..1
*
Représente

Résultat Ordre Contrainte Message Objet

69 70

Envoi de message dans un diagramme de Le temps dans un diagramme de

collaboration collaboration
 Une interaction est réalisée par un groupe d'objets qui  Le temps peut être introduit par le biais de
collaborent en échangeant des messages
la numérotation des envois de messages
 Extension des diagrammes d'objets

 Un message est représenté par une flèche labellée par le

(ordre)
nom de l'opération
: Ascenseur

1:Monter
: Cabine
Message Ouvrir 3:Fermer
2:Mettre en marche : Porte
: ClasseA : ClasseB : Cabine : Porte
: Cabine
71 72
Contraintes associées aux envois de Itération dans un diagramme de
messages collaboration
 Les objets et les liens créés ou détruits au cours d'une  La notation permet d'introduire un envoi répétitif de
interaction peuvent respectivement porter les messages (événtuellement en parallèle) sur une
contraintes {nouveau} ou {détruit} collection d'objets d'une classe

 Les objets créés, puis détruits au sein de la même

interaction, sont associés à la contrainte {transitoire} Instituteur Élève
1 *

B
{nouveau}) *[tous] : Debout
:Instituteur : Élève
A

C
{transitoire}
D
{détruit} 73 74

Introduction d'un acteur extérieur Objets actifs

 La notation permet de faire figurer un acteur dans un  Les objets qui contôlent le flot sont dits actifs. Un objet
diagramme de collaboration afin de représenter le actif peut activer un objet passif en lui envoyant un
déclenchement des interactions par un élément externe message. Une fois le message traité, le flot de contrôle
au système est restitué à l'objet actif

1:Appeler 2:Écrire
: Imprimante

: Ascenseur : Traitement de texte

:Personne : Scanner
1:Lire
2:Selectionner l'étage

: Cabine

75 76
 Envois conditionnels de messages Envoi de message avec résultat
 Le résultat d’un message peut être
 L'envoi d'un message peut être assorti d'une condition
visualisé sous la forme d'une liste de

A
[condition] : Message
B
valeurs retournées par le message.
Message
A B
[poids>=300] : Sonner valeurs retournées
: Cabine : Alarme

Afficher âge
* || [âge>=18] : Voter : Université : Etudiant
âge
: Mairie : Personne

77 78

Exemple

Demande d’une boisson disponible avec introduction du montant exact de la

boisson
: Utilisateur

1: Introduire 2: boisson := Choisir

: Pièce Café : Boisson DIAGRAMMES DE SÉQUENCE

1.1: Comptabiliser(valeur)
2.3: FinOpération

: Gestionnaire
1.1.1: Afficher 2.1: réponse:= VérifierPrix(prix)
de pièces
SommeVersée 2.2: réponse:= Disponibilité

: Gobelet
2.2.1: gobelet 79 80
 Représentation des interactions entre
Diagramme de séquence objets
 Le concept de message unifie toutes les formes de communication
 Modélisation des interactions entre objets
entre objets (appel de procédure, événement discret, signal entre
suite à un événement externe flots d'exécution ou interruption matérielle)

 2 catégories d'envois de message :

 Les interactions entre objets selon un  Les envois synchrones pour lesquels l'émetteur est bloqué et attend que

point de vue temporel l'appelé ait fini de traiter le message

 Les envois asynchrones pour lesquels l'émetteur n' est pas bloqué et
peut continuer son exécution
Nom : Classe Nom : Classe Nom : Classe
Message A B
Message
Message synchrone
Message

Message asynchrone
81 82

Message réflexif Création et destruction d' objet

 La création d'un objet se représente par un
Un objet peut s'envoyer un message à lui-même
message pointant sur l'objet crée
Un objet

Message réflexif
 La destruction est indiquée par la fin de la
ligne de vie et par la lettre X
: Bibliothécaire
Objet composite Composant a Composant b

Point d'entrée Créer

: Livre

Détruire
X
83 84
 Périodes d’activité des objets Envoi conditionnel de message
Message synchrone
A B A B C
Un objet

Activation [condition] Message

[non condition] Message

Retour implicite

Message asynchrone
: Abonné : Livre : Livre
A B Un objet
Récursion
[disponible] Emprunter

[non disponible] Réserver

Retour explicite
85 86

Contraintes temporelles Traitement conditionnel d’un message reçu

A B
: Ligne
Appelant : Client téléphonique Appelé : Client
Décroche Message [condition]
Tonalité
x [non condition]
{y-x < 10s} Numérotation
y
Indication de sonnerie Sonnerie
z
{w-z < 20s} : Abonné : Livre
Décroche
w
Retourner [en bon état]

[en mauvais état]

87 88
 Diagramme d'états-transitions
 Décrit le comportement des objets d'une classe au moyen d'un
automate d'états associé à la classe
 Le comportement est modélisé dans un graphe dont les nœuds
sont les états possibles des objets de la classe et les arcs sont
les transitions d'état à état. Chaque transition résulte de

DIAGRAMMES D'ÉTATS- l'exécution d'une action et représente la réaction des objets

aux événements qui surviennent
TRANSITIONS  Les objets qui n'ont pas un comportement réactif très
important peuvent être considérés comme des objets qui
restent toujours dans le même état: leurs classes ne possèdent
alors pas d'automate
1
89 Classe Automate 90
0..1

La notion d'état Notion d'état

 Un état est un étape dans le cycle de vie d’un objet durant lequel l’objet  Un état est l'image de la conjonction instantanée des
satisfait certaines conditions, réalise certaines actions ou attend
valeurs des attributs de l'objet, et de la présence ou non
certains évènements
de ses liens à d'autres objets
 Chaque objet est à un moment donné, dans un état particulier
Exemple: L'état d'une personne résulte de la conjonction suivante :
 Chaque état possède un nom qui l'identifie
◦ âge de la personne,
 Un état est stable et durable
◦ présence d'un lien vers une société

Personne Laurent Au chômage

Société Age: 30 ans
0..1 1..* Age
: Société Bruno
En activité
Age: 40 ans
En activité A la retraite
André
Au chômage 91 Age: 75 ans A la retraite 92
 Notion d'état
 Chaque diagramme d’états-transition contient un état initial
 Pour un niveau hiérarchique donné, il y a un et un seul état
initial mais il est possible qu'il y ait plusieurs états finaux qui
correspondent chacun à une fin de vie d'objet différente
 Il est également possible de n'avoir aucun état final (par
exemple, un système qui ne s'arrête jamais)
Notion de transition
 Lorsque des événements se produisent, les objets changent d'état en
respectant les règles décrites dans l'automate associé à leur classe
 Les diagrammes d'états-transitions sont des graphes dirigés
 Les états sont reliés par des connexions unidirectionnelles, appelées
transitions
Etat A Etat B

Disponible Emprunté
État intermédiaire
État initial État final
Classe : Exemplaire
Réservé Acheté

93 Classe : Article 94

Notion d'événement Notion d'événément

 Un événement correspond à l'occurrence d'une situation  La syntaxe générale d'un événement est la suivante:
donnée dans le domaine du problème Nom de l’événement (Nom de paramètre : Type, …)

 Un événement est par nature une information  La spécification complète d'un événement comprend:
◦ le nom de l'événement
instantanée qui doit être traitée sans plus attendre.
◦ la liste des paramètres
 L'événement est le déclencheur de la transition d' état à ◦ l'objet expéditeur
état Un objet, placé dans un état donné, attend ◦ l'objet destinataire
◦ sa description
l'occurrence d'un événement pour passer dans un autre Plus de 60 ans
En activité
état
Événement Emprunt Perte d'emploi A la retraite
Etat A Etat B Disponible Emprunté Embauche

Classe : Exemplaire Au chômage

95 Plus de 60 ans 96
 Communication entre objets par Communication entre objets par
événement événement
 La communication par événement est de type  L'objet émetteur de la requête se met en
asynchrone, atomique, et unidirectionnelle. Un objet
attente de la réponse de l’objet récepteur
peut envoyer un événement à un autre objet qui doit
toujours être à même de l'interpréter de la requête
Un événement
Un objet Un autre objet A

 Les besoins de communication par événements synchrones ou Question posée à l’objet X

les échanges bidirectionnels peuvent se représenter au moyen de Attente réponse
deux échanges asynchrones de directions opposées
Réponse reçue de la part de l’objet X
Une question
Un objet Un autre objet B

97 98
La réponse

Notion de garde Notions d'opération et d'action

 Une garde est une condition booléenne qui permet ou  Le lien entre les opérations définies dans la spécification d'une classe
et les événements apparaissant dans le diagramme d'états-
non le déclenchement d'une transition lors de
transitions de cette classe est assuré par le biais des actions et des
l'occurrence d'un événement
activités
Événement [Condition]
A B
 Chaque transition peut avoir une action à exécuter lorsque la
 Les gardes permettent de maintenir l'aspect déterministe d'un transition est déclenchée par un événement
automate d'états finis. Lorsque l'événement a lieu, les gardes -  L'action est considérée comme instantanée et atomique
qui doivent être mutuellement exclusives - sont évaluées et une
transition est validée puis déclenchée Événement / Action
A B
Exemple : Livre Emprunté
Retour [bon état] Retour [mauvais état]  L'action correspond à une des opérations déclarées dans la
classe de l'objet destinataire de l'événement. L'action a accès
Disponible En réparation aux paramètres de l'événement, ainsi qu'aux attributs de l'objet
99 100
 Actions dans un état Opération, action, activité
 Les états peuvent également contenir des actions; elles sont  Un événement interne n’entraîne pas l’exécution des
exécutées à l'entrée ou à la sortie de l'état ou lors de l'occurrence
actions de sortie et d’entrée, contrairement au
d'un événement pendant que l'objet est dans l'état :
déclenchement d’une transition réflexive
◦ L'action d'entrée (entry:) est exécutée de manière instantanée et
atomique dès l'entrée dans l'état
E1 / Action
A
◦ L'action de sortie (exit:) est exécutée à la sortie de l'état B
entry: Action d'entrée
◦ L'action sur événement interne (on:) est exécutée lors de on E1: Action entry: Action d'entrée
exit: Action de sortie exit: Action de sortie
l'occurrence d'un événement qui ne conduit pas un à un autre
état
 Les actions correspondent à des opérations dont le temps
Nom d’un état
d'exécution est négligeable. Une opération qui prend du temps
entry : Action d'entrée
correspond à un état plutôt qu'à une action (sic!!)
on Nom d’un événement : Action
exit : Action de sortie
101 102

Opération et activité Notion d'activité

 Une opération qui prend un temps non négligeable et qui est exécutée
 Lorsque l'activité se termine, les transitions
pendant que l'objet est dans un état donné est appelée une activité
 Le mot-clé do: indique une activité automatiques, sans événements, mais
 Contrairement aux actions, les activités peuvent être interrompues à tout éventuellement protégées par des gardes, sont
moment, dès qu'une transition de sortie de l'état est déclenchée
déclenchées
 Activité cyclique: elle ne s'arrête que lorsqu'une transition de sortie est
A
déclenchée B
Do: Activité séquentielle
 Activité séquentielle: elle démarre à l'entrée dans l'état Lorsqu'elle
parvient à son terme, l'état peut être quitté si une des transitions est
A [X]
franchissable. C'est une transition automatique B
Do: Activité séquentielle

Etat A [ not X ]
C
Do: Une opération
103 104
 Diagramme E/T du distributeur automatique des
Points d’exécution des opérations boissons
6 façons d'associer une
opération à une transition: Pièces insérées (montant) / régler montant
Encaissement d’argent
/ Op1 En attente
◦ l'action associée à la transition
do : augmenter le montant
d'entrée (Op1) Un état
entry: Op2 [article vide] Article sélectionné [montant <
◦ l'action d'entrée de l'état (Op2)
do: Op3 prix article]
◦ l'activité dans l'état (Op3) exit: Op4 Test d’article
on UnEvénement: Op5
◦ l'action de sortie de l'état (Op4) do : tester article et calculer
la monnaie à rendre
◦ l'action associée aux événements / Op6
[montant = prix article]
internes (Op5) [montant > prix article]

◦ l'action associée à la transition de Distribution Encaissement

sortie de l'état (Op6) do : distribuer article do : rendre monnaie

105 106

Généralisation d’états Généralisation d’états

 Un état peut être décomposé en plusieurs sous-états  Les transitions d'entrée ne sont pas
disjoints; les sous-états héritent des caractéristiques de
héritées par tous les états, seul un état
leur super-état
 Décomposition disjonctive: l'objet doit être dans un seul peut être cible de la transition
B
sous-état à la fois B1
E1 AB A B A
A B
E1
A B
E2 E2 B2
C E2

C L'état B est divisé en deux sous-états B1 et B2. La transition d'entrée dans l'état B doit être
AB est un super état dont A et B sont des sous-états
reportée directement sur un des sous états.
Cette généralisation permet de factoriser la transition E2

107 108
Généralisation d’états Généralisation d’états
 Il est préférable de limiter les liens entre Exemple: boîte automatique de transmission

niveaux hiérarchiques d'un automate en passer à M

Point mort Marche arrière
définissant systématiquement en état passer à P
passer à Avant passer à Point mort
initial pour chaque niveau
Marche Avant
augmentation vitesse augmentation vitesse
stop
Première Deuxième Troisième
B réduction vitesse
réduction vitesse
A B1

La généralisation d'état permet de mettre en facteur les deux transitions

B2 'passer à Avant' et 'passer à Point mort'
109 110

Agrégation d’états Agrégation d’états

 L'agrégation d'états est la composition d'un état à partir de plusieurs
autres états indépendants
 La composition est de type conjonctive ce qui implique que l'objet
Exemple: activité d’émission des billets
doit être simultanément dans tous les états composant l'agrégation
d'états
 Forme de parallélisme entre automates Emission
S
T U
prêt do : distribuer billets billets pris
X E1 Préparation
Accueille

A do : éjecter carte carte prise

E3 Y

E2 E1 E4[ in Z ]
Z

B
111 112
 Diagramme d'activités Gardes
 Les transitions entre activités peuvent être gardées par des
 Variante des diagrammes d'états-
conditions booléennes, mutuellement exclusives. Les gardes sont
transitions, ce diagramme met l'accent sur des labels des transitions dont elles valident le déclenchement

les activités, leurs relations et leurs Mesurer la

[trop froid] température [trop chaud]

impacts sur les objets Chauffer Refroidir

E1
 Une condition peut être matérialisée par un losange d'où
Activité sortent plusieurs transitions
do: Activité
Mesurer la
Activité finie température

[trop froid] [trop chaud]

E2
113 Chauffer Refroidir 114

Synchronisation Diagramme d'activités

 Les diagrammes d'activités peuvent être découpés en couloirs
 Les diagrammes d'activités représentent
d'activités pour montrer les différentes responsabilités au sein d'un
les synchronisations d'activités au moyen mécanisme logiciel ou d'une organisation. Chaque responsabilité est
assurée par un ou plusieurs objets et chaque activité est allouée à un
de barres de synchronisation couloir donné
Enseignant Étudiant Jury
Refroidir Arrêter le
Aérer Enseigner
chauffage

Apprendre

Arrêter le Mesurer la Contrôler les Composer

Aérer
chauffage température connaissances

Évaluer
115 116
 Objets dans un diagramme d'activités Etats et événements
 Il est possible de faire apparaître des objets dans un diagramme
 Les diagrammes d'activités peuvent faire
d'activités, soit au sein des couloirs d'activités, soit ien dehors de ces
couloirs référence à des états et à des événements
Client Vendeur Expédition

Ouvrir la
Se renseigner Établir un devis fenêtre

Commande ^Thermostat.DonnerUneConsigne
Commander [passée]
Aérer
Facturer Bon de
Consigne atteinte
livraison
Fermer la
Commande fenêtre
Payer Livrer
[payée]
117 118

Diagramme de composants
 Un diagramme de composantes présente
la vue statique de l'implémentation d'un
système
DIAGRAMME DE
COMPOSANTS

119 120
Composante Nommer une composante
 Une composante est une partie physique  Chaque composante doit avoir un nom qui le

et remplaçable d'un système qui se distingue des autres composantes - Unicité du

conforme et réalise un ensemble nom complet (noms des packages englobant

d'interfaces. + le nom de la composante).

 En pratique les noms de composantes sont

des noms pris dans le vocabulaire de
l'implémentation et dépendant du ou des
systèmes d'exploitation utilisés.
121 122

Représentation graphique d'une

composante
Composantes et classes
 Une composante est l'implémentation
compartiment extra
composante
physique de classes.
agentfraude.dll
agent.java Réalise
AgentFraude
PolitiqueFraude
Recherche

valeur étiquetée
system::dialog.dll
{version = 4.1}

123 124
 Composantes et classes - Représentation
graphique
Composantes et interfaces
 Une interface est une collection de
composante
spécifications d'opérations qui définissent
relation de réalisation agentfraude.dll
le service rendu par une classe ou une
composante.

AgentFraude  Les interfaces représentent le ciment qui

Recherche

PolitiqueFraude lie les composantes entre elles

classe

125 126

Composantes et interfaces - Représentation

graphique
Remplacement de composantes
 L'intention de base des composantes est
composante
interface d'être capable d'assembler un système à
image.java component.java partir d'éléments remplaçables.

ImageObserver  Une composante est physique.

dépendance réalisation
«interface»  Une composante est une partie d'un système.
ImageObserver component.java
image.java
abort: int {static}  Une composante se conforme et réalise un
error: int {static}
ensemble d'interfaces.
imageUpdate()

127 128
Types de composantes Stéréotypes standards
UML distingue trois types de composantes : UML définit cinq stéréotypes pour les composantes :

 exécutable
 Composante de déploiement
spécifie une composante exécutable sur un nœud
Ce sont les composantes nécessaires et suffisantes pour
 librairie
construire un système exécutable.
spécifie un objet de type librairie statique ou dynamique
 Composante de réalisation
 table
Ce sont les composantes résultats du travail de
spécifie une table d'une base de données
développement (code source, fichier, ...)
 fichier
 Composante d'exécution spécifie un fichier qui contient du code source ou des données
Ce sont les composantes qui sont créées lors de l'exécution  document
d'un système spécifie une composante qui représente un document
129 130

Pour modéliser le code source Pour modéliser un exécutable

 Pour représenter la gestion de  Pour représenter la composition d'un
configuration des fichiers sources. exécutable.
signal.h signal.h signal.h chemin.dll collision.dll
{version = 3.5} {version = 4.0} {version = 4.1}

«parent» «parent»

driver.dll
{version = 4.3.5}
signal.c Idrive
interrupt.c
{version = 4.1}
ISelfTest

131 132
Pour modéliser une base de données Pour modéliser un système dynamique
 Pour représenter le schéma physique  Pour représenter le comportement
d'une base de données. physique d'un système dynamique.

université.db

La base de données est

répliquée sur le serveur
B

professeur département cours étudiant :université.db :université.db

{localisation = serveur A} {localisation = serveur B}

«copier»

133 134

Diagramme de dépoilement
 Un diagramme de déploiement présente la
configuration physique des ordinateurs et
périphériques ainsi que les composantes
DIAGRAMME DE qui s'exécutent.
DÉPOILEMENT

135 136
 Nœud Nommer un nœud
 Un nœud est un élément physique qui  Chaque nœud doit avoir un nom qui le
existe au moment de l'exécution et qui distingue des autres nœud - Unicité du
représente une ressource ayant des nom complet (noms des packages
possibilités d'exécution . englobant + le nom du nœud).
 En pratique les noms de nœuds sont des
noms pris dans le vocabulaire de
l'implémentation
137 138

Représentation graphique d'un nœud Nœud et composante

 Un nœud représente le déploiement
compartiment extra
nœud
physique des composantes.
kiosque_2 ventes
Déploie
 Un nœud exécute des composantes.
stock.exe
région.exe

serveur::sauvegarde valeur étiquetée

{réservéAdministration}

139 140
Nœuds et composantes - Représentation
graphique
Connexion
 Les associations entre nœuds représentent
nœud
ventes
les connections physiques tels une
relation de dépendance connexion Ethernet, un câble série, ou
encore un bus commun.

stock.exe région.exe

composante
141 142

Nœud et connexions - Représentation Pour modéliser les systèmes

graphique embarqués
 Pour modéliser la partie matérielle d'un
stéréotype
système.
port série
kiosque
«10-T Ethernet»
sonar «processeur» «RS232»
serveur carte mère
4
«RS232»

console
moteur moteur
connexion mouvement direction

M M
~ ~
143 144
 Pour modéliser les systèmes client-
Pour modéliser les systèmes distribués
serveur
 Pour modéliser l'implémentation de  Pour modéliser la topologie de systèmes
système client-serveur. distribués.
serveurs

:console
clients
2..* 4..* :serveur
«processeur» «processeur» régional
cache serveur
:Internet
kiosque Déploie Déploie
http.exe db.exe :console
console log.exe
:serveur
régional
:serveur :serveur
régional national
145 146

Standard UML et Éditeur Le standard UML …

 Le standard UML définit ce qu’est UML
 définit précisément tous les éléments UML
 Les éditeurs doivent être conformes au
standard et leurs relations : sémantique
 définit précisément une notation
 Pas de procédure de conformité
 Forte évolution des standards sans graphique pour chaque éléments :
compatibilité ascendante
notation

Qu’est ce qu’un outil UML standard ?

147 148
 Modéliser la sémantique Le méta-modèle UML

 Pourquoi ne pas faire un modèle représentant les éléments UML :

 Le standard UML définit de manière
Un méta-modèle pseudo formelle la sémantique des
generalization
concepts UML en fournissant le méta-
*
modèle UML
Package Class Opération
0..1 * 0..1 *
0..1 ◦ Plus de 50 concepts (méta-classes)
* ◦ Structuration en package (core, common
Attribut
behavior, …)
◦ Aucune présence des diagrammes
149 150

Le méta-modèle UML … Notation

 La notation est la partie visible du standard
 La sémantique des utilisateurs se base sur
la notation
 Le standard n’établit pas un lien précis
entre la notation et la sémantique

151 152
 Outil UML standard Objecteering
 Il est communément établie qu’un outil  Objecteering (version 5.2.2) est un outil
UML standard est un outil qui UML standard créé par la société
◦ Respecte intégralement la notation UML SOFTEAM
 Même si tous les diagrammes ne sont pas supportés ◦ Il permet l’élaboration de tous les diagrammes
◦ Dispose d’un format de représentation interne UML
compatible avec le méta-modèle UML standard ◦ Il dispose de son propre méta-modèle
 Le difficulté de ce point s’illustre avec XMI compatible avec le méta-modèle UML

153 154

Objecteering Le méta-modèle Objecteering

Explorateur
de modèles

Explorateur de
Zone d’élaboration
diagrammes
des modèles
155 156
Autres outils standards
 Rational Rose
◦ Outil de plus important du marché
◦ http://www.rational.com
◦ Racheté par IBM
 Together
◦ Outil fortement couplé avec Java
◦ http://www.togethersoft.com
◦ Racheté par Borland
 ArgoUML
◦ Outil Open Source
◦ http://argouml.tigris.org
 Visio
◦ Outil non complet de microsoft
◦ http://www.microsoft.com/office/visio

157