Cours UML (Tous Les Chapitres)

Cours : Modélisation Orientée
Objet (MOO avec UML)
Responsable : Achraf MTIBAA
1
Introduction : Rappel sur
les concepts orientés objet
2
1-Approches de conception
Approche Fonctionnelle (60-70)

- Décomposition du système en des
fonctions
Approche Systémique (70-8x)
- Dichotomie Données / Traitement
Approche Objet (8x- ….)
- Se base sur les concepts Objets
3
2-Concepts des Objets
Le monde est composé d’entités qui « collaborent »

chauffeur
Feu
direction
Boîte de
moteur
vitesse
roue roue Freins
• L’approche objet consiste à résoudre un problème en termes

d’objets qui collaborent.
• Ces objets sont des abstractions des objets réels
4
2-Concepts orientés objet
L’OBJET
Est un élément du réel à modéliser :
Posséde sa propre identité : OID (Object Identifier) :
OID : est une valeur indépendante des valeurs des prorpriétés de
l’objet
Attribuée par le système et elle est totalement transparante à
l’utilisateur
Peut avoir plusieurs états durant son cycle de vie :
Etat d’un objet : situation significative que peut prendre un objet,
déterminée en fonction des valeurs des différents attributs et liens
de l’objet
Cycle de vie : les états que peut prendre un objet, entre sa création
et sa suppression (et les conditions de passage d’un état à un
autre).
Exemples :
La facture 100567 : {100567, 27/1/2005, ...}
Les états que peut prendre la facture : {saisie, livrée, en attente de
livraison, soldée, …}
5
La CLASSE
Regroupe un ensemble d'objets semblables :
les mêmes propriétés structurelles (attributs);
le même comportement (opérations, méthodes);
les mêmes liens avec les autres objets;
et ayant un intérêt pour l'application.
Encapsule les données et les traitements :
La classe Facture : {NumFacture, DateFacture, …,
Imprimer(), Solder(), ...}
6
L’ENCAPSULATION
Est un principe qui consiste à :
cacher les données et les détails d'implantation (algorithmes) et
laisser visible la partie interface (signatures des opérations
publiques) des classes
Approche classique Approche objets

Inte rfac e
Encapsulation Inte rfac e
Inte rfac e
Données Traitements Echange de messages
7
L’HERITAGE
Est un mécanisme permettant le partage des caractéristiques
d’une classe (généralisation) par une ou plusieurs autres classes
(spécialisations).
Personne Nom, Prénom, Adresse, ...
Héritage simple
Cours, Diplôme, ... Enseignant Etudiant Année, ...
Héritage multiple
Etudiant_Enseignant Numéro, TD, ...
8
3-Démarche Orientée objet
Principales étapes de conception objet
Le cycle de vie du logiciel suivant une approche objet est Itératif et
Incrémental.
Itératif : l’architecture subit plusieurs cycles d’analyse, de conception et
d’implémentation.
Incrémental : les décisions sont raffinées à chaque cycle d’analyse /
conception / implémentation, menant à un système qui répond plus aux
exigences.
Dans chaque itération, on s’intéresse aux activités suivantes :
Identifier les classes et les objets à un niveau donné d’abstraction
Identifier les relations entre classes
Spécifier l’interface des classes.
Phase Conception
9
Analyse : Modéliser le domaine d’activité du client.
Conception : Choisir l’architecture du système et définir la

responsabilité de chaque composant.
Implémentation : Définir l’algorithme de chaque programme
10
Les différents points de perception d’un système :
La vision statique :
Description des entités représentant l’univers de discours et de leurs
relations.
De quoi est fait le système ?
La vision dynamique :
Description des évolutions, dans le temps, des entités représentant
l’univers de discours.
Comment il peut évoluer ?
La vision fonctionnelle :
Description du fonctionnement (des différentes fonctionnalités) du
système.
Comment il fonctionne ?
11
Modèle statique
Décrire les objets : Contrôler les

. structures de données évolutions, dans le
. opérations temps, des objets du
. liens entre les classes système
Modèle
dynamique
Modèle fonctionnel Décrire le fonctionnement

du système
12
5-UML - Le langage Objet unifié
Unified Modeling Language
UML est un langage formel (ou pseudo-formel)

basé sur un métamodèle.
Le métamodèle permet de définir :
• les concepts et éléments de modélisation
• la sémantique de ces éléments
UML se base sur une notation graphique

UML propose neuf types de diagrammes
• représentent les aspects statiques et dynamique
• couvrent l’ensemble des phases de développement
UML est ouvert et extensible
13
6-UML - Le langage Objet unifié
Historique
UML est un langage de modélisation objet
et non une méthode
2005 UML 2.0
UML 1.4
01/ 99
révision 1.3 UML 1.3
11/ 97 Adoption par UML 1.1

l ’OMG
01/ 97 Soumission à UML 1.0
l ’OMG
10/ 96 UML 0.91
06/ 96 UML 0.9
Unified Method 0.8
Booch 93 OMT-2
Booch 91 OMT-1 OOSE
14
7-Les différents diagrammes du langage UML
Spécifications de besoins
- Diagramme de cas d’utilisation,
- Diagramme d’activités.
Le modèle structurel
- Le diagramme de classes,
- Le diagramme d’objets.
15
7-Les différents diagrammes du langage UML
Le modèle dynamique
- Le diagramme de cas d’utilisation,
- Le diagramme d’interaction (collaboration,
séquence),
- Le diagramme d’états.
Architecture
- le diagramme de composants,
- le diagramme de déploiement.
16
8-Ateliers UML
Critères de sélection
• Nombre de diagrammes supportés
• Génération automatique de diagrammes
• Génération de code - langages supportés
• Rétro ingénierie (reverse engineering)
• Prototypage
• Synchronisation du code avec modifications extérieures
• API
• Echanges avec d’autres AGL UML ou IDE
• Utilisation pratique (schémas de qualité, convivialité, générer des images, ... )
• Patterns de conception - et création de patterns
• ...
17
8-Ateliers UML
Quelques AGL :
• StarUML : http://staruml.io/
•Together ( Togethersoft) http://www.togethersoft.com
• Rational ROSE (Rational corp.) http://www.rational.com
• Paradigm (Platinium) http://www.platinium.com
• Magic Draw UML (NoMagic) http://www.nomagic.com
• DOM (ObjetDirect) http://www.objetdirect.com
• Objecteering (SoftTeam) http://www.objecteering.com
• Aonix Life Cycle Desktop (Aonix) http://www.aonix.com, .fr
• UML Studio (Pragsoft) http://www.pragsoft.com
18
Bibliographie
Livres :
Modélisation objet avec UML

JA Muller, N. Gaertner. Editions Eyrolles.
UML par la pratique
UML en action
De Merise à UML, …
Cours : MM : F.Gargouri & K.Haddar
Sur le Web :
http://www.omg.org/uml/
http:// www.rational.com
http://www.uml.free
Sous google :
UML
Français
19
MOO (UML)
Chapitre 1: Le diagramme de
cas d’utilisation
20
Chapitre 1: Le diagramme de cas d’utilisation
Les cas d’utilisation (use cases) ont été formalisés par

Ivar Jacobson. Les cas d’utilisation décrivent, sous la
forme d’actions et de réactions, le comportement d’un
système du point de vue d’un utilisateur.
Un cas d’utilisation est une manière spécifique d’utiliser
un système. C’est l’image d’une fonctionnalité du
système, déclenchée en réponse à la stimulation d’un
acteur externe.
21
1-Définitions
Définition 1:
Un cas d’utilisation (use case) modélise une interaction entre
le système informatique à développer et un utilisateur ou
acteur interagissant avec le système.
Définition 2:
Un cas d’utilisation décrit un ensemble d’actions réalisées par
le système qui produit un résultat observable pour un acteur.
Spécifications
Use Cases
Analyse Tests
22
Définitions
Les cas d’utilisation :
servent de base à la traçabilité des exigences d'un système
dans un processus de développement intégrant UML.
se limitent aux préoccupations "réelles" des utilisateurs :
ne présentent pas de solutions d'implémentation et
ne forment pas un inventaire fonctionnel du système.
Un cas d’utilisation avec UML :
est la solution pour représenter au niveau conceptuel, les
besoins des utilisateurs (Merise ne permet pas cette
modélisation).
permet de structurer les besoins des utilisateurs et les objectifs
(fonctionnalités) correspondants d'un système.
identifie les utilisateurs du système (acteurs) et leurs interactions
avec le système.
permet de classer les acteurs et structurer les objectifs du
système. 23
Définitions
Recentrent l’expression des besoins sur les utilisateurs
ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et
organiser les besoins
Partitionnent l’ensemble des besoins d’un système.
Les besoins:
définissent le contour du système à modéliser
ils précisent le but à atteindre,
permettent d'identifier les fonctionnalités principales (critiques)
du système.
24
2-Intérêt des cas d’utilisation
Utilisateur C
Ensemble des besoins
Utilisateur A Utilisateur B
Les cas d’utilisation partitionnent Cahier des charges

l’ensemble des besoins d’un
système
25
3-Concepts de base : les acteurs
Définition 1 :
Représente 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é
Définition 2 :
Une entité externe agissant sur le système qui peut :
Échanger de l’information avec ce système
consulter ou modifier l'état du système,
Les acteurs sont :
Déterminés en examinant les :
Utilisateurs directs du système
Responsables de l’exploitation et/ou de la maintenance
Autres systèmes interagissant avec le système
Représentés sous forme de petits personnages ou sous forme
de rectangle avec le mot clé <<acteur>>
26
4-Grandes 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.
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.
27
5-Concepts de base : les cas d’utilisation
Définition 1 :
Un ensemble d'actions réalisées par le système, en réponse à
une action d'un acteur
Définition 2 :
Modélise une fonctionnalité d’un système ou d’une classe

sont représentés par des ellipses
Peuvent être contenus dans un rectangle (représentant le
système)
Sont déterminés en observant et en précisant
Acteur par acteur les scénarios du point de vue utilisateur
Sont décrits en termes :
d’informations échangées et
d’étapes d’utilisation du système.
28
Concepts de base : les cas d’utilisation
Un cas d’utilisation :
Regroupe une famille de scénarios d’utilisation
Est une abstraction du dialogue système/utilisateurs
Quand un acteur interagit avec le système:

Le cas d’utilisation instancie un scénario
L'ensemble des cas d’utilisation décrit les objectifs du système

Utilité des cas d’utilisation pour :
les utilisateurs : exprimer les besoins
Les analystes : comprendre
Les programmeurs : réaliser
Les testeurs : vérifier
29
Concepts de base : les cas d’utilisation
Une fois identifiés, les acteurs doivent être décrits d’une

manière claire et concise, en trois ou quatre lignes
maximum.
Lorsqu’il y a beaucoup d’acteurs dans un système, il est
conseillé de les regrouper par catégories afin de faciliter
la navigation dans le modèle des cas d’utilisation
Les cas d’utilisation doivent être vus comme des classes
dont les instances sont les scénarios.
Un scénario correspond au flot de messages échangés
par les objets.
30
Concepts de base : relations entre cas
d’utilisation
Association (relation de communication):
Relation entre un acteur et un cas d’utilisation
Un acteur déclenche un cas d’utilisation :
CasUtilisation
Acteur
<<inclut>>
Relation d’inclusion :
Entre cas d'utilisation CasUtilisation1
CasUtilisation2
L’instance du CU source contient aussi le
comportement décrit par le CU destination.
31
d’utilisation
Relation d’inclusion (suite) :
La relation d’inclusion a un caractère obligatoire:
La source doit indiquer à quel endroit le CU cible doit être inclus
Permet de :
Décomposer les comportements et
Définir des comportements partageables entre plusieurs CU.
Relation d’extension :
Entre cas d'utilisation
L’instance du CU source ajoute son comportement au CU destination (si la
condition est réalisée).
Le CU destination étend son comportement par l’ajout de celui du CU
source, si la condition est vérifiée.
<<étend>>
[condition d'extension]
CasUtilisation1 CasUtilisation2
32
d’utilisation
Relation d’extension (suite) :
Peut être soumise à une condition :
Le comportement ajouté est inséré au niveau d’un point d’extension
Ce point d’extension est défini dans le CU destination
Permet de modéliser des variantes de comportement d’un CU
Selon les interactions des acteurs et l’environnement du système
la condition d’extension peut être spécifiée
à côté du mot-clés <<étend>>
Point d’extension :
Possède un nom
Décrit :
Un emplacement dans le CU destination où le comportement du
CU source sera inséré.
UML ne définit aucun format de description de point d’extension
33
d’utilisation
Relation de généralisation :
Entre cas d'utilisation
Le cas d’utilisation Fils est une spécialisation du cas d’utilisation Parent
CasUtilisationParent
Virement
CasUtilsationEnfant
VirementParInternet
Exemple : On désire représenter par un diagramme de CU les virements bancaires

effectués par des clients:
Un client peut être local ou distant
Un client peut effectuer un virement via Internet ou direct (banque)
Dans tous les cas, on doit procéder à une identification du client
Dans le cas d’un virement dont le montant dépasse 500, on procède à une
vérification du solde du compte du client.
34
Exemple
Virement Client Local

Client Distant
<<étend>>
Montant > 500
<<Inclut>>
VirementInternet
Identification Vérification solde compte
35
Exemple
Et voici le point d’extension :
Virement
Points d’extension
• Vérification supplémentaire:
après identification
36
MOO (UML)
Description des cas d’utilisation
(Suite Chapitre I)
37
Il n’existe pas de norme (UML) établie pour la description textuelle
des cas d’utilisation.
Généralement, on y trouve pour chaque cas d’utilisation :

son nom,
un bref résumé de son déroulement,
le contexte dans lequel il s’applique,
les acteurs qu’il met en jeu,
une description détaillée :
le déroulement nominal de toutes les interactions,
les cas nécessitant des traitements d’exception,
les effets du déroulement sur l’ensemble du système,
etc.
38
Sommaire d’identification
Titre : ……………….. Type : …………………
Résumé :………………………………………………………………………………
Acteurs :
Date de création : Date de mise à jour :…………………………………
Version : Auteur(s) :
Description des Enchaînements :

Pré conditions :
Scénario nominal :
1.
2.
…
Enchaînements alternatifs :
A1…
A2…
Contraintes
….
39
Exemple de Cas d’utilisation
Sommaire d’identification
Titre : Traiter le passage en caisse
Résumé : un client arrive à une caisse avec des articles à acheter. Le caissier enregistre
les achats et récupère le paiement. A la fin de l’opération, le client part avec les articles.
Acteurs : Caissier (P), Client (S), Gestion des stock (S)
Date de création : Date de mise à jour :…………………………………
Version : 1 Auteur(s) : Etudiants 2ème année
Description des Enchaînements :
Pré conditions : La caisse est en service : un caissier y est connecté
Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes interactions
utilisateur / système permettant l’exécution réussie du traitement
(voir suite)
40
1. Ce CU commence quand un client arrive à la

caisse avec des articles qu’il veut acheter.
2. Le caissier enregistre chaque article. S’il y a 3. La caisse détermine le prix de l’article et ajoute
plus d’un exemplaire par article, le caissier des informations sur l’article à la vente en cours.
indique également la quantité. La caisse affiche la description et le prix de
l’article en question.
4. Après avoir enregistré tous les articles, le 5. La caisse calcule et affiche le montant total de
caissier indique que la vente est terminée. la vente.
6. Le caissier annonce le montant total au client.
7. Le client choisit le type de paiement :

a. En cas de paiement …
b. En cas de …
c. En cas …
8. La caisse enregistre la vente et imprime …
9. Le caissier donne le ticket de caisse au client.

41
Enchaînement alternatif :
Quand l’enchaînement précisé par le scénario nominal ne peut
pas se dérouler comme prévu :
Le cas d’utilisation converge tout de même.
Exemple:
Numéro d’identification d’un article est inconnu
l’enchaînement démarre au point 2 du scénario nominal.

3. La caisse indique que le numéro d’identification de l’article est
inconnu. L’article ne peut alors pas être pris en compte dans la
vente encours.
Le scénario reprend au point 2.
42
Enchaînement d’erreur :
Quand l’enchaînement précisé par le scénario nominal ne peut
pas se dérouler :
Le cas d’utilisation se termine par un échec.
Exemple:
Client ne pouvant payer (ou le centre d’autorisation refuse le
payement)
l’enchaînement démarre au point 6 du scénario nominal.
7. Le client ne peut pas payer le total avec aucun des moyens
autorisés.
8. Le caissier annule l’ensemble de la vente et le cas d’utilisation
se termine en échec :
la vente ne peut pas avoir lieu
43
Fonctionnement des caisses enregistreuses d’un super marché :
Un client arrive à la caisse avec des articles à payer.
Le caissier enregistre le numéro d’identification de chaque article,
ainsi que la quantité si elle est > 1.
La caisse affiche le prix de chaque article et son libellé.
Quand tous les achats sont enregistrés, le caissier signale la fin de la
vente.
La caisse affiche alors la fin des achats et le prix total à payer.
Après la saisie des articles, le client peut présenter des coupons de
réduction pour certains articles
Le client choisit son mode de paiement :
Liquide : le caissier encaisse l’argent reçu, la caisse indique le
montant à rendre au client.
Chèque : le caissier vérifie la solvabilité du client en transmettant
une requête à un centre d’autorisation via la caisse.
Carte de crédit : un terminal bancaire fait partie de la caisse et
transmet une demande d’autorisation en fonction du type de la
carte.
La caisse enregistre la vente et imprime le ticket.
Le caissier donne le ticket au client.
Quand le paiement est terminé, la caisse transmet l’information sur le
nombre d’articles vendus au système de gestion des stocks.
chaque matin, le responsable du magasin initialise les caisses pour la
44
journée.
Responsable Initialier la caisse

Magasin
<<étend>>
Prendre en compte coupons

Caissier Traiter le passage en caisse
<<Acteur>>
<<inclut>> Gestion des stocks
Client <<Acteur>>
Traiter le Paiement Centre autorisation
cartes
<<Acteur>>
Centre autorisation
chèques
Paiement Liquide Paiement Chèque Paiement Carte
45
MOO (UML)
Chapitre II: Diagramme de
classes
46
Chapitre 2 : Les diagrammes de classes
Les diagrammes de classes expriment la structure statique d’un système en
termes :
De classes et de relations entre elles et
Un ensemble d’interfaces et de paquetages ainsi que leurs relations.
Une classe décrit un ensemble d’objets, une association décrit un ensemble
de liens
Les objets sont instances des classes et les liens sont instances des
associations
Un diagramme de classes décrit de manière abstraite les liens potentiels
d’un objet vers d’autres objets. Est une instance de
1,N 0,N
Lien Objet Relation Classe
1, N 1, N
Est une instance de
47
1- Concepts de base
AVEC UML, UNE CLASSE :
est un type abstrait avec des caractéristiques communes à un
ensemble d'objets.
permet de créer des objets ayant ces caractéristiques
Est représentée par un rectangle avec:
Propriétés Nom de Classe
Méthodes et Propriétés
Exceptions / Conditions. Méthodes
Classe = propriétés + méthodes + instanciation

48
Concepts de base
LES ATTRIBUTS ET LES OPÉRATIONS :

Sont décrits dans le deuxième et troisième compartiments
Peuvent être précisés par : attributs et opérations
Nom de Classe
NomAttribut [: type = valeur
initiale]
Opération ()
Remarques :
L’ordre opération / attribut = attribut / opération
Opération = méthode = fonction-membre, …
Attribut = propriété = donnée-membre, …
49
Concepts de base
La syntaxe de description des attributs est :
Visibilité NomAttribut [[Multiplicité] : Type [=ValeurInitiale]

[{Propriété}]]
Visibilité = type d'accessibilité :

Public : visible et modifiable par tout objet du même paquetage
Private : seulement visible et modifiable par les opérations de
l'objet auquel il appartient.
Protected : seulement accessible et modifiable par les opérations
des classes descendantes
Multiplicité : intervalle ou nombre
Propriété : mutabilité (gelé, variable, ajout Uniquement, …)
50
2- Les relations entre classes
Association
Agrégation
Composition Remarque : par rapport au modèle E/A de base
Héritage RC UML + riches sémantiquement et + proches de la réalité
Les associations :
Une association exprime une connexion sémantique
bidirectionnelle entre n classes (n>=1).
Une association est instanciable dans un diagramme d'objets ou
de collaboration sous forme de liens entre objets issus des
classes associées.
ADHERENT
Nom emprunter
EXEMPLAIRE
Prénom
Adresse
51
LES ASSOCIATIONS :
représentent des relations statiques/conceptuelles entre objets
et à longue durée de vie (n’est pas un lien instantané ni
passager).
Relient une ou plusieurs classes : arité 1 ou plus
Par rapport au modèle Entité / Association :
Entité 1 Entité 2
Card1 Card2
Diag. Entité / P11, Ass P21,
Association P12 P22
… …
Card2 Card1
Diag. De CEntité1 CEntité2
classes 52
Arités des associations :
Une association peut être binaire ou naire.
Exemple : on désire représenter le fait suivant : un
Professeur enseigne dans une salle des étudiants.
PROFESSEUR
Enseigner
SALLE ETUDIANT
Si on veut matérialiser le cours
COURS
Association porteuse de données
53
Les associations : Nommage
Une association peut être nommée
[ Nom Association ]
Classe1 Classe2
Comment justifier la non obligation du nom de l’association :

Aux niveaux conception et implantation
Sens de lecture d’une association :
Association en forme verbale active (ou passive) :
précise le sens principal de lecture d'une association (>
ou <).
Est Employée Par>
HÔTEL héberge> PERSONNE PERSONNE SOCIÉTÉ
Association en forme verbale active Association en forme verbale Passive

54
Association à navigabilité restreinte :
Par défaut, une association est navigable dans les deux sens.
On peut la limiter à un seul sens dans un modèle (et non lors de
d'implémentation).
indique que les instances d'une classe ne "connaissent" pas les
instances d'une autre.
ELECTEUR vote CANDIDAT
Connaître
ETUDIANT ENSEIGNANT
Les associations : Notion de rôle
Rôle des associations (utilisé pour les associations ambiguës) :
spécifie la fonction d'une classe pour une association donnée
Client Parents
HÔTEL PERSONNE PERSONNE
Directeur Enfants
55
La notion de rôle :
[ Nom Association ]
Classe1 Classe2
[Rôle1] [Rôle2]
Rôle 1 : le rôle joué par Classe 1 dans l’association

Rôle 2 : le rôle joué par Classe 2 dans l’association
Professeur Etudiant
Enseigne Est Enseigné
56
LES ASSOCIATIONS : CARDINALITÉS
précisent le nombre d'instances qui participent à une relation.
Combien d’objets de la classe considérée peuvent être liés à
un objet de l’autre classe?
1 Un et un seul
0 .. 1 Zéro ou un
N N (entier naturel)
M .. N De M à N (entiers naturels)
* De 0 à plusieurs
0 .. * De 0 à plusieurs
1 .. * De 1 à plusieurs
57
Un exemple illustratif
58
L’agrégation :
Est une association non symétrique,
Exprime un couplage fort et une relation de subordination.
Représente une relation de type "ensemble/élément".
Peut notamment (mais pas nécessairement) exprimer :
qu'une classe (un "élément") fait partie d'une autre
("l'agrégat"),
qu'un changement d'état d'une classe, entraîne un
changement d'état d'une autre,
qu'une action sur une classe, entraîne une action sur une
autre.
Une instance d'élément agrégé peut :
être liée à plusieurs instances d'autres classes :
l'élément agrégé peut être partagé (dans le temps)
exister sans agrégat (et inversement)
les CV de l'agrégat et de ses éléments agrégés peuvent être
indépendants :
La création de l’un n’implique pas celle de l’autre
59
Composition :
La composition est une agrégation forte.
Les cycles de vie des éléments (les "composants") et du
composé coïncident :
si le composé est détruit (ou copié), ses composants le sont
aussi.
une instance de composant ne peut être liée qu'à un seul
composé.
Les "objets composites" sont des instances de classes
composées.
COUVERTURE LIVRE CHAPITRE
Agrégation Composition
Remarque : toutes les conventions relatives aux cardinalités restent
valables pour les Agrégations et les compositions
60
Propriétés de la composition
La composition implique une contrainte sur la valeur de
la multiplicité du côté de l’agrégat : elle ne peut prendre
que les valeurs 0 ou 1.
La composition et les attributs sont sémantiquement
équivalents.
Cylindre
Immeuble Chambre
Voiture Moteur
Cercle
Carburateur
Point
Rectangle
61
LA GÉNÉRALISATION :
L’héritage, avec UML, est désigné par GENERALISATION
Elle représente une relation de classification entre élément plus
général et un élément plus spécifique.
Elle peut être appliquée aux classes, aux paquetages et aux cas
d’utilisations
La généralisation peut être
Simple ou
GENARALISATION
SPECIALISATION
Remarque : une classe généralisée peut être spécialisée selon ≠ critères

Multiple :
La spécialisation a plus qu’une généralisation
62
Contraintes et propriétés de la généralisation :
Les attributs, les opérations, les relations et les contraintes définies
dans les super-classes sont hérités dans les sous-classes
La contrainte exprimée par le mot-clé {disjoint}
Tout objet est au plus instance d’une seule sous-classe
La généralisation, par défaut, symbolise une décomposition
exclusive.
La contrainte exprimée par le mot-clé {chevauchement}
Une classe descendante au produit cartésien de ses classes
généralisées
VEHICULE
Premier Deuxième
critère critère
Motorisation Milieu
{chevauchement}
A VOILE A MOTEUR TERRSETRE MARIN
63
LES DEUX
Contraintes et propriétés de la généralisation :

La contrainte exprimée par le mot-clé {complet}
Indique que la généralisation est terminée :
Il n’est pas possible d’ajouter d’autres sous-classes
La contrainte exprimée par le mot-clé {incomplet}
Indique que la généralisation est extensible : elle peut avoir
d’autres spécialisations
COURS
{incomplet}
COOSI IA GL BDA
64
LES ASSOCIATIONS : CONTRAINTES
La multiplicité représente un exemple de contrainte sur le nombre de
liens qui peuvent exister entre deux objets.
permettent d'étendre ou de préciser la sémantique
permettent de restreindre le nombre d'instances visées
peuvent s'exprimer en :
Langage Naturel ou
graphiquement avec un {texte} ou
En OCL (Object Constraint Language)
Les types de contraintes exprimables sur les associations :
Ordonné;
Sous-ensemble;
Ou-exclusif, …
65
Les associations : Contraintes
Ordonné :
PERSONNE 1 0..* COMPTE

{ordonné}
La collection des comptes d’une personne est triée
Sous-ensemble :
SERVICE 1 affecter 1..* EMPLOYE
Numéro_S Numéro
{sous-ensemble} Nom
Nom_S
... ....
0..1 diriger 1
66
Les associations : Contraintes
Ou-exclusif :
Indique que pour un objet donné, une seule association est valide
BATTERIE
PORTABLE {Ou-exclusif}
Alimenter SECTEUR
Cette contrainte permet d’éviter l’introduction de classes artificielles
Alimenter ENERGIE
PORTABLE
SECTEUR BATTERIE
67
Classe d'association :
est une classe qui réalise la navigation entre les instances d'autres
classes.
représente les associations porteuses de données.
Passe >
ETUDIANT EXAMEN
NOTE
Remarque : classe d’association (Cde, Client, Facture)& attribut de

lien (Cde, produit, QteCdée)
Qualification :
permet de sélectionner un sous-{} d'objets, parmi ceux participant à une
association.
est définie par une clé, qui permet de sélectionner les objets ciblés.
Personne 0..1 E-mail Réseau
68
Grammaire OCL : Object Constraint
Language
Langage formel pour l’expression de contraintes, standardisé par
l’OMG.
Supprimer des ambiguïtés en se basant sur une grammaire précise.
OCL permet l’expression des contraintes suivantes :
- Les invariants au sein d’une classe ou d’un type,
- Les contraintes au sein d’une opération,
- les pré- et post-conditions d’opération
Chaque contrainte OCL est liée à un contexte définissant le type
auquel la contrainte se rapporte.
Exemple :
Context Classe d’école : : ajouter (unElève : Personne)
pre classeD’écoleNonSurchargée : nbr_élèves <=25
Post : éléves exists (unElève)
69
Complément du Chapitre II :
Du modèle de classes au
modèle relationnel
Conception du stockage de données
Diagrammes structurels schémas de BD
Diagrammes dynamiques requêtes et traitements
applicatifs divers
Modèle objet Modèle relationnel

Classe Table
Attribut de type simple Colonne
Attribut de type composé Colonnes ou clé étrangère
Instance Tuple
OID Clé primaire
Association Clé étrangère ou table de liens
Héritage Clé primaire identique sur
plusieurs tables
Transformation d’une classe avec identifiant unique
Chaque classe devient une relation Classe Personne
Chaque attribut de la classe devient Personne
un attribut de la relation
L’identifiant de la classe devient une CIN {unique}
clé primaire de la relation Prénom
Date-naissance
Personne (CIN, Prénom, Date-nais)
Table Personne
Attribut Domaine Non Null
CIN String(13) Oui

Clé
primaire Prénom String(30) Non
Date-nais Date Non
Transformation d’une classe sans identifiant unique
Classe Adresse
ADRESSE
Id_adresse
N°
Rue
Ville
Table Adresse
Colonnes Domaine Non Null
Clé primaire Id_adresse Identifiant Oui

N° Entier Non
Rue String(30) Non
Ville String(50) Non
Transformation d’une association 1-1
Inclure la clé primaire d’une des relations comme clé étrangère dans l’autre
relation
Exemple:
Un hôte habite dans une et une seule chambre
Une chambre héberge un et un seul hôte
Chambre(N°chambre, superficie, type)

Hôte(ID, nom, prénom, N°chambre#)
Transformation d’une association 1-1
Personne Adresse
N°
CIN {unique} 1 habite à 1 Rue
Nom CP
Ville
Personne (CIN, Nom, Id_adr#)
Adresse (Id_adr, N°, Rue, CP, Ville)
Table Personne
Colonnes Domaines Non

Clé primaire Null
CIN String(13) Oui
Nom String(35) Non
Clé étrangère Id_adresse Identifiant Oui
Transformation d’une association 1-N
Inclure la clé primaire de la relation dont la

multiplicité est N comme clé étrangère
dans l’autre relation
Exemple:
Un hôtel contient un ensemble de chambres
Hôtel(ID_Hotel, nom, adresse)

Chambre(ID_chambre, superficie, type,
ID_Hotel#)
Transformation d’une association 1-N
Personne Compte
CIN {unique} 1 possède0..* N° {unique}

Nom Type
Personne (CIN, Nom)

Compte(N°, Type, CIN#)
Table Compte
Colonne Domaine Non Null
Clé primaire N° String(35) Oui

Type String (20) Non
Clé étrangère # CIN Identifiant Oui
Transformation d’une association N-N
Créer une nouvelle relation dont la clé

primaire est la concaténation des clés
primaires des 2 relations participantes
Les attributs de la classe d’association sont
ajoutés à la nouvelle relation
Exemple:
Etudiant(ID_Etudiant, nom, prenom)
Enseignant(ID_Enseignant, nom, prenom)
Enseignement(ID_Etudiant#, ID_Enseignant#, heure, durée)
Transformation d’une association N-N
Personne Bibliothèque
0..* adhère >0..* Nom
CIN{unique
…
}
...
Adhésion
Date Personne (CIN, …)
Type Bibliothèque(Id_bib, …)
Adhésion(CIN#, Id_bib#, Date, Type)
Table Adhésion
Colonne Domaine Non Null
Clé primaire CIN String(13) Oui
OiD de Bibliothèque Id_bib Identifiant Oui
Date Date Oui
Type String(13) Oui
Transformation de l’héritage
Héritage Les sous classes ont la même clé primaire que la
superclasse
Personne Remarque: Un attribut « type » est
ajouté à la superclasse dans le cas
CIN d’une spécialisation complète
Nom Il existe trois choix :
Prénom
• Aplatir vers le haut
• Aplatir vers le bas

Etudiant Enseignant
• Conserver les niveaux
NumEtudiant Grade
AnnéeEtude Spécialité
Aplatir vers le haut
Personne (CIN, Nom, Prénom, NumEt, AnnéeEtude, Grade, Spécialité, T)
Dom(T)={Étudiant, Enseignant, Autre}
Contraintes:
SI Type = Autre ALORS NumEt=AnnéeEtude= Grade=Spécialité=Null
SI Type = Étudiant ALORS Grade=Spécialité=Null
SI Type = Enseignant ALORS NumEt=AnnéeEtude= Null
Aplatir vers le bas

Personne (CIN, Nom, Prénom)
Étudiant (CIN, Nom, Prénom, NumEt, AnnéeEtude)
Enseignant (CIN, Nom, Prénom, Grade, Spécialité)
Contraintes:
La classe Personne est concrète.
Conserver les niveaux:

Personne (CIN, Nom, Prénom)
Étudiant (CIN, NumEt, AnnéeEtude)
Enseignant (CIN, Grade, Spécialité)
Contraintes:
Projection(Etudiant, CIN) incluse Projection(Personne, CIN)
Projection(Enseignant, CIN) incluse Projection(Personne, CIN)
MOO (UML)
Chapitre III: Diagramme
d’Objets
83
CHAPITRE 4 : DIAGRAMME D’OBJETS
Servent durant la phase exploratoire de l’analyse
Représentent la structure statique du système modélisé.
Montrent :
des objets (instances de classes) dans un état
particulier et
des liens (relations sémantiques) entre ces objets.
Position des diagrammes objets dans un processus de
modélisation :
Use Cases Spécifications
Diag. objet
Conception Modèles dynamiques 84

Concepts de base
Un diagramme d’objets:
est une instance d’un diagramme de classes
Montre un contexte particulier (objet + lien)
facilite la compréhension des structures de données complexes.
Représentation des objets :
Un objet est représenté par un rectangle qui contient :
le nom de l'objet ou,
le nom et la classe de l'objet ou
la classe de l'objet.
Le nom de la classe peut contenir le chemin complet,
composé à partir des noms différents paquetages englobants
repérés par deux points
Nom Objet Nom Objet : Classe :Classe
Mohamed Mohamed : PERSONNE :PERSONNE 85

1- Concepts de base
Représentation des objets :
Un groupe d’objets :
:Personne
Le rectangle représentant un objet peut comporter

une partie contenant les valeurs des attributs de
l’objet :
Ahmed : ADHERENT : VOITURE
Nom = Mohamed Couleur = rouge
Prénom = Ahmed Puissance = 4
Adresse = Sfax Marque = Peugeot
86
Concepts de base
Représentation des liens entre objets :
Les liens entre objets sont :
Des instances des associations entre les classes
des objets participants
Permettent une représentation plus concrète que
celle produite par les diagrammes de classes.
Exemple :
V1:Voiture :Moteur 1 1
Voiture Moteur
1
4
R1:Roue R3:Roue R2:Roue R4:Roue Roue
Diagramme d’objets Diagramme de Classes

87
Concepts de base
Représentation des liens entre objets :
Les liens entre objets peuvent être naires.
Exemple :
: Professeur
: Salle : Etudiant
On peut indiquer les noms des objets et des liens :
Ahmed : ADHERENT
Nom = Mohamed emprunter
UML en Action : EXEMPLAIRE
Prénom = Ahmed
Adresse = Sfax
88
1- Concepts de base
Représentation des objets composites :
Un objet composite est composé d’autres objets (sous-objets)
Le nombre d’instances du composant peut être spécifié
Un Composite
:Partie1 :Partie2
Exemple:
: Fenêtre
: Zone de dessin
: ascHorizontal
Remarque :
Ces diagrammes ne sont utiles que durant la phase exploratoire d’un
domaine.
Ils deviennent vite compliqués et illisibles
89
MOO (UML)
Chapitre IV: Diagramme de
Collaboration
90
CHAPITRE 4: DIAGRAMME DE
COLLABORATION (DCO)
Les diagrammes de collaboration :
représentent :
Une extension des diagrammes d’objets
le contexte d'une interaction en y précisant les états des
objets en collaboration (interaction).
présentent :
des rôles joués par des objets dans un contexte particulier et
les liens entre ces objets.
montrent :
des interactions entre objets (instances de classes et
acteurs).
les interactions entre ces objets par des envois de
messages
91
1-Sémantique
Les diagrammes de collaboration :
permettent :
une représentation (structure) spatiale des objets, des liens
et des interactions (graphe dont les nœuds = intervenants et
les arcs = les interactions).
Une dimension temporelle (ordre de déclenchement) par
l’ajout de numéros de séquence des messages échangés
(on ne représente pas le t de déclenchement ni la durée).
L’objectif est de construire un modèle expliquant la coopération

entre les objets utilisés pour la réalisation d’une fonctionnalité.
Autrement :
Décrire le comportement collectif d’un ensemble d’objets
En vue de réaliser une opération
en décrivant leurs interactions modélisées par des envois
(éventuellement numérotés) de messages
92
Sémantique
Dans un diagramme de collaboration :
les interactions sont représentées par les échanges de
messages.
l’ordre des messages peut être indiqué par leur énumération.
Plusieurs types de messages existent : simples, synchrones,
asynchrones et minutés.
Conventions graphiques :
les objets sont représentés par un rectangle dont le nom et la
classe sont soulignés.
Nom Objet Nom Objet : Classe :Classe
93
Sémantique
Représentation Générale :
3: opération (paramètre)
2 : opération
1 : événement
Objet1 : nom classe Objet 2
4 : opération
5 : opération (paramètres)
Objet 3 :nom de la classe

Nom acteur :
Nom de la classe
Flux de données
94
2-Concepts de base
Une collaboration :
Est la réalisation d’une opération ou d’un cas d’utilisation dans
un contexte particulier.
Possède deux types de descriptions :
Une description générale au niveau spécification, donnant:

Les rôles joués par les intervenants et les rôles des
associations
Une interaction : une séquence de messages
partiellement ordonnés échangés entre les rôles des
intervenants
Une description spécifique au niveau instance, représentant :

Une instance particulière d’une interaction avec les
objets et les liens respectant les rôles définis au niveau
spécification, et les stimulus (instances des messages)
échangés entre ces objets.
PA Muller, N. Gaertner
95
Concepts de base
La notion de rôle :
Les objets et les associations jouent des rôles particuliers dans
une collaboration.
Exemples :
:C Un rôle anonyme de la C :C Objet anonyme, instance de C
/R:C Un rôle R de la classe C /R:C O. anonyme de C jouant le rôle R
/R Un rôle R /R O. anonyme jouant le rôle R
O/R:C Objet O, instance de la classe C, jouant le rôle R
96
Concepts de base
Représentation au niveau spécification:
Forme un graphe de rôles des intervenants (nœuds) liés à des
rôles d’association (arcs)
Exemple :
Collaboration représentant le fait qu’une maison peut être
louée à un ou plusieurs locataires pour un loyer donné.
/Locataire : Personne
* +habitant
1 +habitation
/Maison : Logement *
1 1
1 + adresse 1 +loyer 1 +loueur
:Lieu :Coût /Propriétaire : Personne
97
Concepts de base
Représentation au niveau instance :
Forme un graphe d’instances qui se conforment aux rôles des
intervenants et des associations définis au niveau spécification
On peut y ajouter des instances de messages échangés
Les objets et les liens utiles pour réaliser une action sont ajoutés
Exemple :
Une instance du diagramme précédent avec :
Un acteur qui déclenche l’opération et des
Stimuli (communication entre objets)
1: revenuDeLocation(pourLesMaisons)
Loueur / Propriétaire :
Personne
:Client
1.1 *[i:=1..n]:loyer()
:Coût 1.1.i : valeur() /Maison:Logement 98

Concepts de base
Représentation au niveau instance :
Généralement :
Les rôles ne sont pas indiqués
Les objets, les liens et les stimuli sont représentés
Exemple :
1:total:=valeurStock()
:Entreprise
1.1.1 : Créer(0,0) :SRéel
:Client
2:afficher(total)
1.1.2.i : ajout(p)
1.1 : calculValeur()
:Stock :Produit
:Afficheur
1.1.2 * [i:=1..n]:p:=ValeurP()
99
Concepts de base
Les messages :
Le terme Stimulus désigne :
Une communication entre objets invoquant une opération ou
L’émission d’un signal ou
la création et destruction d’un objet
Le terme message :
Un message est la spécification d’un stimulus définissant :
Le rôle des objets émetteur et récepteur
L’action qui envoie un stimulus quand elle s’exécute.
Un message est l’avènement d’une communication permettant :
La transmission de certaines informations et
Éventuellement avoir des résultats.
Un envoi de message entre un émetteur et un récepteur
nécessite que le dernier puisse réaliser l’activité définie par le
message.
100
3.2 : afficher (liste)
2.3 : afficher ("prêt accordé")
1.3 : afficher("autorisé")
4 : retrait des cassettes obtenues 1.2 : afficher ("refus", raison)
2. référence_film(titre_film)
1 : emprunter des cassettes 1.1 : res, raison := vérifier droits (adhérent)

:F.Gestion Contrôleur
des prêts des droits
3 :rep := demande de réservation 2.2 : dispo, cass_id := recherche_cassettes(id_film, boutiq_id)
: Adhérent
3.3 rep, boutique :=choix_boutique
3.1 : liste := liste_boutique_dispo
3.5 : rep := recherche étendue
2.1 : existe, id_film := recherche_film(titre) Film
2.4 : réserver(adh_id, boutiq_id)
3.6 : recherche_film(titre)
3.4 : réserver (adh_id, boutique)
Ens
Films 2.2.1 :*[i=mes_cassettes] dispo : = dispo(boutiq_id)
: Catalogue
général
Ens
:Empr
Cassette
unt
2.4.1 : créer (adh_id, cass_id, bouti_id)
3.4.1 : créer (adh_id, cass_id, boutique)
101
Diagramme de collaboration emprunt – club vidéo
Remarques
Les acteurs du diagramme de cas d’utilisation sont

aussi présents au niveau du diagramme de
collaboration
Les cas d’utilisation se transforment en un ou
plusieurs messages échangés entre les intervenants
du diagramme de collaboration
Il y a plus d’intervenants et de liens au niveau du
diagramme de collaboration qu’au niveau du
diagramme de cas d’utilisation
102
MOO (UML)
Chapitre V: Diagramme de
Séquences
103
CHAPITRE 5 :DIAGRAMME DE
SEQUENCES (DES)
Les diagrammes de cas d’utilisation ont permis :
aux utilisateurs d’exprimer leurs besoins.
De dresser une première liste des objets et des
acteurs constituant le système.
Les diagrammes de collaboration ont permis de :

détailler les diagrammes de cas d’utilisation.
Préciser comment les objets et les acteurs doivent
collaborer ensemble pour réaliser chacun de ces cas
d’utilisation.
Les diagrammes de séquence :

Ajoutent une dimension temporelle aux diagrammes
de collaboration.
Se concentrent sur la séquence des interactions
selon un point de vue temporel (durée, arrivée,
séquencement, …)
104
1-Formalisme
DSE est une version plus complète du diagramme « trace

d’événements » de la méthode (OO) OMT.
Permet de présenter les scénarios d’un cas d’utilisation donné.
Un message reçu par un objet déclenche l’exécution d’une
opération et en général renvoie un message qui correspond au
résultat de l’opération.
105
2-Sémantique
Les diagrammes de séquence :
permettent de représenter des collaborations entre objets selon
un point de vue temporel :
on s’occupe de la chronologie des envois de messages (durée
et instant).
on n'y décrit pas le contexte ou l'état des objets : la
représentation se concentre sur l'expression des interactions
servent à illustrer un cas d'utilisation.
Représentent les aspects dynamiques d’un système.
Représentation Générale :
Objet 1 Objet 2 : classe Objet 3 : classe de l’objet

de l’objet
Opération 2 (paramètres)
Annotations [x] Opération 1
While Y loop Evt 1
End loop
[non x] opération 3 106
3-Concepts de base
Remarques :
Les objets étudiés sont placés sur la première ligne
Tout objet a une ligne de vie : une barre verticale en pointillée
L’axe temps, dans chaque diagramme, est représenté
(implicitement) de haut vers le bas
L'ordre d'envoi d'un message est déterminé par sa position sur
l'axe vertical du diagramme
Les messages sont représentés par des flèches orientées :
émetteur – destinataire.
La disposition des objets sur l'axe horizontal 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.
107
Exemple
Appelant Ligne Appelé
Téléphonique
décrocher
tonalité
Numérotation
Indication de sonnerie
Sonnerie
décroche
allô
108
4- Les activations et envois de messages
Une période d’activité correspond au temps pendant

lequel un objet effectue une action.
Un Objet
Activation
Durée d’activation
On distingue trois grandes catégories d’envois de

message
1- Flot de contrôle à plat : est utilisé pour indiquer la
progression vers la prochaine étape d’une séquence
109
Envois de messages
Objet émetteur Objet
destinataire
Flot de contrôle à plat
2- Appel de procédure ou flot de contrôle emboîté : la

séquence emboîtées doit se terminer pour que la
séquence englobante reprenne le contrôle
A B C
procédure
une sous-procédure
B récupère le contrôle après que C a fini sa tâche
A récupère le contrôle après que B a fini sa tâche
110
envois de messages
3- Retour d’un appel de procédure : le retour de message

est explicite à la fin de l’exécution d’une sous-procédure
et le retour éventuel de paramètres. A B
retour explicite
Dans un DSE, deux types de messages peuvent être

distingués
Message synchrone : dans ce cas l’émetteur reste en
attente de la réponse à son message. La flèche standard
symbolise ce type de message. Le message retour peut
ne peut être représenté, il est en fait inclus dans la fin
d’exécution de l’opération déclenchée dans l’objet
destinataire du message
111
5- Message synchrone et asynchrone
- Message asynchrone : dans ce cas, l’émetteur n’attend
pas la réponse à son message, il poursuit l’éxecution de
ses opérations. C’est la demi-flèche qui symbolise ce
type de message. A B
Message synchrone
Message asynchrone
Un objet peut également s’envoyer un message. Cette

situation se représente par une flèche qui boucle sur la
ligne de vie de l’objet. Un Objet
Message réflexif
112
6-Complément sur le DSE
Création et destruction d’objet
Si un objet est crée au cours de l’exécution d’un scénario,
celui-ci n’apparaît qu’au moment où il est créé. Si l’objet
est détruit dans un scénario, la destruction se présente
par X.
Objet 1
Objet 2
113
Contrainte temporelle
Des contraintes de chronologie entre les messages
peuvent être spécifiés. De plus lorsque l’émission d’un
message a besoin d’une certaine durée, il se représente
sous la forme d’un trait oblique.
objet1:classe1 Objet2 : classe2
Un message
114
Lorsque le diagramme de séquence est utilisé pour représenter un
sous-ensemble du logiciel à réaliser, il est possible d’indiquer le
pseudo-code exécuté par un objet pendant le déroulement d’une
opération.
Le diagramme de séquence est dit diagramme de séquence
système quand il met en jeu acteurs et système. Le système reste
une boîte noire (voir exemple (Nouvelle entrée).
Système
: Magasinier
nouvelleEntrée(prod,qté)
vérifier_référence(prod)
entréeEnregistrée si référence(prod) alors
entréeRefusée sinon
finsi
115
7- Exemple : Diagramme de séquence
retour – club vidéo
F.Gestion des Cassette Emprunt Ens.
: Adhérent Statistiques
prêts
retour de cassettes(adh_id)
afficher ("numéro cassette")
Pour chaque
vérifier_réservation(adh_id)
cassette rendue
afficher(mnt
saisie(cass_id)
réservé_pour(adh_id)
^(existe)
^(confirme)
si confirme alors
date_emprunt_et_tarif
calcul(date_e,tarif_j)
calculer_prix_à_payer()
stat:=créer (cass_id, adh_id,ma_boutiq, durée) Statistique
[non_nul(stat)]ajouter(stat)
supprimer()
disponible(ma_boutiq, aujourd'hui)
fin_saisie finsi
mt:=calculer_prix_total()
afficher(mt)
116
MOO (UML)
Chapitre VI: Diagramme
d’états transitions
117
Chapitre 7- Diagramme d’états
transitions (DET)
Les objets d’une classe ne sont pas figés :
Ils peuvent évoluer et changer d’états au cours de leur CV.
CV : cycle de vie = durée de vie : depuis sa création jusqu’à sa
suppression
Un DET d’une classe est une description des évolutions possibles
de ses objets donnant :
la liste des états que peut prendre l’objet durant son CV ;
les événements déclenchant les changements d’états;
les éventuelles conditions qu’il doit vérifier avant de changer
d’états et
les opérations qui le font passer d'un état à un autre.
Un DET est une description des changements d'états d'un objet (ou
d'un composant) :
en réponse aux interactions avec d'autres objets/composants ou
avec des acteurs.
118
1 Etat-transition et événement
L’état d’un objet est défini, à un instant donné,

par l’ensemble des valeurs de ses propriétés.
Seuls, certains états caractéristiques du
domaine étudié sont considérés.
Le passage d’un état à un autre état s’appelle
transition
Un événement est un fait survenu qui
déclenche une transition.
119
Etat-transition et événement
Un objet reste dans un état pendant une certaine durée.

La durée d’un état correspond au temps qui s’écoule
entre le début d’un état déclenché par une transition i et
à la fin de l’état déclenché par la transition i+1.
Une condition, appelée garde, peut être associée à une
transition.
Le formalisme de représentation d’état-transition est le
suivant :
Evt([Att]) [Condition(s)]/Action
Etat i Etat j
120
Etat d’un objet
Un état :
se caractérise par sa durée et sa stabilité,
est une conjonction instantanée des valeurs des
caractéristiques d'un objet.
Dans un DET, on distingue trois états :
- L’état initial :état avant la création de l’objet et
- L’état final :état après la destruction de l’objet.
- L’état intermédiaire Etat intermédiaire
121
2- Action et activité
Une action est une opération instantanée

qui ne peut pas être interrompue; elle est
associée à une transition.
Une activité est une opération d’une
certaine durée qui peut être interrompue,
elle est associée à un état d’un objet.
Etat 1 transition [condition]/action Etat 2
do/ activité 1 entry/ activité 2
122
3- Émission d’événement
Après exécution d’une opération
déclenchée par l’arrivée d’un événement,
un nouvel résultat peut être émis vers un
objet cible.
Le formalisme de représentation de
l’émission d’un événement est le suivant :
Etat 1 transition [condition]/action ^cible.événement Etat 2
do/ activité 1 entry/ activité 2
123
4-Représentation du diagramme état-
transition d’un objet
L’enchaînement de tous les états

caractéristiques d’un objet constitue le
digramme d’états. Un diagramme d’états débute
toujours par un état initial et se termine par un
ou plusieurs états finaux sauf dans le cas où le
diagramme d’états représente une boucle.
A un événement peut être associé un message
composé d’attributs.
124
Exemple
paiement
passer 1ere commande Client actif Client

Client douteux
prospect
non paiement limite financière dépassée
Client en
contentieux
Client
une année sans commande
inactif Client
supprimé
Fin du contentieux
125
5- Super-Etat (ou généralisation d’états)
état composite
Dans le cas où une succession d’états peut se répéter
plusieurs fois dans un même diagramme, il est
possible de considérer cette succession d’états comme
un super-état qui ne sera décrit qu’une seule fois dans
le détail et utilisé dans sa globalité plusieurs fois.
Un état composite est décomposé en sous-états,
chaque sous-état peut également être un composite.
Super-état
état 1 état 2
état 3
126
6- Exemple
ordre de récrutement d'un personnel [date prévisionnelle > date du jour] crée() En prévision
d'arrivée
prise en fonction
En activité départ de l'agence Parti
do/ renseigner la date d'arrivée à l'agence do/ renseigner la date de départ de la personne
127
Chapitre VII:
Diagrammes d’activités
Enseignant responsable : Achraf

Mtibaa
Introduction
Un diagramme d’activités (DA) représente le flot d’une
activité à l’autre.
Les activités :
sont des opérations non atomiques.
Elles finissent par exécuter une action composée de
calculs atomiques qui aboutissent à un changement de
l’état du système ou au retour d’une valeur.
129
Introduction
Le DA est une variante du DET :
Les DA utilisent beaucoup d’éléments du DET.
Dans le DET, les états et les transitions sont mis en avant

alors que dans le DA se sont les activités et les
transitions qui sont mises en avant.
Un DA correspond à un diagramme d’états vu sous

forme « procédurale » avec une mise en évidence des
actions/activités (d’où son nom).
130
Introduction
Un diagramme d’activités peut être rattaché à un CU, à
la réalisation d’une opération, ou à un processus
impliquant l’utilisation d’un ou de plusieurs objets.
En théorie, tous les mécanismes dynamiques pourraient
être décrits par un diagramme d'activités, mais seuls les
mécanismes complexes ou intéressants méritent d'être
représentés (faisant intervenir plusieurs objets, créant ou
modifiant divers objets, …).
Une activité : plusieurs opérations

DA : représente l’enchaînement des différentes
opérations
La fin d’une opération engendre le début d’une autre
131
Les états d’action (et d’activités)
Un état d’action modélise une étape dans l’exécution d’un
algorithme ou d’un flot.
C’est un état simplifié dans lequel figure une action d’entrée
et duquel part au moins une transition automatique vers un
autre état, déclenchée par la fin de l’action.
Etudier devis Index = recherche(e)+7
Exemples d’états
d’action
132
Les transitions
Une transition peut être automatique ou gardée.
Une transition automatique est :
franchie quand l’activité précédente est finie.
Une transition gardée est franchie :
quand l’activité précédente est finie et
si la condition est vérifiée.
Activité
Autre Activité
Transitions
automatiques 133
Les transitions
Demande
dossier
Recevoir
dossier
Compléter
dossier
Enregistrer
Transitions
automatiques 134
Les transitions
Transitions gardées
Examen candidature /i=0
Afficher(i)
[rejetée] [retenue] [i<10]/ i=i+1
[sinon]
Rédiger lettre Envoyer
de refus convocation
(I) (II)
Le niveau d’abstraction d’un DA peut être : de haut niveau (I) ou de bas

niveau (II) : algorithmique
135
Synchronisation
Il est possible de synchroniser les transitions à l'aide de barres
de synchronisation (BS)
Une BS permet d'ouvrir et/ou de fermer des branches
parallèles au sein d'un flot d'exécution.
Les transitions qui partent d'une BS ont lieu en même temps.
Activité 1 La fin de A1 engendre les

débuts simultanés de A2
et A3
Activité 2 Activité 3
136
Synchronisation
On ne franchit une barre de synchronisation qu'après
réalisation de toutes les transitions qui s'y rattachent.
Activité 1 Activité 2 Le début de A3 ne se fait que si
A2 et A1 soient terminées
Activité 3
Exemples :
Vérifier Dossier
Vérifier situation Enregistrer
assuré commande
Etudier dossier Préparer Préparer bon

facture de livraison
137
Les travées
Les diagrammes d’activités peuvent être découpés en travées
(ou couloirs d’activité) pour montrer les responsabilités au
sein d’un mécanisme ou d’une organisation.
Chaque activité appartient à une seule travée même si les
transitions peuvent passer d’une travée à l’autre.
Les travées permettent d'organiser un diagramme d'activités
Exemple
138
couloirs d’activité
Client Vendeur Magasinier
Commander produit
Traiter commande
Sortir articles
Expedier commande
Recevoir commande Facturer client
Payer Facture
Cloturer
commande
139
Flot d’objets
Il est possible de faire apparaître les objets dans un DA.
Les objets représentés sont ceux qui:
initient les actions,
utilisés par les actions ou
modifiés par les actions
Un objet utilisé par une action est visualisé par une flèche en
pointillés pointant vers l’état d’action.
Un objet modifié par une action est visualisé par une flèche en
pointillés orientée de l’état d’action vers l’objet.
Il est possible de montrer l’état d’un objet et les valeurs de ses
attributs modifiés.
140
Client Vendeur Magasinier
Commander produit
Traiter commande
Sortir articles
c:COMMANDE
[en cours] Expédier commande
Recevoir commande Facturer client c:COMMANDE

[traitée]
f:FACTURE
Payer Facture [due]
Cloturer
f:FACTURE
commande
[payée]
Remarque: DA = DCU + D. Classes + D. Objets + D. Collaboration + D. ET

141
Les DA pour la modélisation des processus métier
Un processus métier (business process) est l’ensemble des
activités internes d’un métier dont l’objectif est de fournir un
résultat observable et mesurable pour un utilisateur
individuel du métier.
Exemples : Gérer commandes, Gérer retours, …
La modélisation des processus métier fournit le contexte dans
lequel les fonctionnalités des systèmes d’information
(informatisés) seront définies et leur opportunité mesurée.
Les DA permettent de « formaliser » les processus métier.
Les travées permettent de diviser les états d’action (ou
d’activités) en groupes sur le DA, chaque groupe représentant
le département responsable de ces activités.
Exemple :
142
Client Service Ventes Magasinier Comptabilité
Demander retour
Attribuer num
retour
Expedier article
a:ARTICLE Recevoir article

[retourné]
Restocker article
Créditer
a: ARTICLE
compte
[disponible]
Processus métier : Gérer les retours 143

Les DA pour la modélisation des opérations
L’élément le plus courant auquel on peut attacher un DA est
l’opération.
Dans ce contexte, le DA est un organigramme des actions d’une

opération.
Le principal avantage d’un DA dans ce cas est que les éléments

qu’il contient sont sémantiquement liés à un modèle sous-jacent
riche.
144
Les DA pour la modélisation des
opérations
Pour modéliser une opération, il faut
Rassembler les abstractions impliquées dans cette opération
(paramètres, attributs de la classe d’appartenance de
l’opération, et certaines classes voisines.
Identifier les préconditions à l’état initial de l’opération et les
postconditions à son état final, ainsi que les invariants qui
doivent se maintenir pendant l’exécution de l’opération.
en commençant par l’état initial, spécifier les activités et les
actions.
Lorsque cela est nécessaire, utiliser les branchements
conditionnels pour les chemins conditionnels et les itérations.
Si l’opération appartient à une classe qui peut en activer
d’autres, utiliser la synchronisation. 145
Les DA pour la modélisation
des opérations
[pente=l.pente]
[sinon]
x= (l.delta-delta)/(pente-l.pente)
y=(pente*x)+delta
Retourner Point(x, y)
Retourner Point(0,0)
146
DET versus DA
DET DA
Représente l’évolution des Représente l’évolution de
objets l’exécution d’une opération
(CU)
Etat (objet) Etat(activité/opération)
Etats : initial / Final Etats : initial / Final

Transition (gardée / Transition (gardée /
automatique) automatique)
BS BS
147
Chapitre VIII
Diagrammes de composants et de
déploiement
Introduction
Les CU sont créés pour réfléchir au comportement
souhaité du système.
Le diagramme de classes précise le vocabulaire du

domaine.
Les diagrammes de séquence, de collaboration, d’états-

transitions et d’activités précisent la façon dont les
éléments du vocabulaire coopèrent pour réaliser ce
comportement.
Enfin, on transforme ces éléments de construction logiques

en éléments physiques comme des exécutables, des tables,
des fichiers et des documents. 149
Introduction
Ces éléments physiques sont modélisés en UML comme des
composants.
Les Composants peuvent être construits à partir de zéro ou
on peut réutiliser des composants plus anciens.
Un composant est une partie physique remplaçable d’un
système qui fournit la réalisation d’un ensemble
d’interfaces et s’y conforme.
Etudiant
150
Définition
Un composant peut être :
Un document quelconque (<<document>>)
Un programme exécutable (<<exécutable>>)
Un document contenant du code source ou des données
(<<fichier>>)
Une bibliothèque statique ou dynamique
(<<bibliothèque>>)
Une table d’une base de données relationnelle (<<Table>>)
151
Différences entre composants
et classes
Les composants sont similaires aux classes :
Ils ont un nom
Ils réalisent un ensemble d’interfaces
Ils participent à des relations de dépendance, de
généralisation et d ’association et à des interactions.
Ils peuvent être emboîtés et avoir des instances.
152
Différences entre composants
et classes
Il existe des différences importantes entre les composants et
les classes :
Les classes représentent des abstractions logiques alors
que les composants représentent des éléments physiques.
Un composant est l’implémentation physique d’un
ensemble d’éléments logiques, tels que les classes et les
collaborations.
Les classes peuvent avoir directement des attributs et des
opérations. En général, les composants comportent
seulement des opérations que l’on peut atteindre
uniquement par leur interface.
153
Composants et interfaces
Rappel : une interface est un ensemble d’opérations qui servent à
spécifier les services d’une classe ou d’un composant.
L’implémentation physique du système est décomposée en :
Interfaces qui représentent les principaux points de soudure du
système.
Composants qui réalisent les interfaces
Composants qui ont accès aux services à travers leurs interfaces.
Ce mécanisme permet de déployer un système dont les services sont
indépendants de l’emplacement et remplaçables.
Une interface réalisée par un composant s’appelle une interface
export.
Un composant peut fournir plusieurs interfaces exports
L’interface utilisée par un composant s’appelle une interface import.
154
Composants et interfaces
Exemple
Compte
Identificatio
n
Consultatio
n
Remarque :Il est possible d’avoir une interface utilisée ou
réalisée par un composant et retrouver la même interface
utilisée ou réalisée par les classes implémentées par le
composant.
Les composants d’un composant ainsi que les classes qu’il
réalise sont représentés dans le composant.
155
Diagramme de composants
Un diagramme de composants montre un ensemble de
composants et leurs relations.
Relation de dépendance entre composants :
Elle indique qu’un élément d’un composant fait appel
aux services offerts par les éléments d’un autre
composant.
Elle permet d’identifier les contraintes de compilation
Les composants peuvent être organisés en paquetages
définissant des sous-systèmes.
Un diagramme de composants traduit l’aspect
implémentation en proposant une structure en
composants et paquetages.
156
Buts :
Structurer l’application - Architectures
(fonctionnelle/logicielle)
Regrouper des éléments à forte cohérence dans des
«conteneurs» faiblement couplés (encapsulation de
haut niveau)
Faciliter la maintenance (évolution - adaptation -
debug)
Construction de frameworks (réutilisation)
157
Représente les concepts connus de l’exploitant pour
installer et dépanner le système :
Librairies dynamiques, instances de BD,
applications, progiciels, objets distribués,
exécutables, etc.
Utilisé aussi pour la configuration logicielle pour

montrer comment s’agencent
Fichiers sources, packages de code ou librairies
158
Concepts de base
Programmation
Cours
Cours
Professeur Etudiant
Diagramme de Composants
159
Exemple
DiceSystem Dice
DicePersist Displayable Vizualization
HighScore
Observable
PersistKit
Observer
Randomizer
Random
system
160
Diagramme de déploiement
Localisation des composants sur le réseau physique, et
structure des postes de travail
ingénieur d'exploitation, chargés d'installer les
modules du syst. et d'identification des causes
potentielles de pannes.
Ex. en C/S, on évaluera la répartition locale,
départementale et centrale.
déf. des postes de travail, des serveurs, connexions,
composants logiciels pour mesurer les échanges du
systèmes
161
<<3090>>
Serveur <<UNIX>>
pont filtrant Serveur
Comptabilité
WEB
Référence
DNS
<<LAN>> <<LAN>>
émulation SNA ethernet export
<<NT>> <<UNIX>>
<<LAN>> Serveur central <<LAN>> * PC
Serveur Central
ethernet central ethernet central Central
Bureautique SIVEx
<<WAN>>
internet Firewall
<<NT>>
Serveur Agence <<UNIX>>
Bureautique <<LAN>> Serveur Agence <<LAN>> * PC
ethernet agence SIVEx ethernet agence Agence
162
Terminal X Serveur
<<TCP/IP>>
Imprimante
<<RNIS>>
PC
163
Chapitre IX
Méthode de développement (AGILE)
Méthodologie…Méthode Agile
Définir la méthodologie du travail est une étape
décisive pour l’élaboration d’une application
informatique.
« Une méthode Agile est une approche itérative et

incrémentale pour le développement de logiciel.
Réalisée de manière très collaborative par des équipes
responsabilisées appliquant un cérémonial minimal,
qui produisent un logiciel de grande qualité dans un
délai contraint. Répondant aux besoins changeants des
utilisateurs. » [réf1 Claude Aubry « Scrum »]
165
Le processus Agile permet de s’orienter vers
l’opérationnel plutôt qu’accumuler une masse
d’informations difficile à traiter et qui fait perdre de
vue l’essentiel. Aussi, il cherche la collaboration avec le
client.
Le développement Agile tend à s’adapter aux

changements qui s’opèrent durant la réalisation du
projet plutôt que suivre un plan préétabli, qui ne
prend pas en compte l’évolution de la situation.
166
Scrum
« Scrum signifie mêlée au rugby. Scrum utilise les
valeurs et l'esprit du rugby et les adapte aux projets de
développement. Comme le pack lors d'un ballon porté
au rugby, l'équipe chargée du développement travaille
de façon collective, soudée vers un objectif précis.
Comme un demi de mêlée, le Scrum Master guide les
membres de l'équipe, les repositionne dans la bonne
direction et donne le tempo pour assurer la réussite du
projet. » [réf Scrum guide]
167
Scrum se caractérise par deux notions principales : le
backlog et les sprints.
Les Sprints sont des boites de temps durant lesquelles

des fonctionnalités sont réalisées.
le backlog du produit est le carnet contenant les

fonctionnalités à accomplir pendant la période du
travail
le backlog du sprint désigne les tâches qui doivent être

achevées pendant un sprint bien déterminé
168
Mécanisme de fonctionnement du Scrum
169
Scrum définit trois rôles dans l'équipe du travail. Nous
citons :
Product Owner : C'est le propriétaire du produit, une

personne qui porte la vision du produit à réaliser,
généralement c'est un expert dans le domaine
Scrum Master : C'est la personne qui doit assurer le

bon déroulement des différents sprints, et qui doit
impérativement maitriser Scrum
Le Scrum Team : L'équipe de Scrum est constituée des

personnes qui seront chargées d'implémenter les
différents besoins du client. Bien évidemment, cette
équipe sera constituée des personnes qui ont réalisé et
animé ce projet représenté par moi même. 170
Langage de Modélisation dans Scrum
La modélisation a comme objectif de fournir une

vision claire et cohérente des données manipulées dans
le système d'information.
UML peut être un langage de modélisation dans Scrum

vu son indépendance des langages de programmation,
son caractère polyvalent et sa souplesse qui le rendent
universel
171

Cours UML (Tous Les Chapitres)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML (Tous Les Chapitres)

Transféré par

Droits d'auteur :

Formats disponibles

Cours : Modélisation Orientée

Objet (MOO avec UML)

Responsable : Achraf MTIBAA

Responsable : Achraf MTIBAA

Approche Fonctionnelle (60-70)

Le monde est composé d’entités qui « collaborent »

roue roue Freins

• L’approche objet consiste à résoudre un problème en termes

• Ces objets sont des abstractions des objets réels

Approche classique Approche objets

Encapsulation Inte rfac e

Données Traitements Echange de messages

Cours, Diplôme, ... Enseignant Etudiant Année, ...

Analyse : Modéliser le domaine d’activité du client.

Conception : Choisir l’architecture du système et définir la

Implémentation : Définir l’algorithme de chaque programme

Décrire les objets : Contrôler les

Modèle fonctionnel Décrire le fonctionnement

UML est un langage formel (ou pseudo-formel)

UML se base sur une notation graphique

UML est ouvert et extensible

11/ 97 Adoption par UML 1.1

06/ 96 UML 0.9

Unified Method 0.8

Booch 91 OMT-1 OOSE

Modélisation objet avec UML

Responsable : Achraf MTIBAA

Les cas d’utilisation (use cases) ont été formalisés par

Ensemble des besoins

Les cas d’utilisation partitionnent Cahier des charges

Les acteurs principaux…les personnes qui utilisent les

Les cas d’utilisation :

Quand un acteur interagit avec le système:

L'ensemble des cas d’utilisation décrit les objectifs du système

Une fois identifiés, les acteurs doivent être décrits d’une

Exemple : On désire représenter par un diagramme de CU les virements bancaires

Virement Client Local

Et voici le point d’extension :

Responsable : Achraf MTIBAA

Généralement, on y trouve pour chaque cas d’utilisation :

Description des Enchaînements :

1. Ce CU commence quand un client arrive à la

6. Le caissier annonce le montant total au client.

7. Le client choisit le type de paiement :

9. Le caissier donne le ticket de caisse au client.

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

Le scénario reprend au point 2.

Responsable Initialier la caisse

Prendre en compte coupons

Responsable : Achraf MTIBAA

Classe = propriétés + méthodes + instanciation

LES ATTRIBUTS ET LES OPÉRATIONS :

Visibilité NomAttribut [[Multiplicité] : Type [=ValeurInitiale]

Visibilité = type d'accessibilité :

Comment justifier la non obligation du nom de l’association :

Association en forme verbale active Association en forme verbale Passive

Rôle 1 : le rôle joué par Classe 1 dans l’association

COUVERTURE LIVRE CHAPITRE

Remarque : une classe généralisée peut être spécialisée selon ≠ critères

Contraintes et propriétés de la généralisation :

PERSONNE 1 0..* COMPTE

La collection des comptes d’une personne est triée

Cette contrainte permet d’éviter l’introduction de classes artificielles