Université Sid Mohammed Ben Abdellah

Ecole Nationale des Sciences Appliquées

Fès

UML
Pr. Nabil EL AKKAD

Intitulé du module UML

Etablissement dont relève le Ecole Nationale des Sciences Appliquées
module de Fès (ENSAF)
Département Génie Electrique et
Département d’attache
Informatique (GEI)
Master, (Semestre d’appartenance Génie Informatique (GI) (S2)
du module)

1
 Plan

 Introduction générale

 Diagramme de cas d’utilisation

 Diagrammes de classes, de packages et d’objets.

 Diagrammes de séquences, d’activités, de vue globale

d’interaction et états.

 Chapitre 5: Diagrammes de composant et de déploiement.

2
 bibliographies
• P. ROQUES. – UML 2. Modéliser une application web. N°12136, 3e
édition, 2007, 246 pages (collection Cahiers du programmeur).
• P. ROQUES, F. VALLÉE. – UML 2 en action. De l’analyse des
besoins à la conception. N°12104, 4e édition, 2007, 382 pages
(collection Architecte logiciel). UML, modélisation objet, processus
de développement.
• C. SOUTOU. – UML 2 pour les bases de données. Avec 20
exercices corrigés. N°12091, 2007, 314 pages (collection Noire).
• X BLANC, I. MOUNIER. – UML 2 pour les développeurs. Cours
avec exercices corrigés. N°12029, 2006, 202 pages (collection
Noire).
• H. BERSINI, I. WELLESZ. – L’orienté objet. Cours et exercices en
UML 2 avec Java 5, C# 2, C++, Python et PHP 5. N°12084, 3e
édition, 2007, 602 pages (collection Noire).
• [Link]
• [Link]
3
Chapitre 1 : Introduction générale

4
 Introduction

• L’informatisation est le phénomène le plus important de notre

époque.
• Actuellement, l’informatique est au cœur de la vie quotidienne
des individus, entreprises, organisations, gouvernements, ….
• Les Systèmes Informatiques ce composent de :
– 80 % de logiciel,
– 20 % de matériel.
• Depuis quelques années, la fabrication du matériel est assurée
par quelques fabricants seulement.
– Le matériel est relativement fiable.
– Le marché est standardisé.

5
 Introduction

• Les problèmes liés à l'informatique sont essentiellement des

problèmes logiciels.
Construction d’applications

Besoin code

• Simplification à l’extrême: nous pourrions dire que la

construction d’une application informatique se résume à
réaliser du code pour répondre au besoin d’un utilisateur.???

6
 Introduction

• Exemple de LaTex, qui a été conçu pour permettre à ses

utilisateurs d’écrire des livres, des articles….

Avoir un logiciel
pour écrire un livre LaTex
ou un article

• Cette simplification peut être considérée comme une

simplification brute ou grossière.
• Cependant, la réalisation du code n’est pas la seule activité à
effectuer lorsque nous souhaitons construire un logiciel disant
de qualité.

7
 Logiciel: Définition
• Un logiciel:
– Est un ensemble de programmes,
– Qui permet à un ordinateur d’assurer une tâche ou une fonction bien
précise.
Exemples : Word, Photshop, 3DSMAX,…
• Les logiciels, suivant leur taille, peuvent être développés par:
– Une seule personne,
– Une petite équipe,
– Un ensemble d’équipes coordonnées.
• Le développement de grands logiciels par de grandes équipes
pose des problèmes de conception et de coordination.

8
 Crise du logiciel

Réussite des projets informatiques ( étude du Standish Group)

Année Succès Mitigé Echec
1995 16% 53% 31%
2000 28% 49% 23%
2004 29% 53% 18%
2009 32% 44% 24%

• Succès : livré à temps, sans dépassement de budget accompagné de

toutes les fonctionnalités initialement spécifiées.
• Mitigé : livré et opérationnel, mais avec moins de fonctionnalités
que prévu et un dépassement de budget et/ou de temps.
• Echec : abandonné.
9
 Crise du logiciel

• La crise de l’industrie du logiciel était principalement due à :

– La spécification non correcte des besoins,

– Les difficultés de maintenance et d’évolution,

– La non fiabilité,

– Le non respect des délais,

– L’augmentation des coûts,

– ….

 une nouvelle discipline est née : le génie logiciel.

10
 Génie logiciel

• Le génie logiciel est un domaine de recherche qui a été défini

en 1968 à Garmisch (Allemagne) « 1st conference on software
engineering ».

• Il essai de répondre aux questions suivantes:

– Qu'attend-on d'un logiciel ?

– Comment construire des logiciels de qualité ?

– Quels sont les méthodes utilisés pour la construction?

– Etc.

11
 Génie logiciel (2)

• Proposé comme un axe de recherche par un groupe de

scientifiques pour répondre à la crise du logiciel avec quelques
idées émergentes :
– La production de logiciel doit être organisée, normalisée, …

– Contrôle des coûts et de la qualité,

– Répondre à la demande dans des délais raisonnables,

– Etc.

12
 Génie logiciel (3)
• Constats:
– La réalisation du code n’est pas la seule activité à effectuer lorsque nous
souhaitons construire une application disant de qualité.
– Parmi les autres activités à effectuer, on trouve:
1. S’assurer d’avoir bien compris le besoin de l’utilisateur afin de réaliser une
application qui le satisfasse.
2. S’assurer d’avoir réalisé un code facilement modifiable, permettant de prendre
en compte des évolutions futures.
3. Définir l’architecture de l’application (définition de ses différents composants,
indépendamment du langage de programmation) pour bien comprendre les
relations entre les composants de l’application.
4. Planifier et réaliser des tests afin de mesurer la qualité du code.
13
 Génie logiciel (4)

5. Effectuer un suivi des besoins de l’utilisateur afin d’intégrer des

améliorations.
6. Effectuer les corrections de bogues.
7. Écrire la documentation pour l’utilisateur (help), la documentation
d’installation de l’application et la documentation de l’application afin
qu’une autre équipe de développeurs puisse reprendre le développement.
8. Effectuer une séparation des tâches de développement afin de raccourcir les
délais de livraison de l’application.
9. De plus, il faut noter que certaines activités dépendent d’autres. Alors, il faut
impérativement effectuer une activité avant d’en démarrer une autre:
Planification (Gestion de projet).

14
 Génie logiciel (5)
• Objectifs:
– Ces activités visent à mieux structurer l’ensemble des tâches à effectuer
lors de la construction d’une application.
• Solutions:
– Pour apporter une réponse à tous ces problèmes, le génie logiciel
propose la gouvernance du cycle de vie des logiciels.
– Pour répondre aux exigences de ces activités, il faut faire appel à
l’ensemble des méthodologies, des techniques même des philosophies
de développement d’une application.
• Résultats:
– Ces méthodologies font bien ressortir et adoucir la complexité
intrinsèque de la construction d’une application.

15
 Cycle de vie d’un logiciel

• La qualité du produit est garanti par la qualité du processus de

développement.
• Pour obtenir un logiciel de qualité, il faut maîtriser le processus
d'élaboration et de développement.
– La vie d'un logiciel est composée de différentes étapes.
– La succession de ces étapes forme le cycle de vie du logiciel.
– Chaque étape se termine par la délivrance d'un ou plusieurs documents
validés parallèlement par l’utilisateur et le développeur.
– Il faut contrôler la succession de ces différentes étapes.

16
 Cycle de vie d’un logiciel (2)
• Étapes nécessaires à la réalisation d’un logiciel:
– Analyse:
• Elle a pour but de dégager le problème à étudier.
• Le résultat de l'analyse est le cahier de charges (exprimé dans une langue naturelle)
contenant les besoins du futur système.
• 3 phases: Faisabilité, Spécifications des besoins, Organisation du projet.

– Conception:
• Permet de fournir une description fonctionnelle du système en utilisant une
méthode.
• Les méthodes proposent des formalismes (dans la plupart des temps graphiques)
pour concevoir le système.
• Deux types de conception : Conception générale et Conception détaillée.

17
 Cycle de vie d’un logiciel (3)
• Étapes nécessaires à la réalisation d’un logiciel (suite):
– Codage:
• Des programmes seront élaborés afin de mettre en œuvre des solutions
techniques précédemment retenues.
• Plusieurs types langages sont utilisés: Langages classiques (C, Pascal,
Fortran, …) et langages orientés objets (C++, Java, C#, …).

– Tests :
• Essayer le logiciel sur des données d'exemple pour s'assurer qu'il
fonctionne correctement.
• Différentes types: Test unitaire, d’intégration, test système, alpha, bêta, …

18
 Cycle de vie d’un logiciel (4)
• Étapes nécessaires à la réalisation d’un logiciel (suite):
– Livraison:
• Fournir au client une solution logiciel qui fonctionne correctement.
• Plusieurs tâches : Installation, Formation et Assistance.

– Maintenance:
• Mettre à jour et améliorer le logiciel.
• Elle comprend : Corrective, Adaptative et Évolutive.

– Documentation: Cahier des charges, Modèle Objet, Scénarios des

cas d’utilisation, IHM, Calendrier du projet, Plan de test, Manuel
d’utilisateur, Code source, Rapport des tests, Rapport des défauts…

19
 Types de cycle de vie

• Développement en cascade:
– Chaque étape ne débute que lorsque la précédente est achevée.

• Développement en V:
– A chaque étape correspond à une étape de test spécifique.
– Les tests peuvent être définis avant les phases de test.

• Cycle de vie en spirale:

– Ce modèle est beaucoup plus général que le précédent.
– Il met l’accent sur l’activité d’analyse des risques.

20
 Types de cycle de vie (2)

• Cycle de vie en spirale (suite):

– Chaque cycle de la spirale se déroule en quatre phases :
• L’analyse préliminaire des besoins,
• Analyse des risques,
• Développement et vérification,
• Revue des résultats et vérification du cycle suivant.

• Modèle par incrément.

• Approches agiles.

21
 Modèle

• Un modèle:
– Est une représentation abstraite et simplifiée d’une entité (phénomène,
processus, système, etc.) du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir.
– Il permet de réduire la complexité d’un phénomène en éliminant les
détails qui n’influencent pas sur le comportement de manière
significative.
– Il reflète ce que le concepteur croit important pour la compréhension du
phénomène modélisé.

22
 Modèle (2)
• Exemples :
– Modèle économique: Peut, par exemple, permettre de simuler l’évolution de
cours boursiers en fonction d’hypothèses macro-économiques (évolution du
chômage, taux de croissance, …).
– Modèle mathématique: modélisation d’un problème réel difficile à résoudre
par un problème moins difficile.
– Plans: sont des modèles qui donnent une vue d’ensemble du système
concerné (Bâtiment: il faut préalablement élaborer des plans pour la
construction d’un immeuble).
– Modèle démographique,
– Modèle statistique,
– Etc. 23
 Modèle (3)

• Définition:
– Modèle informatique: est une représentation, à différents niveaux
d’abstraction et selon plusieurs vues, de l’information nécessaire à la
production et à l’évolution des applications.

• Un modèle contient plusieurs informations sur une application

informatique.
• Ces informations ont toutes vocation à faciliter d’une manière
ou d’une autre la production du code de l’application.

24
 Modèle (4)
• Un modèle peut préciser :
– Les différentes données manipulées par l’application (vue des
données),
– Les différentes fonctionnalités directement offertes aux utilisateurs de
l’application (vue des utilisateurs),
– Les technologies (Java, C++, PHP, …) utilisées pour réaliser
l’application (vue technique).
• Alors, un modèle est composé de plusieurs vues sur une
application.
• Chacune de ces vues contient certaines informations sur
l’application.
• Ces vues peuvent cibler les différents niveaux d’abstraction, et
elles doivent être cohérentes.
25
 Modèle (5)
Exemple

26
 Modèle (6)

• Modèle vis-à-vis code:

– Le modèle doit contenir toute l’information permettant la production du
code,
– Le modèle contient beaucoup plus d’information que le code.
– Ces informations fortement diversifiées doivent d’être cohérentes.
– L’élaboration d’un modèle complet est un exercice encore plus difficile
que la rédaction de code.
– L’objectif des modèles est de contenir l’information nécessaire à la
production et à l’évolution du code.

27
 Pourquoi modéliser ?

• Modéliser un système avant sa réalisation permet:

– De mieux comprendre le fonctionnement du système.
– De maîtriser la complexité et d’assurer la cohérence d’un système.
– C’est un langage commun, précis, qui est connu par tous les membres
de l’équipe (facilité la communication).

• Remarque:
– Cette communication est essentielle pour aboutir à une compréhension
commune, aux différentes parties prenantes, et précise d’un problème
donné.

28
 Pourquoi modéliser ? --

• Dans le domaine de l’ingénierie du logiciel:

– Le modèle permet de mieux répartir les tâches et d’automatiser
certaines d’entre elles.
– C’est un facteur de réduction des coûts et des délais.
– Le modèle est indispensable pour assurer un bon niveau de qualité et
une maintenance efficace.
– Le choix du modèle a une influence capitale sur les solutions obtenues.

29
 Qui doit modéliser ?
• Deux acteurs principale dans le domaine de génie logiciel:
–Maîtrise d'ouvrage (MOA) : Le client du projet (mais pas forcément l'utilisateur),
–Maîtrise d’œuvre (MOE) : L'organe réalisateur du projet, représenté par le chef de
projet.

• La modélisation est souvent faite par la maîtrise d’œuvre informatique

(MOE).
• La relation MOA et MOE est définie par un contrat qui précise leurs
engagements mutuels.
• Le MOE est responsable de la qualité technique de la solution.

30
 Modélisation des SI

• Généralement, on distingue 2 approches :

- Approches fonctionnelles,
- Approches objet,

- Approches fonctionnelles :
- Proposée, développée et utilisée jusqu’à 1970,
- Mettent l’accès sur les traitements,
- Ce type d’approches fait la distinction entre les données et les
traitements,
- Exemple de Merise (MCD, MCT, ..),

31
 Modélisation des SI (2)

• Approches objet :
- La 1ère génération : 1980, début 1990,
- Mettent l’accès sur le concept de l’objet,
- Chaque objet est caractérisé par des données et des traitements,
- Exemple de UML.

32
 Modélisation des SI (3)

Méthodes fonctionnelles
• Généralement, qualifiées de méthodes structurées.
• Trouvent leur origine dans les langages procéduraux.
• Elles mettent en évidence les fonctions à assurer.
• Elle proposent une approche hiérarchique descendante et
modulaire.
• Chaque niveau est décomposé en respectant les entrées/sorties
du niveau supérieur.
• La décomposition se poursuit jusqu’à arriver à des composants
maîtrisables.

33
 Modélisation des SI (4)

Méthodes fonctionnelles (suite)

• L’approche fonctionnelle dissocie le problème de la

représentation des données, du problème du traitement de ces
données.

• L’accès peut être :

– Direct: les données sont regroupées dans une base de données,

– Indirect: réalisé par le passage de paramètre depuis le programme

principal.

34
 Modélisation des SI (5)
Méthodes fonctionnelles (suite)

Programme principale
Données

Sous fonction 1 Sous fonction 2 Sous fonction 3

Sous Sous Sous Sous Sous

fonction 1.1 fonction 1.2 fonction 2.1 fonction 2.2 fonction 3.1

Sous fonction
1.2…
35
 Modélisation des SI (6)

L’approche orientée objet

• Considère le logiciel comme une collection d’objets dissociés,
identifiés et possédant des caractéristiques.
• Une caractéristique:
– Soit un attribut (une donnée caractérisant l’état de l’objet),
– Soit une fonction (entité comportementale de l’objet).

• La fonctionnalité du logiciel émerge de l’interaction entre les

différents objets qui le constituent.

36
 Modélisation des SI (7)

L’approche orientée objet (2)

• L’une des particularités de cette approche est qu’elle rapproche
les données et leurs traitements associés au sein d’un unique
unité: objet.
• Un objet est caractérisé par plusieurs notions :
– L’identité:
• Permet de distinguer l’objet des autres, indépendamment de son état.
Exemple:
 Un produit pourra être repéré par un code,
 Une voiture par un numéro de série,...
– Les attributs:
• Il s’agit des données caractérisant l’objet.
• Ce sont des variables stockant des informations sur l’état de l’objet.
37
 Modélisation des SI (8)

L’approche orientée objet (3)

• Un objet est caractérisé par plusieurs notions :
– Les méthodes:
• Les méthodes d’un objet caractérisent son comportement,
• C’est l’ensemble des actions (appelées opérations) que l’objet est à même
de réaliser.
• Ces opérations permettent de faire réagir l’objet aux sollicitations
extérieures (ou d’agir sur les autres objets).
• De plus, les opérations sont étroitement liées aux attributs, car leurs actions
peuvent dépendre des valeurs des attributs, ou bien les modifier.
• La Conception Orientée Objet (COO) est la méthode qui conduit à
des architectures logicielles fondées sur les objets du système, plutôt
que sur la fonction qu’il est censé à réaliser.

38
 Modélisation des SI (9)

Remarque
– D’après Church Turing: tout programme écrit dans un langage pourrait
également être écrit dans n’importe quel autre langage.

– Alors, tout ce que l’on fait avec un langage de programmation par

objets pourrait être fait en programmation fonctionnelle.

– La différence entre une approche fonctionnelle et une approche objet

n’est pas d’ordre logique, mais pratique.

39
 UML : Introduction
• La description de la programmation par objets a fait ressortir
l’étendue du travail conceptuel nécessaire :
– Définition des classes,
– De leurs relations,
– Des attributs et méthodes,
– Des interfaces
– etc.
• Pour programmer une application, il ne convient pas de se
lancer tête baissée dans l’écriture du code :
– Il faut d’abord organiser les idées,
– Les documenter,
– Puis organiser la réalisation en définissant les modules et étapes de la
réalisation.
40
 UML: Historique

• Pionnier de l ’Orienté-Objet
– Article en 1981: ‘ Object Oriented Development ’
– Au début, méthode pour le développement d ’applications en Ada pour
le ‘ Department of Défense ’
– Etendue au C++
• Distingue 2 niveaux:
– Logique
• Diagrammes de classes
• Diagramme d’instance
• Diagramme états/transitions
– Physique
• Diagrammes de modules (principe des packages) Grady Booch
• Diagramme de processus
41
 UML: Historique (2)

• Object Modeling Technique

– Livre de James Rumbaugh (1991)

• 3 axes
– Statique
– Dynamique
– Fonctionnel

James Rumbaugh

42
 UML: Historique (3)

• Object Oriented Software Engineering (OOSE).

– Souvent appelée Objectory
• 5 modèles
– Besoins
– Analyse
– Conception
– Implantation
– Test Ivar Jacobson
• Utilisation: Use Cases

43
 UML: Historique (4)

Les méthodes objet

• En 1994, plus de 50 méthodes OO
– Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-
Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,
COMMA, HOOD, Ooram, DOORS...
• Les notations graphiques sont toutes différentes
• L’industrie a besoin de standards

44
 UML: Historique (5)

• 1993-1994: Booch’93, OMT-2

– Les 2 méthodes sont leaders sur le marché
– Elles sont de plus en plus proches
• Octobre 1994
– J. Rumbaugh (OMT) rejoint G. Booch chez Rational
– Annonce de l’unification des deux méthodes
• Octobre 1995: Méthode Unifiée v0.8
• Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint à
son tour Rational

45
 UML: Historique (6)

• Janvier 97 : Soumission à l’OMG de la version UML 1.0

• Septembre 97 : UML 1.1
• La dernière version diffusée par l’OMG est UML 2.4.1 depuis
aout 2012.
• OMG :
– Organisme à but non lucratif fondé en 1989.
– Est un regroupement d’industriels dont l’objectif est de standardiser
autour des technologies objet, afin de garantir l’interopérabilité des
développements.
– Comprend actuellement plus de 800 membres, dont les principaux
acteurs de l’industrie informatique (Sun, IBM, etc.), mais aussi les plus
grandes entreprises utilisatrices dans tous les secteurs d’activité.

46
 UML: Historique (7)
Définition en cours par une UML 2.0
commission de révision
Soumission à l’OMG UML 1.x 1999-2002

UML 1.2 Juin 1998

Standardisation par l’OMG
UML 1.1 Novembre 1997
Soumission à l’OMG
Septembre 1997
Soumission à l’OMG UML 1.0 Janvier 1997
Version bêta OOPSLA’96 UML 0.9 Juin 1996

OOPSLA’95 Méthode unifiée 0.8 Octobre 1995

Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

47
 Qu’est ce que UML ?
• UML(Unified Modeling Language) un langage de
modélisation unifié graphique et textuel.
• 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.
• Destiné à:
– Comprendre et décrire des besoins,
– Spécifier et documenter des systèmes,
– Esquisser des architectures logicielles,
– Concevoir des solutions,
– Communiquer des points de vue.

48
 Qu’est ce que UML ?

• UML est caractérisé par :

– Un travail d'expert,
– Utilise l’approche orientée objet,
– Normalisé et riche,
– Formel : sa notation limite les ambiguïtés et les incompréhensions,
– Langage ouvert: Indépendant du langage de programmation,
– Domaine d'application : permet de modéliser n'importe quel système.
• Supporté par plusieurs outils : Objecteering, Open tools, IBM
Rational Rose, PowerAMC, WinDesign, argoUML, StarUML,
• Attention: UML est un langage et non pas une méthode qui :
– Permet de représenter les modèles,
– Permet de définir le processus d'élaboration des modèles.
49
 Diagrammes d'UML

• UML s’articule autour de treize types de diagrammes.

• Chacun étant dédié à la représentation des concepts

particuliers d’un système logiciel.

• Il définit deux types de diagrammes:

– Sept diagrammes comportementaux (dynamiques ),

– Six diagrammes structurels (statiques).

50
 Diagrammes d'UML
• Sept diagrammes comportementaux :
– Diagramme de cas d’utilisation: modélise les interactions fonctionnelles entre les
acteurs et le système à l’étude.
– Diagramme de séquence: montre la séquence verticale des messages passés entre
objets au sein d’une interaction.
– Diagramme de communication: représente la communication entre objets dans le
plan au sein d’une interaction.
– Diagramme d’activité: montre l’enchaînement des actions et des décisions au sein
d’une activité.
– Diagramme d’états: montre les différents états et transitions possibles des objets
d’une classe.
– Diagramme de vue d’ensemble des interactions: fusionne les diagrammes
d’activité et de séquence pour combiner des fragments d’interaction avec des
décisions et des flots.
– Diagramme de temps: fusionne les diagrammes d’états et de séquence pour
montrer l’évolution de l’état d’un objet au cours du temps.
51
 Diagrammes d'UML

• Six diagrammes structurels :

– Diagramme de classes: montre les briques de base statiques : classes,
associations, interfaces, attributs, opérations, généralisations, etc.
– Diagramme d’objets: montre les instances des éléments structurels et
leurs liens à l’exécution.
– Diagramme de packages: représente l’organisation logique du modèle
et les relations entre packages.
– Diagramme de composants: montre des structures complexes, avec
leurs interfaces fournies et requises.
– Diagramme de déploiement: montre le déploiement physique des «
artefacts » sur les ressources matérielles.
– Diagramme de structure composite: représente l’organisation interne
d’un élément statique complexe.

52
 Diagrammes d’UML
• UML 2.5 est composé de plusieurs diagrammes :

53
Conclusion

54
Chapitre 2 : Diagramme de cas
d’utilisation

55
 Diagramme de cas d’utilisation

Objectifs

• Présenter les concepts UML relatifs à la vue fonctionnelle

(diagramme de cas d’utilisation).

• Présenter la notation graphique du diagramme de cas

d’utilisation.

• Expliquer la sémantique des cas d’utilisation UML en

précisant le lien avec les interactions UML.

56
 Diagramme de cas d’utilisation
• Décrit, sous forme d’actions et de réactions, le comportement
d’un système du point de vue utilisateur.
• Permet de définir les limites du système et ses relations avec
l’environnement externe.
• Sert à modéliser les aspects fonctionnels d'un système.
• Fait ressortir les acteurs et les fonctions assurés par le système.
• Utilisé pour modéliser les exigences (besoins) du client.
• Comporte plusieurs éléments :
– Acteurs;
– Cas d'utilisation;
– Relations de dépendances, de généralisations et d'associations.

57
 Acteurs

• UML n’emploi pas le terme «utilisateur » mais « acteur ».

• Le terme acteur ne désigne pas:

– Seulement des utilisateurs humains;

– Mais également les autres systèmes (machines, programmes, …).

• Un acteur:
– Est un rôle joué par une entité externe,

– Qui agit sur le système (Comptabilité, service commercial, …),

– En échangeant de l’information (en entrée et en sortie).

58
 Acteurs (2)

• Remarques:
– La même personne physique peut jouer le rôle de plusieurs acteurs.

Exemple : Chef d’agence est un client de la banque.

– Plusieurs personnes peuvent jouer le même rôle, et donc agir comme un

même acteur.

Exemple:
• Plusieurs personnes peuvent jouer le rôle d’administrateur.

• Tout porteur d’une carte bancaire joue le rôle du client.

59
 Acteurs (3)
• Un acteur peut être représenté de deux manières différentes :
– Petit personnage (stick man)

Nom acteur

– Classe stéréotypée
<<Acteur>>
Nom Acteur

60
 Acteurs (4)
• Les acteurs peuvent être de trois types :
– Humains : utilisateurs du logiciel à travers son interface graphique, par
exemple.
– Logiciels : disponibles qui communiquent avec le système grâce à une
interface logicielle (API, ODBC, …).
– Matériels : exploitant les données du système (Imprimante, robots,
automates, …).

61
 Acteurs: exemple

<<Acteur>>
Site web de
l’établissement Professeur

association

<<Acteur>> Etudiant
imprimante

62
 Acteurs (5)
• De point de vue système on distingue deux types :
– Acteurs principaux :
• Utilisent les fonctions principales du système.
• Pour qui le cas d’utilisation produit un résultat observable.
Exemple: le client pour un distributeur de billets.
– Acteurs secondaires :
• Effectuent des tâches administratives ou de maintenance.
• Ils peuvent uniquement consulter ou informer le système lors de
l’exécution du cas d’utilisation.
Exemple: la personne qui recharge la caisse contenue dans le
distributeur.

63
 Acteurs (6)

Remarques:
– Une association est une relation entre des éléments UML (classes, cas
d’utilisation, etc.) qui décrit un ensemble de liens.

– Une association est utilisée dans le cadre du diagramme de cas

d’utilisation pour relier les acteurs et les cas d’utilisation par une
relation qui signifie simplement : « participe à ».

64
 Acteurs (7)

• Un acteur peut être une spécialisation

d'un autre acteur déjà défini.
• Dans ce cas, on utilise la relation de
généralisation/spécialisation. Acteur
général
• Remarque:
– Une bonne pratique consiste à faire figurer
les acteurs principaux à gauche des cas
d’utilisation et les acteurs secondaires à
droite.

Acteur
particulier 65
 Cas d'utilisation
• Introduit par Ivar Jacobson en 1992 dans sa méthode Object-
Oriented Software Engineering (OOSE).
• Technique de description du système étudié privilégiant le
point de vue de l'utilisateur.
• Repris par UML dans le but de:
– Déterminer une bonne délimitation du système;
– Spécifier d’une manière assez correcte les besoin d’un utilisateur;
– Améliorer la compréhension de son fonctionnement interne.

66
 Cas d'utilisation (2)
• Les cas d’utilisations:
– Permettent de modéliser les attentes (besoins) des utilisateurs;
– Représentent les fonctionnalités du système.
– Il correspond à un certain nombre d’actions que le système devra
exécuter en réponse à un besoin d’un acteur.
– Un cas d’utilisation représente un résultat observable pour un ou
plusieurs acteurs.
– Une interaction permet de décrire les échanges entre un acteur et un cas
d’utilisation.
– Un cas d'utilisation est représenté par une ellipse en trait plein,
contenant son nom.

cas d'utilisation
67
 Cas d'utilisation (3)
• L’intitulé du cas d’utilisation respecte le pattern:
verbe + compléments
– Le verbe de l’intitulé permet de spécifier la nature de la fonctionnalité
offerte par l’application.
– Les compléments permettent de spécifier les données d’entrée ou de
sortie de la fonctionnalité.
– Exemple « calculer taux d’intérêt du prêt » permet de comprendre que
l’application permet à ses utilisateurs de calculer le taux d’intérêt d’un
prêt.
calculer taux
d’intérêt du prêt

68
 Cas d'utilisation (4)
• Il faut bien comprendre que chaque cas d’utilisation doit avoir
un objectif en soi et pouvoir être réalisé indépendamment des
autres.
Exemple : site d’ e-commerce:
– Un internaute visite quelquefois le site dans le seul but de chercher des
ouvrages, sans intention d’acheter.
– Dans d’autres cas, il gère un panier virtuel pour faire une simulation, ou
obtenir un devis.
– Il peut également se connecter pour surveiller l’état de sa dernière
commande.
• Tous ces objectifs sont bien indépendants et auto-suffisants : il
s’agit de vrais cas d’utilisation.

69
 Structuration des cas d'utilisation
• Après avoir identifié les acteurs et les cas d'utilisation, il est
utile de restructurer l'ensemble des cas d'utilisation afin de
rechercher les:
– Comportements partagés;
– Cas particuliers, exceptions, variantes;
– Généralisations/spécialisations.
• UML définit trois types de relations standardisées entre les cas
d'utilisation :
– Une relation d'inclusion, formalisée par la dépendance «include»
– Une relation d'extension, formalisée par la dépendance «extend»
– Une relation de généralisation/spécialisation.

70
 Relation d'inclusion

• Lors de la description des cas d'utilisation, il apparaît qu'il existe des

sous-ensembles communs à plusieurs cas d'utilisation.

• Donc, il convient de factoriser ces fonctionnalités.

• Comment?
– Via la création de nouveaux cas d'utilisation qui sont utilisés par les autres
cas qui les avaient en commun.

71
 Relation d'inclusion (2)
• Cas A inclut cas B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser des
fonctionnalités partagées.

Cas B
<<include>>

Cas A

• Le cas d'utilisation pointé par la flèche (cas B) est une sous

partie de l'autre cas d'utilisation (cas A, dans notre exemple).

72
 Relation d'inclusion (3)
Retirer de
l’argent

Déposer
de l’argent
<<include>> S’authentifier

Effectuer
de Les cas d'utilisation "Déposer de
virements
l'argent", "Retirer de l'argent",
"Effectuer des virements" et "Consulter
Consulter solde" incorporent de façon explicite le
solde cas d'utilisation "S'authentifier", à un
endroit spécifié dans leurs
enchaînements.
73
 Relation d'inclusion (4)
• On utilise cette relation pour éviter de décrire plusieurs fois un
même enchaînement d'actions.
• Le but est de factoriser un comportement commun à plusieurs
cas d'utilisation dans un cas d'utilisation à part.
Remarques:
– La relation «include» n’a pour seul objectif que de factoriser une partie
de la description d’un cas d’utilisation qui serait commune à d’autres
cas d’utilisation.
– Le cas d’utilisation inclus dans les autres cas d’utilisation n’est pas à un
vrai cas d’utilisation:
• Car il n’a pas d’acteur déclencheur ou receveur d’évènement. Il est juste un
artifice pour faire de la réutilisation d’une portion de texte.

74
 Relation d'inclusion (5)

Synthèse:
– Une instance du cas source inclut obligatoirement le comportement
décrit par le cas d’utilisation destination.

– Permet de décomposer des comportements et de définir les

comportements partagées entre plusieurs cas d’utilisation.

Factorisation

75
 Relation d'extension
• Le CU source (B) ajoute, sous certaines conditions, son
comportement au CU destination (A).
• En d’autres termes, le CU B peut être appelé au cours de
l’exécution du CU A.
Cas A
Cas B <<extend>> point
d’insertion

• Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans le CU destination.

76
 Relation d'extension (2)

• Le cas d'utilisation de destination peut fonctionner tout seul,

mais il peut également être complété par un autre cas
d'utilisation, sous certaines conditions.
• On utilise principalement cette relation pour séparer le
comportement optionnel du comportement obligatoire.
Exemple : Au moment de l'authentification, il se peut que le
guichet retient la carte.

Retenir la S’authentifier
carte <<extend>>
77
Relations d’inclusion et d'extension
• La relation « extend » montre une possibilité d'exécution
d'interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle et non obligatoire.

• La relation stéréotypée «extend» permet d'étendre les

interactions et donc les fonctions décrites dans les cas
d'utilisation, mais sous certaines contraintes (conditions).

• La relation « include » suppose une obligation d'exécution

des interactions dans le cas de base.
78
 Relation d'héritage
• Il peut également exister une relation d'héritage entre cas
d'utilisation.
• Cette relation exprime une relation de
spécialisation/généralisation au sens classique.
Exemple
– Dans un système d'agence de voyage, un acteur "Touriste" peut
participer à un cas d'utilisation de base qui est "Réserver voyage", qui
suppose par exemple, des interactions basiques au comptoir de
l'agence.
– Une réservation peut être réalisée par téléphone ou par Internet.

79
 Relation d'héritage : Exemple
• On voit qu'il ne s'agit pas d'une relation "extend", car la
réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas d'utilisation "Réserver voyage".

• Les deux cas d'utilisation "Réservation voyage" et "Réserver

voyage par Internet" sont liés : la réservation par Internet est un
cas particulier de réservation.

• De façon générale, une situation de cas particulier se traduit par

une relation de généralisation/spécialisation.
80
Relation d'héritage : Exemple

Réserver
voyage

Réserver
Réserver
voyage par
voyage par
téléphone
internet

81
Structuration entre cas d’utilisation

Synthèse:

• Les UC peuvent être structurées par des relations :

– A inclut B : le cas A inclut obligatoirement le comportement définit
par le cas B; permet de factoriser des fonctionnalités partagées

– A étend B : le cas A est une extension optionnelle du cas B à un certain

point de son exécution.

– A généralise B : le cas B est un cas particulier du cas A.

82
 Relations entre cas d’utilisation
Exercice
– Un client peut effectuer un retrait bancaire via une carte
bancaire.
– Le retrait peut être effectué sur place ou par Internet.
– Le client doit être identifié (en fournissant son code d’accès)
pour effectuer un retrait, mais si le montant dépasse 500DH,
la vérification du solde de son compte est réalisée.
– Si le client n’a pas pu s’identifier, la carte est avalée.

83
 Description des cas d’utilisation
• Le diagramme de cas d’utilisation décrit les grandes fonctions
d’un système du point de vue des acteurs.
• Mais il n’expose pas de façon détaillée le dialogue entre les
acteurs et les cas d’utilisation.
• Alors, il est nécessaire de décrire ce dialogue.
• Deux façons sont couramment utilisées pour décrire les cas
d’utilisation :
– Description textuelle;
– Description à l’aide d’un diagramme de séquence.
84
Description des cas d’utilisation (2)
Exemple:
Retirer de
l’argent

SA
Déposer
VISA
de
<<include>>
l’argent S’authentifier
Porteur
de CB Effectuer
Visa de
virements

Consulter
solde
85
Description des cas d’utilisation (3)
Exemple:

Cas d’utilisation détaillé : sommaire d’identification

Titre : Retirer de l'argent avec une carte Visa
Résumé : ce cas d'utilisation permet à un porteur de carte Visa, non
client de la banque, de retirer de l’argent, si son crédit hebdomadaire
le permet.
Acteurs : Porteur de CB Visa (principal), SA Visa(secondaire).
Date de création : 20/07/24
Date de mise à jour : 15/09/24
Version : 1.2
Responsable : Monsieur X

86
Description des cas d’utilisation (4)

Description des enchaînements

Préconditions
1. La caisse du GAB est alimentée,
2. Aucune carte bancaire n'est dans le lecteur.
3. Le GAB est connecté à l’internet.

Scénario nominal :
1. Le porteur de CB Visa introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte Visa.
3. Le GAB demande au porteur de CB Visa de saisir son code d’identification.
4. Le porteur de CB Visa saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui codé sur la puce de la
carte.
6. Le GAB demande une autorisation au système d'autorisation VISA.

87
Description des cas d’utilisation (5)

Description des enchaînements (suite)

Scénario nominal (suite) :
7. Le système d'autorisation VISA donne son accord et indique le solde
hebdomadaire.
8. Le GAB demande au porteur de CB Visa de saisir le montant désiré du retrait.
9. Le porteur de CB Visa saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire.
11. Le GAB demande au porteur de CB Visa s'il veut un ticket.
12. Le porteur de CB Visa demande un ticket.
13. Le GAB rend sa carte au porteur de CB Visa.
14. Le porteur de CB Visa reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le porteur de CB Visa prend les billets et le ticket.

88
Description des cas d’utilisation (6)

Description des enchaînements (suite)

Enchaînements alternatifs

A1 : code d’identification provisoirement erroné

L’enchaînement A1 démarre au point 5 du scénario nominal.
6. Le GAB indique au client que le code est erroné, pour la première ou
deuxième fois.
7. Le GAB enregistre l’échec sur la carte.
Le scénario nominal reprend au point 3.

89
Description des cas d’utilisation (7)

Description des enchaînements (suite)

Enchaînements alternatifs (suite)

A2 : montant demandé supérieur au solde hebdomadaire

L’enchaînement A2 démarre au point 10 du scénario nominal.
11. Le GAB indique au client que le montant demandé est supérieur au
solde hebdomadaire.
Le scénario nominal reprend au point 8 (la ressaisi du mentant.)

90
Description des cas d’utilisation (8)

Description des enchaînements (suite)

Enchaînements alternatifs (suite)

A3 : ticket refusé
L’enchaînement A3 démarre au point 11 du scénario nominal.
12. Le porteur de CB Visa refuse le ticket.
13. Le GAB rend sa carte au porteur de CB Visa
14. Le porteur de CB Visa reprend sa carte.
15. Le GAB délivre les billets.
16. Le porteur de CB Visa prend les billets.

91
Description des cas d’utilisation (9)

Description des enchaînements (suite)

Enchaînements d'exception

E1 : carte invalide
L’enchaînement E1 démarre au point 2 du scénario nominal.
3. Le GAB indique au porteur que la carte est invalide (illisible,
périmée, etc.). Le cas d’utilisation est terminé.

92
Description des cas d’utilisation (10)

Description des enchaînements (suite)

Enchaînements d'exception (suite)

E2 : code d’identification définitivement erroné

L’enchaînement E2 démarre au point 5 du scénario nominal.
6. Le GAB indique au client que le code est erroné, pour la troisième
fois.
7. Le GAB garde la carte.
8. Le système d'autorisation VISA est informé et le cas d’utilisation est
terminé.

93
Description des cas d’utilisation (11)

Description des enchaînements (suite)

Enchaînements d'exception (suite)

E3 : retrait non autorisé

L’enchaînement E3 démarre au point 6 du scénario nominal.
7. Le système d'autorisation VISA interdit tout retrait.
8. Le GAB éjecte la carte et le cas d’utilisation est terminé.

E4 : carte non reprise

L’enchaînement E4 démarre au point 13 du scénario nominal.
14. Au bout de 15 secondes, le GAB confisque la carte.
15. Le système d'autorisation VISA est informé et le cas d’utilisation est
terminé.
94
Description des cas d’utilisation (12)

Description des enchaînements (suite)

Enchaînements d'exception confisque

E5 : billets non pris

L’enchaînement E5 démarre au point 15 du scénario nominal.
16. Au bout de 30 secondes, le GAB reprend les billets.
17. Le système d'autorisation VISA est informé et le cas d’utilisation est
terminé.

Postconditions

La caisse du GAB contient moins de billets qu'au début du cas d'utilisation.

95
Description des cas d’utilisation (13)
• Si l’on adopte cette technique pour formaliser les exigences, il
faut savoir qu’un UC ne décrit que les exigences
fonctionnelles.
• Alors, il faut compléter avec d’autres exigences:
– Interfaces externes,
– Règles métier,
– Formats de données,
– Performance…

96
Description des cas d’utilisation (14)
Exemple : Exigences non fonctionnelles
Contraintes Descriptif
Temps de • L’interface du GAB doit réagir en 2 secondes au
réponse maximum.
• Une transaction nominale de retrait doit durer moins de 2
minutes.
Concurrence Non applicable (mono-utilisateur).
Disponibilité • Le GAB est accessible 7 jours sur 7, 24 h sur 24.
• L’absence de papier pour imprimer les tickets ne doit pas
empêcher les retraits.
Intégrité • Les interfaces du GAB doivent être très robustes pour
prévenir aux actes de Vandalisme.
Confidentialité • La comparaison du code d’identification saisi sur le
clavier du GAB avec celui de la carte doit être fiable à 10-6
97
 Description des cas d’utilisation
Exemple : Exigences non fonctionnelles (suite):
– Besoins d’IHM:
• Les dispositifs d’entrée/sortie à la disposition du porteur de carte doivent être :
– Un lecteur de carte bancaire.

– Un clavier numérique (pour saisir son code), avec des touches « validation »,
« correction » et « annulation ».

– Un écran pour l’affichage des messages du GAB.

– Des touches autour de l’écran pour sélectionner un montant de retrait parmi ceux
qui sont proposés.

– Un distributeur de billets.

– Un distributeur de tickets.

98
 Diagramme des cas d'utilisation
• Le diagramme des cas d'utilisation regroupe dans un même schéma:
– Les acteurs,

– Les cas d'utilisation,

• Qui sont reliés par des relations d’inclusion, d’extension et d’héritage.

• Le système étant délimité par un cadre rectangulaire.

• La représentation de base d'un cas d'utilisation est une ellipse contenant le

nom du cas.

• L'interaction entre un acteur et un cas d'utilisation se représente comme une

association.

• Elle peut comporter des multiplicités comme toute association entre classes.

99
 Étapes de construction du diagramme
des cas d'utilisation
• Pour modéliser en diagramme des cas d'utilisation, il faut :
1. Identifier les acteurs qui entourent le système.
• Certains acteurs utilisent le système pour accomplir des tâches (acteurs principaux),
• D'autres effectuent des tâches de maintenance ou d'administration (acteurs
secondaires).
2. Organiser les acteurs selon une hiérarchisation de généralisation/spécialisation.
3. Intégrer les acteurs au diagramme en spécifiant les cas d'utilisation auxquels ils
se rapportent.
4. Structurer les cas d'utilisation pour faire apparaître les comportement partagés
(relation d'inclusion), les cas particuliers (généralisation/spécialisation) ou les
options (relation d'extension).
5. Répéter les points 1-4 jusqu’à la satisfaction.
100
 Résumé

Analyste Comprend Exprime Utilisateur

Les cas d’utilisation

servent de fil
conducteur pour
l’ensemble du projet Réalise
Conçoit Programmeur

Architecte Vérifie

Testeur
Les Cas d’utilisation interviennent tout au longue du cycle de vie d’un projet
101
 Exercice
Quel sont les erreurs commises dans le diagramme de cas
d’utilisation suivant :

Décrocher Appuyer sur Reposer le

le pistolet la gâchette Payer
pistolet

client

102
Conclusion

103
 Chapitre 3: Diagrammes de
classes, de packages et d’objets.

104
 Diagrammes de classes
Objectifs
• Présenter les concepts UML relatifs à la vue structurelle
(diagramme de classes).
• Présenter la notation graphique du diagramme de classes
UML.
• Expliquer la sémantique des classes UML (compatible avec la
sémantique des langages de programmation orientés objet).
• Identifier les concepts du domaine et les modéliser en tant que
classes.
• Identifier les associations pertinentes entre les concepts.

105
 Diagrammes de classes (2)
Objectifs (suite)

• Identifier les multiplicités à chaque extrémité d’association.

• Ajouter des attributs aux classes du domaine.

• Utiliser les classes d’association, contraintes et qualificatifs.

• Utiliser les diagrammes d’objets pour illustrer les diagrammes

de classes.

• Structurer notre modèle de classes en packages.

106
 Diagrammes de classes (3)
• Les diagrammes de cas d'utilisation modélisent à QUOI sert le
système.
• Le système est composé d'objets qui interagissent entre eux et
avec les acteurs pour réaliser ces cas d'utilisation.
• Les diagrammes de classes permettent de spécifier la structure
et les liens entre les objets dont le système est composé.
• Il montre la structure interne.
• Il permet de fournir une représentation abstraite des objets du
système qui vont interagir ensemble pour réaliser les cas
d’utilisation (répondre à QUOI faire).
• C’est le point central dans un développement orienté objet.

107
 Diagrammes de classes (4)

• Permet de donner une vue statique du système en terme de :

– Classes d'objets;
– Relations entre classes:
• Associations;
• agrégation/composition;
• Généralisation/spécification(héritage).
• La description du diagramme de classes est centrée sur trois
concepts :
– Le concept d’objets;
– Le concept de classes d’objets comprenant des attributs et des
opérations;
– Les différents types de relations entre classes.

108
 Concept de classes et instances
• Une instance est une concrétisation d’un concept abstrait.
Exemple :
– Ma voiture « Hyandai Tuccson » est une instance du concept
abstrait Voiture,
– Le cours UML que j’enseigne est une instance du concept
abstrait Cours.
• Une classe est un concept abstrait représentant des éléments
variés comme:
– Des éléments concrets (des voitures, avions, … ),
– Des éléments abstraits (des commandes de marchandises ou services),
– Des composants d’une application (les boutons des boîtes de dialogue),
– etc.
109
 Concept de classes et instances (2)
• Tout système orienté objet est organisé autour des classes.
• Une classe est la description formelle d’un ensemble d’objets
ayant une sémantique et des caractéristiques communes.
• Elle spécifie l'ensemble des caractéristiques qui composent des
objets de même type.
• Classe = ensemble d’objets ayant les mêmes propriétés
(attributs) et le même comportement (opérations).
– Tous les clients sont décrits par un nom, un prénom, … qui peuvent
acheter, négocier, …
– Tous les comptes bancaires ont un numéro, un solde, … sur lesquels
on peut déposer ou retirer l'argent, ou les consulter.
– …
110
 Concept de classes et instances (3)
• Un objet est instance d’une classe, et le fait de créer un
objet d'une classe est dite instanciation.
• Classe représentée par un rectangle à trois parties :
– Partie 1 : Nom de la classe,
– Partie 2 : Attributs (propriétés, champs),
– Partie 3 : Méthodes (fonctions, opérations).

NomClasse
attributs
méthodes
111
 Concept d'objet
• Objet = un concept, abstraction ou une entité autonome qui a
un sens dans le contexte du système à modéliser:
– Un client C1,
– Un livre V1,
– Un compte bancaire n° 1915233C,
– …
• L’état d’un objet correspond aux valeurs de tous ses attributs à
un instant donné.
Remarque
– Un objet doit :
• Être autonome;
• Avoir une signification dans le système;
• En relation avec d'autres objets.
Exemples
• Gestion de stock : Clients, Commandes, Articles, …
• Gestion d’une société: Employé, Atelier, Spécialité, …
112
 Concept d'attribut
• Un attribut est une propriété caractéristique d’un objet.
Exemple :
– un étudiant a un nom, un prénom, une adresse, un CNE, …
– un compte bancaire a un numéro, un solde, …
• Un attribut doit (généralement) avoir une valeur
• La description d’un attribut comporte :
Visibilité attribut: type [= valeur initiale]
– Visibilité : (+ publique), (- privée) et (#protégée, protected)
– Nom d’attribut
– Type d’attribut
– Valeur initiale (facultative)

113
 Concept d'attribut (2)
• Le type d’un attribut peut être :
– Un type de base : entier, réel, …
– Une expression complexe : tableaux, enregistrements, …
– Une classe.
Exemples d’attributs :
• - code : 1254, 2536, …
• # notes[] : float
• - Client : Personne
• Par exemple, une classe « Rectangle » peut contenir les attributs
suivants :
Rectangle
• longueur : réel,
- Largeur : float = 8.0
• largeur : réel,
- Longueur : float
• /surface : réel. - /Surface : float

114
 Concept d'attribut (3)
• On distingue deux types d'attributs :
– Attribut d'instance :
• Chaque instance de la classe possède une valeur particulière pour cet
attribut.
• Notation : Visibilité attribut: type[= valeur initiale]
– Attribut de classe:
• Toutes les instances de la classe possède la même valeur pour cet attribut.
• Notation : Visibilité attribut: type[= valeur initiale]
• Équivalent en C++, Java : static.

115
Concept d'attribut (4)
Fenêtre
- taille : Rectangle = (100,50)
Attributs d'instances
- visibilité : boolean = true
- tailleDefaut : Rectangle
-tailleMax : Rectangle Attributs de classes

116
 Concept d'attribut: Exercice

• Question 1:
 Définissez la classe UML représentant un étudiant. Cette classe
d’étudiants est caractérisée par un identifiant, un nom, un prénom et
une date de naissance.
• Question 2:
 Définissez la classe UML représentant un cours, caractérisé par un
identifiant, un nom, le nombre d’heures de cours magistral, le
nombre d’heures de travaux dirigés et un nombre d’heures de
travaux pratiques que doit suivre un étudiant.

117
 Concept d'attribut: Exercice

• Réponse 1:

• Réponse 2:

118
 Concept d'opération et méthode
• Dans une classe, une opération (même nom et même types de
paramètres) doit être unique.
• Une opération est :
– Un service produit par la classe.
– Une fonction ou une transformation qui peut être appliquée aux objets
d’une classe.
– Permet de décrire le comportement d’un objet.
Exemple, « Embaucher », « Licencier » et « Payer » sont des opérations
de la classe « Société ».
– L’implémentation d’un service proposé par la classe (opération).
– Différents types (Accesseurs, Modificateurs et Constructeurs).

119
Concept d'opération et méthode (2)
La description d’une opération comporte :
Visibilité opération([arguments:type[=valeur initiale]]):type de résultat
– Visibilité de l’opération (-, +, #);
– Nom de l’opération;
– Liste des arguments avec leurs types et éventuellement leurs valeurs par
défaut; Compte
– Le type du résultat retourné. - NumCompte : String
- Solde : float
- Client : Personne

+ <<Constructeur>> Compte()
+ deposer (somme : float) : void
+ retirer(somme : float) : float
+ getSolde() : float
120
Concept d'opération et méthode (3)
• Quand le nom d’une opération apparaît plusieurs fois avec des
paramètres différents, on dit que l’opération est surchargée.

• Il est impossible que deux opérations ne se distinguent que par

leur valeur retournée.

Méthode de classe

• Comme pour les attributs de classe, il est possible de déclarer

des méthodes de classe.

• Une méthode de classe ne peut manipuler que des attributs de

classe et ses propres paramètres.
121
Concept d'opération et méthode (4)

Méthode de classe

• Cette méthode n’a pas accès aux attributs de la classe (i.e. des
instances de la classe).

• L’accès à une méthode de classe ne nécessite pas l’existence

d’une instance de cette classe.

• Graphiquement, une méthode de classe est soulignée.

122
 Concept d'attribut
Fenêtre
- taille : Rectangle = (100,50)
Attributs d'instances
- visibilité : boolean = true
- tailleDefaut : Rectangle
-tailleMax : Rectangle Attributs de classes

+ <<Constructeur>> Fenêtre()
+ affiche() : void
Opérations d'instances
+ cacher() : void
+ getTailleMax() : Rectangle
+ getTailleDefaut() : Rectangle Opérations de classes

123
 Concept d'opération et méthode:
Exercice
Question 1:
• On nomme modifierAdresseEtudiant() l’opération permettant
de modifier l’adresse de l’étudiant.
• Positionnez cette opération dans une classe, puis précisez les
paramètres de cette opération.
Question 2:
• On nomme coursDeEtudiant() l’opération permettant d’obtenir
l’ensemble des cours suivis par un étudiant.
• Positionnez cette opération dans une classe, puis précisez les
paramètres de cette opération.

124
Encapsulation, visibilité et interface

• Encapsulation est le mécanisme de regrouper les attributs et les

opérations au sein d’une même entité (classe).

• Ce regroupement permet d’empêcher d’accéder directement

aux données par un autre moyen que via les services proposés
(opérations).

• Ces services montrés aux utilisateurs ce que l’on appelle

l’interface de la classe.

125
Encapsulation, visibilité et interface (2)

Données
} •
•
Partie statique, passive
Partie cachée, privée

• Partie dynamique, comportementale

Traitement • Partie visible, publique
• Interface avec l’extérieur

utilisateur
126
 Méthodes et classes abstraites
• Une méthode est dite abstraite si on connaît son entête, mais
pas la manière dont elle peut être réalisée.
• Une classe est dite abstraite lorsqu’elle contient au moins une
méthode abstraite.
FormeGeometrique {abstract}
- abs : int
- ord: int
-…

+ {abstract} surface () : double

+ getAbs() : int
+ getOrd(): int
+ ….

127
 Méthodes et classes abstraites (2)

• On ne peut pas instancier une classe abstraite : elle est promise

à se spécialiser.

• Une classe abstraite peut très bien contenir des méthodes

concrètes.

• Une classe abstraite pure ne comporte que des méthodes

abstraites.

128
 Classe « Interface »
• Une interface est une classe spéciale dont toutes les méthodes
sont abstraites.
• Une interface se note en UML avec le stéréotype
<<interface>>
<<interface>>
Forme
- abs : int
- ord: int
-…
+ surface () : double
+ getAbs() : int
+ getOrd(): int
+ ….

129
 Associations

• Un lien est une connexion physique ou conceptuelle entre

instances de classes.

• Une association décrit un groupe de liens ayant une même

structure et une même sémantique.

• Un lien est une instance d’une association.

• Une association entre des classes représente les liens qui

existent entre les instances de ces classes.

• Une association porte un nom (signification).

130
 Associations
• Représentée par une ligne rectiligne.

Client Compte

Etudiant cours

• Une association indique qu’il peut y avoir des liens entre des
instances des classes associées.

131
 Associations
• Remarque
– Une association fonctionne (généralement) dans les 2 sens
(bidirectionnelle).
• Les termes associés à une association sont:
– Nom,
– Sens de lecture,
– Multiplicité,
– Rôle,
– Navigabilité,
– degré (arité).

132
 Associations
Nom et sens de lecture
• Décrit la nature (signification) de l’association.
• Montre la direction de lecture de l’association.
Est titulaire d’un
Client Compte
Appartient à un

Multiplicité
• Indique un nombre de participations d’une classe dans une
association.
• Indique un domaine de valeurs pour préciser le nombre
d’instance d’une classe vis-à-vis d’une autre classe pour une
association donnée.
133
 Associations
Multiplicité
1. indiquée à chaque extrémité d’une association
2. sous la forme min..max
3. min, max = 0, 1, *

1 1..*
Exemples Société Personne
Employeur Employé

Est titulaire d’un

1..1 0..*
Client Compte
Appartient à un

Remarque: peut aussi être utilisée pour d’autres usages

comme par exemple un attribut multivalué.
134
 Associations

Notation abrégée des multiplicités :

1  1..1 (exactement 1)
*  0..* (0 ou plusieurs) * 0..1
A B
n  n .. n (exactement n)
1..*  1 ou plusieurs (1 ou plus) À une instance de A
correspond 0 ou 1 instance de
0..1  0 ou 1 (au plus un) B.
À une instance de B
1..100  entre 1 et 100 correspond 0 à nombre non
déterminé d’instances de A.
2,4,5  2, 4 ou 5

135
 Associations
Rôle d’une association
• Décrit le rôle d’une classe dans une association.
• Le rôle tenu par une classe vis-à-vis d’une association peut
être précisé sur l’association.

Société Personne
Employeur Employé

136
 Associations

Rôle d’une association

• Utile surtout dans deux cas:
– Lorsqu’on a plusieurs associations entre deux classes avec des rôles
différents.
Pilote
Avion Personne
Passager

– Une relation réflexive : relation entre deux instances d’une même

classe.
femme
0..4 Personne
0..1
homme

137
 Associations: Exercice
Question:
• Définissez les associations qui peuvent exister entre un
enseignant et un cours.
Réponse:

138
 Association

Navigabilité
• Par défaut une association est navigable dans les deux sens
c’est-à-dire elle est bidirectionnelle.

Commande Client
1..* 1

Chaque instance de commande a un lien vers le client.

Chaque instance de client a un ensemble de lien vers les
commandes.

• La navigabilité indique si l’association fonctionne de

manière unidirectionnelle ou bidirectionnelle.
139
 Association

Navigabilité
• Elle est matérialisée par une ou deux extrémités fléchées.
• La non navigabilité se représente par un « X ».
• Exemple:

Voiture * * ServiceContravention

• Le service de contravention est associé à une ou plusieurs voiture(s).

• La voiture ne connaît pas service de contravention.

CopieExamen * 1 Etudiant

• À un étudiant sont associées ses copies d’examen.

• l’inverse n’est pas possible (retrouver directement l’auteur de la copie
d’examen). 140
 Associations
degré d’une association = nombre de classes participantes

 Association unaire : relie 2 instances d'une classe

 association binaire : relie 2 classes
 association ternaire : relie 3 classes
 association n-aire : relie n classes

Professeur

Symbole d’association

Salle Etudiant
Attention
difficiles à déchiffrer
141
 Qualification d'une association

• La qualification d’une association permet de restreindre la

multiplicité d’une association.
• La qualification se représente par un rectangle placé au niveau
de la classe source du qualificatif.
• Exemple : une banque contient plusieurs comptes, d'où le
diagramme :
Banque Compte
1 1..*

• Par contre, si on connaît le N°Compte, il y a un et un seul

compte, on obtient alors :

NCompte Compte
Banque
1 1 142
 Qualification d'une association

Exercice
• Un avion est composé de plusieurs sièges, mais dans une
rangée il y a seulement quatre sièges.

143
 Associations
Classe association
• Les associations ne pouvant pas posséder de propriété.
• Donc, il faut introduire un nouveau concept pour modéliser
cette situation : celui de classe association.
• Les classes association sont utiles quand il y a des attributs qui
sont pertinents à l’association, mais à aucune des classes
impliquées.
• Une classe association est connecté à deux ou plusieurs
classes.
• Elle possède également des attributs et des opérations.
• Une classe association est caractérisée par un trait discontinu
entre la classe et l’association qu’elle représente.

144
 Associations
Classe association
• Exemples:
– L’association Emploie entre une Entreprise et une Personne possède
comme propriétés le salaire et la date d’embauche.
– Ces deux propriétés n’appartiennent ni à l’entreprise, qui peut employer
plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs
emplois.
– Il s’agit donc bien de propriétés de l’association Emploie.
1..* 0..1
Personne Entreprise

Emploi
-Periode: int
-Salaire: float
145
 Associations
Classe association
• Exemple
• Le diagramme suivant montre que l’on souhaite enregistrer l’année où
tout étudiant s’inscrit à un module.
• De cette instance, on en déduit, par exemple, que e3 est inscrit au
module 1 en 2005 et au module 3 en 2006.

146
 Agrégation

• Une association simple entre deux classes représente une

relation entre deux classes de même niveau conceptuel :
aucune des deux n’est plus importante que l’autre.
• Lorsque l’on souhaite modéliser une relation (tout)-(partie de
tout) où une classe constitue un élément plus grand (tout) et
composé d’éléments plus petit (partie), il faut penser à autre
relation.
• C’est l’agrégation: association qui représente une relation
d’inclusion d’un élément dans un ensemble.

147
 Agrégation

• L’agrégation est une association qui permet de représenter un

lien de type « ensemble » comprenant des « éléments » :
- Ensemble : agrégat
- Éléments : agrégés
• Est un cas particulier d’association non symétrique exprimant
une relation de contenance.
• Les agrégations n’ont pas besoin d’être nommées :
implicitement elles signifient « contient », « est composé de».
• Graphiquement, on ajoute un losange vide du côté de
l’agrégat.

148
 Agrégation

• Type particulier d’association dans laquelle :

– Classe agrégat (composé), classes agrégée (composant)
– Entre les deux, il existe une relation de type « est composé de »
Agrégat Agrégée

Pays Région
*

Equipe Joueur
*

– Les parties (les composants) sont séparables de l’agrégat.

– La suppression d’une équipe n’implique pas la suppression des
personnes qui la composent.
149
 Composition
• La composition est un cas particulier d’une agrégation dans
laquelle la vie des composants est liée à celle de l’agrégat
composé.
• si l’agrégat est détruit (ou déplacé), ses composants le sont
aussi.
• Contrairement à l’agrégation, une instance de composant ne
peut être liée qu’a un seul agrégat.
• La composition est une relation d’agrégation dans laquelle il
existe une contrainte de durée de vie entre la classe «
composant » et la ou les classes « composé ».

150
 Composition

• La destruction de l’objet composite implique la destruction de

ses composants.
• La multiplicité du côté composite ne doit pas être supérieure à
1.
• La composition se représente par un losange noir (plein).

Fichier Répertoire
0..* 1

151
 Composition

Exercice
• Un document est composé de plusieurs paragraphes, qui, à
son tour, est composé de plusieurs phrases.
• Remarque
• Les notions d’agrégation et surtout de composition posent de
nombreux problèmes en modélisation et sont souvent le sujet de
discussions d’experts et sources de confusions.

152
 Généralisation / Spécialisation

• La généralisation est la relation entre une classe et une ou

plusieurs de ses versions raffinées.
• On appelle la classe dont on tire les précisions la super-classe
et les autres classes les sous-classes.
• C’est une relation de type « est un » ou « est une sorte de ».
• La notation utilisée pour la généralisation est le triangle.
• Généraliser = mettre en facteur des classes  « super-
classe ».
• Spécialiser = décrire de nouveaux détails  « sous-
classes ».

153
 Généralisation / Spécialisation

• Exemple
(StarUML)

Comparable à une association de type « est un»

une sous-classe hérite des attributs et opérations de sa super-classe (classe
mère) 154
 Généralisation / Spécialisation

• Exemple (PowerAMC)
Compte
- N°Compte : String
- Solde : float
+ <<Constructor>> Compte ()
+ Déposer (float Somme) : void
+ Retirer (float Somme) : float
+ AvoirSolde () : String

CompteEpargne
- Taux : float
+ AvoirSolde () : String
155
Généralisation / Spécialisation: Exercice

Exercice
• Pensez-vous qu’il soit possible de définir un lien d’héritage
entre les classes UML représentant respectivement les
étudiants et les enseignants ?

156
 Généralisation / Spécialisation

Une classe peut hériter de plusieurs super-classes

= héritage multiple

Etudiant Employe

EdudiantEmploye

157
 Dépendance

• Une dépendance est une relation unidirectionnelle exprimant

une dépendance sémantique entre des éléments du modèle.
• Elle indique que la modification de la cible peut impliquer une
modification de la source.
• La dépendance est souvent stéréotypée pour mieux expliciter
le lien sémantique entre les éléments du modèle.
• Elle est représentée par un trait discontinu orienté.
• On utilise souvent une dépendance quand une classe utilise
une autre comme argument dans la signature d’une opération.

158
 Dépendance

• Une classe B est en dépendance de la classe A si des éléments

de la classe A sont nécessaires pour construire la classe B.
• Par exemple, le diagramme de la figure (slide suivant) montre
que la classe Confrontation utilise la classe Stratégie car la
classe Confrontation possède une méthode confronter dont
deux paramètre sont du type Stratégie.
• Si la classe Stratégie, notamment son interface, change, alors
des modifications devront également être apportées à la
classe Confrontation.

159
 Dépendance

• Exemple

160
 Contraintes sur les associations
• Une contrainte:
– Est une note ayant une valeur sémantique particulière pour un élément
de la modélisation.
– Permet d’imposer des règles à respecter lors du passage à
l’implémentation.
– Concepts avancés des associations.
– Représentée entre accolades.
– Peut être exprimée dans n’importe quel langage.
• Il est possible d’attribuer toutes sortes de contraintes à une
association.

161
 Contraintes sur les associations
contrainte {ordonné}

• Les contraintes (prédéfinies) souvent utilisées :{ordonné},

{xor}, {frozen} …
• Indique que les objets seront ordonnés à chaque opération de
création, modification, suppression, …

1 0..*
Client Compte
{ordonné}

Les comptes d’une personne sont ordonnés

1 0..*
Classe Chaise
{ordonné}
162
 Contraintes sur les associations
contrainte {xor}

• Indique que parmi un groupe d’associations, une seule est

valide à la fois

1 Batterie

1 Un PC Portable est alimenté soit à partir

PC Portable {xor} d’une batterie, soit à partir d’un secteur
1

1 secteur

163
 Contraintes sur les associations
contrainte {frozen}

• La contrainte prédéfinie {frozen} interdit l’ajout, la

suppression ou la mise à jour des liens d’un objet vers les
objets de la classe associée, après l’initialisation du premier.

0..*
Personne enfant
{frozen} 2
parent

164
 Package
• Un package permet de regrouper des classes, des interfaces et
même d’autre packages.
• La structuration d’un modèle en packages est une activité
délicate.
• Elle doit s’appuyer sur deux principes fondamentaux:
– Cohérence
– Indépendance.
Cohérence
• La cohérence consiste à regrouper les classes qui sont proches
d’un point de vue sémantique.

165
 Package
Cohérence
• Les critères de cohérence suivants doivent être réunis :
– Finalité : les classes doivent rendre des services de même nature aux
utilisateurs,
– Évolution : on isole ainsi les classes réellement stables de celles qui
vont vraisemblablement évoluer au cours du projet, ou même par la
suite,
– Cycle de vie des objets: ce critère permet de distinguer les classes dont
les objets ont des durées de vie très différentes.
Indépendance
• Forcer la minimisation des relations entre packages.

166
 Package
• Un package est représenté par un rectangle possédant un
onglet dans lequel est inscrit le nom du package
Dessin
<<interface>>
Forme

Rectangle
<<implements>>

Cercle
Carré
<<realize>>

167
 Import des packages
• La relation d’import permet à une classe d’un package
d’utiliser les classes d’un autre package.
• La relation est monodirectionnelle : elle comporte un package
source et un package cible.
• La relation d’import s’exprime avec une flèche en pointillé.
• Dans l’exemple, la classe ‘Afficheur’ a besoin des classes du
package ‘Dessin’.

168
 Import des packages

Dessin
Outil Dessin
<<interface>>
Forme

Rectangle afficheur
<<implements>>

Cercle
Carré <<realize>>

169
Etapes d'établissement un diagramme de classes

A partir d’une description du système :

1. Identifier au premier lieu ensemble de classes candidates
2. Identifier les associations et les attributs
3. Identifier les généralisations
4. Lister les traitements, choisir les opérations
5. Vérifier le modèle obtenu
a. Supprimer les transitivités
b. S’assurer que le schéma répond à la demande
6. Itérer jusqu’à satisfaction …

170
 Diagramme d’objets

• 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
classes.
• Ils ne montrent rien de architecture différente de diagrammes
de classes, mais reflètent la multiplicité et rôles.

171
 Diagramme d’objets

• Représente les objets (instances de classes) et les liens

(instances de relations) à un instant donné.
• Peut être utilisé pour :
– Illustrer le modèle de classes en montrant un exemple qui explique le
modèle,
– Préciser certains aspects du système,
– Exprimer une exception en modélisant des cas particuliers,
– Permettre d’affiner un aspect délicat d’un diagramme de classes via un
exemple, ou encore un contre-exemple.
– Etc.
• Un diagramme d’objets est compose :
– d’objets (instances de classes),
– de liens (instances d’associations).

172
 Diagramme d’objets
• Le nom d’un objet est souligné
– Nom : Classe
– Nom
– :Classe

173
 Diagramme d’objets
• Les objets sont relies par des instances d’associations : les
liens.
• Un lien représente une relation entre objets à un instant donné.
• ATTENTION : la multiplicité des extrémités des liens est
toujours égal à 1.
• Les rôles des associations peuvent être représentés
explicitement :

0..* Khalid
Personne enfant Père
2
parent

Nadine
174
 Diagramme d’objets
• Règles:
– Chaque objet est instance d’une classe et la classe de l’objet ne change
pas durant la vie de l’objet.
– Les classes abstraites ne peuvent pas être instanciées.
– Les liens relient les objets et les relations relient les classes.
– Chaque lien est instance d’une relation (association, agrégation,
composition)
– Un lien entre deux objets implique une relation entre les classes (ou
superclasses) des 2 objets.
– Un lien entre 2 objets indiquent qu’ils se connaissent et qu’ils peuvent
s’échanger des messages.
– Les diagrammes d’objets qui contiennent des objets et des liens sont
instances des diagrammes de classes qui contiennent des classes et des
relations.

175
 Diagramme d’objets
• Exemple :
– Une entreprise emploie au moins deux personnes.
– Une personne travaille dans une au plus deux entreprises.

Entreprise
:Entreprise e1:Entreprise

0..2

2..*

Personne
:Personne p1:Personne p2:Personne p3:Personne p4:Personne

176
 Diagramme d’objets
• Exemple

177
Conclusion

178
 Chapitre 4 : Diagrammes de
séquences, d’activités, de vue globale
d’interaction et états.

179
 Diagrammes de séquences

Objectifs
• Présenter les concepts UML relatifs à la vue comportementale
du système (diagramme de séquence).
• Présenter la notation graphique du diagramme de séquence
UML.
• Expliquer la sémantique des séquences UML en précisant le
lien avec les classes UML.

180
 Diagrammes de séquences

• Les diagrammes de cas d'utilisation listent des interactions

avec des acteurs en spécifiant les grandes fonctions d'un
système.
• Les diagrammes de séquences permettent de décrire comment
les éléments d'un système et les acteurs interagissent:
– Les objets au cœur d'un système interagissent lorsqu'ils s'échangent des
messages.
– Les acteurs interagissent avec le système au moyen d'IHM.
• Un diagramme de séquences montre l'échange d'informations
entre différents classeurs (acteurs, classes, etc).

181
 Diagrammes de séquences

• Ils montrent sous la forme de scénarios, la chronologie des

interactions (« envoies de messages ») issus d’un cas
d’utilisation:
– Entre objets (et acteurs),
– Selon un point de vue temporel (chronologie des envois de messages).
• Ils représentent une instance d’un cas d’utilisation (les
scénarios possible d’un cas d’utilisation donné).
• Le diagramme de séquence fait ressortir :
– Les acteurs,
– Les objets,
– Les messages.
182
 Diagrammes de séquences
 L'ordre d'envoi d'un message est déterminé par sa position sur
l'axe vertical du diagramme.
DiagremmeSequences
le temps s'écoule
du haut en bas de :Objet 1 :Objet 2 :Objet 3
cet axe
Message 1
temps
Message 2
Message 3

Ligne de vie de l’objet

183
 Diagramme de séquences
• Un objet est représenté par un rectangle.
• La ligne verticale représente la ligne de vie de l’objet.
• Les objets communiquent via des messages représentés par des
flèches orientées de l’émetteur au récepteur.
• L’ordonnancement verticale des messages indique la
chronologie.
• Un message reçu par un objet déclenche l’exécution d’une
opération ou plusieurs.
• Un message envoyé par objet correspond :
– Demander un service d’un autre objet;
– Renvoyer le résultat d’une opération;

184
Diagrammes de séquences : Exemple
DiagremmeSequences_1

:Compte
:Client
retirer(somme)

Solde -=somme

Donner (somme)

imprimerReçu()

• Le client demande un service (retirer de l’argent) à l’objet Compte

• Le compte reçoit le message et déclenche l’opération de même nom avec
une opération de soustraction
• Le compte retourne le résultat (donner la somme et imprimer le reçu) 185
 Diagrammes de séquences
• Plusieurs concepts additionnels :
– Période d’activité;
– Types de messages;
– Création et destruction d’objets;
– Structures de contrôles;

186
 Période d’activité
• Une période d’activité correspond au temps pendant lequel un
objet effectue une action:
– soit directement,
– soit par l’intermédiaire d’un autre objet qui lui sert de sous-traitant.
• Représentée par une bande rectangulaire superposée sur la
ligne de vie de l’objet. DiagremmeSequences_1

:Objet 1 :Objet 2
Message 1()
t1
{t2-t1 <2s} Durée
t2 d’activation

187
 Période d’activité

• Remarque
– Lorsque le diagramme de séquence est utilisé pour représenter un
sous-ensemble du logiciel à réaliser, il est possible d’indiquer le
pseudo-code exécuté par un objet pendant le déroulement d’une
opération.

188
 Messages
• Les messages traduisent les interactions (échange
d’informations) entre objets.
• Ils sont représentés par des flèches orientées de l’émetteur au
récepteur.
• Plusieurs types :
– Message simple,
– Message minuté (Timeout),
– Message récursif,
– Message synchrone,
– Message asynchrone,
– Etc.

189
 Message simple

• Message pour lequel on ne spécifie aucune information

d’envoi ou de réception.

DiagremmeSequences

:Objet 1 :Objet 2
Message 1()

190
 Message minuté
• Message minuté bloque l’expéditeur pendant un temps donné,
en attendant la prise en compte du message par le récepteur.
• Après le délai, l’expéditeur est libéré et peut envoyer un autre
message.
DiagremmeSequences

: Objet 1 : Objet 2

Message( 1 minute)

191
 Message minuté : Exemple
• La carte est t’éjecter, si la carte n’est pas récupérée dans 10
seconde, le GAB va déclencher un message d’avaler la carte.

DiagremmeSequences

:Client :GAB
Ejecter Carte( 10 seconde)

AvalerCarte()

192
 Message récursif
• Appelé aussi message réflexive.
• Message envoyé d’un objet vers lui-même.

DiagremmeSequences

:objet1

Message1()

193
 Message récursif : Exemple
• Lorsque le client introduit sa carte de guichet, ce dernier
vérifie la validité de la carte avant de demander le code
d’accès.
DiagremmeSequences

:Client :GAB
IntroduirCarte()

VerificationValidité()

DemandeCode()

194
Message synchrone (appel de procédure)

• Message synchrone bloque l’expéditeur jusqu’à la prise en

compte du message par le récepteur.
• Le contrôle est passé de l’émetteur au récepteur qui devient à
son tour émetteur (actif).
• Si un objet A invoque une opération d'un objet B, A reste
bloqué tant que B n'a pas terminé.
• Dans ce cas l’émetteur reste en attente de la réponse à son
message avant de poursuivre ses actions.
• La flèche avec extrémité pleine symbolise ce type de message.

195
 Message synchrone (appel de procédure) :
Exemple
• Communication client serveur : Sockets

CommServeur ConsulterSolde

:client :Serveur :client :GAB :SAB

Sollitation() ConsulterSolde()

demandeSolde()
Acceptation()

Requête() getSolde()

Réponse() AfficheSolde()

196
 Message asynchrone

• L’expéditeur peut émettre sans attendre la réponse du

récepteur.
• Dans ce cas, l’émetteur n’attend pas la réponse à son message,
il poursuit l’exécution de ses opérations.
• C’est une flèche avec une extrémité non pleine qui symbolise
ce type de message.

197
 Message asynchrone

• Présentation
DiagremmeSequences DiagremmeSequences

:objet1 :objet2 :Client :Commande

Message1() ajouterArticle(codeArtl)

198
 Création et destruction d’objets
Un message peut créer ou détruire un objet.

Objet_1 Objet_3

Message_1
Objet_2

Création d’objet
Message_2

Objet créé au cours de l’exécution du scénario Destruction d’objet

Objet détruit dans un scénario

199
•
Exercice
Elaborer un diagramme de séquence convenable à ce scénario nominal
• Scénario nominal :
1. Le porteur de CB Visa introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte Visa.
3. Le GAB demande au porteur de CB Visa de saisir son code d’identification.
4. Le porteur de CB Visa saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui codé sur la puce de la carte.
6. Le GAB demande une autorisation au système d'autorisation VISA.
7. Le système d'autorisation VISA donne son accord et indique le solde hebdomadaire.
8. Le GAB demande au porteur de CB Visa de saisir le montant désiré du retrait.
9. Le porteur de CB Visa saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire.
11. Le GAB demande au porteur de CB Visa s'il veut un ticket.
12. Le porteur de CB Visa demande un ticket.
13. Le GAB rend sa carte au porteur de CB Visa.
14. Le porteur de CB Visa reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le porteur de CB Visa prend les billets et le ticket.

200
 Fragments
• Permet de décomposer une interaction complexe en fragments
simples.
• Représenté par un rectangle dont le coin supérieur gauche
contient un pentagone.
• Dans le pentagone figure le type du fragment.
– loop : boucle
– alt : alternative
– ref : référence
– …

201
 Fragments
• Opérateur alt :
– correspond à une instruction de test avec une ou plusieurs alternatives
possibles. Il est aussi permis d’utiliser les clauses de type sinon.
emprunterLivre

:Adhérent :Emrunt
:Gestionnaire
saisirAdherent()
controlerEtat()

Alt EtatEmpunt
[etat emprunt= rendu]
autoriserEmprunt()

[etat emprunt= non rendu]

refuserEmprunt()
202
 Fragments
• Opérateur opt (optional):
– On peut optionnellement mettre l’ouvrage trouvé dans le panier.

DiagremmeSequences_1

:System
:internaute
chercherOuvrage()
OuvrageTrouvé()

opt

miseDansPanier()

203
 Fragments
• Opérateur loop:
– Permet d’exécuter une séquence d’interaction tant qu’une condition
(min, max) est satisfaite.

DiagremmeSequences_1

:Caissier :SE

Loop tant que il y un article

enregistrerArt(code, qts)

mentantPartiel

204
 Fragments
• Opérateur par:
– permet de représenter deux séries d’interactions qui se déroulent en
parallèle.
DiagremmeSequences_1

:Internaute :SrveurInternet

par
consulterSite([Link])

consulterSite([Link]
services/[Link])

conculterAbsence()

205
 Fragments
• Opérateur break:
– Permet de représenter une situation exceptionnelle correspondant à un
scénario de rupture par rapport au scénario général.
– Le scénario de rupture s’exécute si la condition de garde est satisfaite.
DiagremmeSequences_1

:GAB
:Client
demanderCode()

break
AppuyerAide()
afficherAide()

206
 Fragments
• Opérateur ref:
– Permet d’appeler une séquence d’interactions décrite par ailleurs
constituant ainsi une sorte de sous-diagramme de séquence.

Sd Retirer de l’argent (nominal)

:GAB
:Client B : SAB
ref
S’authentifier

demanderAutorisation(numCa
rte)
{< 2s}
demandeMontantRetrai() Autorisation(solde)c

….
207
 Fragments
• Opérateur ref:

Sd S’authentifier

:GAB
:Client B
introdureCarte()
verifierCarte()

demandeCode()

saisieCode(code)
verifierCode()

codeOk()

208
 Fragments
• Opérateurs strict et weak sequencing
– L’opérateur strict est utilisé quand l’ordre d’exécution des opérations
doit être strictement respecté.
– L’opérateur weak est utilisé quand l’ordre d’exécution des opérations
n’a pas d’importance.
• Opérateurs ignore et consider:
– Sont utilisés pour des fragments d’interactions dans lesquels on veut
montrer que certains messages peuvent être:
• Soit absents sans avoir d’incidence sur le déroulement des interactions
(ignore),
• Soit obligatoirement présents (consider).

209
 Fragments
• Opérateur assert:
– permet d’indiquer qu’une séquence d’interactions est l’unique séquence
possible en considérant les messages échangés dans le fragment.
– Toute autre configuration de message est invalide.
• Opérateur neg (negative):
– Permet d’indiquer qu’une séquence d’interactions est invalide.
• Opérateur critical:
– Permet d’indiquer qu’une séquence d’interactions ne peut être
interrompue compte tenu du caractère critique des opérations traitées.
– On considère que le traitement des interactions comprises dans la
séquence critique est atomique.

210
Conclusion

211