Modélisation UML: Introduction

L‘ingénierie des systèmes d’information

INGENIERIE DES BESOINS

Élucidation des besoins

modélisation INGENIERIE DU LOGICIEL
Système réel conception
validation
production
Schéma
conceptuel vérification
Domaine du problème Système
logiciel

Domaine de la solution

1
 Modélisation UML: Introduction
Intérêt de la modélisation

 Modéliser le processus de développement permet de:

 Bien répartir les tâches et d'automatiser certaines d'entre elles ;
 Réduire les coûts et les délais ;
 Assurer un bon niveau de qualité et une maintenance efficace.

 Modéliser un système avant sa réalisation permet de

 Comprendre le fonctionnement du système ;
 Maîtriser sa complexité ;
 Assurer sa cohérence ;
 Pouvoir communiquer au sein de l'équipe de réalisation

2
 Modélisation UML: Introduction

Composants d’une méthode de construction de SI

des MODÈLES
Une DÉMARCHE Pour décrire
- des étapes les données et
les traitements

Une
MÉTHODE de
CONSTRUCTION
De systèmes
d’information

des OUTILS
- manuels
- automatisés (AGL)
3
 Modélisation UML: Introduction
Processus de développement

Comprendre le problème
Analyse en terme de métier du client.

Concevoir une solution informatique

Conception en terme de responsabilité fonctionnelle.

Réaliser la solution en terme

Implantation
de programme.

4
 Modélisation UML: Introduction
L’unification des méthodes : Principales étapes de la définition d’UML
Livres:
Guide de l’utilisateur
1999 Standardisation par l’OMG UML 1.3 Manuel de référence
Guide du processus
1997 Soumission à l’OMG
UML 1.0 Spécification disponible sur Internet

OOPSLA’96
UML 0.9 Spécification disponible sur Internet

1995 OOPSLA’95 Méthode unifiée 0.8

Booch’93 OMT-2

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

Rumbaugh’91 Jacobson’92 Rational 5
 UML: Introduction
Résumé
• UML est une notation, pas une méthode
• UML est un langage de modélisation objet
• UML convient pour toutes les méthodes objet

Programmation Orientée Objet

modéliser informatiquement des éléments d'une partie du monde réel
en un ensemble d'entités informatiques (objets)

Intérêt
• définir le problème à haut niveau sans rentrer dans les spécificités du
langage
• définir un problème de façon graphique
• utiliser les services offertes par l’objet sans rentrer dans le détail de
programmation (Encapsulation)
• Réutilisation du code
6
 UML: Utilisation de diagrammes
Définition d’un diagramme

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

aspect précis du modèle. C'est une perspective du modèle, pas "le 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).

 Chaque type de diagramme UML véhicule une sémantique précise (un

type de diagramme offre toujours la même vue d'un système).

 Combinés, les différents types de diagrammes UML offrent une vue

complète des aspects statiques et dynamiques d'un système.

7
 UML: Utilisation de diagrammes
Définition d’un diagramme

En résumé

 UML est langage de modélisation, pas une méthode

 UML est un langage de modélisation objet

 UML convient pour toutes les méthodes objet

 UML est dans le domaine public

UML est le langage standard de

modélisation orientée objet

8
UML: Utilisation de diagrammes
Les différents types de diagrammes UML

9
 UML: Utilisation de diagrammes
Les différents types de diagrammes UML

Vues statiques Vues dynamiques

diagramme de cas d'utilisation diagramme de séquences

diagramme de classes
diagramme d'états-transitions

diagramme d'objets

diagramme de collaboration
diagramme de composants

diagramme de déploiement diagramme d'activités

10
 UML: Utilisation de diagrammes
Vues statiques du système

But:
 Définition du contour du système à modéliser,
 Identification des fonctionnalités principales (critiques) du système.

Le modèle conceptuel doit:

 permettre une meilleure compréhension du système.
 doit servir d'interface entre tous les acteurs du projet.

11
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Le diagramme des cas d’utilisation identifie:

 Les utilisateurs du système (acteurs)
 Les interactions de ces acteurs avec le système.

 Expression du comportement du système (actions et de réactions),

selon le point de vue de l’utilisateur
 Décrivent le système et les relations entre le système et
l’environnement 12
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)
Acteur:
Toute entité qui est en dehors du système à modéliser et qui interagit avec lui.

Il existe 4 catégories d’acteurs :

 Acteurs principaux : les personnes qui utilisent les fonctions
principales du système
 Acteurs secondaires : les personnes qui effectuent des tâches
administratives ou de maintenance.
 Le matériel externe : les dispositifs matériels incontournables qui
font partie du domaine de l’application et qui doivent être utilisés.
 Les autres systèmes : les systèmes avec lesquels le système doit
interagir.

Formalisme :
13
Nom_acteur
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)
Acteurs – Utilisateurs :
 Un acteur représente un rôle joué par un utilisateur qui interagit
avec le système.

 La même personne physique peut jouer le rôle de plusieurs acteurs

(vendeur, client).

 D’autre part, plusieurs personnes peuvent également jouer le même

rôle, et donc agir comme le même acteur (tous les clients)

14
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Cas d’utilisation (use case) :

 correspond à un objectif du système, motivé par un besoin d’un ou
plusieurs acteurs.
 L'ensemble des use cases décrit les objectifs (le but) du système.
Formalisme :

Nom_use_case

15
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Relation :
 Exprime l’interaction existant entre un acteur et un cas d’utilisation.
Formalisme :

Nom_use_case

3 types de relations entre cas d’utilisation:

 la relation de généralisation
 la relation d’extension
 la relation d’inclusion
16
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Relation de généralisation :
Dans une relation de généralisation entre 2 cas d’utilisation, le cas
d’utilisation enfant est une spécialisation du cas d’utilisation parent.
Formalisme :

cas d'utilisation
parent

cas d'utilisation
enfant
17
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Relation d’inclusion :
Elle indique que le cas d’utilisation source contient aussi le
comportement décrit dans le cas d’utilisation destination.
Formalisme :

virement

<<Include>>

identification
18
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Relation d’extension:
 Elle indique que le cas d’utilisation source ajoute son comportement
au cas d’utilisation destination.
 L’extension peut être soumise à condition.
 Le comportement ajouté est inséré au niveau d’un point d’extension
défini dans le cas d’utilisation destination.
Formalisme :

Cas d'utilisation <<extend>> Cas d'utilisation

source destination

19
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Relation d’extension:

Vérification <<extend>>
virement
solde compte

Passer
commande <<extend>> Passer
urgente commande
Fixer priorité Fixer priorité

20
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Exemple de cas d’utilisation :

21
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Exemple de cas d’utilisation :

22
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Scénarios :
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 peuvent être classés en :
 Scénarios principaux : ils correspondent à l’instance principal du
cas d’utilisation. C’est souvent le chemin « normal » d’exécution du
cas d’utilisation qui n’implique pas d’erreurs.
 Scénarios secondaires : ils peuvent être des cas alternatifs (un
choix), un cas exceptionnel ou une erreur.

23
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)
Acteurs et cas d’utilisation:
 Les cas d’utilisation représentent le dialogue entre l’acteur et le
système de manière abstraite

 Ensemble de scénarios au sein d’une description unique

 Les cas d’utilisation doivent être vus comme des classes de

scénarios.

24
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Conclusion
 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
souvent limité. Il y a souvent un acteur par cas d’utilisation.
 Un cas d’utilisation est une abstraction : il décrit de manière abstraite
une famille de scénarios.
 Dans n’importe quels système, il y a relativement peu de cas
d’utilisation mais beaucoup de scénarios.
25
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Détermination des cas d’utilisation

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

 Quelles informations l’acteur doit-il créer, sauvegarder, modifier,
détruire ou simplement lire?
 L’acteur devra-t-il informer le système de changements externes?
 Le système devra-t-il informer l’acteur de conditions internes au
système?

26
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Dans un établissement scolaire, on désire gérer la réservation des salles

de cours ainsi que du matériel pédagogique (ordinateur portable ou / et
Vidéo projecteur).
 Seuls les enseignants sont habilités à effectuer des réservations (sous
réserve de disponibilité de la salle ou du matériel).
 Le planning des salles peut quant à lui être consulté par les
enseignants et étudiants.
 Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.
 Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.
Modéliser cette situation par un diagramme de cas d’utilisation 27
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases) - Exercice
Choisissez et dessinez les relations entre les cas suivants :
[Link] agence de voyages organise des voyages où l’hébergement se fait en hôtel.
Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel.

Diagramme incomplet des cas d’utilisation d’une agence de voyages

[Link] clients demandent à l’agent de voyages d’établir une facture détaillée.
Cela donne lieu à un nouveau cas d’utilisation appelé « Établir une facture
détaillée ». Comment mettre ce cas en relation avec les cas existants ?
[Link] voyage se fait soit par avion, soit par train. Comment modéliser cela ?.
28
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de cas d'utilisation (use cases)

Dans un magasin, un commerçant dispose d’un système de gestion de

son stock d’articles,
dont les fonctionnalités sont les suivantes :
 Edition de la fiche d’un fournisseur
 Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur
est automatiquement éditée. Si le fournisseur n’existe pas, on peut
alors le créer)
 Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer
l’inventaire, d’effacer un article ou d’éditer la fiche d’un article).
Modéliser cette situation par un diagramme de cas d’utilisation

29
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes
Qu’est-ce qu’un Objet ?
Définition Générale:
« ce sur quoi porte notre connaissance »

Pour les technologies objet:

« c’est une abstraction du monde réel »

Pour l’analyse du domaine:

« c’est une entité pertinente du domaine »

Dans un langage de programmation OO:

« c’est un ensemble de fonctions associées à une structure de données »

Objet = État + Comportement + Identité

30
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes
Pourquoi l’approche objet ?
But:
 modélisation des propriétés statiques et dynamiques de l’environnement dans
lequel sont définis les besoins (domaine du problème),
 formalisation de la perception du monde et des phénomènes qui s’y déroulent,

Avantages:
capacité à :
 Regrouper ce qui a été séparé,
 Construire le complexe à partir de l’élémentaire,
 Intégrer statiquement et dynamiquement les constituants d’un système.

31
 UML: Utilisation de diagrammes
Vues statiques du système – 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.
classe

attribut

Identifiant

Opération

Relation (Association)

généralisation / spécialisation 32
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de classe
Une classe est une description abstraite (condensée) d’un ensemble
d’objets qui définit la structure (des données), leurs comportements et
leurs relations.
Nom de Classe
Attributs
Opérations () Moyen de transport
Type
Formalisme :
Poids
Couleur
Démarrer ()
Accélérer ()
Freiner ()

33
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’Objet
un objet est une instanciation (occurrence) d'une classe

Exemple
une personne, une voiture, une maison, ...

Caractérisation d’un objet

Identité FIAT-UNO-17 : Voiture
permet de le distinguer des autres objets 233434 : Numéro de série
1500 kg : Poids
Attributs 8864 YF 17 : Immatriculation
données caractérisant l'objet 133 000 : kilométrage

Méthodes Démarrer ()
Arrêter()
actions que l'objet est à même de réaliser Rouler()

34
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de classe – Objets

Voiture FIAT-UNO-17
Numéro de série : Int 233434 : Numéro de série
Poids : double 1500 kg : Poids
Immatriculation : String 8864 YF 17 : Immatriculation
Kilométrage : double 33 000 : kilométrage

Démarrer ()
Arrêter()
Rouler()

Renault-Clio-17 Peugeot-206-75
5323454 : Numéro de série 3434 : Numéro de série
1500 kg : Poids 1700 kg : Poids
64 YFT 17 : Immatriculation 8634 YGG 75 : Immatriculation
23 000 : kilométrage 15 000 : kilométrage

35
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’attribut
Un attribut représente la modélisation d’une information élémentaire
représentée par son nom et son format.
Formalisme :

36
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’attribut – Niveaux de visibilité

 public (+) : l’élément est visible pour tous les clients de la classe

 protégé (#) : l’élément est visible pour les sous-classes de la classe

 privé (-) : l’élément n’est visible que par les objets de la classe dans
laquelle il est déclaré.

Formalisme :

37
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’ identifiant
L’identifiant est un attribut particulier, qui permet de repérer de façon
unique chaque objet (instance de la classe).

38
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’opération
Une opération est une fonctionnalité assurée par une classe. La
description des opérations peut préciser les paramètres d’entrée et de
sortie ainsi que les actions élémentaires à exécuter.
Formalisme :

39
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion d’opération – Niveaux de visibilité pour les opérations

 public (+) : l’opération est visible pour tous les clients de la classe
 protégé (#) : l’opération est visible pour les sous-classes de la classe
 privé (-) : l’opération n’est visible que par les objets de la classe dans
laquelle elle est déclarée.
Formalisme :

40
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation
Les liens entre les objets doivent être considérés comme des instances
de relations entre classes.
 l’association
 la généralisation/spécialisation
 la dépendance:

Travaille pour
Personne société association

Travaille pour
Ahmed ONCF
Travaille pour liens
Med ONE

41
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes
Notion de relation – Exemple

42
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes
Documentation d’une association

 Nom de l’association
lien sémantique entre les classes
La personne achète la voiture
La voiture est achetée

 Rôle d’une association

Spécification du rôle de la classe

La personne joue le rôle de

propriétaire de la voiture

43
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association

 Une association est une relation statique n-aire (plus souvent binaire) :
c’est-à-dire qu’elle relie plusieurs classes entre elles.
 Chaque classe qui participe à l’association joue un rôle.
Les rôles sont définis par 2 propriétés :
 la multiplicité

 la navigabilité

44
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association

 Une association est une relation statique n-aire (plus souvent binaire) :
c’est-à-dire qu’elle relie plusieurs classes entre elles.
Association n-aire = Une association parmi 3 classes ou plus. Chaque instance
de l’association est un n-tuple de valeurs des classes respectives

Exemple d’Association n-aire

45
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : multiplicité

La multiplicité est une information qui définit combien d’objets de la

classe considérée peuvent être liés à un objet de l’autre classe

1
Personne Société
1..*

Chaque personne travaille pour une société,

chaque société emploie de une à plusieurs personnes.
46
Multiplicité = cardinalité
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : multiplicité

La multiplicité est une information qui définit combien d’objets de la

classe considérée peuvent être liés à un objet de l’autre classe

* 0..*

0..1
1 Un et un seul

1..*
0..1 facultatif (au plus un)

2..4
N ou * N (entier naturel) (au moins N)
M..N De M à N (entiers naturels)
0..* ou * plusieurs (zéro ou plus)
1..* obligatoire (au moins 1)
47
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : 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.

• Chaque instance de voiture a un lien vers le propriétaire

• Chaque instance de Personne a un ensemble de lien vers les voitures

48
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : navigabilité

 Restriction de la navigabilité.

• Le service de contravention est associé à une ou plusieurs voitures

• La voiture ne connaît pas service de contravention
49
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : classes-association

50
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’association : classes-association

51
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation

Une agrégation représente une association non symétrique dans
laquelle une des extrémités joue un rôle prédominant par rapport à
l’autre extrémité.
L’agrégation ne peut concerner qu’un seul rôle d’une association.

52
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation

53
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation : composition

Exemples d’agrégation

54
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation : composition

La composition est un cas particulier de l’agrégation dans laquelle la vie
des composants est liée à celle des agrégats.

la destruction de l’agrégat (ou conteneur) implique automatiquement la

destruction de tous les composants liés. 55
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation : composition

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).

56
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de relation – L’agrégation : composition

Exemples de composition

57
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation (héritage)

Le principe de généralisation / spécialisation permet d’identifier parmi
les objets d’une classe (générique) des sous-ensembles d’objets (des
classes spécialisées) ayant des définitions spécifiques.
La classe plus spécifique (appelée aussi classe fille, classe dérivée,
classe spécialisée, classe descendante …) est cohérente avec la classe
plus générale (appelée aussi classe mère, classe générale …), c’est-à-dire
qu’elle contient par héritage tous les attributs, les membres, les relations
de la classe générale, et peut contenir d’autres..
 La généralisation décrit une relation entre une classe générale (classe
de base ou classe parent) et une classe spécialisée (sous-classe). La
classe spécialisée est intégralement cohérente avec la classe de base

58
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation (héritage)

59
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation (héritage)

L’héritage est la propriété qui fait bénéficier à une sous classe de la structure
et du comportement de sa surclasse.
60
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation (héritage)

Exemple de relation de spécialisation

Spécialisation Généralisation
étendre les propriétés factoriser les propriétés
d'une classe, sous groupe de classes sous
forme de sous-classes forme de super-classe

61
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation (héritage)

Exemple de relation de spécialisation

62
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Notion de généralisation / spécialisation : spécialisation multiple

Les classes peuvent avoir plusieurs superclasses ; dans ce cas, la
généralisation est dite multiple et plusieurs flèches partent de la sous-
classe vers les différentes superclasses. La généralisation multiple
consiste à fusionner plusieurs classes en une seule classe.

63
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Soient le système suivant :

 Un répertoire contient des fichiers
Elaborez le diagramme de classe correspondant en choisissant le type de
relation approprié

64
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Soient le système suivant :

 Une pièce contient des murs
Elaborez le diagramme de classe correspondant en choisissant le type de
relation approprié

65
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Soient le système suivant :

 Les modems et claviers sont des périphériques d’entrée / sortie
Elaborez le diagramme de classe correspondant en choisissant le type de
relation approprié

66
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Soient le système suivant :

 Une transaction boursière est un achat ou une vente
Elaborez le diagramme de classe correspondant en choisissant le type de
relation approprié

67
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Soient le système suivant :

 Un compte bancaire peut appartenir à une personne physique ou
morale
Elaborez le diagramme de classe correspondant en choisissant le type de
relation approprié

68
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes - Exercice
Concevoir le diagramme de classe d’une application de gestion d’hôtel.
Voici ce que vous devez modéliser :
 Un hôtel est constitué d'un certain nombre de chambres. Un
responsable de l'hôtel gère la location des chambres. Chaque chambre
se loue à un prix donné.
 L'accès aux salles de bain est compris dans le prix de la location d'une
chambre. Certaines chambres comportent une salle de bain, mais pas
toutes. Les hôtes de chambres sans salle de bain peuvent utiliser une
salle de bain sur le palier. Ces dernières peuvent être utilisées par
plusieurs hôtes.
 Les pièces de l'hôtel qui ne sont ni des chambres, ni des salles de bain
(hall d'accueil, cuisine...) ne font pas partie de l'étude (hors sujet).
 Des personnes peuvent louer une ou plusieurs chambres de l'hôtel, afin
d'y résider. En d'autre termes : l'hôtel héberge un certain nombre de
personnes, ses hôtes (il s'agit des personnes qui louent au moins une
chambre de l'hôtel...). 69
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes - Exercice

Une académie souhaite gérer les cours dispensés dans plusieurs

collèges. Pour cela, on dispose des renseignements suivants :
 Chaque collège possède d’un site Internet
 Chaque collège est structuré en départements, qui regroupent
chacun des enseignants spécifiques. Parmi ces enseignants, l’un
d’eux est responsable du département.
 Un enseignant se définit par son nom, prénom, tél, mail, date de
prise de fonction et son indice.
 Chaque enseignant ne dispense qu’une seule matière.
 Les étudiants suivent quant à eux plusieurs matières et reçoivent
une note pour chacune d’elle.
70
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes

Une académie souhaite gérer les cours dispensés dans plusieurs

collèges. Pour cela, on dispose des renseignements suivants :
 Chaque collège possède d’un site Internet
 Chaque collège est structuré en départements, qui regroupent
chacun des enseignants spécifiques. Parmi ces enseignants, l’un
d’eux est responsable du département.
 Un enseignant se définit par son nom, prénom, tél, mail, date de
prise de fonction et son indice.
 Chaque enseignant ne dispense qu’une seule matière.
 Les étudiants suivent quant à eux plusieurs matières et reçoivent
une note pour chacune d’elle.
71
 UML: Utilisation de diagrammes
Vues statiques du système – Diagramme de classes
 Pour chaque étudiant, on veut gérer son nom, prénom, tél, mail,
ainsi que son année d’entrée au collège.
 Une matière peut être enseignée par plusieurs enseignants mais a
toujours lieu dans la même salle de cours (chacune ayant un
nombre de places déterminé).
 On désire pouvoir calculer la moyenne par matière ainsi que par
département
 On veut également calculer la moyenne générale d’un élève et
pouvoir afficher les matières dans lesquelles il n’a pas été noté
 Enfin, on doit pouvoir imprimer la fiche signalétique (nom,
prénom, tél, mail) d’un enseignant ou d’un élève.
Elaborez le diagramme de classes correspondant. Pour simplifier
72
l’exercice, on limitera le diagramme à une seule année d’étude
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences
Le diagramme de séquence permet de visualiser les messages par une
lecture de haut en bas.

73
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Interactions
L’interaction 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.

Activations
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.

74
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Interactions / Activations

75
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Catégories de message
 flot de contrôle à plat

76
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Catégories de message
 flot de contrôle à plat

77
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Catégories de message
 appel de procédure (ou flot de contrôle emboîté)

78
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Catégories de message
 Retour de procédure

79
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Contraintes temporelles

80
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

Contraintes temporelles

81
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences
Le déroulement normal d’utilisation d’un distributeur automatique de billets est le suivant
 le client introduit sa carte bancaire
 la machine vérifie alors la validité de la carte et demande le code au client
 si le code est correct, elle envoie une demande d’autorisation de prélèvement au
groupement de banques. Ce dernier renvoie le solde autorisé à prélever.
 le distributeur propose alors plusieurs montants à prélever
 le client saisit le montant à retirer
 après contrôle du montant par rapport au solde autorisé, le distributeur demande au
client s’il désire un ticket
 Après la réponse du client, la carte est éjectée et récupérée par le client
 les billets sont alors délivrés (ainsi que le ticket)
 le client récupère enfin les billets et son ticket

Modéliser cette situation à l’aide d’un diagramme de séquence en ne prenant

en compte que le cas où tout se passe bien. 82
 UML: Utilisation de diagrammes
Vues dynamiques du système – Diagramme de séquences

83
 Types de relation : Agrégation

A B
Type de relations
– A « contient » des instances de B,
Agrégat

Propriétés de l’agrégation
• La suppression de A n’implique pas la suppression de B
• L'élément agrégé peut être partagé

Exemples :
• L’enseignant est un composant
d’une (ou plusieurs) équipe de
recherche d’un seul département

• La disparition d’une équipe de

recherche n’entraine pas la
disparition d’un enseignant

84
Diagramme de classes

85
 Diagramme de classes

Client

1..1
Paquet

1..* 0..*
Livraison
Lettre Colis 1..1

Colis national Colis international

0..*

Peut contenir

0..*
Marchandise

Interpréter le diagramme de classes suivant afin de donner une spécification

en langage naturel.

86
 Implémentation : Héritage

public class Personne {

public String nom;
public String prenom;
}

public class Etudiant extends Personne {

public int noEtudiant;
}

87
 Implémentation : Associations

public class Personne {

public String Nom;

public String prenom;
public [Link] voiture =
new [Link]();
}

public class Voiture {

public String immatriculation;

public Personne Propriétaire;
public void demarer() { }
}

public class ServiceContraventions {

public [Link] Voiture = new [Link]();

}

88
 Implémentation : Agrégation

public class Enseignant extends Personne {

public String telephone;
public [Link] equipeRecherche = new [Link]();
public Departement departement;
}

public class Département {

private int nomDépartement;
private int codetheme;
public [Link] enseignant = new [Link](); 89
}
 Implémentation : Composition

public class EquipeRecherche {

public String[] nomEquipe;
public String thématique;
public [Link] enseignant = new [Link]();
public Laboratoire laboratoire;
}

public class Laboratoire {

public [Link] equipeRecherche = new [Link]();
} 90