Modélisation UML

Élaboré par:
Mme Bourkhis Dalel

A.U: 2017/2018
 Plan

I. Introduction

II. Modélisation objet

III. Les diagrammes UML

1. Diagramme de cas d’utilisation

2. Diagramme de classe

3. Diagramme de séquence

4. Diagramme d’activité

2
 Introduction

Spécification
Spécifications Validation
s

Conception
Conception Intégration
Préliminaire
Préliminaire

Réalisation

UML (Unified Modeling Language) 3

 Introduction

UML est une notation, 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

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'une méthode objet

• 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

4
 Modélisation objet

Notion d’Objet
Une abstraction du monde réel c.-à-d. des données informatiques
regroupant des caractéristiques du monde réel

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

5
 Les diagrammes UML

• Vues statiques
– Les diagrammes de classes
– Les diagrammes d’objets
– Les diagrammes de cas d’utilisation
– Les diagrammes de composants
– Les diagrammes de déploiement

• Vues dynamiques
– Les diagrammes de séquence
– Les diagrammes de collaboration
– Les diagrammes d’états-transition
– Les diagrammes d’activités

6
Le diagramme de classe

7
 Diagramme de classe

Notion de Classe
• Structure d'un objet, c.-à-d. une déclaration de l'ensemble des entités
qui composeront l’objet
• Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un
moule

Notation
un objet est une instanciation (occurrence) d'une classe

Une classe est composée: Nom_de_la_classe

 attributs
attribut1 : Type
données dont les valeurs représentent attribut2 : Type
…
l'état de l'objet
 méthodes méthode1 ()
méthode2 ()
opérations applicables aux objets …

8
 Diagramme de classe

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

9
 Diagramme de classe

Visibilité des attributs

définissent les droits d'accès aux données (pour la classe elle-même,
d'une classe héritière, ou bien d'une classe quelconque)

 Publique (+)
les classes peuvent accéder aux données et
méthodes d'une classe définie avec le niveau
de visibilité public Nom_de_la_classe
# Attribut1 : Type
- Attribut2 : Type
 Protégée (#): l'accès aux données est …
réservé aux fonctions des classes héritières + méthode1 ()
Méthode2 ()
…
 Privée (-): l'accès aux données est limité
aux méthodes de la classe elle-même

10
Types de relation entre classes

Héritage

Association

Contenance

11
 Types de relation : Héritage

permet de créer une nouvelle classe à partir d'une classe existante

Principe
classe dérivée contient les attributs et les méthodes de sa superclasse

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

Chaque personne de l’université est identifiée par son nom, prénom

Les étudiants ont plus un noEtudiant
Les enseignants ont un numéro de téléphone interne 12
 Types de relation : Association

Connexion sémantique entre deux classes

Navigabilité
 Par défaut une association est navigable dans les deux sens

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

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

 On "passe" d'une classe à l'autre en parcourant les associations; ainsi par

défaut
On peutles associations
considérer sont
que le train n'a pas "navigables"
besoin de dans les deux sens. Il peut être
pertinent
"connaître" au moment de l'analyse de réduire la navigabilité à un seul sens.
son conducteur.

13
 Types de relation : Association

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

14
 Types de relation : Association

Relation n-aire
Type particulier d’association qui relie plus de deux classes

Professeur

Symbole d’association

Salle Etudiant

Attention
difficiles à déchiffrer

15
 Types de relation : Association

Multiplicités
1 : la classe est en relation avec un et un seul objet de l’autre classe
1..* : la classe est en relation avec au moins un objet de l’autre classe
0..* : la classe est en relation avec 0 ou n objets de l’autre classe
0..1 : la classe est en relation avec au plus un objet de l’autre classe

Une voiture est achetée par une

Une personne peut acheter
et une seule personne
0 ou n voitures

16
 Types de relation : Contenance

Cas particulier d’association exprimant une relation de contenance

Exemples:
• Une voiture a 4 roues
• Un dessin contient un ensemble de figures géométriques
• Une présentation PowerPoint est composé de transparents
• Une équipe de recherche est composée d’un ensemble de personnes

Deux types de relations de contenance en UML

• Agrégation
• Composition (Agrégation forte)

17
 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

18
 Types de relation : Composition

 La suppression de A entraine la suppression de B

Exemple:
« Une présentation PowerPoint est composé de transparents »

La suppression de la présentation entraine la disparition des transparents

qui la compose

19
Diagramme de classes

20
 Implémentation : Héritage

public class Personne {

public String nom;
public String prenom;
}

public class Etudiant extends Personne {

public int noEtudiant;
}

21
 Implémentation : Associations

public class Personne {

public String Nom;

public String prenom;
public java.util.Collection voiture =
new java.util.TreeSet();
}

public class Voiture {

public String immatriculation;

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

public class ServiceContraventions {

public java.util.Collection Voiture = new java.util.TreeSet();

}

22
 Implémentation : Agrégation

public class Enseignant extends Personne {

public String telephone;
public java.util.Collection equipeRecherche = new java.util.TreeSet();
public Departement departement;
}

public class Département {

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

public class EquipeRecherche {

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

public class Laboratoire {

public java.util.Collection equipeRecherche = new java.util.TreeSet();
} 24
 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...). 25
Solution

26
Le diagramme de cas d’utilisation

27
 Le diagramme de cas d’utilisation

Définition
Un cas d’utilisation « raconte » comment on doit utiliser
le système pour atteindre un but particulier

Il correspond à une fonction du système

Il décrit les interactions entre le système et les utilisateurs
Il est exprimé en prose structurée
Il détermine un contrat à remplir par le système
Il induit des exigences fonctionnelles applicables au système
et il peut être utilisé pour organiser la spécification

28
 Le diagramme de cas d’utilisation

Concepts
ACTEUR
représente un rôle joué par une personne ou une chose qui
interagit avec le système mais qui lui est extérieure.
est caractérisé par un nom qui exprime son rôle.
une même personne physique peut être modélisée par
plusieurs acteurs.

CAS D ’UTILISATION

unité fonctionnelle cohérente assurée par un système ou une

classe
correspond à un certain type d’interaction entre le système et
les acteurs.
doivent être vus comme des classes dont les instances sont
des scénarios.

Inscription
29
 Le diagramme de cas d’utilisation

Identification des acteurs:

On distingue 4 catégories d ’acteurs:

les acteurs principaux (ex: usager, client, etc.)
les acteurs secondaires (ex: opérateur de maintenance,
administrateur, etc.)
le matériel externe (capteurs, imprimantes, périphériques
divers, etc.)
les autres systèmes (serveur central, service ou organisation,
etc.)

Système
 Un Acteur peut hériter
d’autres Acteurs secrétaire

directeur
30
 Le diagramme de cas d’utilisation

 Identification des cas d’utilisation:

Les cas d ’utilisation correspondent

• aux principales tâches de chaque acteur

• à une valeur ajoutée pour l ’utilisateur
• à des fonctionnalités ou à des services attendus
• à des opérations sur les données du système
• à des anomalies ou des cas particuliers.

 Liens entre cas d ’utilisation :

Communication – exprime le fait que

l ’acteur participe à la réalisation d ’un cas
d ’utilisation . C ’est la seule relation qui peut Consommateur Payer

exister entre un acteur et un cas d ’utilisation.

31
 Le diagramme de cas d’utilisation

Généralisation - un cas d ’utilisation « enfant »

hérite du comportement et de la sémantique du Payer

cas d ’utilisation parent

Régler par chèque Régler par CB

Relation « Include » – Une relation

« include » du cas d ’utilisation A vers le cas
d ’utilisation B signifie que le flot d ’événements <<include>>

de A contient une séquence d ’événements qui

correspond à B. Régler par CB Composer Code

Relation « Extend » – Une relation « extend » du <<extend>>

cas d ’utilisation A vers le cas d ’utilisation B signifie
que le flot d ’événements de A peut intervenir, de Remplir ordre et montant Régler par chèque
façon facultative, pendant le déroulement de B. B automatiquement
spécifie un comportement facultatif

32
 Le diagramme de cas d’utilisation

Exemple:

33
 Le diagramme de cas d’utilisation

Exemple: diagramme de cas d’utilisation d'une application de suivi

de patients dans un établissement hospitalier:
Voici les cas d'utilisation de notre application :
· Authentification : l'application vérifie que l'utilisateur est bien ce qu'il
prétend être et lui donne ensuite l'autorisation d'accès .
· Ajout : pouvoir ajouter des nouveaux patients, nouveau-nés, . . .etc.
· Modification : sert à modifier l'information dans la base de données
· Recherche : rechercher des informations sur un patient, un nouveau-né . .
.etc. pour pouvoir se renseigner ou renseigner les visiteurs.
· Imprimer :
Bulletins propre aux patients: (bulletin d'admission, billet de salle,
certificat de séjour, certificat de présence et déclaration de décès).
Pour le garde-patient : (billet de salle).
Pour la naissance : (billet de salle, déclaration de naissance).
· Calcul des statistiques : nombre de nouveau-nés, nombre des
accidentés, moyenne des décès et des naissances par mois .. .etc.
D'où la présentation de notre diagramme de cas d'utilisation

34
 Le diagramme de cas d’utilisation

Exemple:

diagramme de cas
d’utilisation d'une
application de suivi
de patients dans
un établissement
hospitalier

35
 Le diagramme de cas d’utilisation

Exemple:

36
 Le diagramme de cas d’utilisation

Exemple:

37
 Le diagramme de cas d’utilisation

 Scénario - description textuelle en langage naturel:

Il est donc nécessaire d’adjoindre à chaque cas d’utilisation une
description détaillée. Cette description est parfois textuelle et
composée de plusieurs rubriques dont les plus importantes sont :

 Le scénario nominal : enchaînement d’actions typiques dans le

cas où les choses se passent comme prévu.

 Les enchaînements alternatifs : enchaînements dans des cas

particuliers.

38
 Le diagramme de cas d’utilisation

Exemple:
Cas d’utilisation : Retrait-distributeur (cas d’erreur)

1. Dupont insère sa carte,

2. le distributeur D1 accepte la carte et lit le numéro du compte
et de la banque,
3. D1 demande le code de Dupont,
4. Dupont entre le code ‘2341’,
5. D1 demande au consortium C1 de vérifier le numéro de
compte et le code saisi,
6. C1 signifie son refus à D1,
7. D1 demande à Dupont demande à nouveau le code de
Dupont,
8. Dupont entre le code ‘2341’,
9. D1 demande à nouveau au consortium C1 de vérifier le
numéro de compte et le code saisi,
10.C1 signifie à nouveau son refus à D1,
11.D1 signifie son refus de l'opération à Dupont, et conserve la
carte,
12.D1 met fin à son utilisation par Dupont...
39