Uml Ibn Batouta 1

ANALYSE ET CONCEPTION ORIENTEE
OBJET
Définir les besoins pour une solution

logicielle
Prof. Zouhair IBN BATOUTA
Prof. Zouhair IBN BATOUTA 1

PLAN
Processus De Développement Logiciel
Spécification des exigences
Méthodes d’analyse : UML
Diagramme des cas d’utilisations
Diagramme de contexte statique et

dynamique
Diagrammes UML
Processus De Développement Logiciel Cascade

Déterminer les exigences fonctionnelles
 En ingénierie, et plus particulièrement dans les

procédures d'appel d'offres publiques et privées, les
exigences sont l'expression d'un besoin
documenté sur ce qu'un produit ou un service
particuliers devraient être ou faire.

La phase exigence
La phase de développement des exigences peut avoir été
précédée par une étude de faisabilité, ou une phase
d'analyse conceptuelle du projet. La phase d'exigences
peut être décomposée en :
 Mettre à jour les exigences: rassembler les exigences des
parties prenantes;
 Analyser : vérifier la cohérence;
 Définir: écrire les exigences sous une forme
aisément
compréhensible pour les utilisateurs et les développeurs ;
 Spécifier: créer une interaction initiale entre les exigences
et la conception.
Exigences produit & exigences de
processus
 Les projets sont soumis à trois sortes d'exigences :
 Les exigences métier. Elles décrivent ce qui doit être fourni ou
réalisé.
 Les exigences produit. Elles répondent aux exigences métier et
sont couramment formulées comme les fonctionnalités que le
système doit réaliser. On les appelle également exigences
fonctionnelles ou spécifications fonctionnelles.
 Les exigences de processus qui décrivent le comment. Ces
exigences prescrivent les processus que l'on doit suivre et les
contraintes auxquelles on doit se conformer pour la réalisation
du système. Dans ce cas, on trouve par exemple des exigences de
sécurité, d'assurance qualité, ou de management.
Les intervenants d’un projet informatique
 Le client
 Le prestataire SSII ou le service informatique de l’entreprise.
 La Maîtrise d’œuvre: représente le prestataire assure la
réalisation et le pilotage technique du projet
 La maîtrise d’ouvrage : représente le client et assure la
conformité du projet vis-à-vis de la demande du client.
 Le directeur du projet ou chef de projet est le responsable
de la mise en œuvre du projet dans le cadre du cahier des
charges, veille au respect des délais, à la qualité du travail et
dirige l’équipe affectée au projet Il s’appuie sur le Groupe de
Pilotage.
 Le responsable qualité
 Les utilisateurs sont les destinataires finaux du projet
 Fournisseurs peuvent fournir des matériels, logiciels, des
ressources humaines et des services
La modélisation du
système
Les méthodes d’analyse
Méthodes orientées comportement
 on s’intéresse à la dynamique du
système ex : réseaux de Pétri
Méthodes fonctionnelles :
 s’inspirent de l’architecture des
ordinateurs
 on s’intéresse aux fonctions du
système ex : SADT
Méthodes orientées données :
 on ne s’intéresse pas aux
traitements ex : MERISE
Méthodes orientées objets :
 on ne sépare pas les données et les
traitements ex : Booch, OMT, UML
Prof. Zouhair IBN BATOUTA 5
Genèse d’UML
 UML est le fruit de l’unification de 3 méthodes de
modélisation orientées objet
 OMT (Object Modeling Technique) : James Rumbaugh
 Booch : Grady Booch
 OOSE (Object Oriented Software Engineering) : Ivar
Jacobson
 UML est le fruit d’un consensus général

 élaboré avec le concours de la communauté des
utilisateurs
 UML est une notation (relativement) simple et non

propriétaire
 standardisé par l’OMG (Object Management Group)
Genèse d’UML
- UML
2.0
2002
- UML
1999 1.3
- 1997(Q4) U M L 1.1
- 1997 (Q1) UML

1.0
- U M L 0.9
1996
- Méthode unifiée 0.8
1995
- Booch’9 O M T-
1993 3 2
Autres méthodes O M T- O O SE Partenaires OMG

Booch’91 1

UML est une notation
 UML est un langage de modélisation objet

 Support des phases d’Analyse et de Conception orientée objet
 UML est un langage de communication

 utilisation d’un même formalisme par tous les intervenants
 permet de lever les ambiguïtés du langage naturel
 UML est un langage simple de haut niveau

 facile à appréhender car visuel
 indépendant de tout langage de programmation

UML est une notation
 UML est un langage semi-formel
 basé sur un méta-modèle décrit en UML
 les concepts manipulés et leur sémantique sont
clairement
établis par le méta-modèle
 les différents diagrammes sont cohérents entre-eux
 UML est largement outillé
 UML est un langage ouvert

 possibilité d’ajouter des notes (texte)
 utilisation de stéréotypes permettant d’étendre la notation,
améliorant ainsi la sémantique des éléments modélisés

UML n’est pas une méthode
 UML n’est pas une méthode, ce n’est qu’une
notation
 attente de la part des utilisateurs d’une
normalisation du
formalisme
 définir un processus de développement logiciel universel
est illusoire
 UML est indépendant de toute démarche
 ce qui en fait un langage universel
 mais favorise la mise en œuvre d’un processus itératif et
incrémental, fondé sur les cas d’utilisation et centré sur
l’architecture

Système réel
Analyse
Modèle Conception
Modèle de Réalisation
Modèle de Déploiement
Modèle de
d’Analyse Conception Réalisation Déploiement
BOOCH, OMT, OOSE,…
UML (Unified Modeling Language)

Types De Diagrammes UML
 Dans UML On distingue trois types de diagrammes UML
 Diagrammes Structurels ou Diagrammes statiques ( ce
que le système est)
 diagrammes de classes
 diagrammes d’objets
 diagrammes de composants
 diagrammes de déploiement
 diagramme des paquetages
 diagramme de structure composite

TYPES DE DIAGRAMMES UML
 Diagrammes Comportementaux ou Fonctionnel (ce que
le système fait)
 diagrammes de cas d'utilisation

 diagramme états-transitions
 diagramme d'activité
 Diagramme d'interactions ou Diagrammes d

interactions dynamiques (comment le système évolue)
 diagrammes de séquence
 diagramme de communication
 diagramme global d'interaction
 diagramme de temps
UML est une proposition complexe et en constante évolution dont nous n’étudions
que les bases.
conceptuel physique
la structuration
des objets les composants
Vue logique Vue logiciels
statique implantation
Diagrammes
classes, objets, Diagrammes
collaborations, composants
séquences
les fonctions Vue externe
du système cas
d’utilisation
Vue logique Vue
dynamique déploiement
la dynamique Diagrammes
des objets l’architecture
Diagrammes déploiement physique
états, activités
concepts utilisables tout au long du projet

analyse  conception  implantation
Diagramme des cas d’utilisation
(Use Cases)

Cas d’utilisation (Use Cases)
Objectifs
 Définir les besoins fonctionnels du système

Les cas d’utilisation ont pour principal objectif la capture des
fonctionnalités couvertes par le système
 Définir le périmètre fonctionnel du système

Les cas d’utilisation permettent de définir les frontières
du
système avec son environnement
 Définir le dialogue entre l’utilisateur et le système

Les cas d’utilisation recensent comment l’utilisateur
interagit avec le système
16
Cas d’utilisation (Use Cases)
Objectifs (suite)
 Etablir les scénarios fonctionnels qui seront utilisés pour la

recette du système
Les cas d’utilisation recensent et décrivent les
principales
fonctionnalités attendues du système
 Servir de support de référence tout au long des phases de

développement du système
Les cas d’utilisation seront consultés et référencés tout
au long du processus de développement du système 17
 Décrivent le comportement du système (actions

et de réactions), selon le point de vue de
l’utilisateur
 Chaque cas d’utilisation décrit le comportement
du système suite à une stimulation externe
 Modèle
Acteurs + Cas d’utilisation + Relations
Exemple Diagramme de cas
d’utilisation (Notation)
30
Cas d’utilisation
(Définition)
Un cas d’utilisation est une séquence d’activités ou
d’actions organisées en étapes distinctes, et qu’un système
effectue
en réponse à une sollicitation extérieure
 Le cas d’utilisation est déclenché par un événement extérieur au
système appelé événement initiateur
 Le cas d’utilisation possède un nom : celui de la fonctionnalité

du système qu’il prend en charge
 Le cas d’utilisation met en œuvre un dialogue entre le système

et l’entité à l’origine de l’événement initiateur
19
Cas d’utilisatio n
(Notation)
• Un cas d’utilisation est Notation
représenté par un
ovale
• Le nom du cas
d’utilisation apparaît à
l’intérieur de l’ovale.
Il est composé : DAB::Retirer argent
- d’un nom optionnel
de
paquetage
- du nom de la
fonctionnalité
qu’il prend
en charge 20
Description d’un cas
d’utilisation
 Titre (commence par un verbe)
 Objectif (descriptif court : une phrase si possible)
 Acteurs
 Pré-conditions
 conditions nécessaires pour que le cas d’utilisation s’exécute
 Scénario nominal
 description pas à pas textuelle
1. Introduire la carte
 chaque étape du cas d’utilisation est numérotée 2. Taper le code
 Exceptions 3. …
 Post-conditions
 état d’une partie du système après l’exécution du cas
d’utilisation
 Fréquence & performance requises
© 2011 KARIM LAMIAA 21
Comment déterminer les cas
d’utilisation
Se poser les questions suivantes :
 Quelles sont les grandes fonctionnalités attendues

du
système ?
 Le système doit-il informer une personne ou un
dispositif extérieur lorsque son état interne est modifié ?
 Le système doit-il être informé d’événements extérieurs se
produisant dans son entourage ?
 Le système stocke-t-il des informations ? Comment
sont- elles stockées, mises à jour, détruites ?
 …
22
Acteur
(Définition)
Un acteur définit un rôle qu’une entité extérieure
assume lors de son interaction avec le système
 L’acteur est à l’origine des événements initiateurs reçus
par le système
 L’acteur dialogue par la suite avec le cas d’utilisation dont
il est l’initiateur
 L’ acteur possède un nom : celui du rôle qu’il joue lors de
son interaction avec le système
 L’acteur n’est pas forcément humain. Il peut s’agir :
 d’un autre système
 d’un équipement
23
Acteur
 « Pierre utilise le système pour gérer son agenda »
 « Philippe utilise aussi le système pour gérer son agenda.
Mais Philippe est aussi autorisé à administrer le système
»
 Pierre n’est pas un acteur du système, Philippe n’est pas
un acteur du système
 Le rôle « Utilisateur » est un acteur du système
 Le rôle « Administrateur » est un acteur du système
Ne pas confondre personne physique et rôle

Une personne peut très bien assumer plusieurs
rôles
et réciproquement
24
Catégories d’acteurs :
Lorsqu’un cas d’utilisation rend service principalement à un acteur
lors cet acteur est qualifié de principal : stéréotype « primary»
 Les autres acteurs sont alors qualifiés de secondaires : stéréotype <<
secondary >>
Remarques :
 Un cas d’utilisation a au plus un acteur principal.
 Un acteur principal obtient un résultat observable du système
tandis qu’un acteur secondaire est sollicité pour des informations
complémentaires.
 En général l’acteur principal initie le cas d’utilisation d utilisation
sollicitations.
 Cas d’utilisation interne :
Quand un cas n’est pas directement relié à un acteur, il est
qualifié de cas d’utilisation interne
25
Acteur
(Notation)
• Un acteur est représenté
Notation
par un petit personnage
• Le nom de l’acteur
apparaît sous le petit
personnage
• On peut définir des Utilisateu
catégories d’acteurs r
plus générales
ou
au contraire spécialiser
un type d’acteur Utilisateu Utilisateu
r r
26
Prof. Zouhair IBNexterne
BATOUTA interne
Comment déterminer les
acteurs
Se poser les questions suivantes :
 Qui installe le système ?

 Qui utilise le système ?
 Qui démarre le système ?
 Qui maintient le système?
 Quels sont les autres systèmes qui utilisent le système ?
 Qui fournit de l’information au système ?
 Qui récupère de l’information à partir du système ?
 …
27
Diagramme de cas d’utilisation
(Définition Rappel)
Le diagramme de cas d’utilisation est une représentation
contextuelle de haut niveau du système modélisé
 Permet de définir de manière précise les frontières

du
système à modéliser
 Montre les interactions entre le système et

son environnement extérieur
 Montre les dépendances existant entre les

cas d’utilisation 28
Diagramme de c as d’utilisation
(Notation)
Le diagramme de cas Notation
d’utilisation met en
scène :
- les acteurs Cas d’utilisation 1
- les cas d’utilisation

- les interactions entre
acteurs et cas Acteur 1
Cas d’utilisation 2
d’utilisation
- les dépendances entre
cas d’utilisation Cas d’utilisation 3
Acteur 2
29
Diagramme de cas d’utilisation
(Notation)
30
Interaction entre a cteur et cas
d’utilisation
• Elle est représentée par Retirer
une association sous la argent

1
forme d’un lien
éventuellement orienté 1
dans le sens de
l’interaction
Client
• Une seule association est 1
utilisée pour représenter Déposer

l’ensemble des événements argent
échangés
• L’association peut comporter 1
des cardinalités *
31
Prof. Zouhair IBN BATOUTA Consulter compte
Dépendances entre cas d’utilisation
Il existe 3 types de dépendances entre use cases :
 Les dépendances d’utilisation

Mise en facteur de séquences d’événement communes
 Les dépendances d’extension

Externalisation de séquences d’événement
exceptionnelles
 Les dépendances de généralisation

Généralisation / spécialisation de cas
d’utilisation 32
Dépendance d’utilisation
• Indique qu’un cas d’utilisation
utilise systématiquement
Notation « include »
et intégralement une Authentifier

séquence d’activités décrite carte
« include »
dans un autre cas Cas d’utilisation 2
d’utilisation
• Est représentée par une Acteur 1
flèche pointillée
étiquetée
« include », pointant
vers le Le cas d’utilisation 1 utilise
cas d’utilisation utilisé systématiquement le cas d’utilisation 2
Prof. Zouhair IBN 33

BATOUTA
• Le cas d’utilisation source Notation
1. Etape 1
de la dépendance 2. Etape2
3. Etape3 (include)
d’utilisation contient une 4. …
référence vers le
cas d’utilisation
inclus Cas d’utilisation 1 Authentifier
carte
« include »
• L’inclusion est signalée par
le texte « (include) » à Cas
d’utilisation 2
l’étape correspondante
Acteur 1
34
Retirer
« include »
• Permet de décomposer argent

« include »
un cas d’utilisation Authent
ifier
complexe en cas Client
Déposer
carte
d’utilisation plus simples Acteur 1

Déposer
argent
argent
• Permet de factoriser des Retirer
comportements utiles à argent « include »
plusieurs cas d’utilisation « include » Authentifier

carte
Client
Déposer
argent
35
Dépendance d’ extension
• Indique qu’un cas Notation Cas d’utilisation 1
d’utilisation utilise
facultativement ou sous
certaines conditions une
séquence d’activités décrite Cas d’utilisation 2
dans un autre cas « extend »
d’utilisation
• Est représentée par une Cas d’utilisation 2

flèche pointillée étiquetée Utilisateur
« extend », pointant vers le
cas d’utilisation étendu
Le cas d’utilisation 2 est une

extension du cas d’utilisation 1
36
• Le cas d’utilisation étendu
contient une liste de Notation C
a
points d’extension s
d
• Un point d’extension est ’
u
t
composé d’un nom suivi i
l
i
d’un numéro d’étape s
a
(emplacement) t
i
o
• Le cas d’utilisation qui étend n
1
indique dans sa description
Points d’extension :
sous quelles conditions il . point extension1 : emplacement1
se déclenche . point extension2 : emplacement2
« extend »

Utilisateur
• Permet d’ajouter à un cas Retirer argent
d’utilisation un « include »
Points d’extension :
comportement exceptionnel . Guichet vide : avant étape 1
. Carte invalide : avant étape 2Authentifier
complexe (hors cas nominal) carte
• Détermine les conditions Cas d’utilisation 2

« extend »
d’application d’un
comportement alternatif au
cas nominal
Traiter authentification
• Déporte la description incorrecte
d’une exception significative Client
dans un cas d’utilisation

Si le code fourni est incorrect
Au point « Carte invalide » :
1.Alerter le client
2.Redemander la saisie du code
3. …
38
• Un comportement Retirer argent
exceptionnel complexe Points d’extension :

. Guichet vide
d’un cas d’utilisation doit être : avant étape 1
déporté dans un cas d’utilisation . Carte
invalide : avant étape 2
avec une dépendance « extend
»
• Un comportement « extend »
Traiter
exceptionnel simple doit authentification
être explicité dans le e
incorrect
paragraphe
« Exceptions » de la •Titre
description du cas d’utilisation •Résumé (une phrase)
•Acteurs
•Pré-conditions
•Scénario nominal
•.Exceptions
Exception
•
s Post-conditions
39
Dépendance de Généralisation
/spécialisation
• Indique qu’un cas Notation « include »
d’utilisation est une
spécialisation d’un autre Cas d’utilisation 1 Authentifier
carte
cas d’utilisation Cas d’utilisation 2
• Est représentée par

Acteur 1
une flèche « Cas d’utilisation 2
d’héritage » pointant
du cas
d’utilisation spécialisé vers
Le cas d’utilisation 2 est une spécialisation
le cas d’utilisation le plus du cas d’utilisation 1
général
40
Dépendance de Généralisation
/spécialisation
• Permet de factoriser un
Notation « include »
comportement commun Retirer argent
à un ensemble de cas Authentifier

carte
d’utilisation proches Cas d’utilisation 2
• Le cas d’utilisation le plus Retirer argent

avec ticket
général est dit abstrait Utilisateur <<Abstract>>
Ouvrir compte
si seuls les cas
d’utilisation spécialisés
sont exécutables
Ouvrir compte
chèque Ouvrir compte
épargne
41
Exemple 2:
Exemple 3:
Entre acteurs

Mise en œuvre des cas d’utilisations

 Identifier la plupart des cas d’utilisations (<20)
 Décrire briévement chaque cas d’utilisation (2 à 3 phrases)
 Décrire en détails chaque cas d’utilisation
 Debut
 Fin
 Interaction entre acteur et le cas d’utilisation
 Chronologie
 Echange d’informations

Recommandations
 Ne pas confondre cas d’utilisation et scénario
 Chaque cas d’utilisation correspond à un objectif d’un acteur vis à vis du
système
 Un scénario décrit le déroulement d’un cas d’utilisation
 Ne pas oublier les scénarios correspondant aux principaux cas d’échec du
cas d’utilisation (mot de passe invalide, carte de crédit invalide, article du
catalogue indisponible ou en nombre insuffisant…)
 Ne décrire que les principaux cas d’utilisation du système

Un cas d’utilisation doit contenir une quantité « appréciable et
tangible » de travail
 Ne pas décomposer trop finement les cas d’utilisation

Les dépendances d’utilisation et d’extension ne doivent être utilisées
que pour des comportements significatifs du système
47
Recommandations (suite)
 Lorsque le système est complexe, il n’est pas anormal
d’avoir de nombreux cas d’utilisation. Il faut alors les
classer et les rassembler dans des bibliothèques de cas
d’utilisation
  on définit pour cela des paquetages (notion abordée
dans
ce cours)
 Lorsque le système est complexe, les cas d’utilisation

peuvent s’emboîter les uns dans les autres. Veiller à ne
pas mélanger un cas d’utilisation « générale » (exemple :
prendre une commande) avec des cas d’utilisation plus
fins (exemple : choisir son mode de paiement)
  Utiliser les relations de dépendance entre cas
(notamment les include)
48
Diagramme de Contexte
Les Diagramme de contexte statique
Les Diagramme de contexte dynamique

Les Diagramme
permet de décrirede
les contexte statique
acteurs du système.
spécifie le nombre d’instances d’acteurs reliées au système à
un moment donné.
 Ce diagramme est un diagramme de classe UML ne faisant
intervenir que les acteurs et le système

diagramme de Contexte statique (boite
noir)

représente de façon synthétique les messages

Les Diagramme de contexte dynamique
Système <-> Acteurs identifiés.
en utilisant les règles suivantes.

Le système est l’objet principal
Il est entouré d’acteurs
Des liens relient le système aux acteurs : sur chaque lien sont
montrés les messages en entrée et en sortie du système.

diagramme de Contexte dynamique

Exercice
d’application
 Un opérateur Télécom désire disposer d’une plateforme
d’achat en ligne ou les clients peuvent consulter
ou/et commander les produits qui sont disponibles
sur un catalogue.
 Les administrateurs de FT sont responsables de la mise
à jour des produits et du traitement des commandes
effectués par les clients.
10/08/2012
Corrigé
Identification des acteurs :
- Administrateur
- Client
 Identification des cas d’utilisations
:
- Consulter le catalogue
- Commander un produit
- Mettre à jour le catalogue
- Traiter une commande
10/08/2012
Corrigé
Commander
un produit
Consulter le
catalogue
Client
Mettre à jour
le catalogue
Administrateur
Traiter la
commande
10/08/2012
Corrigé
Description textuelle du cas d’utilisation
 Nom du cas d’utilisation : Mettre à jour le catalogue
 Acteurs déclencheurs : Administrateur.
 Contexte de déclenchement: l'acteur sélectionne la mise à jour
d’un
catalogue.
 Pré-conditions : l’acteur s’est connecté au système et choisit
un catalogue
 Description du UC : permet à l'acteur de gérer un catalogue à
savoir : l’ajout, la modification et la suppression du catalogue.
 Post-conditions : le catalogue est mise à jour.
 Scénario nominal :
1.Connexion au système ;
2. Sélection d’un catalogue
3. Mise à jour du catalogue.
10/08/2012
Conclusion
 L'objectif poursuivi par les cas d'utilisation est de
permettre de décrire, dans des documents lisibles
par tous, la finalité des interactions du système et
de ses utilisateurs.
Ils ne doivent pas chercher l'exhaustivité,
mais clarifier, filtrer et organiser les besoins !
 Après avoir rédigé les cas d’utilisation, il faut identifier

des objets, des classes, des données et des
traitements qui vont permettre au système de
supporter ces cas d’utilisation.
Exercices: Passage 1
10/08/2012
10/08/2012


Corr : Passage 1

Corr : Passage 2

Corr : Passage 3

Corr : Passage 4

S cénario
Le scénario est au cas d’utilisation
ce que l’objet est à la classe
 Un cas d’utilisation propose un comportement nominal

(scénario nominal)
 Un cas d’utilisation propose aussi un ou plusieurs
comportements alternatifs (scénario alternatif) chacun
représentant un cheminement particulier dans le cas d’utilisation
 Un cas d’utilisation décrit aussi des situations exceptionnelles
 L’idéal est de créer suffisamment de scénarios couvrant
l’essentiel d’un cas d’utilisation
 Il est inutile d’identifier tous les scénarios possibles
42
Exemple de scénario (I)
 CAS D’UTILISATION: prendre une commande
 Nom : prendre une commande
 Contexte : système de prise de commande par
téléphone pour un club de loisir…

 Objectif : le membre, après avoir consulté son
catalogue, téléphone pour commander

 Scénario :
 # 1 : le télévendeur identifie l’internaute

 # 2 : le membre choisit les articles commandés
 # 3 : le système accepte la commande
 # 4 : le système envoie la commande à la logistique
43
Exemple de scénario (II)
 Le scénario décrit est le scénario « idéal »!
 Que se passe-t-il si….

 L’internaute n’est pas un membre du club ?
 Il n’y a pas assez d’article en stock ?
 Il n’y a plus d’article en stock ?
 L’internaute a eu un incident de paiement par le passé ?
 …
44
Exemple de scénario (III)
 CAS D’UTILISATION
 Nom : prendre une commande
 Contexte : système de prise de commande par téléphone pour un
club de loisir…
 Objectif : le membre, après avoir consulté le catalogue, téléphone
pour commander
 Scénario :
 # 1 : le télévendeur identifie l’internaute
 # 2 : le membre choisit les articles commandés
 # 3 : le système accepte la commande
 # 4 : le système envoie la commande à la logistique
 Extensions :
 # 1a : l’internaute n’est pas membre…
 # 2a : un des articles n’est pas en nombre suffisant : proposer une
réduction du nombre d’article ?
 # 3a : l’internaute a eu un incident de paiement : est-il VIP ?
011 KARIM LAMIAA 45

Diagramme d’activité
En plus de descriptions textuelles, le scénario peut être représenté en
utilisant un diagramme d’activité
Un cas d’utilisation montre ce que fait ou doit faire le système. Un
diagramme d’activité permet de spécifier comment le système accomplit
les fonctionnalités demandées.
Un diagramme d’activité montre les actions à un très haut niveau
d’abstraction avec les interactions entre elles.
 Dans la pratique, les diagrammes d’activité sont bien adaptés à cette
phase de l’analyse qui consiste en l’expression des processus
métier comme un ensemble d’actions coordonnées pour atteindre un
Le diagramme d’activité permet de :
Présenter « l’algorithme », c’est-à-dire les étapes de la fonctionnalité
(workflow)
Visualiser l’aspect temporel des interactions
Connaître le sens des interactions (acteur vers système ou inverse)
Distinguer le cas nominal des variantes (p.ex. avec traitement des
erreurs)

Actions et choix

Concurrence (parallélisme)

Exemple

Diagramme de classes

Sommaire
 Introduction
 Objectifs
 Diagramme de classes
 Classe (Nom, attribut, opération)
 Visibilité et portée des constituants d’une classe
 Association (Nom, rôles)
 Association réflexive
 Navigabilité d’une association
 Contraintes sur association
 Qualificateur d’une association
 Classe associative
 Types d’association (Agrégation, composition,
généralisation / spécialisation)
 Classe et opération abstraites
52
 Apport en grande partie de méthode
la (Rumbaugh) OMT
 S’apparente à un diagramme entité-association

(MERISE). Il présente les différents objets (classes)
du système ainsi que les liens entre ces objets
(associations)
 Diagramme le plus important dans une

modélisation objet
53
Objectifs
 Déterminer les données qui manipulées par le

seront
système
Ces données sont organisées en classes
 Donner la structure statique de ces données
Ce diagramme permet de décrire la structure interne
de chacune des classes
 Représenter les relations statiques existant entre

les différentes données du système
54
Objectifs (suite)
 Faire abstraction des aspects temporels

et dynamiques de la modélisation
Seul l’aspect statique compte, la dynamique
est prise en charge par d’autres modèles
55
D iagramme de
( classes Définition)
Le diagramme de classes est un diagramme
entités-associations décrivant les différentes classes,
leur structure et les associations statiques les
unissant
 Le diagramme de classes est un diagramme structurel ne
présentant que les classes et pas les instances de classe
 Il permet de décrire la structure interne des classes en terme

d’attributs et d’opérations
 Il permet de représenter les associations statiques entre les

classes, mais ne décrit pas comment les liens effectifs entre les
instances sont effectués
56
Exemple
Clien CompteCourant
1 0..
t
possède 1
*
1
souscri achèt
t e
0.. *
1
Plan Epargne Actions
Actions
Classe
(Définition)
Une classe est une abstraction de choses
du monde réel possédant des caractéristiques
et des comportements communs
 La classe est la fabrique, le moule, à partir duquel

on fabrique les instances (les objets)
 Seules les caractéristiques pertinentes pour

le
problème étudié entrent dans la composition de la classe
58
Classe
A bstraction
Abstraction
Chien Personne
age age
pedigree nationalit
courir() é
aboyer() se promener() 59
crier()
Classe
(Notation)
 Une classe Notation
est
représentée par un
rectangle découpé
en 3 parties
<< Stéréotype >>
Nom paquetage :: Nom classe
 Sont présents :
 le nomde Attributs
la classe
 la listede Opérations
ses attributs
 la listede
ses opérations
60
Nom de la classe
 Le nom d’une login :: Code secret

Compte
classe abstraite
N°
est donné en Code
Italique Créditer(
)
 Le nom de la Débiter()
classe est préfixé
par un nom de
paquetage si la
classe est externe Compte chèque
au paquetage
N° de compte
courant
61
Attribut de la classe
(Définition et notation)
Un attribut est une caractéristique intrinsèque
partagée par tous les objets d’une classe
 L’attribut possède un nom

unique dans la classe Notation
 On associer à
peut type des Nom paquetage :: Nom classe
l’attributqu’il peut prendre
valeurs nomAttribut1 : typeAttribut1 = valeurInitiale1
…
nomAttributN : typeAttributN = valeurInitialeN
le
 On peut donner
une 62
valeur initiale à l’attribut
Recommandations pour trouver les
attributs
Les 3 règles d’or de l’attribut :
 Eliminer les attributs caractérisant une autre classe

ex : l’attribut « nom client » dans la classe «
compteBancaire »
 Se méfier des attributs multi-valués, ils cachent souvent eux-

mêmes une classe
ex : l’attribut « enfants » dans la classe « Personne »
 Se méfier des attributs structurés, ils cachent souvent eux-

mêmes une classe
ex : l’attribut « Adresse » dans une classe « Personne » 63
Recommandations pour trouver les
attributs
 Ne donner les types et les valeurs initiales
des attributs qu’en phase de Conception
 Lorsqu’une classe possède de très nombreux

attributs se poser la question du découpage
de la classe
64
Opération de la classe
Une opération est un service que propose
une classe sur son interface
 L’opération possède un nom

pas forcément unique dans Notation
la classe
 On peut associer à l’opération Nom paquetage :: Nom classe

ses arguments
nomOpération1 (nomArg1 :TypeArg1 = valeurParDéfaut1, ...)

 On peut associer à l’opération : typeRetour1
son type de retour …
nomOpérationN (nomArgN :TypeArgN = valeurParDéfautN, ...)
: typeRetourN
65
Opération de la classe
Recommandations pour
trouver les opérations
 Ne donner les informations sur les arguments

et le type de retour qu’en phase de
Conception
 Lorsqu’une classe possède de très

nombreuses opérations se poser la question
du découpage de la classe
66
Exemple de classe
Compte
numero
solde
effectuerVirement()
Accesseurs
getSolde()
setSolde()
getNumero()
setNumero()
67
Visibilité et Portée
des constituants de la classe
 La visibilité précise Notation
manière
la dont un nom peut
être vu et utilisé par les Nom Classe
autres (public, protégé,
privé)
+Attribut public
#Attribut
 La portée précise protégé
quel contexte un dans -Attribut privé
prend sa nom Attribut de
signification classe
(instance ou classe) ~ Paquetage
/Attribut dérivé
 Par défaut, la visibilité est
+Opération publique()
publique et la portée est #Opération protégée()
d’instance -Opération privée() 68
Opération de
Association
(Définition)
Une association est une abstraction de liens
qui peuvent exister entre les instances de plusieurs classes
 Dans le monde réel, les objets sont liés physiquement ou

fonctionnellement les uns avec les autres
 Ces liens entre objets se traduisent au niveau des classes

par des associations
 Une association traduit donc une relation

structurelle
statique entre deux ou plusieurs classes 69
Association
A bstraction
Abstraction
Chien Personne
Abstraction
âge
âge
nationalit
courir() é
aboyer() se promener() 70
2011 KARIM LAMIAA crier()
Association
(Notation)
 Une association est représentée au moyen d’un
trait
orienté reliant chacune des classes concernées
 Il est possible de nommer l’association et de préciser les
rôles tenus par chaque classe
Notation
Client achète Voiture
Personne salarié Société

Nom de l’association
 Le nom de l’association est

en général une forme Notation
verbale ou passive
qui décrit globalement le lien
active
 Le nom de l’association est Client Voiture

achète
facultatif
 Le nom doit apparaître sur

l’association, mais ne doit
pas être rattaché à l’une des
extrémité
72
Rôles de l’association
 Le rôle permet de décrire, à

l’aide d’un nom, comment une Notation
classe perçoit une autre classe
au travers de l’association
 Un rôle doit figurer à

l’extrémité de
qu’il qualifie l’association Personne salarié
Société
 Les rôles sont facultatifs employeur

L’association peut faire figurer
les deux, un seul ou aucun des
rôles
73
Association binaire et n-aire
Une association binaire est matérialisée par un trait
plein entre les classes associées.Elle peut être
ornée d’un nom, avec éventuellement une précision
du sens de lecture (▸ ou ◂).
Quand les deux extrémités de l’association pointent
vers la même classe, l’association est dite réflexive.
74
Association n-aire
 Une association n-aire lie plus de deux
classes.
75
Nom et rôles de la classe
(Recommandations)
 L’utilisation du nom et des rôles d’une association

n’est
pas exclusif
 Cependant, les deux notations sont rarement utilisées

conjointement
 L’usage du nom et des rôles n’est pas obligatoire, mais il

s’avère indispensable si deux objets sont reliés par
plusieurs associations ou si une association est réflexive
76
Association réfl exive
 Une association peut Client Voiture

achète
mettre en jeux deux
classes distinctes
Exemple d’association classique
 Mais, elle peut aussi Vit en couple avec
apparaître sur une

seule et même classe Personne
Dans ce cas précis,

l’association est dite Exemple d’association réflexive
réflexive
77
Navigabilité de l’association
 La navigabilité d’une
association permet de
définir quel
l’association
dans peut sens Notation
parcourue être
Personne a
Film
 La navigabilité
vu
association
d’une est
par
modéliséeune flèche sur
l’extrémité être
Chaque personne a accès aux films qu'elle a déjà vus,
atteinte
pouvantpar navigation mais à partir d'un film, on interdit de retrouver la liste
des personnes l'ayant vu
 La navigabilité peut être bi-
directionnelle
L’absence de flèche sur les Client achète Voiture
deux extrémités signifie que
l’association est bi-
directionnelle
L’association peut être parcourue dans les deux sens
78
Multiplicités de l’association
 La multiplicité
Notation
associée est
à extrémité une Personne emploie Société
l’association de
indique combien 1 ..*
1
d’instances de et la Une société emploie de une à plusieurs personnes
Une personne est employée par une seule
classe société
considérée
peuvent être liées à Client achète Voiture
une instance de
l’autre classe 0..1 *
Un client achète zéro à plusieurs voitures
Une voiture peut être achetée par un client au plus
79
Multiplicités de l’association
La multiplicité est une spécification respectant les
conventions suivantes :
1 : un et un seul (notation facultative)
0..1 : zéro ou un
N : exactement N (N: entier naturel)
M..N : de M à N (deux entiers naturels)
* : de zéro à plusieurs
0..* : de zéro à plusieurs
1..* : de un à plusieurs
N..* : N ou plus (N: entier 80
naturel)
Contraintes sur association
D’autres types de contraintes existent sur

une association :
 Des contraintes prédéfinies :
 Les contraintes ensemblistes :
{Sous- ensemble}
 Les contraintes
d’ordonnancement :
{Ordonné}
 Les contraintes d’exclusion : {Ou - exclusif}
81
Contraintes ensemblistes sur
association
 Ce type de contrainte permet de modéliser le
cas où un ensemble d’associations est
inclus dans un autre ensemble d’association
Notation
* est nominé *
Prix Personne
{Sous-ensemble}
* est lauréat 1
Les personnes lauréates d’un prix sont obligatoirement choisies parmi celles qui
sont nominées pour ce prix
Contraintes d’ordonnancement sur
association
 Ce type de contrainte permet de modéliser le cas
où pour une instance donnée, l’ensemble des
instances avec lesquelles elle est en relation doit
être ordonné
Notation
{Ordonné}
0..* 0..6
Grand prix est dans
Pilote
les points
Lors d’un grand prix au maximum 6 pilotes peuvent être dans les points
Ces 6 pilotes sont classés à l’arrivée
Contraintes d’exclusion sur association
 Ce type de contrainte permet de modéliser le cas
où pour une instance donnée d’une classe, une
seule association prise parmi plusieurs possibles,
peut être valide à un instant donné
Notation
employé
Société Personne
0..*
{Ou - exclusif}
employeur
Une personne peut être soit employée par une société, soit
employeur
d’une société
Mais une personne ne peut pas être à la fois employeur et employé
Navigabilité
 La navigabilité indique s’il est possible de traverser une
association.
On représente graphiquement la navigabilité par une flèche du côté
de la terminaison navigable et on empêche la navigabilité par une

croix du côté de la terminaison non navigable.
 Par défaut, une association est navigable dans les deux sens.
 la terminaison du côté de la classe Commande n’est pas
navigable : cela signifie que les instances de la classe Produit ne
stockent pas de liste d’objets du type Commande. Inversement, la
terminaison du côté de la classe Produit est navigable : chaque
objet commande contient une liste de produits.
 Implicitement, ces trois notations ont la même sémantiq
85
Qualificateur d’une association
 Le qualificateur est un attribut ou un ensemble
d’attributs permettant de partitionner l’ensemble
des instances d’une classe qui sont en relation
avec une instance donnée
 Le qualificateur permet de restreindre la
multiplicité de l’association
Notation
Classe A Qualificateur Classe B
Qualificateur = attribut1, …,
attributN
Qualificateur d’association
Exemples
1..*
Université Salle
possède
Une université possède de une à plusieurs

salle(s)
Une salle appartient à une et une seule
université
0..1
Université numéro Salle
possède
Une université possède au plus une salle ayant ce

numéro Une salle appartient à une et une seule
université
Classe associative
 Une association peut être
matérialisée par une classe dans Notation
une des circonstances suivantes
:
 si l’association est porteuse
d’attributs
 si l’association se matérialise
par un objet concret dans le Classe A Classe B
monde réel
 si l’association est de
multiplicité M .. N
 Une classe associative est une
classe à part entière Classe associative
 Elle est modélisée par un lien en
pointillé allant de la classe vers
l’association concernée
88
Classe associative
Exemples
Société Personne
1..*
nom nom
numSiret prenom
adresse age
Emploi
fonctio
n
salaire
Etudiant Concours
nom
1..* 1..* nom école
prénom date
lieu
adresse
note
Résultat
Les différents types
d’association
Il existe plusieurs types d’association
 L’agrégation
Forme spéciale d’association entre un tout et une partie
 La composition
Forme spéciale d’agrégation où le cycle de vie de la partie est
régi par celui du tout
 L’héritage
Forme spéciale d’association permettant de factoriser les
caractéristiques et comportement communs à un ensemble
de classes
 L’association simple
Ce sont les associations qui ne se réclament d’aucune
des catégories précédemment citées
90
Agrégation
 Une agrégation est une association non symétrique dans laquelle
l’une des deux classes joue un rôle prépondérant
 Une agrégation est une relation tout-partie entre un agrégat (le tout)
et un composant (la partie)
 L’agrégation est représentée par un losange blanc du côté de l’agrégat
 Le composant peut appartenir simultanément à plusieurs agrégats
 Le cycle de vie des composants n’est pas tributaire de celui de
l’agrégat
CLAVIER
ORDINATEUR
0..*
COMPOSANT
© 2011 KARIM LAMIAA COMPOSEE 91
AGREGAT
Composition
 Une composition est une agrégation à part entière
 La composition est représentée par un losange noir du côté
de l’agrégat
 Le composant ne peut pas appartenir simultanément
à plusieurs agrégats (multiplicité 1 ou 0..1 côté agrégat)
 Le cycle de vie des composants est tributaire de celui
de l’agrégat
HOMME TETE
possède
Université Salle
1..*
Une université est composée de une à plusieurs salles

Une salle n’appartient qu’à une et une seule université
Composition : abus de
langage !
 Attention : on parle très souvent de composition
pour désigner une simple association entre deux
classes. Cela ce traduit par l’existence d’un attribut
qui référence une (des) instance(s) d’une autre
classe.
*
Personne Compte
Une personne possède des comptes mais n’est pas composée de

comptes
93
Généralisation / Spécialisation
 La généralisation /
spécialisation est une Notation
relation de classification
entre une classe plus
générale et une classe plus Super-classe
spécialisée
Spécialisation
 On l’appelle aussi relation

d’héritage ou relation « Généralisation
est- une-sorte-de »
Sous-classe
 La généralisation est
représentée au moyen d’une
flèche pointant de la classe
la plus spécialisée vers la
classe la plus générale 94
Généralisation / Spécialisation
Exemple
Compte
numér
o
solde
getSolde()
CompteCourant CompteEpargne
montantDécouvertAutorise tauxEpargne
getDecouvert() calculerIntérêts()
95
Classe et opérati on abstraites
 Une classe abstraite est une classe
pour laquelle il n’est pas possible de
créer d’instances directement
Son nom est écrit en italique Forme géométrique
 Une opération abstraite d’une

classe A est une opération ne
Dessiner()
possédant pas d’implémentation
dans A mais qui doit obligatoirement
être implémentée dans les sous-
classes de A
Sa signature est écrite en italique
stéreotipe Abstract Rectangle
 Toute classe contenant au moins une
opération abstraite est abstraite
Rond Dessiner() Dessiner()
96
Discriminant s ur relation
d’héritage
 La spécialisation d’une
super-classe peut avoir
lieu selon différents
critères simultanés
Personne
 Chacun de ces critères
est représenté par une sexe travail
chaîne de caractères et
s’appelle un discriminant
Homme Femme Etudiant
Employé
 Le discriminant est
positionné à côté de la
sous-arborescence qu’il
qualifie
97
Discriminant sur relation d’héritage

Discriminant sur relation d’héritage

(Recommandations)
 Toujours garder à l’esprit qu’un diagramme de
classe propose une vision statique des données
du problème
 Les associations d’un diagramme de classes

sont statiques, mais la création des liens entre
objets est dynamique
 Ne jamais hésiter à donner les multiplicités
98
Implémentation : Héritage
public class Personne {

public String nom;
public String prenom;
}
public class Etudiant extends Personne {

public int noEtudiant;
}
Implémentation : Associations
public class Personne {
public String Nom;

public String prenom;
public java.util.Collection voiture =
new java.util.TreeSet();
}
public class Voiture {
public String immatriculation;

public Personne Propriétaire;
public void demarer() { }
}
public class ServiceContraventions {
public java.util.Collection Voiture = new java.util.TreeSet();

}
Implémentation : Agrégation
public class Enseignant extends Personne {

public String telephone;
public java.util.Collection equipeRecherche = new java.util.TreeSet();
public Departement departement;
}
public class Département {

private int nomDépartement;
private int codetheme;
public java.util.Collection enseignant = new java.util.TreeSet();
}
Implémentation : Composition
public class EquipeRecherche {

public String[] nomEquipe;
public String thématique;
public java.util.Collection enseignant = new java.util.TreeSet();
public Laboratoire laboratoire;
}
public class Laboratoire {

public java.util.Collection equipeRecherche = new java.util.TreeSet();
}
Le diagramme d’objet
Diagramme d’objets
Objectifs
 Un diagramme d’objets peut être considéré comme

un cas particulier d’un diagramme de classes.
 Les diagrammes d’objets utilisent un sous-ensemble
des éléments d’un diagramme de classes afin de
souligner la relation entre les instances de classes à
un certain moment.
 Ils sont utiles dans la compréhension des
diagrammes de classe
Objectifs
 Illustrer par un exemple concret un diagramme de

classes
 Faciliter la validation d’un diagramme de classes

complexe en présentant une ou plusieurs
instanciation de celui-ci
 Visualiser un instantané de l’état d’un système

(Définition)
Un diagramme d’objets est une instance
d’un diagramme de classes
représentant des objets et les liens qui les
unissent
 Un diagramme d’objets est un graphe représentant
des instances de classe liées entre elles statiquement
 Un diagramme d’objet est conforme au diagramme

de classes qu’il illustre (vérifie les contraintes)
 Un diagramme d’objets ne montre pas les interactions

entre les objets
Objet
(Notation)
Notation
 Un objet est
représenté par un
rectangle découpé nomObjet : nomClasse
en deux nomAttribut1 = valeur1
compartiments …
nomAttributN = valeurN
 Sont présents :
 le nom de l’objet
 la liste des
attributs
Nom de l’objet
(Notation)
 Le nom de l’objet peut Notation
être présenté selon trois
formats plus ou moins
précis nomObjet
 Il peut contenir :
 Un nom optionnel
Ou nomObjet : nomClasse
identifiant l’objet de
manière unique
 Le nom optionnel de la
classe à laquelle Ou : nomClasse
appartient l’objet
 Le nom de l’objet est
souligné
103
Exemple
Personne salarié Société

nom * nom
prénom activit
employeur é
Diagramme
Philippe:Personne d’objets
Nagora:Société
nom = Dupont
nom = Nagora
prénom = Philippe
activité = SSII
Eric:Personne
nom = Durand
prénom =
Eric
Objet composit e
(Notation)
 Un objet composé de sous-
objets est appelé Notation
composite
nomComposite : classeComposite
 Les objets composites sont
issus de classes liées par : classePartie1 : classePartie2
une composition
 Les attributs d’un objet

composite sont eux-mêmes Ou
des objets
nomComposite : classeComposite
 Les sous-objets peuvent
être représentés de : classePartie1
manière graphique ou : classePartie2
textuelle
105
Objet composite
Exemple
Diagramme de
classes
possède
Université Salle
1..*
Orsay : Université
salle H123 :
Salle salle G246
: Salle
Objet composite
Exemple
Lien
Lien (suite)
Lien (suite)
(Recommandations)
 Le diagramme d’objets ne doit être utilisé que pour
clarifier certaines structures complexes apparaissant sur
un diagramme de classes
 Tous les objets du diagramme de classes ne doivent pas

obligatoirement figurer sur le diagramme d’objets
 Le diagramme d’objets peut servir de base à un

diagramme d’interaction
Diagrammes d’objets et d’interaction
(Recommandations)
 Utiliser le diagramme d’objets uniquement pour illustrer
des situations complexes d’un diagramme de classes
 Ne pas mélanger diagramme de classes et diagramme

d’objets sur un même modèle (certains outils le
permettent)
 Privilégier l’utilisation du diagramme de séquence à celle

du diagramme de collaboration, dès la phase d’analyse
 Ne pas mélanger des niveaux de détails différent sur le

même diagramme de séquence
Exemple
1 *
Exemple
Exemple : montrer une
défaillance du Diag classe
Exemple
Exercice
Exercice
Exercice
Solution
Exercices similaires
• Le systeme gére un seul batiment contenant deux portes. `

• Le systeme peut etre géreré par une personne nomm
Ahmed ayant le password ‘aaa’ .
• Deux utilisateurs peuvent acceder au batiment :
– kamal a accesé a la premiére (8h-12h) et seconde porte `
(12h-22h)
– Brahim a acces a la seconde porte toute la journée
LES DIAGRAMMES
DE
COMMUNICATION
(CONNUS PAR DIAGRAMMES DE COLLABORATION)

DIAGRAMMES DE COMMUNICATION
 Montrent des interactions entre objets

(instances de classes et acteurs).
 Ils insistent plus particulièrement sur :
 la structure spatiale statique qui permet la mise
en collaboration d un d objets (au travers des
objets etdes liens) .
 l’interaction entre ces objets (par les envois de
messages).
 Une extension des diagrammes d’objets.
110
DIAGRAMMES DE COMMUNICATION
 Le contexte d'une interaction comprend :
 les arguments,
 les variables locales créées pendant l'exécution, ainsi que
 les liens entre les objets qui participent à l'interaction.
 Un diagramme de communication est représenté sous forme
d’un cadre avec une étiquette « com » suivi du nom du
diagramme contenant les objets en interactions.
EXEMPLE
112
EXEMPLE
 Le diagramme suivant représente une cabine
d’ascenseur qui demande à une porte de
s’ouvrir.
113
EXEMPLE 2
 Les différents messages sont numérotés
pour indiquer l’ordre des envois
114
Diagramme de communication
 Diagramme de communication illustrant la
recherche puis l’ajout, dans son panier
virtuel, d’un livre lors d’une commande sur
Internet.
115
Diagramme de communication
 Contrairement à un diagramme de séquence, un
diagramme de communication rend compte de
l’organisation spatiale des participants à
l’interaction, il est souvent utilisé pour illustrer un cas
d’utilisation ou pour décrire une opération.
 Le diagramme de communication aide à valider les

associations du diagramme de classe en les
utilisant comme support de transmission des
messages.
116
Message d’un diagramme de
COMMUNICATION
Notation
[ Prédécesseurs / ] [ garde ] [ séquence : ] [ valeurRetour := ] signatureMessage

 Prédécesseurs = liste de messages qui doivent avoir été émis précédemment. A3
signifie message 3 de la classe A
 Garde = condition sur le déclenchement du message
 Séquence = numéro de séquence de l’appel suivi éventuellement par une itération
 valeurRetour = valeur retournée par le message et pouvant être manipulée par les
messages émis par la suite
 signatureMessage= signature du message émis
Exemples
Message simple
2: display (x, y)
Appel avec valeur de retour
1.3.1: c:= chercherClient(nom)
Message conditionnel
[x < 0] 4: inverser (x, couleur)
Synchronisation avec d’autres threads et itération
A3,B4 / C3.1*[i := 1..n] : miseAJour ()
Exemple
Exemple
LES DIAGRAMMES
DE séquence
Diagramme de séquence
Objectifs
 Montrer explicitement les interactions intervenir

pouvant entre des objets
 Représenter les interactions en favorisant une

vision
temporelle de celles-ci
 Préciser la chronologie des interactions en précisant

les contraintes temporelles
119
Objet du diagramme
séquence (Notation)
 Dans un diagramme de
séquence, on ajoute à l’objet un Notation
axe temporel représentant sa
ligne de vie
nomObjet: nomClasse
 Cet axe temporel est matérialisé
par une ligne pointillée sous
l’objet
Axe Barre d’activation
temporel
 Sur cet axe temporel
apparaissent des bandes
rectangulaires représentant les
périodes d’activité de l’objet
 Onconsidère que le
temps
s’écoule du haut vers le bas 120
Création, animation et
destruction d’un objet
 Certains messages ont
une signification bien Notation
précise :
 Message « Créer » : Classe1

message ayant pour nom
« Créer », demandant la création Créer
d’une instance : Classe2
 Message d’activation
message de nom quelconque Message activation
qui déclenche une bande

d’activité chez une instance
 Message « Détruire » Détruire
message ayant pour nom
 Une« instance
Détruire » détruite
demandant
voitlasa
destruction
bande d’une
d’activité s’achever par une
instance
croix 124
Envoi de message
 Les envois de message sont
matérialisés par des flèches étiquetés Notation
par le nom du message envoyé
 3 types de message : : Classe1 : Classe2

 Message synchrone
l’objet émetteur envoie le message et Message synchrone
reste bloqué tant que le destinataire n’a
pas fini de traiter le message reçu Retour d’appel
synchrone
 Message asynchrone
l’émetteur envoie le message et ne
reste pas bloqué pendant le traitement Message réflexif
du message par le destinataire
 Message réflexif
Message asynchrone
l’objet s’envoie un message à lui-même
Retour asynchrone
121
 Conception détaillée : La syntaxe de
réponse à un message est la suivante :
[<attribut> = ] message [ :
<valeur_de_retour>]
122
Diagramme de séquence
Exemple
 Représentation chronologique des envois de messages entre objets
 Possibilité d’exprimer de façon précise les contraintes temporelles
grâce à un axe gradué
 Un élément extérieur au système, comme un acteur, peut figurer dans
un diagramme de séquence
: : :
Client ServeurWeb Cuisinier
Afficher carte
Passer cde
Décrire cde
Réaliser plat
Donner
Envoyer message disponibilit
é
Messages synchrones et diagramme de
classe
Les messages synchrones correspondent le plus souvent à une
opération :
•A l’invocation, le flux contrôle passe de l’émetteur au récepteur
•L’émetteur attend la fin de l’exécution, et reprend après le retour
Les méthodes correspondant aux messages synchrones doivent être
définies dans un diagramme de classes.
Les méthodes sont définies dans la classe du récepteur, et pas de
l’émetteur du message.
Echange de messages et code Java CAS Messages synchrones
Condition sur message
 Il est possible de faire apparaître des branchements
conditionnels sur un diagramme de séquence
 Les conditions sont présentes sous formes de gardes
entre [ crochets ]
: : : : Serveur
Client Serveur Cuisinier
Passage cde
[Repas] Description cde
[Apéritif] Description cde

Contraintes temporelles
 Tracer une flèche oblique
Notation
pour représenter un
délai de propagation
important entre deux : Classe1 :
objets Classe2
 Des contraintes X Message1

temporelles sur l’axe
vertical peuvent être {Y-X >10s}
ajoutées sous forme Message2
textuelle entre {accolades}
Y
126
Fragments d’interaction combinés
 Il existe 12 d’opérateurs définis dans la notation

UML 2.0.
 Les fragments combinés permettent de décrire
des diagrammes de séquence de manière
compacte.
 Les fragments combinés peuvent faire intervenir
l’ensemble des entités participant au scénario
ou juste un sous-ensemble.
 Un fragment combiné se représente de la
même façon qu’une interaction.
127
Fragments d’interaction combinés
 La liste suivante regroupe les

opérateurs d’interaction par fonctions :
 les opérateurs de choix et de
boucle : alternative, option, break et loop ;
 les opérateurs contrôlant l’envoi en parallèle de
messages : parallel et critical region ;
 les opérateurs contrôlant l’envoi de
messages : ignore, consider, assertion et

negative ;
 les opérateurs fixant l’ordre d’envoi des messages : weak
sequencing , strict sequencing.
128
Opérateur strict
 Un fragments combiné de type strict sequencing, ou strict,
possède au moins deux sous-fragments. Ceux-ci s’exécutent
selon leur ordre d’apparition au sein du fragment combiné.
 Ce fragment combiné est utile surtout lorsque deux parties
d’un diagramme n’ont pas de ligne de vie en commun
134
Procédures de décollage d’un avion dans l’ordre.
Opérateur alt
 L’opérateur alternative, ou alt, est un opérateur conditionnel
possédant plusieurs opérandes.
 C’est un peu l’équivalent d’une exécution à choix multiple

(condition switch en C++).
 Chaque opérande détient une condition de garde.

L’absence de
condition de garde implique une condition vraie (true).
 La condition else est vraie si aucune autre condition n’est

vraie. Exactement un opérande dont la condition est vraie est
exécuté. Si plusieur opérandes prennent la valeur vraie, le
choix est non déterministe.
129
Opérateur alt
 Représentation d’un choix dans un diagramme de séquence
illustrant le découvrement d’une case au jeu du démineur.
130
Opérateurs opt
 L’opérateur option, ou opt, comporte une
opérande et une condition de garde
associée.
 Le sous-fragment s’exécute si la condition de
garde est vraie et ne s’exécute pas dans le
cas contraire.
131
Opérateur loop
 Un fragment combiné de type loop possède un sous-fragment et
spécifie un compte minimum et maximum (boucle) ainsi qu’une
condition de garde.
 La syntaxe de la boucle est la suivante :
 loop[ '('<minInt> [ ',' <maxInt> ] ')' ] La condition de garde est

placée entre crochets sur la ligne de vie
 La boucle est répétée au moins minInt fois avant qu’une

éventuelle condition de garde booléenne ne soit testée. Tant que
la condition est vraie, la boucle continue, au plus maxInt fois.
132
Opérateur par
 Un fragments combiné de type parallel, ou par,
possède au moins deux sous-fragments
exécutés
simultanément.
 Microwave est un exemple d’objet effectuant deux tâches en 133
parallèle.
Exemple: diagramme séquence « Boite noire »
du use case ajout de RDV
Exemple: diagramme séquence « Boite noire » du use case s’authentifier
Exemple: diagramme séquence « Boite noire »
du use case s’inscrire
Exercice:
Le scénario enchaînement nominal du cas d'utilisation retrait d'espèces
contient les éléments suivants :
1. Le guichetier saisit le numéro de compte du client ;

2. L'application valide le compte auprès du système central ;
3. Le guichetier demande un retrait de 100 euros ;
4. Le système guichet interroge le système central pour s'assurer que le
compte est suffisamment approvisionné ;
5. Le système central effectue le débit du compte ;
6. En retour, le système notifie au guichetier qu'il peut délivrer le montant
demandé.
Question : Donner le diagramme de séquences associé à cette description
textuelle.
Solution
Diagramme états-transitions
Sommaire
 Introduction
 Objectifs
 Diagramme états-transitions
 Etat d’un objet
 Evénement
 Transition entre états (Garde, action)
 Transition réflexive
 Actions d’un état
 Activité d’un état
 Transition automatique
 Sous-états séquentiels
 Sous-états concurrents
 Etat à historique
 Apport en grande partie de la méthode OMT (Rumbaugh)
 Le diagramme états-transitions utilisé dans UML

s’inspire largement des Statecharts de Harel
 Le diagramme états-transitions est utilisé pour modéliser un

automate à états finis
 Diagramme indispensable pour modéliser les

systèmes communiquant de manière asynchrone
Diagrammes états-transitions
Objectifs
 Définir les circonstances permettant le

déclenchement des traitements
Certains traitements sont tributaires de
la survenue d’événements
dans le système
Objectifs (suite)
 Représenter les interactions asynchrones sein du

au système
L’appel synchrone de fonctionnalité n’est pas toujours un
moyen de communication satisfaisant, en particulier pour les
applications industrielles ou temps-réel
 Déterminer les états stables par lesquels passe le système

Parmi l’infinité d’états caractérisant un système,
seuls
quelques uns sont significatifs pour le problème donné
D iagramme états-
( transitions Définition)
Le diagramme états-transitions est un automate à
états finis décrivant les différents états par
lesquels passe une instance quelconque d’une
classe
en réponse à des événements
 Le diagramme états-transitions ne présente que les états significatifs
pour le problème posé
 Il ne montre que les transitions autorisées entre les différents états

de l’objet
 Il donne des précisions sur les événements déclencheurs

des transitions
 Il indique les traitements effectués par l’objet lorsqu’une transition est

effectuée
 Un diagramme états-transitions est utilisé pour décrire le

comportement type d’une instance quelconque d’une
classe
 Seules les classes ayant un cycle de vie significatif
nécessitent le recours au diagramme états-transitions
 Un diagramme états-transitions est utilisé pour modéliser le

comportement d’objets actifs interagissant entre-eux de
manière asynchrone
 Aider à déterminer les événements qui occasionnent les
transitions
 Aider à déterminer les opérations qui vont permettre ces
transitions
Diagramme d’états-transitions
Exemple
en activité âge légal de

atteint la majorité [ job la retraite
trouvé ]
embauche Décès
à la retraite
perte
emplo
i
atteint la majorité âge légal de
[pas de job trouvé] la
au chômage retraite
Etat d’un objet
Voiture
 Un objet est caractérisé par couleur :
chaîne année :
un ensemble d’attributs entier marque :
chaîne
 Les attributs d’un objet

changent de valeur au
cours du temps
Voiture
couleur = «bleue» Voiture
année = 1980 peindre en jaune couleur = «jaune»
marque = année = 1980
«Renault» marque =
«Renault»
normale
repeinte
Les valeurs des attributs d’un objet forment l’état de l’objet
E tat d ’un
(objet
Définition)
L’état d’un objet est une configuration particulière
des valeurs de ses attributs,
significative pour le problème posé
 Unobjet possède autant que de configurations

d’états possibles pour ses valeurs
d’attributs
 Ce nombre peut être infini si le domaine de certains attributs
n’est pas discret
 Parmi la multitude d’états que peut posséder un objet, seuls

certains d’entre-eux sont dignes d’intérêt
Comment trouver les états
significatifs d’un objet
Pierre Pierre
 En général, les états
âge = 12 âge = 34
significatifs d’un objet
peuvent être décelés
en examinant : O ui
« Mineur
»
[ âge < « Majeur
Non
 les valeurs de ses 18 ] »
attributs qui satisfont

Ampoule
certaines conditions
intéressantes pour le Eclairer()
système
« Allumée « Eteinte »
 les activités qu’il exerce »
dans le système
 les événements sur
lesquels il est en attente
« Au départ « En course 145
» »
Etat d ’un objet
(Notation)
• Un état est représenté
au moyen d’un
rectangle à coins
arrondis Notation
• Le nom de l’état est

positionné à
l’intérieur du NomEtat
rectangle
• Le nom de l’état est

en général un adjectif
ou une petite phrase
le décrivant
Etat initial et état final d ’un
objet (Notation)
• L’état initial indique le point
de départ par défaut du
diagramme états- Notation
transitions
Etat initial
• L’état initial est représenté
par un point noir plein
• L’état final indique que le

cycle de vie de Etat final
l’instance s’achève
• L’état final est représenté

par un point noir
encerclé
DIAGRAMME D’ETATS-
TRANSITIONS
ETATS SPECIAUX:
• 2 états prédéfinis :
• état de démarrage : obligatoire, unique
• état de fin : optionnel, peut-être multiple
Création de l’objet Fin de vie de l’objet
ETAT 1 ETAT X
E vénement (Définition)
Un événement est l’occurrence d’un stimulus
susceptible d’entraîner le déclenchement d’une
réaction au sein du système
 La provenance de l’événement peut être aussi

bien
interne, qu’externe au système
 Un événement est par nature instantané et doit donc

être traité immédiatement
 Un événement ne provoque pas systématiquement

une réaction de la part du système
Les différents types
d’événement
Il existe divers types d’événement :
 L’événement sur condition
Condition booléenne particulière dont la valeur passe à VRAI (ne pas

confondre avec une garde)
ex : « le feu est vert »
 L’événement temporel
Ecoulement d’une certaine période de temps ou occurrence d’une
certaine heure / date définie
ex : « Après (15s) »
« Quand (date = ‘1er Janvier 2002’) »
 Le signal
Signal explicitement émis par un objet
Ex : « Bouton Souris = down »
Signal émis par un objet
• Un objet peut émettre un signal
vers un autre objet Notation
• A la différence de l’invocation d’une
méthode, un signal est
asynchrone « Signal »
• Les signaux peuvent être modélisés User
sur un diagramme de classes à
l’aide input
d’une classe stéréotypée « Signal
• »
Un signal peut transporter des « Signal » « Signal »
données
Bouton Souris Touche clavier
Elles apparaissent comme attributs
de la classe position caractère
150
Transition entre états
(Définition)
Une transition est une connexion orientée entre deux états,
se déclenchant lorsque l’événement auquel elle est
associée est reçu par l’objet et
provoquant ainsi le passage d’un état vers l’autre
 Une absence de transition entre deux états indique qu’il

n’est pas possible pour un objet de passer de l’un de ces
états vers l’autre
 L’état source est l’état dans lequel se trouve l’objet
avant
l’apparition de l’événement
 L’état cible est l’état dans lequel se retrouve l’objet après
la survenue de l’événement
Transition entre états
(Notation)
 Une transition est modélisée sous la forme d’une flèche
reliant les deux états, étiquetée par une description
textuelle de la transition
 La description textuelle est constituée de trois éléments
:
 Un événement déclencheur
 Une condition de garde
 Une action
Notation
NomEtatSource Événement [ Garde ] / Action NomEtatCibl
e
Garde sur transition
Une garde sur une transition est une condition booléenne
optionnelle qui doit être vérifiée pour que la transition
puisse être déclenchée lors de la survenue de l’événement
• A la différence de l’événement sur condition, la garde est évaluée

une seule fois (à la survenue de l’événement)
• La garde est exprimée sous la forme d’un texte entre [ crochets ]
Notation
60ème anniversaire [ a cotisé ]
Salari Retrait
é é
Action d’une
(transition Définition
et notation)
Une action sur une transition est un traitement atomique
exécuté lorsque la transition est déclenchée
• Une action peut comporter
- Des appels à des opérations de l’objet
- Des créations et destructions d’autres instances
- Des envois de signaux vers des objets (y compris lui-même)
• Une action ne peut pas être interrompue par un événement
et s’accomplit totalement contrairement à une activité
60ème anniversaire [ a cotisé ] / Faire un pot()

Salari Retrait
é é
Mouvement détecté / Send(Problème) à Central
vigilanc En
e alerte
TRANSITIONS
COMMUNICATION ENTRE OBJETS PAR
EVENEMENTS :
Retour [bon état] Retour [mauvais état]

Emprunté
Disponible En réparation
NOTION D’EVENEMENT:
Exemple
Plus de 60 ans
En activité
Embauche Perte A la retraite

D’emploi
Au chômage
Plus de 60 ans
EXEMPLE
Transition réflexive sur un état
 Une transition peut avoir pour état source et état cible un seul
et même état
On parle alors de transition réflexive ou auto-transition
 Ce type de transition est utile lorsque l’on souhaite exécuter

une action tout en revenant dans le même état
Bouton « off » pressé Tic horloge / Emettre bip()

Notation
Arrêt En
marche
Bouton « on » pressé
Actions d’un
(état Définition)
Une action d’état est un traitement interne atomique
associé à un état et dont les conditions de
déclenchement sont liées soit à la survenue d’un
événement,
soit à l’entrée ou à la sortie de l’état
Un état peut comporter :
 Une action en entrée
A chaque fois que l’objet entre dans l’état, l’action est exécutée
 Un action en sortie
A chaque fois que l’objet sort de l’état, l’action est exécutée
 Plusieurs actions internes sur événement

A chaque fois qu’un événement défini survient, une transition
interne est déclenchée et l’action associée est exécutée
Actions d’un état
(Notation)
• Les actions associées à un état
sont identiques à celles associées
aux transitions Notation
• Les actions en entrée et en

sortie permettent de factoriser NomEtat
des traitements à effectuer
Elles sont précédées des mot- Entry / Action entrée
clés Exit / Action sortie
« Entry » ou « Exit » Evénement1 / Action1
• Une transition interne n’a pas les EvénementN /
mêmes effets qu’une transition
ActionN
réflexive
Activité d’un état
éfinition)
(D d’actions
Une activité d’état est une séquence interruptible
associée à un état et s’exécutant tant que
l’objet se trouve dans cet état
• Chaque action composant l’activité est atomique (non interruptible et

s’exécutant totalement)
• Par contre, la séquence est interruptible par un événement

quelconque intervenant entre deux actions
• Une activité peut s’exécuter indéfiniment dans un état ou bien

s’achever
d’elle-même ou bout d’un certain temps
• Après interruption consécutive à un événement, l’activité redémarre

si l’objet est resté dans le même état
Activité d’un ét at
(Notation)
• L’activité d’un état est précédée du
mot-clé « Do » Notation
• L’activité se déclenche une fois

que l’objet se retrouve dans l’état
associé à celle-ci NomEtat
Entry / Action entrée
• Si l’état possède une action en Exit / Action sortie
entrée, celle-ci sera déclenchée
avant que ne démarre l’activité Evénement1 / Action1
EvénementN /
• La survenue d’un événement sur ActionN Do / Activité
action interne interrompt
l’activité le temps du traitement de
l’action interne
Activité et actions
Exemple
Activités de la journée
préparerCafé()
9h /
préparerCafé() débrancherRépondeur()
travailler()
Au répondreTéléphone()
bureau
Entry / débrancherRépondeur()
travailler ()
ouvrirPorte()
Exit / brancherRépondeur() travailler ()
12h /
manger() brancherRépondeur()
téléphoneSonne / répondreTéléphone()
manger()
sonneriePorte / ouvrirPorte()
débrancherRépondeur()
Do / travailler() travailler ()
répondreTéléphone()
18h / travailler ()
prendrePain()
brancherRépondeur()
prendrePain()
Transition automatique
 Une transition peut ne pas avoir d’événement associé
On parle alors de transition automatique
 Une transition automatique se déclenche lorsque l’activité de
son état source est terminée
 Une transition automatique peut être conditionnée par une
garde
incident
Alerte
Repos
do /
émettre_alarme()
[ incident non [ incident

résolu ] résolu ]
Exemple DAB: Encaissement d’argent
do: augmenter le montant
Article sélectionné
[article vide]
[montant < prix
En article]
attente
Test d’article
do: tester articler et calculer la

monnaie à rendre
[montant =
prix article] [montant > prix
article]
Distribution Encaissement
do: distribuer article do: rendre monnaie

S ous-états d’un
(état Définition)
Un état composé est un état dans lequel viennent
s’emboîter d’autres états que l’on appellent sous-états
 Par opposition, on parle d’état simple lorsque l’état n’a

pas de structure interne
 Il existe deux catégories de sous-états :

 Les sous-états séquentiels
L’objet ne peut se trouver que dans un seul de ces sous-états
à un instant donné
 Les sous-états concurrents
L’objet se trouve dans les deux sous-états à un instant donné
Sous-états séquentiels
 L’état composé possède un nom et embarque en son sein les
sous-états
 Les sous-états participent à un diagramme états-
transitions
classique
 A un instant donné, un objet ne peut se trouver que dans un
seul des sous-états séquentiels
Notation
NomEtatComposé
Événement [ Garde ] / Action
NomSousEtat1 NomSousEtatN
ETATS IMBRIQUES /COMPOSITES
Sous-états séquentiels
Vivant
mariable
Mariage [âge légal
Naissance
Célibataire atteint]
Marié
Décès conjoint
Veuf
Divorce
Divorcé
Décès
Destruction
Mort
Sous-états concurrents
 La figure illustre l'utilisation d'un état composite
orthogonal pour modéliser le fait que la préparation
de la boisson d'un distributeur de boissons se fait
en parallèle au rendu de la monnaie.
TRANSITIONS
Généralisation d’états:
e1 AB
A B e1
A B
e2 e2
C e2
C
Diagramme états-Transition
(Recommandation)
 Ne faire les Créée
diagrammes états-
transitions que pour
les classes ayant un Mise à jour
comportement
significatif dans le
Détruite
système
 Un diagramme à
états-transitions est A
un automate à ev ev
états finis t t
déterministe B C
165
EXO1
• On considère une boîte de vitesses automatique de

voiture. La boîte au démarrage est au point mort. La
marche arrière ainsi que la position parking peuvent
être enclenchées à partir du point mort. La première
marche avant peut également être enclenchée à
partir du point mort. En revanche, les autres marches
avant, la seconde et la troisième, sont enclenchées
en séquence: 1 2 3 pour une accélération, et
3 2 1 pour une décélération. Seules la marche
arrière, la position parking et la première marche
avant peuvent être ramenées directement au point
mort.
 Exercice 2
Considérons une classe Partie dont la responsabilité est de gérer le

déroulement d'une partie de jeu
d'échecs. Cette classe peut être dans deux états :
le tour des blancs
le tour des noirs.
Les événements à prendre en considération sont
un déplacement de pièces de la part du joueur noir
un déplacement de pièces de la part du joueur blanc
la demande de prise en compte d'un échec et mat par un joueur. S'il est
validé par la classe partie,
un échec et mat assure la victoire du dernier joueur. Dans ce cas, une
activité « noirsGagnants » ou « blancsGagnants » selon le cas est
déclenchée (appel de méthode).
la demande de prise en compte d'un pat qui mène aussi à une n de
partie, avec une égalité. Dans
ce cas, une activité « égalité » est déclenchée.
Question : Donner le diagramme d'états/transitions associé à la classe
Partie
Solution
 Exercice 3
Montre digitale
Une montre digitale simple possède un cadran et deux boutons, que l’on
nommera A et B, pour la mettre à l’heure. La montre a deux modes
d’opérations, affichage de l’heure et mise à l’heure. En mode d’affichage, les
heures et les minutes sont affichées, séparées par un signe « deux points »
intermittent.
Le mode de mise à l’heure à deux sous-modes, heures et minutes. Le bouton
A s’utilise pour les modes. A chaque fois que l’on appuie dessus, le mode
change suivant la séquence: affichage, configurer heures, configurer minutes,
affichage, etc. Dans une sous-mode, le bouton B s’emploie pour avancer les
heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons
doivent être relâchés avant de pouvoir produire un autre événement.
Préparez un diagramme d’états de la montre.
Solution
EXO4
• On veut représenter par un diagramme d’états, la vie d’un
exemplaire de livre dans une bibliothèque. Quand un exemplaire
est créé, il entre dans le « hors-prêt » (consultation sur place
seulement) s’il est le seul exemplaire de l’ouvrage ou devient
disponible pour le prêt sinon. Quand il y a plusieurs exemplaires
le bibliothécaire peut décider de changer l’exemplaire en « hors
prêt
».
Quand un exemplaire prêté ne revient pas après les relances il
est considéré comme perdu et retiré de la base un an après. S’il
est retrouvé, il redevient disponible pour le prêt.
En cas de détérioration, l’exemplaire est sorti des rayons et
marqué
« à enlever ». Il peut être renouvelé ou retiré de la base. Il n’y
a pas
de notion de réservation d’un ouvrage non disponible.
Solution

Uml Ibn Batouta 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml Ibn Batouta 1

Transféré par

Droits d'auteur :

Formats disponibles

ANALYSE ET CONCEPTION ORIENTEE

Définir les besoins pour une solution

Prof. Zouhair IBN BATOUTA

Prof. Zouhair IBN BATOUTA 1

Processus De Développement Logiciel

Spécification des exigences

Méthodes d’analyse : UML

Diagramme des cas d’utilisations

Diagramme de contexte statique et

Prof. Zouhair IBN BATOUTA

 En ingénierie, et plus particulièrement dans les

Prof. Zouhair IBN BATOUTA

 UML est le fruit d’un consensus général

 UML est une notation (relativement) simple et non

- 1997 (Q1) UML

Autres méthodes O M T- O O SE Partenaires OMG

Prof. Zouhair IBN BATOUTA

 UML est un langage de modélisation objet

 UML est un langage de communication

 UML est un langage simple de haut niveau

Prof. Zouhair IBN BATOUTA

 UML est un langage ouvert

Prof. Zouhair IBN BATOUTA

Prof. Zouhair IBN BATOUTA

BOOCH, OMT, OOSE,…

UML (Unified Modeling Language)

Prof. Zouhair IBN BATOUTA

 diagrammes de cas d'utilisation

 Diagramme d'interactions ou Diagrammes d

concepts utilisables tout au long du projet

Prof. Zouhair IBN BATOUTA

 Définir les besoins fonctionnels du système

 Définir le périmètre fonctionnel du système

 Définir le dialogue entre l’utilisateur et le système

 Etablir les scénarios fonctionnels qui seront utilisés pour la

 Servir de support de référence tout au long des phases de

 Décrivent le comportement du système (actions

 Le cas d’utilisation possède un nom : celui de la fonctionnalité

 Le cas d’utilisation met en œuvre un dialogue entre le système

 Quelles sont les grandes fonctionnalités attendues

Ne pas confondre personne physique et rôle

 Qui installe le système ?

 Permet de définir de manière précise les frontières

 Montre les interactions entre le système et

 Montre les dépendances existant entre les

- les cas d’utilisation

une association sous la argent

utilisée pour représenter Déposer

 Les dépendances d’utilisation

 Les dépendances d’extension

 Les dépendances de généralisation

et intégralement une Authentifier

dans un autre cas Cas d’utilisation 2

• Est représentée par une Acteur 1

Prof. Zouhair IBN 33

• Permet de décomposer argent

d’utilisation plus simples Acteur 1

• Permet de factoriser des Retirer

comportements utiles à argent « include »

plusieurs cas d’utilisation « include » Authentifier

• Est représentée par une Cas d’utilisation 2

Le cas d’utilisation 2 est une

Cas d’utilisation 237