Support de cours Modélisation Objet (UML)msj-learning.com/pdf/uml.pdf · 1990 et 1995 tels que...

Ministère de l’Enseignement Supérieur,

et de la Recherche Scientifique

Direction Générale des Etudes Technologiques

Institut Supérieur des Etudes Technologiques de Djerba

Support de cours

Modélisation Objet (UML)

Elaboré par :

Maèl SALAH JRAD

Public cible : Classe de 2ème année

Licence Appliquée : Technologies de l’Informatique

Option : Multimédia et Développement Web

Année Universitaire : 2016-2017

Support de cours Modélisation Objet : Fiche Matière

Fiche Matière

Unité d'enseignement

- Système d'information 1

Pré-requis

- UE : Programmation structurée

- UE : Programmation et structures dynamiques

Public cible

- Etudiants des classes de 2ème année : L2-TI

- Licence : Technologies de l’Informatique (MDW)

Volume horaire

- -1h 30 de cours intégré (cours + TD)

- Soit en total 22,5h

Moyens pédagogiques

- Tableau

- Micro-ordinateurs

- Vidéo projecteur

- Polycopiés des Travaux Dirigés

Evaluation

- Coefficient :2

- Crédits :2

- Note de devoir de contrôle (mi semestre) : 32%

- Note de devoir de synthèse (fin de semestre) : 48%

- Note personnalisée (compte rendus, mini projet) : 20%

Résumé du cours

Le cours de modélisation objets est destiné aux étudiants de deuxième

année du tronc commun de l’option Technologies de l’Informatique.


Ce cours définit et décrit le langage de modélisation «UML » comme étant

un outil d’analyse et de modélisation réussite dans le monde génie logiciel

pour les approches objets.

Il introduit d’une façon simple, les principes de base ainsi que les

principaux éléments de notation UML nécessaires pour élaborer les

diagrammes UML(diagramme d’objets, diagrammes de classes et packages,

diagramme de séquence, diagramme de collaboration, diagramme d’états,

diagrammes de use-case, diagrammes d’activités, diagrammes de

composants et diagrammes de déploiement).

Pour pouvoir à la fin de ce module introduire l'implantation des modèles

UML.

Objectifs généraux

- Ce cours vise à permettre l'apprenant d’acquérir une vision globale

du développement par objet ;

- Lire et comprendre les modèles d’un système d’information développé

dans les notations et les méthodologies OO comme UP dans le but de

passer d'une solution conceptuelle à une réalisation.

Pré-requis

- Néant

Evaluation

- Interrogation Orale ;

- Interrogation Orale;

- Un devoir surveillé d’une heure;

- Examen Final écrit de 1h30 sur tout le programme .

Moyens Pédagogiques

- Exposé informel ;

- Support du cours ;

- Travaux dirigés.

M


Méthodologie

- Le cours s’articule autour de 2 types d’activités, les cours intégrés et

les séances de travaux dirigés ;

- Les séries d’exercices sont distribués aux étudiants et corrigées.

Support de cours Modélisation Objet

Table des matières

Chapitre 1: Introduction au langage de modélisation UML ..................................... 2

1. Historique d’UML ......................................................................................................... 2

2. Caractéristiques d'UML ............................................................................................... 3 3. Les diagrammes d’UML ............................................................................................... 6

Chapitre 2 : Diagramme de cas d'utilisation .............................................................. 9

1. Introduction ................................................................................................................... 9 2. Définition ....................................................................................................................... 9

3. Eléments des diagrammes de cas d’utilisation .......................................................... 9 3.1. Acteur ............................................................................................................................... 9 3.2. Cas d’utilisation ........................................................................................................... 10 3.3. Représentation d’un diagramme de cas d’utilisation .......................................... 12 3.4. Relations dans les diagrammes de cas d’utilisation ............................................ 12

3.5. Notions générales du langage UML ........................................................................ 17 3.6. Description textuelle des cas d’utilisation ............................................................. 19 3.7. Elaboration des cas d’utilisation .............................................................................. 20

4. Etude de cas : Guichet Automatique de Banque ...................................................... 21

4.1. Etape 1 - Identification des acteurs du GAB ......................................................... 22 4.2. Etape 2 - Identification des cas d'utilisation ......................................................... 23

4.3. Etape 3 - Réalisation de diagramme de cas d'utilisation ................................... 24

4.4. Etape 4 - Description textuelle des cas d'utilisation ........................................... 24

4.5. Etape 5 - Organisation des cas d'utilisation .......................................................... 26

Chapitre 3 : Diagramme de classes /Diagramme d'objets ....................................... 29

1. Introduction ................................................................................................................. 29

2. Diagramme de classes ................................................................................................ 29 2.1. Eléments de modélisation.......................................................................................... 29

3. Diagramme d'objets .................................................................................................... 42

1. Introduction ................................................................................................................. 46 2. Définition ..................................................................................................................... 46

3. Notation ....................................................................................................................... 46 4. Le diagramme de séquences ...................................................................................... 47

4.1. Scénario ......................................................................................................................... 47

4.2. Diagramme de séquence ............................................................................................ 47

4.3. Eléments graphiques .................................................................................................. 47 5. Le diagramme de communication ............................................................................. 51

5.1. Définition....................................................................................................................... 51 5.2. Eléments de modélisation.......................................................................................... 51

Chapitre 5: Diagramme d' Etats-transitions ............................................................ 55

1. Introduction ................................................................................................................. 55

2. Définition ..................................................................................................................... 55 3. Eléments de modélisation .......................................................................................... 56

3.1. Etat ................................................................................................................................. 56 3.2. Transition ...................................................................................................................... 57

Chapitre 6: Diagramme de Paquetages ................................................................... 59


1. Introduction ................................................................................................................. 59

2. Définition et contenu .................................................................................................. 59 3. Dépendance entre paquetages ................................................................................... 60

4. Accéder et importer .................................................................................................... 61

Bibliographie ............................................................................................................... 64


Liste des figures

Figure 1: Evolution d'UML .................................................................................................. 3

Figure 2: La vue « 4+1 » de ph. Kruchten ......................................................................... 5

Figure 3: Les diagrammes en UML ................................................................................... 7

Figure 4: Représentation graphiques possibles d’un acteur ...................................... 10

Figure 5: Représentation d’un cas d’utilisation ............................................................ 12

Figure 6: Diagramme de cas d’utilisation ...................................................................... 12

Figure 7: Exemple d’une association ............................................................................... 13

Figure 8: Exemple de relation de communication ........................................................ 13

Figure 9: Exemple de relation d’inclusion ...................................................................... 14

Figure 10: La relation d’extension .................................................................................. 15

Figure 11: Exemple de relation d’extension entre les cas d’utilisation ................... 15

Figure 12: Relation de généralisation/spécialisation ................................................... 16

Figure 13: Exemple de relation de généralisation ........................................................ 16

Figure 14: Généralisation entre acteurs ......................................................................... 17

Figure 15: Exemple de généralisation entre acteurs ................................................... 17

Figure 16: Exemple de note ............................................................................................... 18

Figure 17: Diagramme de cas d’utilisation version simple ........................................ 24

Figure 18: Diagramme de cas d'utilisation complet. .................................................... 27

Figure 19: Représentation d'une classe .......................................................................... 30

Figure 20: Exemple d'une classe....................................................................................... 32

Figure 21: Exemple d’une association avec deux rôles ................................................ 33

Figure 22: Exemple de multiplicité d’association ......................................................... 33

Figure 23: Exemple de multiplicité d’association ......................................................... 34

Figure 24: Exemple de classe d’association.................................................................... 34

Figure 25: Exemple d’une association de dimension 3 ................................................ 35

Figure 26: Représentation et Exemple de la relation réflexive ................................. 35

Figure 27: Exemple de notation de rôle .......................................................................... 36

Figure 28: Exemple d’agrégation et de composition..................................................... 36

Figure 29: Exemple de super- classe et sous- classes .................................................. 37

Figure 30:Exemple de la contrainte sous ensemble ..................................................... 38

Figure 31:Exemple de la contrainte d'exclusion sur les associations ...................... 38

Figure 32:Exemple de la relation d'exclusion sur la généralisation ....................... 39

Figure 33: Exemple de la contrainte de totalité ............................................................ 39

Figure 34: Exemples d’objets ............................................................................................. 43

Figure 35:Exemple de lien entre les objets .................................................................... 43

Figure 36:Exemples de diagramme d’objets .................................................................. 44

Figure 37: Diagramme de séquence Illustration .......................................................... 47

Figure 38: Exemple simplifié............................................................................................. 48

Figure 39: Représentation de la ligne de vie ................................................................ 49

Figure 40: Représentation de la période d’activité ....................................................... 49

Figure 41:Représentation du flot de contrôle ................................................................ 50


Figure 42:Représentation de message asynchrone ...................................................... 50

Figure 43: Représentation des messages réflexif ......................................................... 51

Figure 44: Exemple d'interaction entre objet" produits "et objet "commande " ..... 52

Figure 45:Représentation des interactions entre des objets ...................................... 52

Figure 46: Représentation des états ................................................................................ 56

Figure 47: Représentation d'un état initial et d'un état final .................................... 56

Figure 48:Un diagramme d’état simple .......................................................................... 57

Figure 49: Un diagramme d’état simple ......................................................................... 57

Figure 50: Diagramme d’états simple du Commande ................................................. 57

Figure 51: Exemple de paquetage .................................................................................... 59

Figure 52: Un paquetage contenant deux classes ........................................................ 60

Figure 53: Deux classes préfixées du nom de leur paquetage ................................... 60

Figure 54: Dépendance entre deux paquetages ............................................................ 61

Figure 55: Une relation d'importation ............................................................................ 61

Figure 56: Relations successives "import" et "access" ................................................. 62

1

Chapitre 1 Introduction aux langages de modélisation

UML

Objectifs Spécifiques

A la fin de ce chapitre, l’étudiant doit être capable de :

- Expliquer l’origine et l’histoire du langage UML;

- Décrire le langage UML;

- Enumérer les principaux diagrammes d’UML.

Plan du chapitre

- Historique d’UML

- Caractéristiques d’UML

- Les diagrammes d’UML

Volume horaire

- 3 heures

Modélisation Objet Introduction au langage de modélisation UML

2

Chapitre 1: Introduction au langage de modélisation UML

1. Historique d’UML

Avec l'arrivé des approches objet ,plus de cinquante méthodes apparaissaient entre

1990 et 1995 tels que (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM,

OOSE, etc.).Ces méthodes étaient très concurrentes mais aucune ne parvient à

s’imposer sur le marché mondial. Il faut attendre l'initiative des trois "amigo"

concrétisée par l'apport de chaque méthode relative à chacun de ces auteurs et la

possibilité d'intégrer les concepts de chacune dans un seul processus de conception et

développement mettant fin à la dite "Guerre des méthodes". Ci-dessous, on résume les

points forts de chaque méthode origine du futur processus:

OMT de James Rumbaugh (General Electric) fournit une représentation

graphique des aspects statique, dynamique et fonctionnel d’un système ;

OOD de GradyBooch, définie pour le Department of Defense, introduit le

concept des paquetage (package) ;

OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des

besoins des utilisateurs (cas d’utilisation, ou use cases).

C'est par les efforts de convergence de ces auteurs, qu'ils sont devenus alors convaincus

de la possibilité de définir des méthodes et/ou processus de développement unifiés et se

basent tous sur un langage unifié pour les différentes phases d'analyse et de conception

d'un système tout en mettant en exergue la vision de l'utilisateur.

Ces esprits de convergence ont imposé de nature la nécessité de définir d'abord un

langage /notation Unifié puis se concentrer sur les aspects

Événement considérable, les trois fondateurs des trois méthodes se mirent d’accord

pour définir une méthode commune qui fédérerait leurs apports respectifs (on les

surnomme depuis « the Amigos »). UML (Unified Modeling Language) est né de cet

effort de convergence.

L’unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres)

se sont mis d’accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996,

Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot méthode


3

par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du

logiciel s’associent alors à l’effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys

etc.) et UML 1.0 est soumis à l’OMG. L’OMG adopte en novembre 1997 UML 1.1

comme langage de modélisation des systèmes d’information à objets. La version d’UML

en cours en 2008 est UML 2.1.1 et les travaux d’amélioration se poursuivent.

UML est dépasse le titrage d’un outil intéressant pour être décrite sous le titre norme

qui s’impose à la majorité des technologies, méthodes et framework de développement

avec l’approche objet.

A la date d’écriture de ce support, la dernière version normalisé UML est 2.5 et date de

Juin 2015[http://www.uml-diagrams.org/]

Figure 1: Evolution d'UML

2. Caractéristiques d'UML

UML (Unified Modeling Language) est un langage basé surtout sur des symboles

graphiques s’appuyant sur un méta modèle unique qui permet de décrire et de

concevoir des systèmes logiciels, orientés objet en particulier.

UML s’adresse à toutes les personnes jouant un rôle dans le cycle de vie d’un logiciel

(analystes, développeurs, chefs de projets, architectes…), mais peut également servir à

la communication le client et l’équipe responsable sur développement du logiciel. Il

permet de construire plusieurs modèles d’un système, chacun mettant en valeur des


4

aspects différents : fonctionnels, statiques, dynamiques et organisationnels. UML

devenu un langage de modélisation incontournable dans les projets de développement.

UML n’est pas une méthode (i.e. une description normative des étapes de la

modélisation) : ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une

méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir

un langage graphique qui permet de représenter, de communiquer les divers aspects

d’un système d’information (aux graphiques sont bien sûr associés des textes qui

expliquent leur contenu). UML est un langage de modélisation objet et propose donc

une notation et une sémantique associée à cette notation (des modèles), ne propose pas

de processus (démarche proposant un enchaînement d’étapes et d’activités qui mènent

à la résolution d’un problème posé). UML reprend en particulier les notions de :

Partitions en sous-systèmes;

De classes et d’associations;

D’expression des besoins par les interactions entre les utilisateurs et le système.

UML permet de suivre une approche entièrement objet et non fonctionnelle, couvrant

tout le cycle de développement : analyse, conception et réalisation, le système est

décomposé en objets collaborant. UML est conçu pour modéliser divers types de

systèmes, de taille quelconque et pour tous les domaines d’application (gestion,

scientifique, temps réel, système embarqué). UML permet de diviser le système

d’information d’une organisation en :

Système métier : modélise les aspects statiques et dynamiques de l’activité selon

une vision externe et une vision interne (en ignorant l’implémentation

technique),

Système informatique : recouvre la partie automatisée du système métier

concrétisant les choix effectués parmi les différentes technologies d’actualité.

Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs

d'UML préconisent d'utiliser une démarche :

Itérative et incrémentale : Pour modéliser (comprendre et représenter) un

système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son

analyse par étapes.

Guidée par les besoins des utilisateurs du système : Avec UML, ce sont les

utilisateurs qui guident la définition des modèles. Le périmètre du système à


5

modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent

ce que doit être le système). Le but du système à modéliser est de répondre aux

besoins de ses utilisateurs (les utilisateurs sont les clients du système).

Centrée sur l'architecture logicielle : Une architecture adaptée est la clé de

succès d'un développement. Elle décrit des choix stratégiques qui déterminent

en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...).

UML offre différentes vues (perspectives) complémentaires d'un système, qui guident

l'utilisation des concepts objets. La relation entre les différentes perspectives a été

représentée par ph. Kruchten dans le schéma suivant, dit « schéma 4+1 vues ».

Figure 2: La vue « 4+1 » de ph. Kruchten

Vue logique: Cette vue de haut niveau se concentre sur l'abstraction et

l'encapsulation, elle modélise les éléments et mécanismes principaux du système.

Elle identifie les éléments du domaine, ainsi que les relations et interactions

entre ces éléments (notions de classes et de relations entre elles) :

Les éléments du domaine sont liés au(x) métier(s) de l'entreprise,

Ils sont indispensables à la mission du système,

Ils gagnent à être réutilisés.

Vue des composants: Elle exprime la perspective physique de l’organisation du

code en termes de modules, de composants et surtout des concepts du langage ou

de l’environnement d’implémentation. Dans cette perspective, l’architecte est

surtout concerné par les aspects de gestion du code, d’ordre de compilation, de

réutilisation, d’intégration et d’autres contraintes de développement pur. Pour


6

représenter cette perspective, UML fournit des concepts adaptés tels que les

modules, les composants, les relations de dépendance, l’interface.

Vue de processus: Cette vue est très importante dans les environnements

multitâches ; elle exprime la perspective sur les activités concurrentes et

parallèles. Elle montre ainsi : la décomposition du système en terme de

processus (tâches). les interactions entre les processus (leur communication). la

synchronisation et la communication des activités parallèles (threads).

Vue de déploiement: Cette vue exprime la répartition du système à travers un

réseau de calculateurs et de nœuds logiques de traitements. Cette vue est

particulièrement utile pour décrire la distribution d’un système réparti. Elle

montre : la disposition et nature physique des matériels, ainsi que leurs

performances. l'implantation des modules principaux sur les nœuds du

réseau.les exigences en termes de performances (temps de réponse, tolérance aux

fautes et pannes...).

Vue des cas d’utilisation: Cette vue permet d’expliquer le système, de justifier les

choix qui ont guidé sa conception et son fonctionnement pour pouvoir le

construire, le maintenir et le tester. Pour cela UML offre des concepts adaptés

tels que les scénarios et les cas d’utilisation qui vont permettre de guider la

modélisation du système.

3. Les diagrammes d’UML

Comme nous avons déjà indiqués UML permet de représenter un système selon

différentes vues complémentaires à travers l’utilisation des diagrammes.

Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect

précis du modèle. Chaque type de diagramme UML possède une structure (les types

des éléments de modélisation qui le composent sont prédéfinis) et véhicule une

sémantique précise (il offre toujours la même vue d'un système).

Une caractéristique importante des diagrammes UML, est qu'ils supportent

l'abstraction. Cela permet de mieux contrôler la complexité dans l'expression et

l'élaboration des solutions objet.

Combinés, les différents types de diagrammes UML offrent une vue complète des

aspects fonctionnels, statiques et dynamiques d'un système.


7

Figure 3: Les diagrammes en UML

Diagrammes de cas d’utilisation: Représente les fonctions du système du point de

vue de l’utilisateur

Diagrammes de Classes: Représente la structure statique en terme de classes et

de relations.

Diagrammes d’Objets: Représente les objets et leurs relations.

Diagrammes d'Etats-Transitions: Représente le comportement d’une classe en

terme d’états.

Diagrammes d'Activités: Représente le comportement d’une opération en terme

d’actions.

Diagrammes de Séquence: Représentation temporelle des objets et de leurs

interactions.

Diagrammes de Communication(Collaboration): Représentation spatiale des

objets, des liens et des interactions.

Diagrammes de Composants: Représente les composants physiques d’une

application.

Diagramme de Déploiement: Représente le déploiement des composants sur le

dispositif matériel.

8

Chapitre 2 Diagramme de cas d'utilisation


A la fin de ce chapitre, l’étudiant doit être capable de :

- Analyser un cahier de charge et le traduire en un diagramme de cas

d’utilisation.

- Dégager les principaux cas d’utilisation.

- Joindre une description textuelle reflétant les interactions (acteur-

système) pour un cas d’utilisation

- Distinguer entre acteur et utilisateur

- Raffiner un diagramme de cas d’utilisation

Plan du chapitre

- Introduction

- Définition

- Eléments des diagrammes de cas d’utilisation

- Etude de cas : Guichet automatique de banque

Volume horaire

- 3 heures

Modélisation Objet Diagramme des cas d'utilisation

9

Chapitre 2 : Diagramme de cas d'utilisation

1. Introduction

UML permet de construire plusieurs modèle d’un système : certains montrent le

système du point de vue des utilisateurs, d’autres montrent sa structure interne,

d’autre encore donnent une vision globale ou détaillée. Les modèles se complètent et

peuvent être assemblés. Ils sont élaborés tout au long du cycle de vie du développement

d’un système (depuis le recueil des besoins jusqu’à la phase de conception).

Dans ce chapitre, nous allons étudier un des modèles, en l’occurrence le premier à

construire : le diagramme de cas d’utilisation. Il permet de recueillir, d’analyser et

d’organiser les besoins. Avec lui débute l’étape de l’analyse d’un système.

Les diagrammes de cas d’utilisation montrent quels acteurs interagissent avec chaque

cas d’utilisation.

2. Définition

Un diagramme de cas d’utilisation capture le comportement d’un système, d’un

sous-système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il

scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un

sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des

utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin au

contraire d’une vision informatique. Il ne faut pas négliger cette première étape pour

produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas

d’utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

3. Eléments des diagrammes de cas d’utilisation

3.1. Acteur

Un acteur est l’idéalisation d’un rôle joué par une entité externe (utilisateur humain,

dispositif matériel ou autre système) qui interagit directement avec le système étudié..

Un acteur peut consulter et/ou modifier directement l’état du système, en émettant

et/ou en recevant des messages susceptibles d’être porteurs de données.


10

Comment les identifier ?

Dans UML, il n’y a pas de notion d’acteur interne et externe. Par définition, un

acteur est externe au périmètre de l’étude, qu’il appartienne ou pas à la société.

Enfin, un acteur n’est pas nécessairement une personne physique : il peut être un

service, une société, un système informatique, etc.

Il existe 4 catégories d’acteurs :

Les acteurs principaux : les personnes qui utilisent les fonctions

principales du système

Les acteurs secondaires : Les personnes qui effectuent des tâches

administratives ou de maintenance.

Matériel externe : Les dispositifs matériels incontournables qui font

partie du domaine de l’application et qui doivent être utilisés.

Autres systèmes : Les systèmes avec lesquels le système doit

interagir.

Comment les représenter ?

Les acteurs se représentent sous la forme de petits personnages ou via un symbole

de classe avec le mot clé<<actor>>.

Figure 4: Représentation graphiques possibles d’un acteur

Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme

graphique du stick man pour les acteurs humains et une représentation

rectangulaire pour les systèmes connectés.

3.2. Cas d’utilisation

Un cas d’utilisation est une unité cohérente d’une fonctionnalité visible de

l’extérieur. Il réalise un service de bout en bout, avec un déclenchement, un


11

déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation modélise

donc un service rendu par le système, sans imposer le mode de réalisation de ce

service.

Comment les identifier ?

L’objectif est le suivant : l’ensemble des cas d’utilisation doit décrire

exhaustivement les exigences fonctionnelles du système.

Chaque cas d’utilisation correspond donc à une fonction métier du système, selon

le point de vue d’un de ses acteurs. Pour chaque acteur, il convient de :

Rechercher les différentes intentions métier avec lesquelles il utilise le

système,

Déterminer dans le cahier des charges les services fonctionnels attendus du

système.

Nommez les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du

point de vue de l’acteur (et nom pas du point de vue du système). (à partir d'UML

2.0: Le choix des mots et des verbes est défini )

Comment les analyser ?

Pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente

consiste à recenser de façon textuelle toutes les interactions entre les acteurs et

le système. Le cas d’utilisation doit avoir un début et une fin clairement

identifiés. Il faut également préciser les variantes possibles, telles que le cas

nominal, les différents cas alternatifs et d’erreur, tout en essayant d’ordonner

séquentiellement les descriptions, afin d’améliorer leur lisibilité.

Le sens doit représenter une interaction entre l'acteur etle système (exemple: le

cas d'utilisation "Acheter un livre ")autrement dit cette expression représente un

but de l'acteur (rôle) et non pas l'utilisateur .

Comment les représenter ?

Un cas d’utilisation se représente par une ellipse contenant le nom du cas (un

verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.


12

Figure 5: Représentation d’un cas d’utilisation

Un cas d'utilisation factorise un ensemble de scénarios possibles pour un but

à atteindre par l'acteur .

3.3. Représentation d’un diagramme de cas d’utilisation

La frontière du système est représentée par un cadre. Le nom du système figure

à l’intérieur du cadre, en haut. Les acteurs sont à l’extérieur et les cas d’utilisation

à l’intérieur.

Figure 6: Diagramme de cas d’utilisation

3.4. Relations dans les diagrammes de cas d’utilisation

3.4.1. Relations entre acteurs et cas d’utilisation

Relation d’association

Une relation d’association est un chemin de communication entre un acteur

et un cas d’utilisation et il est représenté par un trait continu.les associations

sont utilisées pour lier des acteurs avec des cas d’utilisation. Elles indiquent

qu’un acteur déclenche uncas d’utilisation (exécution d'un scénario) . Les

associations sont représentées par une ligne reliant l’acteur et le cas

d’utilisation.


13

Figure 7: Exemple d’une association

Relation de communication

La participation de l’acteur est signalée par une flèche entre l’acteur et le cas

d’utilisation. Le sens de la flèche indique l’initiateur de l’interaction.

Figure 8: Exemple de relation de communication

Multiplicité

Lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est

possible d’ajouter une multiplicité sur l’association du côté du cas d’utilisation.

Le symbole * signifie plusieurs, exactement n s’écrit tout simplement n, n..m

signifie entre n et m, etc. Préciser une multiplicité sur une relation n’implique

pas nécessairement que les cas sont utilisés en même temps. La notion de

multiplicité n’est pas propre au diagramme de cas d’utilisation. Nous en

reparlerons dans le chapitre consacré au diagramme de classes.

3.4.2. Relations entre cas d’utilisation

Il existe 3 types de relations entre cas d’utilisation:

la relation de généralisation;

la relation d’extension;

la relation d’inclusion.


14

Relation d’inclusion

Un cas d’utilisation B est inclus dans un cas A si le comportement décrit par le

cas B est inclus dans le comportement du cas A : on dit alors que le cas A

dépend de B. Cette dépendance est symbolisée par le stéréotype « include ».

Les inclusions permettent essentiellement de factoriser une partie de la

description d’un cas d’utilisation qui serait commune à d’autres cas

d’utilisation. Les inclusions permettent également de décomposer un cas

complexe en sous-cas plus simples. Cependant, il ne faut surtout pas abuser de

ce type de décomposition : il faut éviter de réaliser du découpage fonctionnel

d’un cas d’utilisation en plusieurs sous-cas d’utilisation pour ne pas retomber

dans le travers de la décomposition fonctionnelle.

Figure 9: Exemple de relation d’inclusion

La relation d’extension

On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas

d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B.

Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à

l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le

stéréotype « extend». L’extension peut intervenir à un point précis du cas

étendu. Ce point s’appelle le point d’extension. Il porte un nom, qui figure dans

un compartiment du cas étendu sous la rubrique point d’extension, et est

éventuellement associé à une contrainte indiquant le moment où l’extension

intervient. Une extension est souvent soumise à condition. Graphiquement, la

condition est exprimée sous la forme d’une note.

Les cas d’utilisation ne s’enchaînent pas, car il n’y a

aucune représentation temporelle dans un

diagramme de cas d’utilisation.


15

Figure 10: La relation d’extension

Exemple : La figure 11 présente l’exemple d’une banque où la vérification du

solde du compte n’intervient que si la demande de retrait d’argent dépasse 10

dinars.

Figure 11: Exemple de relation d’extension entre les cas d’utilisation

Relation de généralisation

Un cas A est une généralisation d’un cas B si B est un cas particulier de A.

Cette relation de généralisation/spécialisation est présente dans la plupart des

diagrammes UML et se traduit par le concept d’héritage dans les langages

orientés objet.


16

Figure 12: Relation de généralisation/spécialisation

entre les cas d’utilisation

Exemple : A la figure 13 la consultation d’un compte bancaire via Internet est

un cas particulier de la consultation.

Figure 13: Exemple de relation de généralisation

3.4.3. Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A

est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B.

Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais

l’inverse n’est pas vrai. Le symbole utilisé pour la généralisation entre acteurs est

une flèche avec un trait plein dont la pointe est un triangle fermé désignant l’acteur

le plus général (comme nous l’avons déjà vu pour la relation de généralisation entre

cas d’utilisation).


17

Figure 14: Généralisation entre acteurs

Exemple :

Figure 15: Exemple de généralisation entre acteurs

3.5. Notions générales du langage UML

Les éléments du langage UML que nous abordons ici ne sont pas spécifiques au

diagramme de cas d’utilisation mais sont généraux. Nous avons déjà utilisé certains

de ces éléments dans ce chapitre et nous utiliserons les autres dans les chapitres qui

suivent, notamment dans le chapitre sur les diagrammes de classes.


18

3.5.1. Note

Une note contient une information textuelle comme un commentaire, un corps

de méthode ou une contrainte. Graphiquement, elle est représentée par un

rectangle dont l’angle supérieur droit est plié. Le texte contenu dans le rectangle

n’est pas contraint par UML. Une note n’indique pas explicitement le type

d’élément qu’elle contient, toute l’intelligibilité d’une note doit être contenu dans

le texte même. On peut relier une note à l’élément qu’elle décrit grâce à une ligne

en pointillés. Si elle décrit plusieurs éléments, on dessine une ligne vers chacun

d’entre eux.

Figure 16: Exemple de note

3.5.2. Stéréotype

Un stéréotype est une annotation s’appliquant sur un élément de modèle. Il n’a pas

de définition formelle, mais permet de mieux caractériser des variétés d’un même

concept. Il permet donc d’adapter le langage à des situations particulières. Il est

représenté par une chaînes de caractères entre guillemets (« ») dans, ou à proximité

du symbole de l’élément de modèle de base.

3.5.3. Classeur

Un classeur est un élément de modèle qui décrit une unité comportementale ou

structurelle. Un classeur modélise un concept discret qui décrit un élément (i.e.

objet) doté d’une identité (i.e.un nom), d’un état (i.e. des attributs), d’un

comportement (i.e. des opérations), de relations et d’une structure interne

facultative. Il peut participer à des relations d’association, de généralisation, de


19

dépendance et de contrainte. On le déclare dans un espace de noms, comme un

paquetage ou une autre classe. Un classeur se représente par un rectangle, en

traits pleins, contenant éventuellement des compartiments. Les acteurs et les cas

d’utilisation sont des classeurs. Tout au long de ce cours, nous retrouverons le

terme de classeur car cette notion englobe aussi les classes, des parties d’un

système, etc.

3.5.4. Paquetage

Un paquetage est un regroupement d’éléments de modèle et de diagrammes. Il

permet ainsi d’organiser des éléments de modélisation en groupes. Il peut contenir

tout type d’élément de modèle: des classes, des cas d’utilisation, des interfaces, des

diagrammes, . . .et même des paquetages imbriqués. Les éléments contenus dans un

paquetage doivent représenter un ensemble fortement cohérent et sont généralement

de même nature et de même niveau sémantique. Généralement, il existe un seul

paquetage racine qui détient la totalité du modèle d’un système.

3.5.5. Espace de noms

Les espaces de noms sont des paquetages, des classeurs, etc. On peut déterminer

un élément nommé de façon unique par son nom qualifié, qui est constitué de la série

des noms des paquetages ou des autres espaces de noms depuis la racine jusqu’à

l’élément en question. Dans un nom qualifié, chaque espace de nom est séparé par

deux doubles points ( : :).

Par exemple, si un paquetage B est inclus dans un paquetage A et contient une

classe X, il faut écrire A :: B :: X pour pouvoir utiliser la classe X en dehors du

contexte du paquetage B.

3.6. Description textuelle des cas d’utilisation

Une fois les cas d’utilisation identifiés, ceux ci ont pour objectifs de décrire les

interactions d'un coté entre acteur et système et autre coté préparer les interactions

entre éléments du système . La fiche de description textuelle d’un cas d’utilisation

n’est pas normalisée par UML.

Un cas d’utilisation est une abstraction de plusieurs chemins d’exécution. Une

instance de cas d’utilisation est appelée : « scénario ».

Les scénarios sont utiles pour :


20

analyser et concevoir le système ;

justifier les choix effectués (ils serviront à la documentation des cas d’utilisation) ;

tester : les scénarios constituent le meilleur moyen de spécifier les tests.

Une description textuelle couramment utilisée se compose de deux parties.

La première partie permet d’identifier le cas, elle doit contenir les informations qui

suivent :

Nom : Utiliser une tournure à l’infinitif (ex : retirer de l'argent ).

Objectif : Une description résumée permettant de comprendre l’intention

principale du cas d’utilisation. Cette partie est souvent renseignée au début du

projet dans la phase de découverte des cas d’utilisation.

Acteurs principaux : Ceux qui vont réaliser le cas d’utilisation (la relation avec

le cas d’utilisation est illustrée par le trait liant le cas d’utilisation et l’acteur

dans un diagramme de cas d’utilisation)

Acteurs secondaires : Ceux qui ne font que recevoir des informations à l’issue

de la réalisation du cas d’utilisation

Dates : Les dates de créations et de mise à jour de la description courante.

Responsable : Le nom des responsables.

Version : Le numéro de version.

La deuxième partie contient la description du fonctionnement du cas sous la forme

d’une séquence de messages échangés entre les acteurs et le système. elle doit

contenir les informations qui suivent :

Les pré-conditions : elles décrivent dans quel état doit être le système

(l’application) avant que ce cas d’utilisation puisse être déclenché.

Des scénarii : Ces scénarii sont décrits sous la forme d’échanges d’évènements

entre l’acteur et le système. On distingue le scénario nominal, qui se déroule

quand il n’y a pas d’erreur, des scénarii alternatifs qui sont les variantes du

scénario nominal et enfin les scénarii d’exception qui décrivent les cas

d’erreurs.

Des post-conditions : Elles décrivent l’état du système à l’issue des différents

scénarii

3.7. Elaboration des cas d’utilisation

Un cas d’utilisation doit être avant tout simple, intelligible et décrit de manière

claire et concise. Le nombre d’acteurs qui interagissent avec le cas d’utilisation est


21

souvent limité. Il y a souvent un acteur par cas d’utilisation. Lors de l’élaboration

d’un cas d’utilisation, il faut se demander :

o Quelles sont les tâches de l’acteur ?

o Quelles informations l’acteur doit-il créer, sauvegarder, modifier ou lire ?

o L’acteur devra-t-il informer le système des changements externes ?

o Le système devra-t-il informer l’acteur des conditions internes ?

o Quelles sont les conditions de démarrage et d’arrêt du cas d’utilisation ?

Les cas d’utilisation peuvent être présentés à travers de vues multiples : un acteur

avec tous ses cas d’utilisation, un cas d’utilisation avec tous ses acteurs …

Un cas d’utilisation est une abstraction : il décrit de manière abstraite une famille

de scénarios. Il ne faut donc pas réaliser trop de cas d’utilisation car cela

constituerait un manque d’abstraction. Dans n’importe quel système, il y a

relativement peu de cas d’utilisation mais beaucoup de scénarios. Un grand

nombre de cas d’utilisation signifie par conséquent que l’essence du système n’est

pas comprise.

4. Etude de cas : Guichet Automatique de Banque

Cette étude de cas concerne un système simplifié de Guichet Automatique de

Banque(GAB). Le GAB offre les services suivants :

1. Distribution d’argent à tout porteur de carte de crédit, via un lecteur de carte et

un distributeur de billets.

2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèque pour les

clients porteurs de carte de crédit de la banque adossée au GAB.

N’oubliez pas non plus que :

3. Toutes les transactions sont sécurisées.

4. Il est parfois nécessaire de recharger le distributeur, etc.

A partir de ces quatre phrases, nous allons progressivement :

Identifier les acteurs ;

identifier les cas d’utilisation ;

construire un diagramme de cas d’utilisation ;

décrire textuellement les cas d’utilisation ;

organiser et structurer les cas d’utilisation.


22

4.1. Etape 1 - Identification des acteurs du GAB

Considérons linéairement les phrases de l’énoncé.

La phrase 1 : Nous permet d’identifier immédiatement un premier acteur

évident : tous « Porteur de carte ». Il pourra uniquement utiliser le GAB pour

retirer de l’argent.

En revanche, attention : le lecteur de carte et le distributeur de billets font

partie du GAB. Ils ne peuvent donc pas être considérés comme des acteurs !

Vous pouvez notez ici que l’identification des acteurs oblige à fixer

précisément la frontière entre le système à l’étude de son environnement.

Autre piège : la carte bancaire elle- même est-elle un acteur ? La carte est

bien externe du GAB, et elle interagit avec lui… Pourtant, nous ne

recommandons pas de la répertorier en tant qu’acteur, car nous appliquons le

principe suivant : éliminer autant que possible les acteurs « physiques » au

profit des acteurs « logique ». L’acteur est celui qui bénéficie de l’utilisation

du système. C’est bien le porteur de carte qui retire de l’argent pour le

dépenser ensuite, pas la carte !

La phrase 2: Identifie des services supplémentaires qui ne sont proposés

qu’aux clients de la banque porteurs d’une carte de crédit de cette dernière. Il

s’agit donc d’un profil différent du précédent, que nous matérialisons par un

deuxième acteur, appelé Client banque !

La phrase 3: Nous incite à prendre en compte le fait que toutes les

transactions sont sécurisées. Mais sécurisées par qui ? Pas par le GAB. Il

existe donc d’autres entités externes qui jouent le rôle de système

d’autorisation et avec lesquelles le GAB communique directement. Une

interview de l’expert métier est nécessaire, pour nous permettre d’identifier

deux acteurs différents :

-le Système d’autorisation global Carte Bancaire, pour les transactions de

retrait ;

-le Système d’information de la banque, pour autoriser toutes les

transactions effectuées par un client avec sa carte de la banque, mais

également pour accéder au solde des comptes.


23

Enfin, la phrase 4: Nous rappelle qu’un GAB nécessite également des actions

de maintenance, telles que le rechargement en billets du distributeur, la

récupération des cartes avalées, etc. Ces actions de maintenance sont

effectuées par un nouvel acteur, que nous appellerons pour simplifier :

Opérateur de maintenance.

4.2. Etape 2 - Identification des cas d'utilisation

Reprenons un à un les cinq acteurs et listons les différentes façons qu’ils ont

d’utiliser le GAB :

Porteur de carte :

Retirer de l’argent.

Client banque :

Retirer de l’argent.

Consulter le solde de son compte courant.

Déposer de l’argent (numéraire ou des chèques).

Opérateur de maintenance :

Recharger le distributeur.

Maintenir l’état opérationnel (récupérer les cartes avalées, récupérer les

chèques déposés, remplacer le ruban de papier, etc.).

Système d’autorisation (Sys.Auto) :

Néant.

Système d’information (SI) banque :

Néant.

A retenir : Acteur principal ou secondaire

Contrairement à ce que l’on pourrait croire, tous les acteurs n’utilisent pas

forcément le système ! Nous appelons acteur principal celui pour qui le cas

d’utilisation produit un résultat observable. Par opposition, nous qualifiions

d’acteurs secondaires les autres participants du cas d’utilisation. Les acteurs

secondaires sont souvent sollicités pour des informations complémentaires ; ils

peuvent uniquement consulter ou informer le système lors de l’exécution du cas

d’utilisation.


24

C’est exactement le cas des deux acteurs « non humains » de notre exemple : le Sys.

Auto et le SI banque sont uniquement sollicités par le GAB dans le cadre de la

réalisation de certains cas d’utilisation. Mais ils n’ont pas eux- même de façon

propre d’utiliser le GAB, d’objectif à part entière.

4.3. Etape 3 - Réalisation de diagramme de cas d'utilisation

Figure 17: Diagramme de cas d’utilisation version simple

Remarque :

On peut considérer l’acteur Client banque comme une spécialisation de l’acteur plus

général Porteur de carte, comme nous l’avons déjà indiqué sur la figure 17 Un client

de la banque est en effet un porteur de carte particulier qui à toutes les prérogatives

de ce dernier, ainsi que d’autres qui lui sont propres en tant que client.

4.4. Etape 4 - Description textuelle des cas d'utilisation

Sommaire d'identification

Titre : Retirer de l’argent.

Résumé : ce cas d’utilisation permet à un porteur de carte, qui n’est pas client de la

banque, de retirer de l’argent, si son crédit hebdomadaire le permet.

Acteurs : Porteur de carte non client (principal), Sys.Auto. (Secondaire).

Date de création : 02/12/11 Date de mise à jour : 04/01/12


25

Version : 2.0

Description des scénarios

Pré conditions

· La caisse du GAB est alimentée (il reste au moins un billet).

· Aucune carte ne se trouve dans le lecteur.

Scénario nominal

1. Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB.

2. Le GAB vérifie que la carte introduite est bien une carte bancaire.

3. Le GAB demande au porteur de carte de saisir son code d’identification.

4. Le porteur de carte saisit son code d’identification.

5. Le GAB compare le code d’identification avec celui qui est codé sur la puce de la

carte.

6. Le GAB demande une autorisation au système d’autorisation.

7. Le système d’autorisation donne son accord et indique le solde hebdomadaire.

8. Le GAB demande au porteur de carte de saisir le montant désiré du retrait.

9. Le porteur de carte 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 carte s’il veut un ticket.

12. Le porteur de carte demande un ticket.

13. Le GAB rend sa carte au porteur de carte.

14. Le porteur de carte reprend sa carte.

15. Le GAB délivre les billets et un ticket.

16. Le porteur de carte prend les billets et le ticket.

17. Le GAB enregistre la transaction de retrait.

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 porteur de carte 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.

A2 : montant demandé supérieur au solde hebdomadaire.


26

L’enchaînement A2 démarre au point 10 du scénario nominal.

11. Le GAB indique au porteur de carte que le montant demandé est supérieur au

solde hebdomadaire.

Le scénario nominal reprend au point 8.

…

Enchaînements d'erreurs

E1 : carte non- valide.

L’enchaînement E1 démarre au point 2 du scénario nominal.

3. le GAB indique au porteur de carte que la carte n’est pas valide (illisible,

périmée, etc.); le cas d’utilisation se termine en échec.

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 porteur de carte que le code est erroné, pour la troisième

fois.

7. Le GAB confisque la carte.

8. Le système d’information est informé ; le cas d’utilisation se termine en échec.

….

Post condition

La caisse du GAB contient moins de billets qu’au début du cas d’utilisation (le

nombre de

billets manquants est fonction du montant du retrait).

Une transaction de retrait a été enregistrée par le GAB avec les informations

pertinentes

(montant, numéro de carte, date, etc.).

4.5. Etape 5 - Organisation des cas d'utilisation

On peut identifier un nouveau cas d’utilisation inclus dans les précédents, que

nous appellerons S’authentifier, et qui contient les enchaînements cités plus haut.

Cela nous permettra d’enlever des autres cas d’utilisation toutes ces description

textuelles redondantes, en se concentrant mieux sur leurs spécification

fonctionnelles.


27

Considérons le cas d’utilisation Déposer de l’argent. Il possède deux scénarios

principaux :

Déposer du numéraire et Déposer des chèques. Nous pouvons utiliser la relation de

généralisation / spécialisation. Il suffit de considérer que Déposer de l’argent est un

cas d’utilisation généralisé. Ce cas a maintenant la particularité d’être abstrait (il

apparaît alors en italiques), car il ne s’instancie pas directement, mais uniquement

par le biais de l’un de ses deux cas spécialisés.

Figure 18: Diagramme de cas d'utilisation complet.

28

Chapitre 3 Diagramme de classes /Diagramme d'objets


A la fin de ce chapitre, l'étudiant doit être capable de:

- A la fin de ce chapitre, l’étudiant doit être capable de :

- Dégager les principales classes à partir d’un cahier de charge

- Représenter une première ébauche du diagramme de classe(les

classes métier).

- Définir les associations entre les différentes classes.

- Raffiner le diagramme de classe, éventuellement, dégager les classes

d’association

- Définir les principales contraintes notamment avec le langage OCL

ou avec des notes

- Représenter le diagramme d’objet en mettant l’accent sur les objets

qui nécessitent une étude de près.

Plan du chapitre

- Introduction

- Diagramme de classes

- Diagramme d'objets

Volume horaire

- 4 heures et demi

Modélisation Objet Diagramme de classes /Diagramme d'objets

29

Chapitre 3 : Diagramme de classes /Diagramme d'objets

1. Introduction

Chaque classe se décrit par les données et les traitements dont elle est responsable

pour elle même et vis-à-vis des autres classes. Les traitements sont matérialisés par

des opérations. Le détail des traitements n’est pas représenté directement dans le

diagramme de classe ; seul l’algorithme général et le pseudo-code correspondant

peuvent être associés à la modélisation. La description du diagramme de classe est

fondée sur :

le concept d’objet;

le concept de classe comprenant les attributs et les opérations;

les différents types d’association entre classes.

2. Diagramme de classes

Le diagramme de classes exprime la structure statique du système en termes de classes et

de relations entre ces classes. L’intérêt du diagramme de classe est de modéliser les entités du

système d’information. Le diagramme de classe permet de représenter l’ensemble des

informations finalisées qui sont gérées par le domaine. Ces informations sont structurées,

c’est-à-dire qu’elles sont regroupées dans des classes. Le diagramme met en évidence

d’éventuelles relations entre ces classes. Le diagramme de classes comporte 4 concepts :

Classe

Attribut

Opération

Relation

2.1. Eléments de modélisation

2.1.1. Classe et objet

Une classe décrit un groupe d’objets ayant les mêmes propriétés (attributs),

un même comportement (opérations), et une sémantique commune (domaine de

définition). Un objet est une instance d’une classe. La classe représente

l’abstraction de ses objets. Au niveau de l’implémentation, c’est à-dire au cours


30

de l’exécution d’un programme, l’identificateur d’un objet correspond une adresse

mémoire.

Une classe se représente à l’aide d’un rectangle comportant plusieurs

compartiments. Les trois compartiments de base sont :

La désignation de la classe;

La description des attributs;

La description des opérations;

Deux autres compartiments peuvent être aussi indiqués :

La description des responsabilités de la classe;

La description des exceptions traitées par la classe.

Un objet est une entité aux frontières bien définies, possédant une identité et

encapsulant un état et un comportement. Un objet est une instance (ou

occurrence) d’une classe.

Exemple : Maèl Saleh est un objet instance de la classe Personne.

Figure 19: Représentation d'une classe

2.1.2. Attribut

Une classe correspond à un concept global d’information et se compose d’un

ensemble d’informations élémentaires, appelées attributs de classe.

Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une

classe, l’attribut prend une valeur. Le nom de la classe peut être qualifié par un

«stéréotype». La description complète des attributs d’une classe comporte un

certain nombre de caractéristiques qui doivent respecter le formalisme suivant :

Visibilité : Les droits associés à chaque niveau de confidentialité :

Public (+) : Attribut visible par tous.

Visibilité/Nom attribut : type [= valeur initiale {propriétés}]


31

Protégé (#) : Attribut visible seulement à l’intérieur de la classe et pour

toutes les sous classes de la classe.

Privé (-) : Attribut seulement visible à l’intérieur de la classe.

Paquetage (~) : Attribut seulement visible à l’intérieur du paquetage où se

trouve la classe.

Nom d’attribut : nom unique dans sa classe.

Type : type primitif (entier, chaîne de caractères) dépendant des types

disponibles dans le langage d’implémentation ou type classe matérialisant

un lien avec une autre classe.

Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de la

classe.

{propriétés} : valeurs marquées facultatives (ex. : « interdit » pour mise à

jour interdite).

Un attribut peut avoir des valeurs multiples. Dans ce cas, cette caractéristique

est indiquée après le nom de l’attribut (ex. : prénom [3] pour une personne qui

peut avoir trois prénoms). Un attribut dont la valeur peut être calculée à partir

d’autres attributs de la classe est un attribut dérivé qui se note «/nom de

l’attribut dérivé ».

2.1.3. Opération

Une opération est une fonction applicable aux objets d’une classe. Une

opération permet de décrire le comportement d’un objet. Une méthode est

l’implémentation d’une opération. Chaque opération est désignée soit seulement

par son nom soit par son nom, sa liste de paramètres et son type de résultat. La

signature d’une méthode correspond au nom de la méthode et la liste des

paramètres en entrée.

La description complète des opérations d’une classe comporte un certain nombre

de caractéristiques qui doivent respecter le formalisme suivant :

Visibilité : Les droits associés à chaque niveau de confidentialité :

Public (+) : opération visible par tous.

Visibilité Nom d’opération (paramètres) * :*type résultat] {propriétés}]


32

Protégé (#) : opération visible seulement à l’intérieur de la classe et pour

toutes les sous classes de la classe.

Privé (-) : opération seulement visible à l’intérieur de la classe.

Paquetage (~) : opération ou classe seulement visible à l’intérieur du

paquetage où se trouve la classe.

Nom d’opération : utiliser un verbe représentant l’action à réaliser.

Paramètres : liste de paramètres (chaque paramètre peut être décrit, en plus

de son nom, par son type et sa valeur par défaut). L’absence de paramètre

est indiquée par ().

Type résultat : type de (s) valeur(s) retourné(s) dépendant des types

disponibles dans le langage d’implémentation. Par défaut, une opération ne

retourne pas de valeur, ceci est indiqué par exemple par le mot réservé «

void » dans le langage C++ ou Java.

{propriétés} : valeurs facultatives applicables (ex. : query pour un

comportement sans influence sur l’état du système).

Figure 20: Exemple d'une classe

2.1.4. Relation

S’il existe des liens entre objets, cela se traduit nécessairement par des relations qui

existent entre leurs classes respectives. Les liens entre les objets doivent être considérés

comme des instances de relations entre classes. Il existe plusieurs types de relations

entre classes :

l’association

l’agrégation

la composition

la généralisation/spécialisation


33

2.1.4.1. Association

L’association est la relation la plus courante et la plus riche du point de vue

sémantique. Une association est une relation statique n-aire (le plus souvent : elle

est binaire) : c’est-à dire qu’elle relie plusieurs classes entre elles. L’association

existe entre les classes et non entre les instances.

Figure 21: Exemple d’une association avec deux rôles

Chaque classe qui participe à l’association joue un rôle. Les rôles sont définis par

deux propriétés:

la multiplicité : Elle définit le nombre d’instances de l’association pour une

instance de la classe. La multiplicité est définie par un nombre entier ou un

intervalle de valeurs. La multiplicité est notée sur le rôle (elle est notée à

l’envers de la notation MERISE).

1 Un et un seul

0..1 Zéro ou un

N ou * N ou * N (entier naturel)

M..N De M à N (entiers naturels)

0..* De zéros à plusieurs

1..* De 1 à plusieurs

Exemple : une personne peut posséder plusieurs voitures (entre zéro et un

nombre quelconque) ; une voiture est possédée par une seule personne.

Figure 22: Exemple de multiplicité d’association


34

la navigabilité : Une navigabilité placée sur une terminaison cible indique si ce

rôle est accessible à partir de la source. Par défaut les associations sont

navigables dans les 2 sens. Le nom de l’association peut être sous forme verbale

active ou passive et le sens de lecture de l’association peut être indiqué (> ou <).

Dans certains cas, une seule direction de navigation est utile : l’extrémité

d’association vers laquelle la navigation est possible porte alors une flèche.

Figure 23: Exemple de multiplicité d’association

Dans l’exemple ci-dessus, les instances d’Electeur voient les instances de

Candidat mais les instances de Candidat ne voient pas les instances d’Electeur.

Les classes-association:

Il s'agit d'une classe qui réalise la navigation entre les instances d'autres classes.

Les attributs d’une classe dépendent fonctionnellement de l’identifiant de la

classe. Parfois, un attribut dépend fonctionnellement de 2 identifiants,

appartenant à 2 classes différentes. Par exemple, les attributs « grade et salaire»

dépendent fonctionnellement du numéro de commande et du code produit. On va

donc placer l’attribut « quantité commandée » dans l’association « comporter ».

Dans ce cas, l’association est dite « porteuse d’attributs ». Une association

porteuse d’attributs est appelée classe-association.

Figure 24: Exemple de classe d’association


35

Une association de dimension supérieure à 2 se représente en utilisant un

losange permettant de relier toutes les classes concernées. Une classe-association

permet de décrire soit des attributs soit des opérations propres à l’association.

Cette classe-association est elle-même reliée par un trait en pointillé au losange

de connexion. Une classe-association peut être reliée à d’autres classes d’un

diagramme de classes.

Figure 25: Exemple d’une association de dimension 3

et d’une classe-association

Relation réflexive

Une relation réflexive est une relation qui relie une classe à elle-même.

Figure 26: Représentation et Exemple de la relation réflexive

La notion de rôle

Cette notion est Utilisée pour les associations ambiguës. Elle spécifie la fonction

d’une classe pour une association donnée.


36

Figure 27: Exemple de notation de rôle

2.1.4.2. Agrégation et composition

Une agrégation: 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

».

Une composition: est une agrégation plus forte impliquant que :

un élément ne peut appartenir qu’à un seul agrégat composite

(agrégation non partagée) ;

la destruction de l’agrégat composite entraîne la destruction de tous

ses éléments (le composite est responsable du cycle de vie des parties).

Figure 28: Exemple d’agrégation et de composition

2.1.4.3. Généralisation/spécialisation

La généralisation est la relation entre une classe et deux autres classes ou

plus partageant un sous-ensemble commun d’attributs et/ou d’opérations. La

classe qui est affinée s’appelle super-classe, les classes affinées s’appellent

sous-classes. L’opération qui consiste à créer une super-classe à partir de

classes s’appelle la généralisation. Inversement la spécialisation consiste à

créer des sous-classes à partir d’une classe.


37

L’héritage permet à une sous-classe de disposer des attributs et opérations

de la classe dont elle dépend. Un discriminant peut être utilisé pour exploiter

le critère de spécialisation entre une classe et ses sous-classes. Le

discriminant est simplement indiqué sur le schéma, puisque les valeurs

prises par ce discriminant correspondent à chaque sous-classe.

Exemple : les voitures, les bateaux et les avions sont des moyens de

transport. Ils possèdent tous une marque, un modèle, une vitesse, etc. Par

contre, seuls les bateaux ont un tirant d’eau et seuls les avions ont une

altitude…

Figure 29: Exemple de super- classe et sous- classes

Une classe abstraite est simplement une classe qui ne s’instancie pas

directement mais qui représente une pure abstraction afin de factoriser des

propriétés communes. Elle se note en italique. C’est les cas de Moyen de

transport dans l’exemple précédent.

Dans certains cas, il est nécessaire de faire hériter une même classe de deux

classes « parentes » distinctes. Ce cas correspond à un héritage multiple.

2.1.5. Les contraintes sur les associations

Il existe plusieurs types de contraintes sur les associations :


38

la contrainte « Sous ensemble » : Elle permet de préciser qu’une collection est incluse

dans une autre collection. (la flèche de la relation de dépendance indique le sens de la

contrainte).

Par exemple, on veut représenter les règles de gestion suivantes :

o Un employé est affecté à un seul service

o Dans un service, plusieurs employés sont affectés

Un employé peut diriger un service, dans ce cas, il est obligatoirement affecté à ce

service.

Figure 30:Exemple de la contrainte sous ensemble

Toutes les instances de « diriger » sont incluses dans « affecter ».

La contrainte d’exclusion :

Indique que pour un objet donné, une seule association est valide.

Figure 31:Exemple de la contrainte d'exclusion sur les associations

2.1.6. Les contraintes sur la généralisation

la contrainte d’exclusion


39

Elle permet de préciser qu’une instance d’association exclut une autre instance. Par

exemple, un employé ne peut être à la fois directeur financier et directeur

commercial.

Figure 32:Exemple de la relation d'exclusion sur la généralisation

La contrainte de totalité : Toutes les instances d’une classe correspondent

au moins à une des instances des classes liées.

Figure 33: Exemple de la contrainte de totalité

2.1.7. Elaboration d’un diagramme de classe

Généralités

Un diagramme de classes est une collection d'éléments de modélisation statiques

(classes, paquetages...), qui montre la structure d'un modèle. Un diagramme de classes

fait abstraction des aspects dynamiques et temporels. Pour un modèle complexe,

plusieurs diagrammes de classes complémentaires doivent être construits. On peut par

exemple se focaliser sur :

les classes qui participent à un cas d'utilisation (cf. collaboration);


40

les classes associées dans la réalisation d'un scénario précis;

les classes qui composent un paquetage;

la structure hiérarchique d'un ensemble de classes.

Pour représenter un contexte précis, un diagramme de classes peut être instancié

en diagrammes d'objets. Règles d’élaboration Les règles de normalisation des

modèles entité-relation, issues de l’algèbre relationnelle, peuvent être utilement

appliquées à un modèle de classes UML, même si UML ne contient aucune

préconisation sur ces règles. Ces règles aident à conduire les travaux de

modélisation en évitant le plus possible la redondance de l’information, tout en

restant fidèle aux règles de gestion.

Application

1. Des compagnies aériennes proposent différents vols.

2. Un vol est réalisé par plusieurs compagnies

3. Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.

4. Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.

5. Un vol a un aéroport de départ et un aéroport d’arrivée.

6. Un vol peut comporter des escales dans des aéroports

7. Une escale a une heure d’arrivée et une heure de départ.

8. Chaque aéroport dessert une ou plusieurs villes

9. Une réservation concerne un seul vol, et un seul passager.

10. Une réservation peut être annulée ou confirmée.

Eléments de correction

1. Des compagnies aériennes proposent différents vols.

2. Un vol est réalisé par plusieurs compagnies

3. Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.


41

4. Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.

5. Un vol a un aéroport de départ et un aéroport d’arrivée.

1 ère Solution

2 ème Solution

6. Un vol peut comporter des escales dans des aéroports

7. Une escale a une heure d’arrivée et une heure de départ.


42

8. Chaque aéroport dessert une ou plusieurs villes

9. Une réservation concerne un seul vol, et un seul passager.

10. Une réservation peut être annulée ou confirmée.

3. Diagramme d'objets

La modélisation objet consiste à créer une représentation abstraite, sous forme d'objets,

d'entités ayant une existence matérielle (arbre, personne, téléphone, ...) ou bien

virtuelle(sécurité sociale, compte bancaire, ...). Un objet est caractérisé par plusieurs

notions:

Les attributs (on parle parfois de propriétés): Il s'agit des données

caractérisant l'objet. Ce sont des variables stockant des informations d'état

de l'objet


43

Les méthodes (appelées parfois fonctions membres): Les méthodes d'un objet

caractérisent son comportement, c'est-à-dire 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

L'identité: L'objet possède une identité, qui permet de le distinguer des autres

objets, indépendamment de son état. On construit généralement cette identité

grâce à un identifiant découlant naturellement du problème (par exemple un

produit pourra être repéré par un code, une voiture par un numéro de série, ...)

Figure 34: Exemples d’objets

Les liens entre les objets

Dans l'approche objet, les objets ne sont pas des corps inertes isolés. Bien au

contraire, même s'ils possèdent leurs caractéristiques propres par l'intermédiaire

des valeurs de leurs attributs (ce qui constitue ce que l'on appelle l'état), ils ont la

possibilité d'interagir entre-eux grâce à leurs méthodes. UML propose de

représenter les liens qui existent entre les objets grâce à un trait continu.

Figure 35:Exemple de lien entre les objets

Un lien existe dès lors qu'un objet possède une visibilité vis-à-vis d'un autre, c'est-

à-dire lorsqu'un objet a un rapport direct avec un autre (appartenance, utilisation,

communication, ...).


44

Figure 36:Exemples de diagramme d’objets

45

Chapitre 4 Les Diagrammes d'interaction



- Dégager les principales classes dont les instances qui en découlent,

participent à une collaboration pour un cas d’utilisation.

- Représenter une première ébauche du diagramme de séquence en se

basant sur la description textuelle du scénario nominal d’un cas

d’utilisation.

- Raffiner un diagramme de séquence, en tenant compte des méthodes

des classes concernées.

- Représenter un diagramme de communication

Plan du chapitre

- Introduction

- Définition

- Notation

- Le diagramme de séquences

- Le diagramme de communication

Volume horaire

- 3 heures

Modélisation Objet Les Diagrammes d'interaction

46

Chapitre 4: Les Diagrammes d'interaction

1. Introduction

Le diagramme de cas d’utilisation montre des acteurs qui interagissent avec les

grandes fonctions d’un système. C’est une vision fonctionnelle et externe d’un

système. Le diagramme de classes, quant à lui, décrit le cœur d’un système et montre

des classes et la façon dont elles sont associées. C’est une vision statique et

structurelle. Les diagrammes d’interaction permettent d’établir un pont entre ces

deux approches : ils montrent comment des instances au cœur du système

communiquent pour réaliser une certaine fonctionnalité. Les interactions sont

nombreuses et variées. Il faut un langage riche pour les exprimer. UML propose

plusieurs diagrammes : diagramme de séquence, diagramme de communication. Ils

apportent un aspect dynamique à la modélisation du système.

2. Définition

Les diagrammes de communication et de séquence représentent des interactions

entre des lignes de vie. Un diagramme de séquence montre des interactions sous un

angle temporel, et plus particulièrement le séquencement temporel de messages

échangés entre des lignes de vie, tandis qu'un diagramme de communication montre

une représentation spatiale des lignes de vie.

3. Notation

Un diagramme d'interaction se représente par un rectangle contenant, dans le coin

supérieur gauche, un pentagone accompagné du mot-clé "sd" lorsqu'il s'agit d'un

diagramme de séquence, et de corn lorsqu'il s'agit d'un diagramme de communication.

Le mot-clé est suivi du nom de l'interaction. La liste des lignes de vie qui figurent

dans le diagramme peut suivre le nom de l'interaction. Des attributs peuvent être

indiqués près du sommet du rectangle contenant le diagramme. La syntaxe de ces

attributs est la même que celle des attributs d'une classe.


47

4. Le diagramme de séquences

4.1. Scénario

Un scénario est une série d'événements ordonnés dans le temps, simulant une

exécution particulière du système.

Les scénarios permettent d'expérimenter les exécutions du système, ils sont donc

très utiles pour les phases de tests et de maintenance.

4.2. Diagramme de séquence

Diagramme de séquence : exprime la séquence des interactions entre objets du

système selon un point de vue temporel, pour réaliser le cas d’utilisation.

Un diagramme de séquence est à deux dimensions :

dimension verticale : le temps;

L'ordre d'envoi d'un message est déterminé par sa position sur l'axe

vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.

dimension horizontale : les objets (et les acteurs)

4.3. Eléments graphiques

Les objets interagissant dans un scénario.

Représentation graphique de la ligne de vie de chaque objet et de ses

activations.

Les différents types de messages envoyés (simple, synchrone, asynchrone)

Le contrôle (branchement conditionnel et itération, création & destruction

d’objets, délais transmission et contraintes temporelles, etc.)

Figure 37: Diagramme de séquence Illustration


48

La disposition des objets sur l’axe horizontale n’a pas de conséquence pour la

sémantique du diagramme les branchements conditionnels sont indiqués par un

pseudo-code ou par [ ]

on peut aussi placer en pseudo-code les boucles d’itération.

Figure 38: Exemple simplifié

4.3.1. Interaction

Elle est définie dans le contexte d’une collaboration modélisant un composant

dynamique entre objets et se traduit par l’envoi d’un message entre objets. Le

diagramme de séquence insiste sur la chronologie des objets en utilisant la ligne

de vie des objets.

4.3.2. Ligne de vie

Elle est représentée par une ligne verticale en traits pointillés, placée sous le

symbole de l’objet concerné. Cette ligne de vie précise l’existence de l’objet

concerné durant un certain laps de temps. En général, une ligne de vie est

représentée sur toute la hauteur du diagramme de séquence. Par contre, elle

peut débuter et s’interrompre à l’intérieur du diagramme.

La création se représente en faisant pointer le message de création sur le

rectangle qui symbolise l’objet créé. La destruction est indiquée par la fin de la

ligne de vie et par une croix (X).


49

Figure 39: Représentation de la ligne de vie

4.3.3. Période d’activité

Les diagrammes de séquence permettent de représenter les périodes

d’activité des objets. 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. Les périodes d’activité se représentent

par des bandes rectangulaires placées sur la ligne de vie des objets.

Flot de contrôle à plat :

Cette catégorie d’envois est utilisée pour indiquer la progression vers la

prochaine étape d’une séquence. Elle est représentée par une flèche simple.

Figure 40: Représentation de la période d’activité


50

4.3.4. Les catégories des messages

Les diagrammes de séquence distinguent 3 catégories d’envois de message :

Figure 41:Représentation du flot de contrôle

Alternativement, une demi-flèche peut être utilisée pour représenter

explicitement des messages asynchrones pour des systèmes concurrents (la

flèche pleine correspond alors à un message avec attente de prise en compte).

Figure 42:Représentation de message asynchrone

Les messages réflexifs

Un objet peut s’envoyer un message. Cette situation se représente par une

flèche qui revient en boucle sur la ligne de vie de l’objet.


51

Figure 43: Représentation des messages réflexif

5. Le diagramme de communication

5.1. Définition

Le diagramme de collaboration permet de mettre en évidence les interactions

entre les différents objets du système. Dans le cadre de l’analyse, il sera utilisé :

pour préciser le contexte dans lequel chaque objet évolue

pour mettre en évidence les dépendances entre les différents objets

impliqués dans l’exécution d’un processus ou d’un cas d’utilisation.

Un diagramme de collaboration fait apparaître les interactions entre des objets à

travers l’échange de message.

5.2. Eléments de modélisation

5.2.1. L’interaction

Une interaction définit la communication entre les objets sous la forme d’un

ensemble partiellement ordonné de messages. L’objet émetteur envoie un

message à l’objet récepteur. Les objets représentés dans les diagrammes de

collaboration ne sont pas nécessairement des instances d’entités. Certains

messages peuvent avoir pour origine des acteurs que l’on pourra représenter.

Exemple d’interaction entre objets:


52

Figure 44: Exemple d'interaction entre objet" produits "et objet "commande "

5.2.2. Les messages

Les messages sont le seul moyen de communication entre les objets. Ils sont

décrits essentiellement par l’objet émetteur et l’objet récepteur. Leur description

peut être complétée par un nom, une séquence, des arguments, un résultat

attendu, une synchronisation et une condition d’émission. La séquence permet de

préciser l’ordre d’émission des messages.

Figure 45:Représentation des interactions entre des objets

Le message 1 peut avoir comme arguments l’intitulé du produit souhaité, la quantité et la

catégorie du client. Certains messages peuvent solliciter un résultat. Ce cas peut être

modélisé de 2 façons :

un message de demande et un message de réponse ;

indiquer sur le premier message le résultat attendu (lorsque le message en retour est

attendu immédiatement).

Exemple:

Ou


53

Ici, le message émis par le gérant implique la restitution immédiate du résultat

du calcul : la valeur du stock. Nb : l’émission de message peut également être

soumise à une condition, qui s’exprime alors sur le texte du message.

Exemple : la demande de réapprovisionnement n’est envoyée au magasinier que

lorsque la quantité en stock est inférieure au seuil de réapprovisionnement.

54

Chapitre 5 Diagramme d' Etats-transitions



- Dégager les principaux états relatifs aux instances d’une classe

- Représenter une première ébauche du diagramme d’état-transition.

- Raffiner un diagramme d’état-transition, en tenant compte des sous

états.

- Représenter certains contraintes avancées tel que le faite qu’un objet

se souvient de son historique cours et long (H,H*).

- Distinguer entre transition, condition de garde, et activité.

Plan du chapitre

- Introduction

- Définition

- Eléments de modélisation

Volume horaire

- Une heure et demi

Modélisation Objet Les Diagrammes d'Etats-transitions

55

Chapitre 5: Diagramme d' Etats-transitions

1. Introduction

Les diagrammes d'états transitions (ou State charts ) d'UML décrivent l’évolution

dans le temps d’un objet et son comportement vis-à-vis des interactions avec les objets

qui peuplent sont environnement. Ils présentent les séquences possibles d'états et

d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en réaction

à des événements (de type signaux, invocations de méthode). Ils spécifient

habituellement le comportement d'une instance de classeur (classe ou composant). Ils

sont bien adaptés à la description d'objets ayant un comportement d'automate.

Cependant, la vision globale du système est moins apparente sur ces diagrammes, car

ils ne s'intéressent qu'à un seul élément du système indépendamment de son

environnement.

2. Définition

Le diagramme d'états-transitions DET est associé à une classe dont ses instances

peuvent être dans différents états : il permet de représenter les états possibles ainsi

que les événements qui provoquent les changements d'état. Les objets d’une classe ne

sont pas figés, ils peuvent évoluer et changer d’états au cours de leurs vies. Un DET

d’une classe est une description des évolutions possibles de ses objets mettant en jeu :

La liste des états possibles d’un objet durant son cycle de vie

Les événements déclenchant le passage d’un état à un autre.

Les éventuelles conditions qui doivent être vérifiées lors de la transition d’un

état à un autre.

Les activités mis en jeu lors du changement d’un état.

Pour ce diagramme, on s’intéressera qu’aux classes faisant l’objet d’importants

changements pour le domaine étudié.


56

3. Eléments de modélisation

3.1. Etat

Un état est une situation durable dans laquelle se trouve une instance d’une

classe. Elle se caractérise par sa durée et sa stabilité. Il représente une conjonction

instantanée des valeurs des attributs d’un objet. C'est-à-dire la valeur d’un état

d’un objet est déterminée par l’ensemble des valeurs de ses caractéristiques.

Figure 46: Représentation des états

Dans un DET, on distingue deux états particuliers :

L’état initial : état qui coïncide avec l’instant de création de l’objet et constitue un

point d’entrée au DET

L’état final : état qui coïncide avec la destruction de l’objet

Figure 47: Représentation d'un état initial et d'un état final

L’état final correspond à un état à partir duquel l’objet ne peut plus évoluer.

Les opérations conduisant à un état final sont par exemple suppression,

destruction ou archivage.

Une opération sur un objet est soit une action (méthode faisant passer l’objet

d’un état à un autre) ou une activité (ensemble d’actions).

Exemple:

Cet exemple simple présente la notion d'état et l'effet des invocations en

fonction de l'état courant.


57

Figure 48:Un diagramme d’état simple

Les états sont représentés par des rectangles aux coins arrondis, tandis que les

transitions sont représentées par des arcs orientés liant les états entre eux.

3.2. Transition

La transition indique un mouvement instantanée entre deux états. Chaque

transition porte une étiquette(optionnelles) qui comprend trois parties: signature-

déclencheur [condition de garde] /activité.

- Signature-déclencheur : Généralement un unique événement qui déclenche

potentiellement un changement d'état.

- Condition de garde : condition qui doit être vraie pour que la transition soit

empruntée.

- Activité : un comportement quelconque qui s’exécute pendant la transition.

Figure 49: Un diagramme d’état simple

Exemple: La commande n'est expédiée que si la commande comporte au moins 3

produits.

Figure 50: Diagramme d’états simple du Commande

58

Chapitre 6 Diagramme de Paquetages



Plan du chapitre

- Introduction

- Définition et contenu

- Dépendance entre paquetages

- Accéder et importe

Volume horaire

- Une heure et demi

Modélisation Objet Diagramme de Paquetages

59

Chapitre 6: Diagramme de Paquetages

1. Introduction

En UML, On peut regrouper des éléments en utilisant des paquetages alors les

paquetages UML peuvent servir à organiser pratiquement n'importe quel élément

UML: des classes, des cas d'utilisation, des interfaces, des diagrammes, ... et même des

paquetages imbriqués. Les éléments contenus dans un paquetage doivent représenter

un ensemble fortement cohérent. Ils sont généralement de même nature et de même

niveau sémantique. Généralement, il existe un seul paquetage racine qui détient la

totalité du modèle d'un système. Les diagrammes de paquetages font partie de la vue

de développement, qui s'intéresse à l'organisation des parties du système en modules et

paquetages.

2. Définition et contenu

En UML, un paquetage (package en anglais) est un mécanisme qui permet d’organiser

des éléments

de modélisation en groupes

Figure 51: Exemple de paquetage

On peut accéder aux éléments qu’il contient grâce aux noms qualifiés. La visibilité d’un

élément contenu dans un paquetage peut être spécifiée en mettant le signe ’+’ (visibilité

publique) ou ’-’ (visibilité privée) devant le nom de l’élément. Lorsque la visibilité n’est

pas spécifiée, un élément est visible en dehors du paquetage.


60

Sur le plan graphique, un paquetage est représenté par un rectangle avec un onglet sur

le bord supérieur gauche dans lequel se trouve le nom du paquetage. Il peut regrouper

différents éléments UML, qui peuvent être représentés à l'intérieur du paquetage ou à

l'extérieur reliées par une ligne. Dans l’exemple ci-dessous, le paquetage « DAB »

regroupe les classes « Lecteur de carte » et « Ecran »

Figure 52: Un paquetage contenant deux classes

Et Pour indiquer le paquetage auquel appartient une classe, la plupart des outils UML

permettent de faire précéder le nom de la classe du nom du paquetage auquel elle

appartient.

Figure 53: Deux classes préfixées du nom de leur paquetage

3. Dépendance entre paquetages

Une classe d'un paquetage a parfois besoin d'utiliser une classe d'un autre paquetage.

Cela crée une dépendance entre les paquetages : si un élément du paquetage A utilise

un élément du paquetage B alors le paquetage A dépend du paquetage B


61

Figure 54: Dépendance entre deux paquetages

4. Accéder et importer

Quand un paquetage importe un autre paquetage, les éléments du premier peuvent

faire référence aux éléments du second sans utiliser leur nom complet. Cette

fonctionnalité est similaire au mécanisme d'importation de java, grâce auquel une

classe peut importer un paquetage et utiliser son contenu sans préciser le nom du

paquetage. Dans une relation d'importation, le paquetage importé est appelé paquetage

cible. Pour représenter cette relation, tracez une flèche de dépendance partant du

paquetage initial vers le paquetage cible et marquée du stéréotype import

Figure 55: Une relation d'importation

Un paquetage peut également importer un élément particulier d'un autre paquetage et

non son contenu complet. Une fois un paquetage importé, seuls ses éléments publics

sont accessibles depuis l'espace de noms du paquetage demandant l'importation.

Les éléments ne sont pas les seuls à avoir une visibilité. La relation d'importation peut

elle aussi être publique (par défaut) ou privée. L'importation publique (ou privée)

signifie que tous les éléments importés ont une visibilité publique (ou privée) au sein de

l'espace de noms effectuant l'importation. L'importation privée est représentée par le


62

stéréotype «access». La différence entre «import» et «access» apparaît lorsqu'un

paquetage importe un paquetage qui en importe ou accède à d'autres. Puisque les

éléments importés ont une visibilité publique dans le paquetage effectuant

l'importation, ils suivent les importations successives, contrairement aux éléments

accédés. La figure ci-dessous illustre que le paquetage B importe C et accède à D. B voit

donc les cléments publics de C et de D. Puisque A importe B, A voit les éléments publics

de B. A voit également les éléments publics de C car C est importé publiquement dans

B, mais A ne voit pas le contenu de D car D est accédé privativement dans B.

Figure 56: Relations successives "import" et "access"

Les relations d'importation et d'accès peuvent être utilisées pour modéliser

l'importation de classes dans un espace de noms afin que les éléments de l'espace de

noms effectuant l'importation puissent faire référence à ceux de l'espace de noms cible

sans employer son nom. Des dépendances complexes entre paquetages peuvent

conduire à des modélisations ambiguës. En effet, une seule modification de l'un des

paquetages peut provoquer le dysfonctionnement des paquetages dépendants.

Si des dépendances présentent des cycles, il existe différentes manières, de les rompre.

Aller dans le sens de la stabilité signifie qu'un paquetage doit dépendre uniquement de

paquetages plus stables que lui-même. Un paquetage instable dépend de nombreux

autres paquetages ; un partage stable dépend de quelques paquetages. L'étude des

diagrammes de paquetages peut aider à repérer des problèmes de vulnérabilité de la


63

modélisation provenant du fait que les paquetages au coeur du système (comme ceux

contenant les interfaces) dépendent de paquetages instables.

Modélisation Objet Bibliographie

64

Bibliographie

[1] Pascal Roques & Franck Vallée, UML en action, édition Eyrolles 2000, ISBN

2-212-09127-3.

[2] Martin Flower, UML 2.0, éditionCampusPress 2004, ISBN 2-7440-1713-2.

[3] Pascal Roques, UML 2 par la pratique, édition Eyrolles 2005, ISBN 2-212-

11680-2.

[4] Benoît Charroux, Aomar Osmani& Yann Thierry-Mieg, UML 2, édition

Pearson Education

Support de cours Modélisation Objet (UML)msj-learning.com/pdf/uml.pdf · 1990 et 1995 tels que...

Documents

Transcript of Support de cours Modélisation Objet (UML)msj-learning.com/pdf/uml.pdf · 1990 et 1995 tels que...