Contenu

Chap. 1 : Introduction
Chap. 2 : Approche objet
Chap. 3 : Présentation d’UML
Chap. 4 : Diagramme de cas d’utilisation
Chap. 5 : Diagramme d’activité
Chap. 6 : Diagrammes de séquence
Chap. 7 : Diagramme de classes
Chap. 8 : Diagramme d’objets
Chap. 9 : Diagramme d’états-
d’états-transitions

S. MBARKI 2
 CHAPITRE 1
Introduction

S. MBARKI 3
Le logiciel

Le système d’information d’une entreprise est composé

de matériels et de logiciels
Les investissements dans ce système d’information se
répartissent :
20% pour le matériel
80% pour le logiciel
Un logiciel est un ensemble de programmes qui
assurent des fonctions bien déterminées
Logiciel de gestion de scolarité, logiciel de comptabilité
Un logiciel peut être développé par une personne ou
bien par une équipe suivant sa taille
S. MBARKI 4
Pourquoi le génie logiciel ?
Programmation à petite échelle
Programmation individuelle de petits programmes
Algorithmique,, langages de programmation,
Algorithmique programmation, structures de
donnés
Peu méthodologique : analyse déscendante
Programmation à grande échelle
Travail en équipe sur des projets longs et complexes
Traduction du cahier de charges en spécifications précises
Dialogue avec client/utilisateur
client/utilisateur (ouverture vers d'autres
domaines))
domaines
Besoins : gestion de projet,
projet, organisation,
organisation, outils,
outils, théories,
théories,
méthodologies et techniques
à Démarches d’ingénierie : génie logiciel

S. MBARKI 5
Génie logiciel
Définition
Méthodes et outils de production en équipe d’un logiciel complexe et
à multiples versions
Logiciel : ensemble de documents d'analyse,
d'analyse, de conception et de
programmes et documents de tests.
Le génie logiciel comporte également des aspects de gestion de
projets pour maîtriser le coût du logiciel,
logiciel, ses délais et les risques
associés.. Le logiciel doit donner satisfaction aux clients.
associés
Programmation vs Génie logiciel
Programmation : activité personnelle
Génie logiciel : activité d’équipe
La partie programmation n’occupe qu’entre 10% et 30% de l’effort
total du cycle de vie.
S. MBARKI 6
Cycle de vie d’un logiciel

Il décrit les différentes étapes du processus de

développement d’un logiciel, depuis le cahier des
charges jusqu’à la fin d’exploitation.
Le cahier des charges désigne les caractéristiques du
système et les services demandés du point de vue client
On distingue deux types de cycle de vie :
C.V linéaire et C.V itératif

S. MBARKI 7
Les étapes du cycle de vie
Expression des besoins et analyse
Les fonctionnalités du système et les contraintes sont établies en
consultant les utilisateurs. Elles doivent être définies de façon
compréhensible à la fois pour les clients et les développeurs.
• Les besoins sont structurés par les cas d’utilisation.
• L’analyse sert à comprendre la forme interne du logiciel et est structurée
par la réalisation des cas d’utilisation en définissant les classes d’analyse.
Conception du système
Processus à plusieurs étapes et qui consiste à représenter les
diverses fonctions du système d’une manière qui permettra d’obtenir
un ou plusieurs programmes réalisant ces fonctions.
Met le point sur trois propriétés : Architecture du logiciel, structures
de données et le détail procédural
S. MBARKI 8
Les étapes du cycle de vie (suite)
Réalisation et tests unitaires
Réaliser un ensemble d’unités de programme écrites dans un
langage de programmation.
Les tests unitaires permettent de vérifier que les unités de
programme répondent à leurs spécifications
Tests d’intégration
On intègre les unités de programme et on réalise des tests
globales pour être sûr que les besoins ont été satisfaits
Maintenance
Plus longue étape du cycle de vie. Elle consiste à :
• Corriger les erreurs non découvertes lors des étapes précédentes
• Adapter le système aux nouveaux besoins
S. MBARKI 9
Cycle de vie (cascade)

Cycle de vie linéaire sans aucune évaluation entre le

début du projet et la validation

Analyse

Conception

Réalisation

Tests

Maintenance

S. MBARKI 10
Cycle de vie (spirale)
Flexibilité
modification des spécifications = nouvelle itération
Processus adapté à la modélisation objet

S. MBARKI 11
 CHAPITRE 2
Approche objet

S. MBARKI 12
Développement procédural

La réalisation d'un logiciel passe par plusieurs étapes :

Le développement constitue la première partie
La deuxième étape constitue la maintenance (corrective
ou évolutive) et qui occupe 70% du coût total du logiciel
La construction d'un système informatique se résume
par la formule : Algorithmes + structures de données =
Programme
En programmation procédurale, la structure du système
est basée sur la procédure (fonction)
S. MBARKI 13
Structure d’un programme procédural

Les logiciels sont composés de :

Données représentant les éléments manipulés
Une hiérarchie de fonctions
Découpage de l’application en fonctions :

S. MBARKI 14
Inconvénients de l’approche procédurale

Les modules trouvés sont adaptés uniquement au

problème posé
Dissociation entre données et fonctions
Les structures de données se trouvent partagées entre
plusieurs fonctions
Interdépendance des fonctions
D'où la difficulté de maintenance du système

S. MBARKI 15
Structure d’un programme objet

Les objets sont des entités autonomes qui collaborent

afin de fournir les fonctionnalités du système

objet1
Interaction
objet2

objet4 objet3
Interaction

S. MBARKI 16
Avantages du Concept Objet

L'orientation objet permet de modéliser le système sous

forme d'objets interagissant les uns avec les autres
Approche plus proche de la réalité étant donné que notre
environnement est constitué d'objets tels que : les
personnes, les voitures, les maisons, …
Des programmes structurés en objets sont faciles à
comprendre
Les objets sont indépendants les uns des autres grâce au
principe d'encapsulation (la communication entre objets
est limitée à leur interface) d'où la recherche et la
localisation des erreurs est simplifiée
Le principe de réutilisabilité et d'extensibilité est assuré
par le principe d'héritage et d'agrégation
S. MBARKI 17
Acteur principal : objet

En programmation procédurale, on a :
des données, qui sont passifs
Des fonctions, qui peuvent manipuler ces données
Un objet contient à la fois des propriétés et des
opérations qui manipulent ces propriétés.
un objet est actif
chaque objet est responsable de ses propres propriétés.
L’objet : est une entité fondamentale qui regroupe des
propriétés--opérations.
propriétés

S. MBARKI 18
Un objet a un état

Un objet contient à la fois des données et des méthodes

qui manipulent ces données
les données représentent l'état de l'objet
les données peuvent également décrire les relations entre
cet objet et les autres objets
Exemple : CompteBancaire a :
un solde (l'état interne du compte)
Un propriétaire (un objet représentant une personne)

S. MBARKI 19
L'encapsulation

Principe d'encapsulation :
Réunir à l’intérieur d’une même entité les données et
les méthodes
Abstraction des données : la structure d’un objet n’est
pas visible de l’extérieur, son interface est constituée
de messages invocables par un utilisateur, la réception
d’un message déclenche l’exécution de méthodes
Abstraction procédurale : du point de vue de
l’extérieur, on n’a aucune information sur la définition
de la méthode
S. MBARKI 20
L'agrégation

L'agrégation est une association entre deux classes qui

traduit la relation « appartenir à" ou « faire partie
de"
Exemple moteur
voiture

chassis

Les attributs sont des objets appartenant à d'autres

classes (objets membres)
Couplage fort entre abstractions (classes)
S. MBARKI 21
Hiérarchie des classes

Permettent de gérer la complexité des applications en

ordonnant les objets au sein d’arborescence de classes
d’abstraction croissante. Les classes descendantes
héritent des propriétés des classes ancêtres
(Généralisation--Spécialisation)
(Généralisation
La généralisation permet la création de classes de base
regroupant les propriétés et les comportements communs
aux classes dérivées (factorisation).
La spécialisation permet la création de sous-
sous-classes afin
d’ajouter ou modifier certaines propriétés ou méthodes
définies dans les classes de base
S. MBARKI 22
Le polymorphisme

Une même opération peut se traduire différemment selon

l’objet sur lequel elle s’applique.
Objectif du polymorphisme: Pouvoir exécuter un message
par un objet dont le type varie de façon dynamique.
Le système doit déterminer dynamiquement l’implantation
de l’opération à exécuter.
Synonyme : Liaison dynamique :
Simplicité : Pas besoin de distinguer les cas selon les
classes.
Evolution : Programmes facilement extensibles
(Héritage+Redéfinition)
S. MBARKI 23
 CHAPITRE 3
Présentation d’UML

S. MBARKI 24
Méthodologies d'analyse et de conception

Les premières méthodes d'analyse (années 70)

Découpage hiérarchique fonctionnel du système (SADT)
L'approche systémique (années 80)
Modélisation des données + modélisation des traitements
(Merise)
L'approche objet (1990-
(1990-1995) : l’important ce sont les
objets
Objet = données + traitements
début 1990 : Premières générations des méthodologies objets
Permet une analyse beaucoup plus fine que l’approche
fonctionnelle
Prolifération des méthodes: 1990
1990--1995: plus de 50 méthodes
objets (OOA/OOD, HOOD, OMT, OOSE, FUSION, …)
S. MBARKI 25
UML : fusion de notations

UML : un langage de modélisation standard proposé par

OMG (Object Management Group) en 1997
UML est une fusion et une synthèse des méthodes
dominantes :
OOA/OOD de G. Booch
OMT (Object Modeling Technique) de Rumbaugh
OOSE (Object
(Object--Oriented Software Engineering) de Jacobson
Autres (statecharts de Harel,
Harel, design by contract de Meyer, …)
…)
UML est un ensemble de notations orientées-
orientées-objet, dont la
syntaxe et la sémantique sont (assez) précisément définies
UML : peut être utilisé à toute étape du cycle de vie
d’un logiciel mais UML n'est pas une méthode
S. MBARKI 26
UML est un langage

langage = syntaxe + sémantique

syntaxe = notations graphiques consistant
essentiellement en des représentations conceptuelles d’un
système
sémantique = sens précis pour chaque notation
UML Notation Guide – définit la syntaxe graphique
d'UML
UML Semantics – définit la sémantique d'UML
http://umlcenter.visual--paradigm.com/umlresources
http://umlcenter.visual paradigm.com/umlresources//

S. MBARKI 27
UML est un langage de modélisation

Qu’est qu’un modèle?

Un modèle est une simplification de la réalité
Pourquoi modéliser?
Mieux spécifier/comprendre la structure et le
comportement souhaités du système
Mieux communiquer avec le client
Documenter les décisions prises
Minimiser les risques d’échec de développement d’un
système

S. MBARKI 28
Modéliser toutes les vues du système

Le développement d’un
d’un système logiciel doit être abordé
selon différentes vues
Ces vues reflètent les attentes/besoins des différents
acteurs impliqués dans le développement du système
utilisateurs,
client,
analystes,
programmeurs,
chef du projet,
…
Ces vues seront prises en compte en se basant sur
divers diagrammes

S. MBARKI 29
Les diagrammes d'UML

Les diagrammes UML sont utilisés pour visualiser le

système selon différents aspects
Ces aspects sont :
Statique/structurel ou
Dynamique/comportemental
Les diagrammes contiennent des éléments de
modélisation, un élément peut apparaître dans
différents diagrammes

S. MBARKI 30
Les diagrammes d'UML (suite)

S. MBARKI 31
Les diagrammes structurels d'UML :
vue d'ensemble

Diagrammes structurels logiques (au niveau d’analyse)

diagramme de classes
diagramme d’objets
Diagrammes structurels physiques (au niveau
d’implantation)
diagramme de composants
• Il permet de décrire l'architecture physique du système en
terme de modules : fichiers sources, librairies, exécutables,
etc.
diagramme de déploiement
• Il montre la disposition physique des matériels qui
composent le système et la répartition des composants sur
ces matériels.
S. MBARKI 32
Les diagrammes dynamiques d'UML :
vue d'ensemble

Diagramme de cas d’utilisation (décrit les besoins

fonctionnels d’un acteur interagissant avec le système)
Diagrammes de séquences (interactions entre un
ensemble d’objets + messages échangés et leur ordre
temporel)
Diagramme de communication (interactions entre
un ensemble d’objets + messages échangés et l'ordre
est représenté par des numéros)
Diagramme de transition d'état (décrit les
séquences d’états qu’un objet peut parcourir durant sa
vie en réponse aux événements qui lui adviennent)
activitéss (enchaînement d’activités:
Diagramme d’activité
séquentiel, parallèle, conditionnel)
S. MBARKI 33
Les mécanismes communs

UML définit des mécanismes communs qui assurent

l’intégrité conceptuelle de la notation :
Stéréotypes
Valeurs marquées
Contraintes
Notes
commentaires
Paquetages

S. MBARKI 34
Les stéréotypes

Mécanisme d'extensibilité d'UML. Il introduit de

nouvelles classes (spécialisation des classes existantes)

Un stéréotype est un mécanisme qui permet la

classification d’un élément d’UML lorsque la sémantique

de base est insuffisante.

Notation: <<
<<stéréotype
stéréotype>>
>>
S. MBARKI 35
Quelques stéréotypes standards d'une
classe

<<metaclass>>
Domaine ses instances
sont des <<interface>>
classes Transaction

une classe dont

<<utility>>
tous les
Maths
attributs/méthodes
sont statiques

<<exception>>
DivisionPar0

S. MBARKI 36
Cas des stéréotypes Entity, Boundary et
Control

Classe <<Entity
<<Entity>>
>>
Modélise la catégorie d'objets qui ont une durée de vie
importante dans le système
Classe <<Boundary
<<Boundary>>
>>
Modélise la communication des classes entity avec
l'extérieur du système (l'utilisateur)
Classe <<Control>>
Sert à coordonner les échanges de messages entre les
autres classes pour réaliser un Use case

S. MBARKI 37
Cas du stéréotype Utility

Classe <<Utility>>
Contient un ensemble d'attributs et de méthodes à accès
libre
Ces méthodes n’appartiennent à aucune instance
En général, ces méthodes offrent un ensemble de
fonctionnalités utiles dans plusieurs contextes:
• Fonctions mathématiques,
• Algorithmes de tri
• Algorithmes de recherche,
• Etc.
S. MBARKI 38
Les valeurs marquées

C'est une paire (nom, valeur) qui permet d'ajouter une

nouvelle propriété à un élément de modélisation
Spécification de la valeur marquée : {nom = valeur}

classe A
{auteur = Alami}

Attributs

Opérations

S. MBARKI 39
Les notes

Une note est un symbole graphique contenant du texte

et/ou graphiques offrant un commentaire, une
contrainte, le contenu d’une méthode ou des valeurs
marquées à propos d’un élément du modélisation

Voir http://www.
Voir encrypt.doc doc.com

S. MBARKI 40
Les contraintes

Une contrainte est une règle de gestion liée à un

élément du modèle.
Les contraintes sont formulées en langage naturel ou en
langage formel (OCL)
Classe C

+racineCarre
(valeur):reel

{valeur > 0}

S. MBARKI 41
Les commentaires

Un commentaire fournit des explications utiles, des

observations de différentes natures ou des renvois vers
des documents de description plus complets

Classe C
Renvoie valeur contenu de la
^0.5 méthode
+racineCarre
(valeur):reel

valeur > 0 contrainte

S. MBARKI 42
Les packages

Pour les systèmes comprenant plusieurs classes, il

convient de regrouper celles-
celles-ci en entités logiques, les
packages

Un package UML représente un espace de nommage qui

peut contenir:

Des éléments de modélisation

D’autres packages

S. MBARKI 43
Les packages (suite)

Les éléments contenus dans un package:

Doivent représenter un ensemble fortement cohérent
Sont généralement de même nature et de même niveau
sémantique
Le regroupement d'éléments est un critère logique.
L'objectif de décomposition est d'avoir une forte
cohérence interne et un faible couplage externe
Un package est représenté par un dossier (folder
(folder))

IHM

S. MBARKI 44
Les dépendances entre packages

Les classes contenues dans un paquetage emboîté

voient les éléments contenues dans leur paquetage
englobant
UML définit deux stéréotypes standard associés aux
paquetages :
<<importe>> : ajoute les éléments dans l'espace de
nommage source
<<accède>> : référencer des éléments de destination

Destination1
<<importe>>
Source

Destination 2
<<accède>>
S. MBARKI 45
 CHAPITRE 4
Diagramme de cas d’utilisation

S. MBARKI 46
Définition (1)

Jacobson, 1992
« … une façon spécifique d’utiliser le système en utilisant
une partie de sa fonctionnalité. [Un use case] constitue
une séquence complète d’interactions qui a lieu entre un
acteur et le système »
Fowler, 1997
« … une interaction typique entre un utilisateur et un
système informatique … [qui] capture une fonction
d’intérêt pour l’utilisateur … [et qui] permet d’atteindre un
but discret pour l’utilisateur »
Rumbaugh et al, 1999
« …la spécification de séquences d’actions, pouvant
inclure des variantes ou des séquences d’erreur, qu’un
système, sous-
sous-système ou classe peuvent exécuter en
interagissant avec des acteurs extérieurs »
S. MBARKI 47
Définition (2)

Un cas d’utilisation est une technique de description

des besoins fonctionnels d’un système informatique

Chaque besoin fonctionnel est indiqué par une série

d’interactions entre l’utilisateur et le système

Un scénario est une séquence d’étapes de description

d’une interaction entre l’utilisateur et le système

S. MBARKI 48
Exemple (1)

Site de vente en ligne de matériel électronique

(www.microchoix.ma
www.microchoix.ma))
Use case : acheter un produit
Description narrative du scénario :

Le client consulte le catalogue, choisit des articles et les

ajoute dans son panier virtuel.
virtuel. Quand le client souhaite payer,
il remplit,
remplit, dans un formulaire,
formulaire, ses coordonnées (adresse
adresse),), les
informations de sa carte bancaire et confirme l’achat
l’achat.. Le
système vérifie l’autorisation de la carte bancaire et confirme
l’achat immédiatement et en envoyant un e e--mail au client

S. MBARKI 49
 Exemple (2)

Ce scénario est réalisable et peut se dérouler de façon

normale
Scénario 2 ((scénario alternatif) : Un client fidèle n’a pas
scénario alternatif)
besoin de fournir ni les informations de sa carte bancaire ni
ses coordonnées
Scénario 3 (scénario exceptionnel) : Echec de
(scénario exceptionnel)
l’l’autorisation
autorisation de paiement par carte bancaire
èèè Bien qu’ils soient différents
différents,, ces trois scénarios sont
similaires car ils réalisent le même objectif (acheter un
produit))
produit

S. MBARKI 50
Eléments de modélisation : Acteur (1)

Rôle joué par une entité externe (humain, matériel, système)

qui interagit avec le système étudié
Les acteurs sont identifiés en observant les utilisateurs
directs du système, ceux qui sont responsables de son
exploitation ou de sa maintenance,
maintenance, ainsi que les autres
systèmes qui interagissent avec le système étudié
Une même personne peut jouer les rôles de plusieurs
acteurs (client, vendeur)
Plusieurs personnes peuvent jouer le même rôle (tous les
clients)
S. MBARKI 51
Eléments de modélisation : Acteur (2)

Notation :
uc system
uc system

«actor»
Client

Client

Exemple d’acteurs :
Client, Repsésentant du service client, directeur de ventes,
ventes,
administrateur de bases de données,
données, matériel externe
externe,, système
externe,, …
externe
Tout acteur doit communiquer avec le système
S. MBARKI 52
Eléments de modélisation : Cas
d’utilisation (1)

Un cas d’utilisation est une unité cohérente qui représente

un ensemble de comportements fournis par un système à un
ou des acteurs.
Un cas d’utilisation modélise un service rendu par le
système, sans décrire le mode de réalisation de ce service
Notation :
uc system

Retirer argent

S. MBARKI 53
 Description d’un cas d’utilisation (1)
Acheter un produit
Scénario principal :
1. Le client consulte le catalogue et choisit des articles
2. Le client passe au paiement
3. Le client remplit ses coordonnées et le mode de livraison
4. Le système affiche le prix total à payer, livraison incluse
5. Le client fournit les informations de sa carte bancaire
6. Le système vérifie si le client est autorisé
7. Le système confirme l’achat immédiatement
8. Le système envoie une confirmation par e-mail au client
Extensions :
3a: Le client est fidèle
.1: Le système affiche les informations (articles choisis, prix, facture)
.2: Le client accepte ou rectifie ces informations, passer à l’étape 6
6a: Le système n’autorise pas le client
.1: Le client introduit les informations d’une autre carte bancaire ou annule
l’opération
S. MBARKI 54
Description d’un cas d’utilisation (2)

On décrit le cas d’utilisation par le scénario principal comme

une séquence d’étapes numérotées :
Chaque étape dans le cas d’utilisation est un élément de
l’interaction entre l’acteur et le système
Dans la description du scénario
scénario,, un cas d’utilisation peut
inclure un autre cas d’utilisation (lien hypertexte)
hypertexte)
La partie extension ajoute une condition qui change les
interactions du scénario principal et peut produire une erreur
On peut aussi décrire le cas d’utilisation par :
Une pré-
pré-condition : une condition qui doit être vérifiée avant
d’entamer le cas d’utilisation
S. MBARKI 55
Relation entre acteur et cas
d’utilisation
Association
Relie un acteur à un cas d’utilisation montrant que l’acteur participe
au cas d’utilisation
uc system

Retirer argent

Télécharger un
fichier

Internaute
Client
effectuer un v irement

S. MBARKI 56
Relations entre cas d’utilisation (1)

Extension
Le Use Case est une spécialisation d’un autre Use Case plus
général. Le Use Case plus spécifique n’inclut pas
nécessairement tout le comportement du Use Case qu’il
spécialise
Elle associe un use case U1 à un use case U2 (flèche allant de
U1 à U2), spécifiant que le comportement de U1 peut être
occasionnellement inséré dans U2 et U1 peut s’exécuter de
manière autonome

S. MBARKI 57
 Relations entre cas d’utilisation (2)

uc system

effectuer un v irement

«extend»

Vérifier solde
Client

S. MBARKI 58
Relations entre cas d’utilisation (3)

Inclusion

signifie qu’un Use Case utilise intégralement la fonctionnalité

du Use Case plus général en plus de lui ajouter des

fonctionnalités additionnelles

Elle spécifie un lien d’inclusion entre deux use cases. Si U1

inclut U2 (flèche allant de U1 à U2) alors U2 sera toujours

inclus dans U1 et ne sera jamais exécuté de manière autonome

S. MBARKI 59
 Relations entre cas d’utilisation (4)

uc system

effectuer un v irement

«include»

S'authentifier
Client

S. MBARKI 60
Relations entre cas d’utilisation (5)

Généralisation/Spécialisation
Un cas d’utilisation U1 est une généralisation d’un cas
d’utilisation U2 si U2 est un cas particulier de U1
La consultation d’un compte via internet est un cas particulier
de consultation
Cette relation ne se limite pas au diagramme de classe
uc system

Consulter compte

Client
Consulter v ia
Internet

S. MBARKI 61
 Exemple de diagramme de cas
d’utilisation (Système de gestion de commandes)
uc system

Aj outer un client

«include»

S'authentifier

«extend»

«include»
Receptionniste
«include»
Aj outer une
commande
«include»

Facturer une
commande

Liv rer une

commande
Aj outer une
commande Express

Chauffeur

Comptable

S. MBARKI 62
Etude de cas
Système d’Inscription Automatique
Au début de chaque session, les étudiants demandent un
catalogue contenant une liste des cours disponibles durant la
session. Pour aider les étudiants dans leurs choix, des
informations sur chaque cours sont fournies (enseignant,
département, pré-
pré-requis, etc.). Le système permettra aux
étudiants de choisir 4 cours dans une session. En plus, chaque
étudiant choisit deux cours optionnels en cas d’annulation ou de
saturation d’un cours parmi les 4 précédemment choisis. Le
nombre d’étudiants dans un cours est entre 3 et 10. Un cours
contenant moins de 3 étudiants est annulé. Une fois le processus
d’inscription d’un étudiant est validé, le système envoie les
informations au système de paiement. L’étudiant peut donc payer
ses frais de scolarité.
Un enseignant peut indiquer les cours qu’il veut assurer, consulter
la liste des étudiants inscris dans un cours donné
S. MBARKI 63
Diagramme de cas d’utilisation
SIA

Identifier tous les acteurs de l’application SIA

Identifier tous les cas d’utilisation de l’application SIA

Donner le diagramme de cas d’utilisation de l’application

SIA

S. MBARKI 64
Acteurs
SIA

Etudiant

Enseignant

Système de paiement

Administrateur

S. MBARKI 65
Cas d’utilisation
SIA

S’inscrire à un cours
Choisir cours à assurer
Obtenir des informations sur un cours
Maintenir les informations sur enseignants
Maintenir les informations sur étudiants
Maintenir les informations sur les cours
Générer le catalogue

S. MBARKI 66
 Diagramme de cas d’utilisation
SIA
uc system

Choisir cours à
assurer
Etudiant

S'inscrire à un cours Enseignant Obtenir les

informations sur le
cours

Système de paiement

Générer catalogue
Maintenir les
information sur
étudiants

Maintenir Maintenir
informations sur informations sur
cours enseignants

Administrateur

S. MBARKI 67
 CHAPITRE 5
Diagramme d’activité

S. MBARKI 68
Diagramme d’activité (1)

Présente la dynamique du système d’information.

Représente les traitements à effectuer, les acteurs impliqués
et l’utilisation des informations.
Sert à modéliser un processus, un cas d’utilisation ou une
méthode.
Un processus est l’organisation d’un ensemble d’activités
effectués par des acteurs et impliquant des entités, pour
répondre à un type d’événement.
On décrit un processus ou variante par un diagramme
d’activité.
S. MBARKI 69
Diagramme d’activité (2)

Un diagramme d’activité est un graphe orienté qui décrit un

(flot de contrôle).
enchaînement de traitements (flot contrôle).
On peut faire figurer des objets impliqués dans les activités.
La participation de ces objets représente un flot d’objets.
d’objets.
L’enchaînement des activités peut être soumis à des
branchements ou à des synchronisations
synchronisations..
La visualisation des couloirs d’activités permet de
représenter la répartition de la responsabilité des activités
entre différents acteurs.
Les élements de modélisation du diagramme d’activité sont :
S. MBARKI 70
Action

UML propose une description des actions UML :

Action de type call : correspond à un appel de méthode. Ce
type d’appel est bloquant : l’appelant attend la réponse de
l’appelé avant de continuer son exécution.
Action de type send : Correspond à l’envoi de messages
asynchrones : l’appelant poursuit son exécution sans attendre
que l’appelé ait reçu le message. Ce type d’appel est adapté à la
modélisation des protocoles de communication (UDP, MPI), du
multi--Threading. L’action symétrique côté récepteur est accept
multi
event (réception d’un signal). En Java, notify() de la méthode
Object est asynchrone.
S. MBARKI 71
Flot de contrôle (1)

Le diagramme d’activité présente un séquencement de

traitements.
Un traitement peut être :
Une action (opération élémentaire).
Une activité (peut être décrite plus finement).
Les actions/activités sont reliées par des transitions.
Les transitions sont déclenchées par des événements :
achévement de l’action/activité précédant la transition.
réception d’un signal.
disponibilité d’un objet dans un certain état.

S. MBARKI 72
Flot de contrôle (2)

L’ensemble des transitions constitue le flot de contrôle.

Une transition peut être en attente de la vérification d’une
condition de garde
Exemple : l’activité ”Envoi de la commande” n’est effectuée
qu’après l’activité ”Préparation de la commande” mais aussi
en fin de journée
sd Dynamic View

Préparation de la Env oi de la commande

commande [fin de journée]

S. MBARKI 73
Action accept time event (1)

Un signal est une information provenant d’une action

externe à l’activité en cours de description.
On distingue trois types de signaux :
(accept time event)
Signal temporel (accept event)
Signal émis
Signal reçu
Le signal temporel exprime le passage du temps
sd Dynamic View

Etablir la paie

dernier
jour
ouvrable
du mois
S. MBARKI 74
Action accept time event (2)

Un événement temporel sans flot entrant (voir la figure

précédente) est un événement réccurent :
Constitue une alternative pour démarrer une activité.
Modélise une activité qui est exécutée périodiquement.
Exemple : Envoyer la commande et attendre trois jours avant
d’envoyer la facture
sd Dynamic View

Env oyer Commande Ev oyer facture

Attendre
trois
jours

S. MBARKI 75
Actions send signal et accept event
(1)
Des activités peuvent impliquer des interactions avec des
personnes, systèmes ou processus externes :
Pour autoriser une transaction avec une carte de crédit,
crédit, On
procéde à la vérification avec l’émetteur (Banque
Banque)) par
l’intermédiaire de la société de carte de crédit (Visa,
MasterCard, etc).
Dans le diagramme d’activité,
d’activité, un signal est un message qui
peut être émis ou reçu :
Activité autorisation de carte de crédit : Le logiciel envoie une
requête à la société de la carte de crédit pour obtenir
l’autorisation de la transaction du client et le logiciel reç
reçoit la
résponse de la société de crédit.
crédit.
S. MBARKI 76
Actions send signal et accept event
(2)
Un signal reçu déclenche l’exécution d’une activité
Le receveur du signal sait comment réagir dès sa reception
mais ne sait pas quand le signal arrive (message asynchrone)
Exemple : L’arrivée d’une commande déclenche le processus
de traitement d’une commande
sd Dynamic View

Arrivée Traitement de la
commande commande

Exercice : Le clic sur un bouton active l’exécution du code

associé (activité : traitement de l’événement clic sur bouton)
S. MBARKI 77
 Actions send signal et accept event
(3)
Un signal emis est envoyé à un participant externe (personne
ou système).
A sa réception, le participant réagit en réponse au signal
émis, mais sa réponse n’est pas modélisée dans le diagramme
d’activité.
Exemple : Validation de carte de crédit
sd Dynamic View

Send request for Receive

Calculate total Update order status
credit card response
approval

S. MBARKI 78
 Exemple récapitulatif

Action accept event Action time accept event

Action send signal

sd Dynamic View

Appui Eclairer
bouton Eteindre
Affichage affichage
(lumière)
Attendre
2s

S. MBARKI 79
Flot d’objet (1)

Permet d’indiquer quelle est la part prise par chaque objet

dans l’exécution d’un travail.
Exemple :
sd Dynamic View

Préparation de la Env oi de la commande

commande [fin de journée]

:Commande :Commande
Comptabilisation
[ouverte] [envoyée]

S. MBARKI 80
Flot d’objet (2)

Les trois transitions de la figure mettent en jeu un objet

Commande dans différents états et font partie du flot d’objet.
Les transitions du flot d’objet peuvent également comporter
des conditions de garde
Remarques :
Chaque diagramme d’activité à un noeud initial et un noeud
final
sd Dynamic View sd Dynamic View

Add itm to
CheckOut
Cart

S. MBARKI 81
Flot d’objet (3)

Les actions, comme les méthodes, peuvent avoir des

paramètres.
Il n’est pas nécessaire de représenter les informations
concernant les paramètres dans un diagramme d’activité.
Si c’est le cas, on emploie des connecteurs (pins).
(pins).
Les connecteurs sont intéressants pour visualiser les objets
dont les actions ont besoin.
Exemple :
sd Dynamic View

Chercher Contacter
client client
Client Client

S. MBARKI 82
Branchement conditionnel

Un flot de contrôle peut comprendre des chemins alternatifs.

Chaque branche est soumise à une condition (condition de
garde).
Les chemins parallèles fusionnent pour continuer l’activité.
Exemple : Cas d’une commande éléctronique
sd Dynamic View

Constitution du panier de
la commande

[trop cher] [montant acceptable]

Abandon de la commande Env oi de la commande

Mémorisation de
l'env ironnement client

S. MBARKI 83
Synchronisation
sd Dynamic View
Un flot de contrôle
Expression d'une
peut suivre deux demande de crédit

chemins parallèles
(ouverture d’une
fourche ou fork) Recherche dans le
catalogue
Ev aluation du risque
client

Ensuite, les deux

chemins se Sélection des produits à
proposer

rejoingnent dans
une fermeture de
Affichage de la réponse
synchronisation
(join)
S. MBARKI 84
Partition (1)

On définit des colonnes (partitions) pour décrire les acteurs

responsable de chaque activité.
Chaque activité est placée dans la partition de l’acteur qui
s’en charge.
Remarques :
Pour représenter une activité partagée entre deux acteurs, on la
décompose en sous-
sous-activités.
Un diagramme d’activité peut impliquer plusieurs objets
Une activité est un ensemble d’actions élémentaires qui peut
être représentée par un sous-
sous-diagramme d’activités.
S. MBARKI 85
 Partition (2)

sd Dynamic View

Serv ice achats Responsable serv ice achats Application comptabilité

Préparation de la
commande

Env oi de la
commande
:Commande
[ouverte]

:Commande
Comptabilisation
[envoyée]

S. MBARKI 86
Exemple 1 : Cafetière

Construire un diagramme d’activité représentant l’utilisation

d’une cafetière éléctrique
Les actions sont :
Chercher du café
Mettre un filtre
Remplir le réservoir d’eau
Mettre du café
Prendre une tasse
Allumer la cafetière
Servir le café

S. MBARKI 87
Solution : Cafetière
sd Dynamic View

Chercher du
café

Remplir le Prendre une

Mettre un réserv oir
filtre tasse
d'eau

Mettre du
Serv ir le
café
café

Allumer la
cafetière

S. MBARKI 88
Exemple 2 : Traitement d’une
commande
Use case : “traitement d’une commande”:
commande”:

“Quand on reçoit une commande, on vérifie pour chaque

ligne de la commande, si nous disposons de la quantité du
produit demandée en stock
stock.. Si c’est le cas, nous affectons la
quantité demandée à la commande.
commande. On réapprovisionne le
stock en cas de rupture.
rupture. Simultanément, nous vérifions si le
paiement est en ordre
ordre.. Si le paiement est ok et que tous les
produits sont disponibles nous livrons la commande.
commande. Si le
paiement est ok mais nous ne disposons pas des produits,
nous mettons la commande en attente.
attente. Si le paiement n’est
pas ok, nous annulons la commande “.
S. MBARKI 89
Solution : Traitement d’une
commande
sd Dynamic View
retour

Recevoir une
commande

Vérifier Vérifier la
paiement quantité

Reapprov isionner
[rupture] le stock

Annuler la
commande [echec] [disponible]

Affecter la
quantité à la
[Il reste des articles ?] commande

[succes]

Liv rer la [plus d'articles]

commande

S. MBARKI 90
 CHAPITRE 6
Diagramme de classes

S. MBARKI 91
Définition

Un élément essentiel de l’l’approche Orientée Objet

Exprime l’aspect structurel/statique d’un système en
termes de :
classes
relations statiques entre les classes
Sert de base aux autres diagrammes du modèle (tels
que les diagrammes d’états, des objets ou les
diagrammes de communication qui sont des
diagrammes dynamiques)
Diagramme de classes = Modèle entité
entité--association
étendu
S. MBARKI 92
Définition (suite)

Une classe définit la structure commune d’un ensemble

d’objets et permet la construction d’objets instances de
cette classe. Une classe est identifiée par son nom
Un objet est relié à une classe de la même manière
qu’une variable est associée à un type de données dans
un langage de programmation procédurale
On distingue deux catégories de classes :
Classes concrètes : instantiables
Classes abstraites: non instantiables (notation: nom en
italique)
S. MBARKI 93
Notation

la syntaxe dans les différents compartiments est

indépendante des langages de programmation
S. MBARKI 94
Les propriétés

Les propriétés représentent les caractéristiques

structurelles d’une classe
Les propriétés représentent un concept unique mais
apparaissent dans deux notations différentes : les
attributs et les associations
Exemples : le client est une propriété de la
commande, le produit est une propriété de la ligne de
commande, le nom est une propriété de client, …
S. MBARKI 95
Les attributs

Permet de décrire une propriété comme une ligne de

texte dans la classe
type
Private
(-)

Protected
(#)

Public
(+) Valeur par
défaut
S. MBARKI 96
Les attributs (suite)

Syntaxe : visibilité nom : type [multiplicité]

[=
[=valDefaut
valDefaut]] [{contrainte}]
Multiplicité : indique la nature du champ ([0..1] pointeur,
[1] valeur, [x..*] collection)
Contrainte : information supplémentaire sur l’attribut
Exemple :
- nom : String [1]="Said
[1]="Said"" {readonly
{readonly}}
Sémantique : décrivent l'état de l'objet
Visualisé ou pas, selon le niveau de détail souhaité
S. MBARKI 97
Associations unidirectionnelles

L'association constitue une autre méthode pour noter

une propriété
Une association unidirectionnelle est représentée par un
trait continu et orienté entre deux classes
Le nom de la propriété et la multiplicité sont
représentés sur l'association du côté de sa cible
Dans l'exemple suivant, nous donnerons deux figures
représentant de deux façons des propriétés

S. MBARKI 98
Représentation des propriétés
class system
1
Date Commande Boolean
+dateLivr +prePay

0..1 * 1

+lignesComm *
{ordered}
LigneCommande

class system
2
Commande

- dateLivr: Date [0..1]

- lignesComm: LigneCommande [0..n] {ordered}
- prePay: Boolean
S. MBARKI 99
Interprétation de la représentation

Dans la notation associations, on peut représenter

les multiplicités dans les deux extrémités de
l'association
Quel est l'intérêt d'une notation par rapport à l'autre
?
Les attributs sont utilisés pour les types valeurs :
dates, booléens, etc.
Les associations sont plus significatifs pour les
classes (clients, commandes, etc.)
S. MBARKI 100
Multiplicité

Equivalent aux cardinalités du modèle E-

E-A

Le sens de lecture n’est pas le même

0..x : optionnel

1 : un et un seul

x..* : multiple

m..n : borné

La multiplicité par défaut d'un attribut est [1]

S. MBARKI 101
Multiplicité (suite)

Une multiplicité supérieure à 1 implique une collection

d'objets
Les formes les plus courantes d'associations sont :
1 vers 1
1 vers n
n vers m
1 1

classe A 1 * classe B

* *

S. MBARKI 102
Les associations bidirectionnelles

Une association bidirectionnelle est une paire de

propriétés reliées entre elles
La classe Voiture a une propriété propriétaire :
Personne[1]
La classe Personne a une propriété voitures :
Voiture[*]

S. MBARKI 103
Nom d’une association

Décrit la nature de l’association

emploi
Personne Société

Direction de lecture de l’association

travaille pour
Personne Société

S. MBARKI 104
Rôle d’une association

Décrit comment une classe source voit une classe

destination à travers l’association
Une classe peut jouer un même rôle ou différents rôles
au sein de différentes associations
Les associations peuvent relier une classe à elle même
employé
Personne employeur Société

Personne
Chef Nom
NumAssurance
Supervise Adresse

Subordonné
S. MBARKI 105
Les opérations

Permettent de manipuler les propriétés et d'effectuer

des actions. Elles sont appelées par des instances de la
classe
Syntaxe : visibilité nom(liste_paramètres
nom(liste_paramètres)) :
type_retour [{propriété}]
Exemple :
+ deplacer(
deplacer(u:Vecteur
u:Vecteur)) : void
Les opérations constituent l’interface de la classe avec
le monde extérieur
Distinction entre opération et méthode :
Une méthode est l'implémentation d'une opération dans
une classe
Une même opération peut s'appliquer sur plusieurs
classes (polymorphe)
S. MBARKI 106
Exemple d’une classe avec opérations

Opérations public

S. MBARKI 107
Généralisation--spécialisation
Généralisation

Un exemple typique de généralisation est celui de l'étudiant

et l'enseignant
l'enseignant.. Ils ont des différences mais aussi des
similarités. Ces dernières peuvent être placées dans une
super--classe Personne
super
On dit que l'étudiant est un sous-
sous-type (spécialisation
(spécialisation)) de
personne
La généralisation permet la création de super-
super-classes
regroupant les propriétés et les comportements communs
aux sous-
sous-classes (factorisation
(factorisation).).
La spécialisation permet la création de sous-
sous-classes afin
d’ajouter ou modifier certaines propriétés ou comportements
définis dans les super-
super-classes
S. MBARKI 108
Généralisation--spécialisation (suite)
Généralisation

Matériel
Informatique
Référence
Prix

Unité Centrale Ecran Clavier

Vitesse Dimensions NbrTouches

S. MBARKI 109
Généralisation--spécialisation (suite)
Généralisation

Factorisation des relations

factorisation de
l'association d'appartenance

vehicule terrestre appartient personne

0..*

voiture camion
tonnage

S. MBARKI 110
 Généralisation--spécialisation (suite)
Généralisation

Propriétés de la généralisation: non réflexive, non

symétrique et transitive
A A
A

Impossible !!! C
Impossible !!!
B

Généralisation vs Composition
Généralisation = est un: un Window-
Window-avec-
avec-scrollbar est un
Window
Composition = a un: un Window-
Window-avec-
avec-scrollbar a un
scrollbar
S. MBARKI 111
Dépendance

Un lien durable entre objets donne lieu à une

association unidirectionnelle
Un lien temporaire (envoi de message, variable locale,
paramètre) donne lieu à une relation de dépendance
Une dépendance existe entre deux classes si la
modification de l'une (fournisseur) a des répercussions
sur l'autre (client)

Bibliothèque Livre

client fournisseur
S. MBARKI 112
Dépendances (suite)

Plusieurs stéréotypes :

« call » : la source (opération) appelle une opération de

la cible

« instantiate » : une opération de la source crée une

instance de la cible

« send » : la source envoie un signal à la cible

S. MBARKI 113
Composition

Exprime « une partie de »

Une classe composant peut faire l’objet de plusieurs
compositions
Un objet de la classe composant ne peut appartenir
qu’à un seul objet d’un composé
Cycles interdits!
Durées de vie identiques (destructions synchronisées)
La « navigabilité » peut être bidirectionnelle ou non

S. MBARKI 114
Composition (suite)

La création, modification et destruction des composants

sont de la responsabilité du composite

Du coté du composite, la multiplicité est un

Appartement 1 * Chambre

S. MBARKI 115
Agrégation

Une agrégation est une association non symétrique :

l’une des extrémités joue un rôle prédominant que
l’autre

Sémantique identique à la composition

Le partage des objets composants est autorisé
Durées de vie différentes
-salariés * *
Entreprise Personne Association
1 * -adhérents

S. MBARKI 116
Composition / Agrégation

Identification d’une composition (ou agrégation)

Assemblage--parties
Assemblage
• La porte est un composant de la voiture
Collection--membres
Collection
• La personne est membre dans l’association

Contenant--contenu
Contenant
• Le polygone contient des sommets

Modéliser autant que possible les compositions/agrégations

Augmente la lisibilité du modèle
S. MBARKI 117
Membres statiques

Attributs et opérations statiques

Correspondent aux membres static en C++ ou Java

Indiqué par un souligné

S. MBARKI 118
Interfaces

Type de classe définie exclusivement par des fonctions

abstraites

Sert à l’implémentation d’autres classes

Deux notations :

S. MBARKI 119
Interfaces (suite)

Une interface peut être:

implémentée

S. MBARKI 120
Contraintes

Information supplémentaire sur un élément

Placée entre accolades
Peut être un texte en langage naturel
Ou bien OCL (Object Constraint Language
Language))
• Repose sur la logique mathématique
• Évite les ambiguïtés du langage naturel
• Il existe des outils pour OCL
• Permet de décrire les pré et post-
post-conditions, ainsi que les
invariants sur un élément du modèle (attribut, rôle,
opération, etc.)

S. MBARKI 121
Exemple de contraintes OCL

Soit le diagramme de classes suivant :

Chambre
Hôtel -lesChambres
-étage : Integer
-adresse : String -numéro : Integer
* -nbLits : Integer

-laChambre 1

* -lesCLients

-directeur 1 Personne
-nom : String
-prénom : String -lesRésidents
-age : Integer
*
S. MBARKI 122
Exemple de contraintes OCL

On peut exprimer les contraintes :

neuvième étage
// Jamais de neuviè
context Chambre inv
inv:
:
self.é
self. étage <> 9
résidents que de lits sauf s’
// Pas plus de ré s’il y a un enfant
de moins de 4 ans
context Chambre inv
inv:
:
lesRé
lesR ésidents
sidents-->size <= nbLits or
(lesR
lesRéésidents
sidents-->size = nbLits + 1 and
lesRé
lesR ésidents
sidents-->exists
exists(p
(p : Personne | p.âge < 4))

S. MBARKI 123
Contraintes sur les associations

Une contrainte est une condition sur une association qui

doit être préservée. Elle est placée dans une expression
entre accolades
Personne Compte
*
{ordonné}
La contrainte d’inclusion {sous ensemble} indique
qu’une collection est incluse dans une autre collection
Parents d'élèves *
Classe {sous ensemble}
* Personne
délégués

S. MBARKI 124
Contraintes sur les associations (suite)

La contrainte d’exclusion {ou exclusif} indique que pour

un objet donné, une seule association parmi un groupe
est valide

Batterie
PC portable {ou exclusif}

Secteur

S. MBARKI 125
Classes association

On représente une association par une classe pour

ajouter des attributs et des opérations dans l’association
Une classe d’association est intéressante pour les
associations N vers M
Pour les associations 1 vers 1 les attributs de
l’association peuvent être déplacés dans l’une des
classes
Pour les associations 1 vers N, le déplacement se fait
vers la classe du côté N
S. MBARKI 126
Classes association (suite)

Etudiant * * Travail

Classe
Evaluation association
note

Evaluation
Etudiant
1 * note * 1
Travail

S. MBARKI 127
Restriction des associations

La restriction (qualification) d’une association consiste à

sélectionner un sous-
sous-ensemble d’objets parmi l’ensemble qui
participe à l’association
Elle est réalisée au moyen d’une clé, ensemble d’attributs
particuliers. La clé appartient à l’association
Le qualificateur (ex: n°
n° Etudiant) permet d’identifier 0 ou un
étudiant
Pour manipuler (ajouter, consulter, etc.) un étudiant, il faut
obligatoirement un n°
n° Etudiant

0..1
Université n Etudiant Etudiant

S. MBARKI 128
Restriction des associations (suite)

A clé B

Chaque instance de la classe A accompagnée de la valeur de la

clé, identifie un sous ensemble des instances de B qui participent
à l’association
Une restriction réduit le nombre d’instances qui participent à une
association
:B

:B

:B :B
:B
:A :B
avec clé :B
:B
:B
S. MBARKI 129
Associations ternaires

Une association ternaire entre Salle, Cours et

Enseignant est représentée par une classe Séance ayant
deux attributs début et fin
Cours
∗

Enseignant ∗ ∗ Salle

Séance
date
Heure
durée

S. MBARKI 130
 CHAPITRE 7
Diagramme d’objets

S. MBARKI 131
Définition

Le diagramme d'objets permet de représenter les

instances de classes et liens entre elles

Un diagramme d'objets est une instance de diagramme

de classes :

Il montre l'état du système à un instant donné

La notation retenue est dérivée du diagramme de classes

S. MBARKI 132
Représentation des objets

Objet simple
mazda mazda : Voiture : Voiture

Groupe d'objets
: Voiture

Objet d'une classe stéréotypée

<<Exception>>
: DivisionParZero

Objet avec valeurs des attributs

: Voiture
: Voiture
Vitesse = 60
Couleur = noir [ 60, noir ]

S. MBARKI 133
Représentation des liens

Les objets sont reliés par des liens

La représentation concrète d'une structure au moyen
d'objets est plus parlante que celle par des classes
: Voiture : Moteur

: Roue : Roue : Roue : Roue

Ce diagramme d'objets est une instance du diagramme

de classes suivant :
1 1 1
Roue 4 Voiture Moteur

S. MBARKI 134
Les objets composites

Représenter les objets composés de sous objets

Exemple :
Soit le diagramme de classe suivant
Fenêtre Ascenseur
2

1
Zone de texte
Représentation de l'objet composite
:Fenêtre

:Zone de texte ascVertic :

Ascenseur
ascHoriz :
Ascenseur

S. MBARKI 135
Similitudes entre les diagrammes d'objets
et les diagrammes de classes

Pour faciliter la compréhension du lien entre les deux

diagrammes, il faut reporter dans le diagramme d'objets
toutes les caractéristiques des associations (nom, noms
des rôles, l'agrégation, la composition et la navigation)

passagers : Personne

: Bus
: Personne

: Destination

S. MBARKI 136
Relation de dépendance entre objets et
classes

Un objet est une instance d'une classe

Un lien est une instance d'une association

Ces relations entre le classificateur et son instance sont

représentés par des relations de dépendance
stéréotypés par <<instance de>>

Exemple :
ascHoriz : <<instance de>>
Ascenseur
Ascenseur

S. MBARKI 137
Diagramme d'objet : exemple

Soit le diagramme de classe représentant l'organisation

des métiers dans une entreprise
* fils
Nœud

0..1 parent
Personne Métier

Illustrer ce diagramme de classes par un diagramme

d'objets correspondant

S. MBARKI 138
 Exercices

Donner les diagrammes de classes associés aux règles

de gestion suivantes :
Exercice 1
Un salarié travaille dans un seul service, un service
contient plusieurs salariés
Exercice 2
Un salarié travaille dans un ou plusieurs services, un
service contient un ou plusieurs salariés
Exercice 3
Une commande concerne un ou plusieurs produits, un
produit figure dans 0 ou plusieurs commandes
Exercice 4
Un étudiant a une seule note dans une matière donnée
S. MBARKI 139
 Exercices

Etude de cas :
Soit les règles de gestion :
un étudiant s’inscrit dans une et une seule filière.
Une filière est un ensemble de modules.
Un étudiant a une seule note dans un module donné
Un étudiant peut avoir plusieurs diplômes.
Un module est enseigné par un seul enseignant.
Un enseignant enseigne plusieurs modules.
L’administration comptabilise les absences.
S. MBARKI 140
 Exercices

Exercice 5
Une école a décidé de bâtir des chambres (internat) et
des résidences à l’extérieur, un étudiant habite à l’internat
ou à la résidence mais pas aux deux.
Exercice 6
Soit le problème suivant : les étudiants d'une école
émettent des souhaits concernant des stages
un étudiant effectue au plus un stage
un stage est effectué au plus par un étudiant
un stage intéresse 0 ou plusieurs étudiants
un stage effectué par un étudiant doit être un stage
figurant dans les souhaits de cet étudiant
Exercice 7
Un ordinateur est composé d'un écran, d'un ou plusieurs
disques et différents périphériques
S. MBARKI 141
 Exercices
public interface Observer {
public void update(Observable o);
}
public class Observable {
Collection observateurs;
public void notify()
notify() {
Iterator it = this.iterator
this.iterator();
();
while (it.hasNext())
it.hasNext()) {
((Observer) it.next
it.next()).update(
()).update(this
this);
);
}
}
public void addObserver(Observer
addObserver(Observer o) {
observateurs.add(o);
} ... }
public class Bilan extends Observable {
void setChange()
setChange() { notify();
notify();
} ... }
public class UIGraphe implements Observer {
public void update(Observable o) {
Bilan unbilan = (Bilan) o;
double compteResultat = unbilan.getCompteResultat();
unbilan.getCompteResultat();
... S.} MBARKI
... } 142
 CHAPITRE 8
Diagramme de séquences

S. MBARKI 143
Pourquoi interaction/collaboration
d’objets
Les objets contiennent seulement les données et les
méthodes qui relèvent de leurs propres responsabilités
Ils ne connaissent rien sur les données d’autres objets
Pour obtenir le genre de fonctionnalités exigées d’un
système, les objets doivent travailler ensemble,
collaborer
Les objets collaborent en s’envoyant des messages
Seuls les objets liés entre eux (d’une manière ou d’une
autre) peuvent s’échanger des messages
S. MBARKI 144
Messages

Un message modélise une communication

unidirectionnelle entre objets, qui transporte de
l’information avec l’intention de déclencher une réaction
chez le récepteur
Il peut comprendre des paramètres qui transfèrent des
valeurs de l’émetteur au récepteur
UML définit les messages suivants:
Call: appel d’une opération sur un objet (synchrone)
Call:
Return:: renvoi d’une valeur à l’émetteur
Return
Send:: envoi d’un signal à un objet (asynchrone)
Send
Create:: création d’un objet
Create
Destroy:: destruction d’un objet
Destroy
S. MBARKI 145
Liens entre objets

Un lien spécifie le chemin par lequel un objet o1

peut envoyer un message à un autre objet o2 (qui
peut être le même)
Différente
Différent es formes de ce chemin :
Association: o2 est visible par simple association
Association:
Self:: o2 est visible car il est lui même le déclencheur de
Self
l’opération (o2=o1)
Global:: o2 est un objet global par rapport à o1
Global
Local:: o2 est un objet local par rapport à o1
Local
Parameter:: o2 est un paramètre d’une opération de o1
Parameter

S. MBARKI 146
Diagramme d’interaction

Décrit comment des objets interagissent entre eux

Typiquement, un diagramme d’interaction décrit un
scénario possible d’un seul use case
Deux sortes de diagrammes:
Le diagramme de séquences, qui met l’accent sur la
chronologie des messages
Le diagramme de communication, qui met l’accent sur les
relations structurelles entre les objets qui échangent
les messages
Les deux diagrammes sont sémantiquement équivalents
(l’un peut être obtenu à partir de l’autre).
S. MBARKI 147
 Diagramme de séquence

Les participants sont placés sur l’axe horizontal et l’échange

de messages sur l’axe chronologique verticale
sd system

p:Person c:Company

assi gn(Dept R&D)

Barre d’activation
Durée de vie

S. MBARKI 148
Rapport entre DC et DS

Seuls les objets liés entre eux peuvent s’envoyer des

messages

class system

Person Company
+employe +Employer
- -
1..* 1
+ assign(Departement) : void + ()

S. MBARKI 149
Différents types de messages

o1 o2
s im p le

p ro c e du re c a ll

r et u rn

m es s a g e to s e lf

< < c re a te> >

de s tru c tio n m ark er

S. MBARKI 150
Exemple de diagramme de séquence

Calcul du montant d’une commande

La commande parcoure toutes ses lignes de commande :

• Détermine le prix de chaque ligne de commande

La commande calcule la réduction accordée au client

• Consulter le client

S. MBARKI 151
 Solution avec un contrôle centralisé
sd system

uneCommande uneLigneDeCommande unArticle unClient

calculPrix()

getQuantité()

getArticle() :Article

getDetailsPrix()

calculPrixBase()

getInfosRemise()

calculRemise()

S. MBARKI 152
Commentaires

Les messages sont envoyés suivant un ordre chronologique

getArticle est un appel de méthode qui retourne un résultat

(un article)

Le premier message dans le diagramme n’a pas de

participant (source indeterminée),

indeterminée), on l’appelle

“found message”

Diagramme incomplet car il ne montre pas l’itération

S. MBARKI 153
 Solution avec un contrôle distribué
sd system

uneCommande uneLigneDeCommande unArticle unClient

calculPrix()

calculPrix()

getPrix(quantité)

getMontantRemise(uneCommande) :double

getPrixBase()

montantRemise()

S. MBARKI 154
Commentaires

Chaque style a ses avantages et ses inconvénients

Dans le premier style, le traitement est centralisé dans un

seul endroit

Dans le deuxième style, le traitement est distribués entre des

participants qui collaborent entre eux

Le style 2 est plus adapté au concept orienté objet :

Chaque objet est responsable de ses propres données

S. MBARKI 155
 Message de type création

: P rofes s or :Cour s eF orm : Cours e

M anager
s et c ours e info
add c ours e

< < c reate> >

:Cours e

S. MBARKI 156
Itération,, condition
Itération

Le diagramme de séquence n’est pas adéquat pour

montrer les structures de contrôles :
Il s’interesse
s’interesse à l’interaction entre les objets et ne modélise
pas le flot de contrôle
Utiliser un diagramme d’activité
Pour représenter une itération ou une condition,
utiliser :
Interaction frames

S. MBARKI 157
 Exemple

procedure dispatch
foreach (lineitem
lineitem))
if (product.value
(product.value>10k)
>10k)
careful.dispatch
else
regular.dispatch
end if
end for
if (needsConfirmation
(needsConfirmation)) messenger.confirm
End procedure
S. MBARKI 158
 Interaction frames
sd system

:Order careful:Distributor regular:Distributor :Messenger

dispatch()

loop
[for each line item]

alt
[value>10000]
dispatch()

Frame [else]
dispatch()

operator
opt
[needsConfirmation]
confirm()
guard

S. MBARKI 159
Quand utiliser un diagramme de
séquence ?
Pour comprendre et représenter les comportements de
plusieurs objets dans un seul cas d’utilisation
Montre la collaboration entre les objets
Ne définit pas de façon précise le comportement
Pour représenter le comportement d’un objet dans
plusieurs cas d’utilisations :
Diagramme d’état
Pour représenter les comportements de plusieurs objets
dans plusieurs cas d’utilisations :
Diagramme d’activité
S. MBARKI 160
Exemple : gestion d’une bibliothéque

Les use cases principaux d’un système de gestion

d’une bibliothèque sont:
Gestion des emprunts d’ouvrages
Gestion des retours d’ouvrages empruntés
Approvisionnement par de nouveaux ouvrages
Pour chacun de ces use cases, donner les
diagrammes de séquences de différents scénarios
possibles
S. MBARKI 161
 Scénario : emprunter un livre
sd bibliotheque

ep0:Emprunteur ex0:Exemplaire

bibliothecaire

emprunterLivre()

getNombreEmprunts()

n()

opt
[n<MAX] emprunter(ep0, date)

bloquer()

ajouterExemplaire(ex0)

S. MBARKI 162
 Scénario : rendre un livre
sd bibliotheque

ex0:Exemplaire ep0:Emprunteur

bibliothecaire

rendreLivre()

rendre(dateActuelle)

getEmprunteur()

supprimerExemplaire(ex0)

debloquer()

S. MBARKI 163
 Scénario : rendre un livre avec
pénalité
sd bibliotheque

ex0:Exemplaire ep0:Emprunteur

bi bl iothecai re

rendreLi vre()

rendre(dateActuelle)

getEmprunteur()

supprimerExemplaire(ex0)

debloquer()

getDateSortie()

ds()

opt penaliser()
[dateActuelle - ds >15]

S. MBARKI 164
 Scénario : envoyer une lettre de
rappel
sd bibliotheque

ex0:Exempl ai re ep0:Emprunteur

bibl iothecaire

lettreRappel()

loop getEtat()
[pour chaque Exemplaire]
etat()

opt getDateSorti e()

[etat=bloqué]
ds()

opt getEmprunteur()
[dateActuell e - ds > 15]
envoyerLettreRappel()

S. MBARKI 165
 Scénario : approvisionnement
sd bibliotheque

:Bibliotheque

approvisionner()

loop
:Livre
creer()

setDescriptions()

loop
:Exemplaire
creer()

setDescriptions()

ajouterExemplaire()

ajouterLivre()

S. MBARKI 166
 CHAPITRE 9
Diagramme d’états-
d’états-transitions

S. MBARKI 167
Définition

Un diagramme d’états (ex. automate fini) s’intéresse au

cycle de vie d’un objet générique d’une classe
particulière au fil de ses interactions avec son
environnement externe, en traitant tous les cas
possibles
Il décrit les séquences d’états dans lesquelles un objet
peut être durant son cycle de vie et les événements qui
déclenchent les transitions.
S. MBARKI 168
 Qu’est ce qu’un état ?

Un état représente une situation durable dans laquelle peut

se trouver un objet :
Il satisfait une certaine condition
Il exécute une certaine activité
Ou bien il attend un certain événement
Un état est déterminé sur base des valeurs de ses attributs
ou par l’existence de liens avec d’autres objets

Personne En activité A la retraite

Société 0..1 1..* age

Au chômage

S. MBARKI 169
Changement d’états

Changement d’états à la suite de l’occurrence d’un

événement
Un événement déclenche une transition d’état
Une transition d’état : connexion unidirectionnelle reliant 2
états
assure le passage d’un état à l’autre
est supposée instantanée
retirer(somme)

Positif Négatif

déposer(somme)

S. MBARKI 170
Changement d’états

Un événement peut ou non changer un état

Transition reflexive
(Self--transition)
(Self

retirer(somme) déposer(somme)
retirer( somme )

Positif Négatif

déposer( somme )

S. MBARKI 171
Qu’est ce qu’un événement ?

En UML, un événement est une spécification d’une

occurrence significative qui a une localisation dans le
temps et dans l’espace
Une instance d’un événement peut entraîner l’activation
d’une fonctionnalité d’un objet
Il représente l’occurrence d’un fait qui peut déclencher
une transition entre états

S. MBARKI 172
Les quatre types d’événements en
UML

La réception d’un signal : envoyé par un autre objet, ou

par un acteur (p.ex., envoi d’une exception en Java)
L’appel d’une opération (call event) sur l’objet récepteur
(p.ex., déposer(somme))
Le passage du temps (time event) (p.ex., after 30 min)
Un changement dans la satisfaction d’une condition
(change event) (p.ex., when n>Max)

S. MBARKI 173
Exemple de “time Event” et “change
Event”

S. MBARKI 174
Notations relatives à un état

Un état est toujours nommé

Il comporte :
State name
des actions d’entrée (entry/ …)
des actions de sortie (exit/ …) entry / entry-action

des activités (do/…) do / activity-A

Etats particuliers : exit / exit-action

Etat initial
Etat final

S. MBARKI 175
Notions d’actions et d’activités

Action :
Atomique (ininterruptible
(ininterruptible,, instantanée)
Associée à une transition
Peut apparaître dans les clauses “entry” and “exit” au sein
d’un état
Activité :
A une certaine durée (interruptible)
Associée à un état

S. MBARKI 176
Exemples d’actions et d’activités

Actions
Go for dinner
Go to sleep
Go for breakfast
Go for lunch
Activité
Activit és:
Rest
Sleep
Take dinner
Take breakfast
Take lunch

S. MBARKI 177
Notations relatives à une transition
entre états

State-A Event(arguments)[condition]/action
State-B

event : événement ou rien

condition (de garde) = expression logique liée à l’état
que l’on quitte
action exécutée lors du franchissement de la transition
Chacune des trois parties peut être omise

S. MBARKI 178
Les états initial et final

Event(attribute)
Initial state State-B

Start State
End State
Start state
Obligatoire et un seul par diagramme
End state
Terminates a state machine
Optionnel,, plusieurs états sont possibles
Optionnel

S. MBARKI 179
 Diagramme d’état d’une commande
[ not all items checked ] événement Item received [ some
/ get next item items not in stock ]

Action
[ All items checked && some
/ get first item Checking items not in stock ]
Waiting
do: check item

[ All items checked && Activité Item received[ all items

all items available ] available ]

Condition
De garde
Dispatching deliver
Delivered
do: initiate delivery

S. MBARKI 180
Un état composite

Un état composite est un état qui contient d’autres

états, appelés sous-
sous- états ou états imbriqués
Les sous états peuvent être:
Séquentiels ou
Concurrents (aussi appelés parallèles)
Les sous-
sous-états sont à leur tour susceptibles d’être
décomposés

S. MBARKI 181
Cas : annuler une commande

On souhaite annuler, à tout moment, une commande

commande

Solutions:

Transitions à partir de chacun des états vers un

nouveau état “cancelled

cancelled””

Utiliser un état composite et une seule transition vers

l’état “cancelled”

S. MBARKI 182
Solution 1 : plusieurs transitions vers
“cancelled”
[ not all items checked ] Item received[ some
/ get next item
items not in stock ]

[ All items checked &&

/ get first item Checking some items not in stock ]
do: check Waiting
item
Item received[ all
[ All items checked && items available ]
all items available ]
cancel
cancel
Dispatching
cancel
do: initiate delivery
Cancelled

deliver

Delivered

S. MBARKI 183
 Solution 2 : un état composite avec
des sous états

Active
[ not all items checked ] Item received[ some
/ get next item items not in stock ]

[ All items checked && some

/ get first item Checking items not in stock ]
Waiting
do: check cancelled
item Cancelled

[ All items checked && Item received[ all

all items available ] items available ]

deliver
Dispatching
do: initiate delivery Delivered

S. MBARKI 184
 Diagrammes d’états concurrents de la
classe “Commande”
Commande”

authorization
order handling (voir diagramme
d’activité)
Authorizing [ payment not ok ]
Waiting do: check payment

[ payment ok ]
Checking Dispatching

Authorized Rejected

Delivered

S. MBARKI 185
Diagrammes d’états concurrents de la
classe “Commande”
Commande”

Cancelled
order handling
Waiting

Checking Dispatching

Delivered

authorization
Authorizing Authorized
do: check payment

Rejected

S. MBARKI 186
Diagrammes d’états concurrents de
la classe “Commande”
Commande”
Les deux statecharts “order handling
handling”” et “authorization
“authorization”” se
déroulent en parallèle
Si un des deux statecharts arrive à son état final, il doit
attendre, dans cet état, la fin de son statechart concurrent
L’état « cancelled » peut être atteint depuis chacun des états
du statechart « order handling »
L’état « delivered » (positionné exactement en face de la
ligne pointillée) est atteint automatiquement quand les deux
statecharts se trouvent tous les deux dans leur état final
respectif (transition de synchronisation)
L’état « Rejected » (distinct de « cancelled ») est atteint
depuis l’état « authorizing »
S. MBARKI 187
Complémentarité entre diagrammes
d’états et diagrammes d’interaction
Les diagrammes d’états apportent précision et exhaustivité
Ils permettent de valider et de compléter les diagrammes
d’interaction
Ils peuvent également inciter à créer de nouveaux
diagrammes d’interaction
Si une interaction met en jeu deux objets a et b instances de
classes A et B alors les diagrammes d’états des classes A et
B doivent forcément être cohérents avec cette interaction,
même s’ils intègrent de nombreux autres comportements

S. MBARKI 188
 Exemple de cohérence entre
diagrammes d’états et diagrammes
d’interaction
[ autorisé ] / emprunter()

e0 : co : Copie Copie Copie

Emprunteur Disponible Empruntée
[autorisé] emprunter() remettre()
[nbrcpEmpr<Max]ajouterCpyEmpr(c0)

[ autorisé ET nbrcpEmpr<Max ] / ajouterCpyEmpr(c0)

remettre()

supprimCpyEmpr(c0)
Emprunteur
[délai dépassé] pénaliser()

[ délai remise dépassé ] / pénaliser(2jours)

Pénalisé
after 2 jours

S. MBARKI 189
Remarques

Un diagramme d’état est typiquement utilisé pour

décrire un objet d’une classe métier

Mais il est aussi utilisé pour décrire le cycle de vie d’un

sous système ou le système entier

Pas toutes les classes ont besoin d’un diagramme d’état

S. MBARKI 190