Processus et Systèmes d’Information - UML

Modélisation orientée objet - UML

et Initiation Java.

Enseignant : Marie Aimar,

Mail : aimar@[Link],

Modélisation orientée objet - UML – p.1

 Bibliographie

Les best-of :
Conception orientée objet et applications,
G Booch (Addison-Wesley, 1992).

Le génie logiciel orienté objet,I. Jacobson,

M. Christerson, P. Jonsson, G. Overgaard (Addison-Wesley, 1993).

Les outsiders :
Méthodes orientées objet, 2nd édition,
I Graham (thompson Publisher, 1997).

Analyse des systèmes : de l’approche fonctionnelle à

l’approche objet, Ph. Larvet (InterEditions, 1994).

Modélisation orientée objet - UML – p.2

 Bibliographie

Spécial UML :
UML La notation unifiée de modélisation objet,
M. Lai (Dunod, 2000).

Modélisation objet avec UML,

P.A. Muller (Eyrolles, 1998).

Les sites internet :

Index to Object-Oriented Information Sources
[Link] scg/OOinfo/[Link]

UML Resources
[Link] ou [Link]

Aspect-Oriented Programming Home Page

[Link] ou [Link] [Link]

Modélisation orientée objet - UML – p.3

 Objectifs du Cours

Architecture Logicielle :
Approcher les problèmes d’analyse et de conception
des systèmes informatiques (des programmes).
Au travers du filtre des méthodes orientées objet :
Unified Modeling Language.

Modélisation orientée objet - UML – p.4

 Combattre quelques idées reçues

Il existe une étape Analyse - Conception du logiciel

différente de l’analyse des besoins d’une entreprise (ou
d’un service).
Ne pas tenter de solutionner tous les problèmes d’un
service avec un seul logiciel. Apprendre à cerner
précisément le problème à traiter.
Les méthodes orientées objet ne sont pas faites ( et n’ont
pas prétendue être faites) pour traiter les problèmes
organisationels de management d’une entreprise ou d’un
service.

Modélisation orientée objet - UML – p.5

 Analyse des systèmes

1. Analyser un problème.
2. Proposer un modèle.
3. Concevoir un solution.
4. Réaliser (programmer) la solution.

Modélisation orientée objet - UML – p.6

 Schema classique - caricatural

Client Quel est le pb Gestion des stocks

à traiter ?

Identification des
Analyste Analyse taches à accomplir
cahier des charges
des données à manipuler

Conception d’un
Chef de Modèle conceptuel système informatique
projet répondant à la question

Programmeur Réalisation codage du programme

Modélisation orientée objet - UML – p.7

 Les erreurs de cette vision des choses

Vous n’interviendrez “jamais” sur un projet totalement

nouveau
Ignore les relations avec les autres applications de
l’entreprise : la gestion des stocks peut communiquer avec
la fabrication des marchandises, les commandes des
clients . . .
cloisonne les activités : organisation hiérarchique de
l’analyste au programmeur, le client n’a pas de contact
avec le réalisateur final.
Un client connait pas ses besoins.
✔Un système doit être facile à modifier, à enrichir de
nouvelles fonctionnalités.
✔L’architecture doit donc être modulaire et facile à main-
tenir.
Modélisation orientée objet - UML – p.8
 Développement en cascade

Cahier des charges

Expression des besoins
Formalisation
Spécifications
fonctionnelles
Conception
Conception Globale et
détaillée
Codage
Codage et
Validation
Execution
Résultats
Modélisation orientée objet - UML – p.9
 Développement Orienté Objet

Prise d’expertise / Lectures et mises à jour

Expression des
besoins

Conceptualisation

ANALYSE / Modifications
CONCEPTION DEVELOPPEUR

Réutilisation Modifications
classification des classes

IMPLEMENTATION
Interprétation
des classes/codages

Réutilisation
Instanciation
et execution RESULTATS

Modélisation orientée objet - UML – p.10

 Développement Orienté Objet

Conséquences de l’application des méthodes OO :

les phases d’analyse, de conception et de
programmation sont très liées.

Historique des méthodes orientées objet :

1. langages de programmation,
2. méthodes de conception,
3. méthodes d’analyse.

Modélisation orientée objet - UML – p.11

 Quelques repères

Age de l’invention :
1967 - le langage de programmation SIMULA.
1970 - SMALLTALK (Palo Alto).
Age de la confusion :
1980 - les langages ++.
Les méthodes de conception se multiplient
Age de la maturité:
1990 - Object Management Group : standardisation.
Unification des méthodes OMT (Booch) OOSE
(Jacobson) et Rumbaugh : Unified Modeling Language
(version 1.0 1997, version actuelle 1.3).

Modélisation orientée objet - UML – p.12

 Principes des langages orientés objet

Permettent d’exprimer la solution d’un problème à l’aide

des éléments de ce problème.
Les programmes manipulent des structures de données
représentant les différentes entités, les objets, du
domaine traité.
Dans ce contexte, Objet signifie élément de l’univers,
c-à-d : chose palpable et/ou visible, quelque chose qui
peut être appréhendée intellectuellement, quelque chose
vers qui la pensée ou l’action est dirigée.
Pour la conception de logiciels, un objet représente un
élément individuel, identifiable, soit réel, soit abstrait avec
un rôle bien défini dans le domaine du problème.

Modélisation orientée objet - UML – p.13

 Les concepts de base

Objets : unités de base organisées en classes et

partageant des traits communs (attributs ou procédures).
Peuvent être des entités du monde réel, des concepts de
l’application ou du domaine traité.
Encapsulation :
les structures de données et les détails de
l’implémentation sont cachés aux autres objets du
système.
La seule façon d’accéder à l’état d’un objet est de lui
envoyer un message qui déclenche l’exécution de l’une
de ses méthodes.

Modélisation orientée objet - UML – p.14

 Les concepts de base

Encapsulation :
Les types d’objets peuvent être assimilés aux types de
données abstraites en programmation.
Abstraction et encapsulation sont complémentaires,
l’encapsulation dressant des barrières entre les
différentes abstractions.
Héritage : chaque instance d’une classe d’objet hérite
des caractéristiques (attributs et méthodes) de sa classe
mais aussi d’une éventuelle super-classe. L’héritage est un
des moyens d’organiser le monde c.-à-d. de décrire les
liens qui unissent les différents objets.

Modélisation orientée objet - UML – p.15

 Les concepts de base

Polymorphisme : possibilité de recourir à la même

expression pour dénoter différentes opérations. L’héritage
est une forme particulière du polymorphisme
caractéristique des systèmes orientés objet.
Modularité : partition du programme qui crée des
frontières bien définies (et documentées) à l’intérieur du
programme dans l’objectif d’en réduire la complexité
(Meyers). Le choix d’un bon ensemble de modules pour un
problème donné, est presque aussi difificile que le choix
d’un bon ensemble d’abstractions.

Modélisation orientée objet - UML – p.16

 Faire des choix

Tom Jean Claire

Classe de personnes

Personnes

Quelles sont les caractéristiques - attributs - d’une

personne ?
Quels sont les comportements génériques - fonctions -
d’une personne ?

Modélisation orientée objet - UML – p.17

 Le type Personne

Classe Personne

Attributs Comportement

Age Stocker_Age
Femme Communiquer_Age
Ami Marcher
Adresse

Jambe Créer une instance

Tete
Bras

Classe Homme Classe Femme

Comportement Comportement

Sauter Sauter
Danser Danser

Modélisation orientée objet - UML – p.18

3 manières d’ajouter une classe Vieil Homme

Personne Personne
Stocker_Age Stocker_Age
Communiquer_Age Communiquer_Age

Danser Danser Danser Danser Danser

Sauter Sauter Sauter Sauter Sauter
Vieil Homme Homme Femme Homme Femme

Danser
Personne Sauter

Stocker_Age Vieil Homme

Communiquer_Age

Sauter Danser
Sauter
Homme Femme

Danser Danser
Vieil Homme Jeune Homme

Modélisation orientée objet - UML – p.19

 Trouver les bons objets

Méthode de désagrégation / agrégation :

désagréger un module ⇒ une suite de modules,
agréger une suite de modules ⇒ un module.

Désagrégation
On part d’un tout que l’on éclate en plusieurs parties.
Chaque partie, formant à son tour un tout, est
susceptible d’être à nouveau éclatée en parties plus
petites.
Il est difficile d’exprimer en décomposition logicielle ce
qu’est une partie.
La conception fait l’hypothèse que le système est un
tout. Pour détailler et exprimer la solution, on postule
que ce tout est composé de parties cohérentes
séparables. Modélisation orientée objet - UML – p.20
 Trouver les bons objets

Dans un premier temps, la décomposition est basée sur

les entités du domaine du problème.
La désagrégation est très différente de la décomposition
fonctionnelle puisqu’une fonctionnalité n’est pas une entité
du monde concret.
La granularité de la taille des entités à utiliser est un
facteur important de l’effort d’abstraction à réaliser.
Comment faire trouver les bons Objets ?
c.-à-d. :
1) comment trouver un objet ?
2) comment distinguer un bon objet d’un mauvais ?

Modélisation orientée objet - UML – p.21

 Quelques règles d´écriture d’un module

Un module représente un concept et tout le concept.

Pour représenter une idée, il faut que cette idée existe.
Ne pas regrouper dans un module des opérations qui
n’ont pas de raisons particulières d’être ensemble (écriture
de modules fourre-tout).
Pour concrétiser une idée le choix du nom du module est
un élément puissant d’expression (exemple les design
patterns).
Dans une première phase “simpliste” le choix des
méthodes correspond aux verbes.

Modélisation orientée objet - UML – p.22

 Un exemple.. enfin !

distribuerLeCourrier()

leFacteur : Facteur

1 : recupererLeCourrier()
2 : distribuerLeCourrier()

particulier : Particulier laPoste : Poste

Modélisation orientée objet - UML – p.23

 Objets et Classe d’objets

Objet = Etat + Comportement + Identité

Conventions graphiques de UML

Identité Produit Marteau

Prix 25
Attributs Bricolo
Fabriquant
Afficher() Afficher()
Méthodes
CalculerPrix() CalculerPrix()

printf(prix);

Les classes abstraites sont représentées uniquement par

leur nom dans un rectangle. Il est possible de faire appa-
raitre le mot abstract sous ce nom.
Modélisation orientée objet - UML – p.24
 La composition d’objets - 1

Les attributs d’un objet peuvent être eux-même des objets.

La composition par valeur : la construction d’un objet
physique implique la construction de ses attributs par
valeur.

Stock Stock

produit Produit entrepot Entrepot

produit
Produit
entrepot Entrepot
dateMiseaJour Date

dateMiseaJour Date

Modélisation orientée objet - UML – p.25

 La composition d’objets - 2

La composition par référence : c’est un lien de

référence qui peut être partagé par plusiseurs objets.

Camion Chauffeur

La construction du conteneur n’implique pas la

construction de l’objet référencé.
NB : le losange se place du coté de l’objet référençant.

Modélisation orientée objet - UML – p.26

La visibilité des attributs et des méthodes

Publique : un attribut ou une méthode publique est

spécifée avec le signe +.
Privée : un attribut ou une méthode privée est spécifée
avec le signe -.
Protected : un attribut ou une méthode protégée est
spécifée avec le signe #.

Modélisation orientée objet - UML – p.27

 Signature

La signature d’une méthode se compose de :

son nom,
le nombre et le type de ses paramètres en entrée,
Exemple :
public void afficher(String , Integer);

Dans un espace défini (le même espace de noms), deux

méthodes peuvent avoir le même nom si elles n’ont pas la
même signature.

Modélisation orientée objet - UML – p.28

 Représentation de l’héritage

Héritage simple
Véhicule

Aérien Terrestre Marin

Héritage multiple
Tapis Véhicule

Aérien Terrestre Marin

TapisVolant

Modélisation orientée objet - UML – p.29

 Héritage multiple inclusif

Véhicule

Propulsion Inclusif Milieu

A voile A moteur Terrestre Marin

Pétrolette
Mélange
de 2 dimensions

Modélisation orientée objet - UML – p.30

 Un exemple

Contexte :
Un utilisateur d’interface graphique compose des dessins
complexes à partir d’éléments simples tel que les carrés,
les rectangles . . . Une représentation simple définit des
classes primitives graphiques telles que Texte, Ligne . . . et
quelques autres classes classes jouant le rôle de
containers.
Problème :
Cette approche ne permet pas de traiter de façon
identique les objets containers et les objets primitives alors
que l’utilisateur les traite de la même manière.

Modélisation orientée objet - UML – p.31

 L’exemple du pattern Composite

Composant

opération()
ajouter(Composant)
supprimer(Composant)
acqEnfant(int)

Enfants
Feuille Composite
opération() Pour tout g de enfants
opération()
ajouter(Composant) g,operation()
supprimer(Composant)
acqEnfant(int)

Modélisation orientée objet - UML – p.32

 Association de classes

Les liens d’association doivent être portés sur une classe

pas sur les champs (instances).
Stock Stock
Liste

produit listeProduits ListeProduits

Produit

Produit
entrepot Entrepot
entrepot Entrepot
dateMiseaJour Date
dateMiseaJour Date

Modélisation orientée objet - UML – p.33

 Arité d’une association

1 1 est une seule

0..1 0 ou 1 association
M..N de M à N (M et N entiers naturels)
⋆ de 0 à plusieurs
0..⋆ de 0 à plusieurs
1..⋆ de 1 à plusieurs

Modélisation orientée objet - UML – p.34

Marquer les arités dans le diagramme de classe

leFacteur : Facteur leCourrier:Courrier

1..N 1 1

0..N
laPoste : Poste
0..N
1..N
lesBoitesAuxLettres: BoitesAuxLettres

1
0..1
particulier : Particulier

Modélisation orientée objet - UML – p.35

 Les contraintes

Il est possible de préciser les contraintes d’une association

directement sur le diagramme de classe.

Stock Stock
Liste

produit listeProduits ListeProduits

Produit
Produit
entrepot Entrepot {ordonné}
entrepot Entrepot
dateMiseaJour Date
dateMiseaJour Date

Modélisation orientée objet - UML – p.36

 Les contraintes - 2

Les liens d’héritage peuvent aussi être étiquetés par des

contraintes.
Personnel
Complet
Disjoint

Cadre Non-Cadre Stagiaires Autres

Modélisation orientée objet - UML – p.37

 Les Méta-Classes

Définition :
Une méta-classe définit les caractéristiques d’une
classe, c’est un modèle générique de classse (attribut
ou comportement).
Exemple :
classe abstraite, interface, par extension (abus de
langage !) toute classe d’une classe.
On notera qu’une méta-classe est également un objet
dont la classe est la classe de base de référence à partir
de laquelle tous les objets du système sont construits
(classe Object en Java).
A l’étape d’analyse et de conception, il n’existe pas de
différence entre une classe et une méta-classe.

Modélisation orientée objet - UML – p.38

 Les Méta-Classes

<<abstract>>
Object

Véhicule

Terrestre Aérien Marin

Modélisation orientée objet - UML – p.39

 Représentation des Paquetages

Service

Clients
Gestion

Client

Traitement
Etablissement Compte
Banque

<<import>>
Communication
Sauvegarde
Réseaux
Persistance

Modélisation orientée objet - UML – p.40

 Représentation de modules

Les modules sont des unités de compilation. Certains

langages de programmation n’ont aucune correspondance
avec ce concept.

Gestion de

Compte
Clients

Modélisation orientée objet - UML – p.41

 Le diagramme de classes

Le diagramme de classe est une vue statique du modèle.

Il décrit la structure interne des classes et leurs relations
(dépendances, héritage, composition . . . ) .
Les termes : static structural diagram et class diagram
sont équivalents dans la terminologie UML.
Il est une collection des éléments du modèle déclaratif.
Ces éléments sont classifiés grâce au mécanisme de
typage.

Modélisation orientée objet - UML – p.42

 Le diagramme d’objets

C’est le graphe des instances des différentes classes

d’objets.
Il est lui-même une instance du diagramme de classes.
Il sert uniquement à illustrer des exemples.

Modélisation orientée objet - UML – p.43

 Classifier

Il est également possible de construire un diagramme qui

ne contient que les interfaces et les classes abstraites. On
parle alors de Méta-modèle.

Modélisation orientée objet - UML – p.44

 Type vs Implementation

Une classe peut-être spécialisée par des classes

d’implémentation ou de typage.
Un type se caractérise par un rôle (modifiable) qu’un
objet peut adopter puis abandonner.
Une implémentation définit la structure de données
physique et les procédures qui caractérisent un objet.
Un objet peut avoir plusieurs types (qui peut être changé
dynamiquement) mais une seule implémentation.
NB : si leur usage est différent, leur structure interne est
identique.

Modélisation orientée objet - UML – p.45

 Type vs Implementation

<<type>> <<implementation>>
Collection HashTable

<<type>> <<implementation>>
Ensemble HashTableEnsemble
elements : Collection elements : Collection

addElement(Object) addElement(Object)
removeElement(Object) removeElement(Object)
testElement(Object):Boolean testElement(Object):Boolean
setTableSize(Integer)

Modélisation orientée objet - UML – p.46

 Les Modèles UML

La modélisation proposée par UML est définie par un

Méta-modèle indépendant du formalisme de
représentation.
Un modèle peut caractériser :
Un niveau d’abstraction : passer graduellement des
spécifications externes du système à une solution
informatique concrète.
Une phase du cycle de vie de développement :
organisation du développement.
un niveau métier du domaine d’application : connexion
avec le vocabulaire du domaine.
des différentes vues du modèle objet final à obtenir :
classification des modèles (fonctionel, structurel,
temporel).
Modélisation orientée objet - UML – p.47
 a
Cas d’utilisation

Problème :
Les besoins d’un système (cf cahier des charges) sont
souvent exprimés de manière non structurée, sans forte
cohérence (imprécision, oublis, contradictions).

Récepteur de dépots

Panneau client Imprimante à recu

Elt[0..n]

Base de recu Elt déposés

Hérite

Boite Cageot
Bouteille
Modélisation orientée objet - UML – p.48
 Le modèle des cas d’utilisation

Les fonctions du système sont représentées au travers des

Cas d’utilisation.
Représentation des interactions entre le système et
l’extérieur.
Permettent de définir les limites du système et les
relations entre le système et l’environnement.
Décrivent le comportement du système du point de vue
d’un utilisateur, les acteurs.
La structuration de la démarche s’effectue par rapport aux
interactions d’une seule catégorie d’utilisateurs à la fois.
Les acteurs sont représentés comme des classes mais
ne font pas partie de la solution objet à réaliser.

Modélisation orientée objet - UML – p.49

 Le modèle des cas d’utilisation

Les cas d’utilisation sont repésentés à partir d’un

diagramme conceptuel ou diagramme des cas
d’utilisation.
Ce diagramme représente une sorte de diagramme de
communication, de flux d’évènements ou de données
entre des entités externe et le système à concevoir.
Une fois les objets identifiés et décrits, on peut
exprimer comment ces objets participent au cas
d’utilisation.

Modélisation orientée objet - UML – p.50

 Représentation UML

Distributeur Automatique de Billets

effectuer un
virement gérer le <<acteur>>
<<acteur>> distributeur Banque
client
retirer une
somme d’argent
effectuer la
<<acteur>>
maintenance
employé
consulter un
compte

Modélisation orientée objet - UML – p.51

 Descripton d’un cas d’utilisation

l’identification et la représentation graphique d’un cas

d’utilisation donne une connaissance sur l’interface externe
du système.
La description détaillée peut être donnée sous forme de
diagrammes de séquences qui modélisent les échanges
de messages entre les objets.
Dans ce cas, seulement 2 catégories d’objets : les
acteurs externs et et les composants qui interagissent
directement avec les acteurs.

Modélisation orientée objet - UML – p.52

 Diagramme de collaboration

Le diagramme de collaboration montre simultanément les

interactions entre les objets et les relations structurelles
qui permettent ces interactions.
La numérotation donne l’ordre d’envoi des messages.
Le temps n’est pas représenté.

:Ascenseur
1 monter

:Cabine 3 fermer

:Porte
2 allumer

:Lumière Modélisation orientée objet - UML – p.53

 Diagramme de collaboration - 2

Exprime le contexte d’un groupe d’objets (liens entre

objets) et l’interaction entre ces objets (envoi de
messages).
Une interaction est réalisée par un groupe d’objets qui
collaborent en échangeant des messages.
Ces messages sont représentés le long des liens qui
relient les objets avec des flêches orientées vers le
destinataire du message.
Est une extension du diagramme d’objets.
Permet la représentation d’un acteur, élément externe au
système (le premier message est envoyé par l’acteur).
Ne pas confondre ces liens avec ceux de composition des
diagrammes de classes ou d’objets.
Modélisation orientée objet - UML – p.54
 Diagramme de séquence

<<actor >> <<actor>>

client:Client dab:DistributeurAutomatique

afficher message accueil

introduire carte banquaire
demander mot de passe
introduire mot de passe
demander type operation
introduire demande retrait
demander montant
introduire montant
afficher message billets a retirer
distribuer billets
retirer billets
restituer carte
retirer carte
afficher message fin operation

Modélisation orientée objet - UML – p.55

 Diagramme de séquence

Montrent des interactions entre objets selon un point de

vue temporel.
Pas de représentation explicite du contexte des objets.
Notation a :
Un objet est matérialisé par un rectangle est une barre
verticale appelée ligne de vie

unObjet

a
Object Message Sequence Chart, Siemens Pattern Group. Wiley 1996
Pattern-riented Softawre
Modélisation orientée objet - UML – p.56
 Diagramme de séquence - 2

L’ordre d’envoi d’un message est donné par la position

sur l’axe vertical.

unObjet objet2 objet3

un message

un autre message

Modélisation orientée objet - UML – p.57

 Diagramme de séquence - utilisation

Deux utilisations possibles :

Documentation des cas d’utilisation : description des
interactions entre objets sans détails de synchronisation.
Les flèches correspondent à des événements qui
surviennent dans le domaine de l’application. Pas de
distinction entre flots de contrôle et flots de données.

appelant ligne appelé

téléphonique
décroche

tonalité
numérotation
indication de sonnerie sonnerie
décroche
Modélisation orientée objet - UML – p.58
allo
 Diagramme de séquence - utilisation - 2

Représentation précise des interactions entre objets.

le concept de message unifie toutes les formes de
communication : appel de procédures, événemnt
discret, signal de flots, interruption matérielle . . .

objeta objetb objeta objetb

message synchrone un message

message asynchrone

objeta

message
réflexif
Modélisation orientée objet - UML – p.59
 Diagramme de séquence - utilisation - 3

Un message réflexif peut aussi être un point d’entrée

dans une activité qui s’exerce au sein d’un objet (par
exemple composite).

objet composite composant a composant b

point
d’entrée

Modélisation orientée objet - UML – p.60

 Diagramme de séquence - utilisation - 4

Création et destruction d’un objet.

objet a

créer
objet b

détruire

Modélisation orientée objet - UML – p.61

 Diagramme de séquence - utilisation - 5

Représentation des périodes d’activité des objets = temps

pendant lequel un objet effectue une action.
le début et la fin de la bande rectangulaire correspondent
au début et à la fin d’une période d’activité.

objet a

activation

Modélisation orientée objet - UML – p.62

 Diagramme de séquence - utilisation - 6

Les digrammes de séquence permettent également de

représenter les périodes d’activité des objets.

A B

retour
implicite

Modélisation orientée objet - UML – p.63

 Diagramme de séquence - utilisation - 7

Dans le cas d’envoi asynchrone, le retour doit être

signalé.

A B

retour
explicite

Modélisation orientée objet - UML – p.64

 Diagramme de séquence - utilisation - 8

Cas des messages récursifs

appel
récursif

Modélisation orientée objet - UML – p.65

 Mode centralisé - Mode décentralisé

Les diagrammes de séquences reflètent le choix des

structures de controle.

A B C D

Modélisation orientée objet - UML – p.66

 Mode centralisé - Mode décentralisé

Envoi décentralisé de messages.

A B C D

Modélisation orientée objet - UML – p.67

Expression des contraintes temporelles

A B C

x
{y-x <3s}
y
{z-y < 1s} z
t
{t’-t <2s}
t’

Modélisation orientée objet - UML – p.68

 Boucles et branchements

A B A B

while X message *[X]message

loop
end loop

Modélisation orientée objet - UML – p.69

 Branchement Conditionnel

A B C A B C

if X message [X]message

else message2
non[X]message2

Modélisation orientée objet - UML – p.70

 Les diagrammes de collaboration

Rôle :
Ils montrent les interactions entre les objets.
Ils expriment le contexte d’un groupe d’objets.
Ils sont des extensions du diagrammes d’objets.
Une interaction est réalisée par un groupe d’objets qui
collaborent en échangeant des messages.
Ces messages sont représentés le long des liens qui
relient
les objets avec des flêches orientées vers le destinataire
du message.

Modélisation orientée objet - UML – p.71

 Les diagrammes d’états-transitions

Visualisent des automates déterministes a .

On relie l’automate à la classe considérée. On ne
représente pas les automates des objets qui ne changent
pas (ou peu) d’état.

classe automate

a
formalisme de Harel, D. 1987. Statecharts : a Visual Formalism for Complex
Systems. Science of Computer Programming vol 8.

Modélisation orientée objet - UML – p.72

 Les diagrammes d’états-transitions - 2

Un objet est à tout moment dans un état donné.

L’état d’un objet est constitué des valeurs instantanées de
ses attributs.

Etat intermédiaire
Etat initial Etat final

Modélisation orientée objet - UML – p.73

 Les diagrammes d’états-transitions - 3

L’objet passe d’un état à un autre par les transitions.

Déclenché par un événement, les transitions permettent
le passage d’un état à un autre instantanément.

+de 60 ans
en activité

perte embauche retraite

d’emploi

chomage
+de 60 ans

Modélisation orientée objet - UML – p.74

 Les événements

La syntaxe d’un événement dans un diagramme est la

suivante :
Nom_événement ( Nom_paramètre : type, ...)[condition]
condition est la garde qui valide ou non le déclenchement
d’une transition quand l’événement s’est produit.
On peut associer à chaque transition une action à
exécuter lors du franchissement dû à un événement. Les
spécifications de l’action sont contenues dans l’objet
destinataire.
Exemple : l’événement il fait trop chaud entraîne
la climatisation ou l’ouverture des fenêtres selon la saison.

il fait trop chaud[été] il fait trop chaud[hiver]

Modélisation orientée objet - UML – p.75
climatiser aérer
 Les événements

Il est possible de préciser les actions à exécuter lorsque

l’on est dans un état donné, en entrant ou en sortant.
Pour cela UML donne plusieurs mots-clés :
entry : action à exécuter dès l’entrée dans l’état.
exit : action à exécuter lors de la sortie de l’état.
on : action interne provoquée par un événement qui ne
provoque pas le passage à un nouvel état.
do :activité à exécuter (une activité est une action dont
le temps d’exécution est non négligeable).

Modélisation orientée objet - UML – p.76

 Exemple d’un diagramme d´états

fermer(écranPaiement)

ouvrir(écranPaiement)
en attente annulation
entry / ouvrir(écranAccueil)
exit / fermer(écranAccueil)

en attente de sélection
en cours de paiement
entry / ouvrir(écranSélection)
exit / fermer(écranSélection)
ouvrir
(écranPaiement)

choix effectué choix invalide

entry / ouvrir(écranDistribution)
exit / fermer(écranDistribution)

ouvrir(écranHorsService)
Modélisation orientée objet - UML – p.77
 Généralisation d’états

Pour remédier au problème de l’explosion du nombre des

états et de leur connexions, il est possible de définir des
super-classes d’états et des sous-classes qui en
héritent. La démarche d’abstraction est identique à la
généralisation/spécification des classes.
Un état peut-être décomposé en plusieurs sous-états
disjoints (ou-exclusif), un objet ne peut-être que dans un
seul état à la fois.

t1
A B t1
A B

t2 t2
t2
C
C

Modélisation orientée objet - UML – p.78

 Généralisation d’états - 2

Un sous-état hérite des variables d’états et de transitions

externes de sa super-classe.
Un seul état (le super-état ou un des sous-états) hérite
des transitions d’entrée car un seul état peut-être la cible
d’une transition.
Si la décomposition a pour objectif de définir un état
particulier pour le traitement d’une transition interne, cette
transition ne fera pas l’objet d’un héritage.
Cas d’une décomposition qui rompt la barrière
d’asbtraction :
A B
A B1

B2
Modélisation orientée objet - UML – p.79
 Solution

Représentation simplifiée
B

A B1
A B
C
B2

Modélisation orientée objet - UML – p.80

 Agrégation d’états

L’agrégation d’états est un état composé de plusieurs

automates qui évoluent simultanément et
indépendamment.

evt3
U W

evt1 evt2
X
Z
evt4
Y

Modélisation orientée objet - UML – p.81

 Agrégation d’états - 2

Prendre un module
Incomplet

Fabriq1 1-fait Fabriq2 2-fait

Validé

ProjetFini projet fait

ok
TestFinal

échec
Rejeté

Modélisation orientée objet - UML – p.82

 Transitions complexes

DemandeParamC MAJCouleurs

Démarrage Rafraichisseme
DemandeParamP MAJPosition

Modélisation orientée objet - UML – p.83

 Décisions

[cout <$50] débiter

le client

calculer
cout total

demander
[cout >=$50] autorisation

Modélisation orientée objet - UML – p.84

 Diagrammes d’activités

consomateur vendeur stock

demande
service

prendre
payer commande
remplir
commande

délivrer
commande
prendre
commande

Modélisation orientée objet - UML – p.85

 Action et Objets

Consomateur Vendeur Stock

demande
service

commande
[passée]

prendre
payer commande commande
[en stock]

remplir
commande commande
[délivrée]

délivrer
commande commande
[délivrée]

récuperer
commande
Modélisation orientée objet - UML – p.86