CoursUML-SlimMesfar-Total

1
Conception des Systèmes d’Information
Langage de modélisation UML
Unified Modeling Language
Dr. Slim Mesfar
Mail : mesfarslim@yahoo.fr

Ch1 : Introduction  Notion de système d’information
 Présentation de UML2
 Présentation des différentes étapes de développement logiciel
Chapitre 2 :
Analyse fonctionnelle
 Diag de contexte statique
 Diag de CU avec description textuelle des CU
Chapitre 3 :
Analyse dynamique
 Diag de contexte dynamique
 Diag de séquence système
 Diag d'activités (modélisation processus métier et CU)
Chapitre 4 :
Analyse statique
 Diag de classes d’analyse (+ contraintes, stéréotypes)
 Diag d’objets
 Diag de package
Chapitre 5 :
Conception
 Diag de séquence objet (stéréotypes de Jacobson)
 Diag de classes de conception (navigabilité, traduction de l’analyse)
 Diag de communication / de collaboration
 Diag état transition
 Diag de composants
 Diag de déploiement
Chapitre 6 :
Implémentation
 Génération à partir d’un diagramme de classe :
- D’une base de données
- Code source JAVA/C++…
2
Plan du cours

3
Les systèmes d’information
• Des exemples de SI
– Une application de gestion de stocks d’un
supermarché
– Un site web de vente en ligne
– Une bibliothèque numérique
– Un portail avec intranet pour une école/ institut
– ...
Introduction générale

4
• Qu’est ce qu’un SI ?
un SI est un ou plusieurs logiciels manipulant un
ensemble d’informations structurées et cohérentes.
Par exemple : l’intra d’une école supérieure : des
cours, des élèves, des profs, des horaires, des
projets, des groupes, des notes, etc. On peut les
consulter, les créer, les modifier, les détruire.
� Plus largement, aujourd’hui, tout logiciel peut être
considéré comme un système d’information.

5
• Autrement dit :
un SI est un ensemble organisé de ressources :
matériel, logiciel, personnel, données, procédures…
permettant d’acquérir, de traiter, de stocker des
informations (sous formes de données, textes,
images, sons, etc.) dans et entre des organisations.
� Nécessité de collaboration entre les intervenants
pour garantir la bonne conduite du processus de
développement d’un SI
� Nécessité d’un langage de communication unifié

6
Sommaire
• Historique
• La Modélisation
• Les Diagrammes UML
Chapitre 1 : Introduction et historique d’UML

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

9
OMT
• Object Modeling Technique
– Livre de James Rumbaugh (1991)
• 3 axes
– Statique : identifie les propriétés des objets et leurs
liaisons avec les autres objets
– Dynamique : définit le cycle de vie des objets :
comportement des objets, les différents états par
lesquels ils passent, et les événements déclanchant
ces changements d’états
– Fonctionnel : précise les fonctions réalisées par les
objets par l’intermédiaire des méthodes.
James Rumbaugh
Historique

10
OOSE
• Object Oriented Software Engineering
– Souvent appelée Objectory
• 5 modèles
– Description des besoins
– Analyse
– Conception
– Implantation
– Test
• 3 types d ’objets
– entités
– contrôles
– interfaces
• Notion de Cas d’Utilisation: Use Cases
Ivar Jacobson
Historique

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

12
Naissance d’UML
• 1993-1994: Booch’93, OMT-2
– Les 2 méthodes sont leaders sur le marché
– Elles sont de plus en plus proches
• Octobre 1994
– J. Rumbaugh (OMT) rejoint G. Booch
– Annonce de l’unification des deux méthodes
• Octobre 1995: Méthode Unifiée v0.8
• Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint
à son tour J. Rumbaugh et G. Booch
• Janvier 97 : Soumission à l’OMG de la version UML 1.0
– OMG: Object Management Group
• Organisme à but non lucratif fondé en 1989
• Plus de 700 entreprises y adhèrent
• Septembre 97 : UML 1.1
Historique

13
Conclusion
• UML: Prendre le meilleur de chacune des méthodes
– OOSE (Jacobson): Use Cases
– OMT (Rumbaugh): Analyse
– Booch: Conception, Architecture
• Depuis 1997, UML est dans le domaine public
• A partir Juin 2004 : Version UML 2.x avec divers apports :
– Plus de possibilités de représentation, de précision et de capacités de modélisation
(ex : diagrammes de séquence totalement refondus)
– Meilleur support de l’ingénierie des systèmes
– Possibilité de définir et de raffiner les systèmes jusqu’aux couches logicielles
– …
� Plus proche des MDAs
• Actuellement : Version UML 2.4.1 (depuis Aout 2011)
La Convergence vers UML
Historique

15
UML ?
• Est une notation, pas une méthode
• Est un langage de modélisation objet
• Convient à tous les langages objets
– SmallTalk
– C++ (Héritage multiple)
– Java (Interface)
Définition
La Modélisation

16
Un modèle permet de :
– mieux comprendre le système à développer,
– visualiser le système comme il est ou comme il devrait
l'être,
– valider le modèle vis à vis des clients,
– spécifier les structures de données et le comportement
du système,
– fournir un guide pour la construction du système,
– documenter le système et les décisions prises.
La Modélisation
A quoi sert la modélisation?

17
Qu’apporte la modélisation objet?
• plus grande indépendance du modèle par rapport
aux fonctionnalités demandées
• des fonctionnalités peuvent être rajoutées ou
modifiées sans que le modèle objet change
• plus proche du monde réel
La Modélisation
A quoi sert la modélisation?

18
La Modélisation
Objectifs d’UML
•Représenter des systèmes entiers,
•Créer un langage de modélisation utilisable à la fois par les
humains et les machines,
•Rechercher un langage commun qui est utilisable par toutes
les méthodes et adapté à toutes les phases du développement
Pourquoi UML?

19
La Modélisation
UML ?
�UML n’est pas une méthode
�UML est un langage de modélisation objet
�UML est adopté par toutes les méthodes objet
�UML est une norme dans le domaine public
•visualiser
•spécifier
•construire
•documenter
•S.I des entreprises
•Banques et les services financiers
•Télécommunications
•Transport
•Défense et aérospatiale
•Scientifique
•Applications distribuées par le WEB
Utilisé
pour
Utilisé
dans

20
Architecture 4+1
La Modélisation
• Vue des cas d'utilisation : c'est la description du modèle
« vue » par les acteurs du système. Elle correspond aux besoins
attendus par chaque acteur (c'est le QUOI et le QUI).

21
Architecture 4+1
La Modélisation
•Vue logique : c'est la définition du système vu de l'intérieur. Elle
explique comment peuvent être satisfaits les besoins des acteurs
(c'est le COMMENT).
•Vue d'implémentation : cette vue définit les dépendances entre
les modules.
•Vue de comportement ou des processus : c'est la vue
temporelle et technique, qui met en œuvre les notions de tâches
concurrentes, stimuli, contrôle, synchronisation, etc.
•Vue de déploiement : cette vue décrit la position géographique
et l'architecture physique de chaque élément du système (c'est le
OÙ).

22
Axes de Modélisation avec UML
Statiques
DynamiquesFonctionnels
Diagramme de Classes
Diagramme d’Objets
Diagramme de Composants
Diagramme de Déploiement
Diagramme de paquetages
Diagramme de structure composite (UML 2.x)
Diagramme de Use Case
Diagramme de Séquence
Diagramme de communication (UML 2.x)
Diagramme global d’interaction (UML 2.x)
Diagramme de temps (UML 2.x)
Diagramme d'Etats-Transitions
Diagramme d'activités
Cycle de Développement
La Modélisation

23
Modélisation fonctionnelle
La Modélisation
• Diagramme des cas d'utilisation (use-cases) : il permet
d'identifier les possibilités d'interaction entre le système et les
acteurs (intervenants extérieurs au système), c'est-à-dire toutes
les fonctionnalités que doit fournir le système.

24
Modélisation statique
La Modélisation
•Diagramme de classes : il représente les classes intervenant dans
le système.
•Diagramme d'objets : il sert à représenter les instances de classes
(objets) utilisées dans le système.
•Diagramme de composants : il permet de montrer les composants
du système d'un point de vue physique, tels qu'ils sont mis en œuvre
(fichiers, bibliothèques, bases de données...)
•Diagramme de déploiement : il sert à représenter les éléments
matériels (ordinateurs, périphériques, réseaux, systèmes de
stockage...) et la manière dont les composants du système sont
répartis sur ces éléments matériels et interagissent entre eux.

25
Modélisation statique
La Modélisation
•Diagramme des paquetages : un paquetage étant un conteneur
logique permettant de regrouper et d'organiser les éléments dans le
modèle UML, le Diagramme de paquetage sert à représenter les
dépendances entre paquetages, c’est-à-dire les dépendances entre
ensembles de définitions.
•Diagramme de structure composite (UML 2.x) : permet de
décrire sous forme de boîte blanche les relations entre composants
d'une classe.

26
Modélisation dynamique
La Modélisation
•Diagramme de séquence : représentation séquentielle du
déroulement des traitements et des interactions entre les éléments du
système et/ou de ses acteurs.
•Diagramme de communication (UML 2.x) : représentation
simplifiée d'un diagramme de séquence se concentrant sur les
échanges de messages entre les objets.
•Diagramme global d'interaction (UML 2.x) : permet de décrire
les enchaînements possibles entre les scénarios préalablement
identifiés sous forme de diagrammes de séquences (variante du
diagramme d'activités).

27
Modélisation dynamique
La Modélisation
• Diagramme de temps (UML 2.x) : permet de décrire les
variations d'une donnée au cours du temps.
•Diagramme états-transitions : permet de décrire sous forme de
machine à états finis le comportement du système ou de ses
composants.
• Diagramme d'activités : permet de décrire sous forme de flux ou
d'enchaînement d'activités le comportement du système ou de ses
composants.

28
Cycle de développement du
logiciel

� Expression des besoins
� Spécification
� Analyse
� Conception
� Implémentation
� Validation
� Tests de vérification
� Maintenance et évolution
Les différentes étapes du développement logiciel

� L’ Expression des besoins
- Interview de l’expert métier
� La Spécification
– Ce que le système doit être et comment il peut être utilisé.
� L’Analyse
– L’objectif est de déterminer les éléments intervenant dans le
système à construire, ainsi que leur structure et leurs
relations . Elle doit décrire chaque objet selon 3 axes :
 Axe fonctionnel : savoir-faire de l’objet.
 Axe statique : structure de l’objet.
 Axe dynamique : cycle de vie de l’objet au cours
de l’application (États et messages de l’objet).
Ces descriptions ne tiennent pas compte de
contraintes techniques (informatique).

� La Conception :
Elle consiste à apporter des solutions techniques
aux descriptions définies lors de l’analyse :
• architecture technique
• performances et optimisation
• stratégie de programmation
On y définit les structures et les algorithmes.
Cette phase sera validée lors des tests.
� L’implémentation
C’est la réalisation de la programmation.

� La Validation
Le développement d’une application doit être lié à
un contrat ayant une forme d’un cahier des charges, où
doivent se trouver tous les besoins de l’utilisateur. Ce
cahier des charges doit être rédigé avec la collaboration de
l’utilisateur et peut être par ailleurs complété par la suite.
Tout au long de ces étapes, il doit y avoir des
validations en collaboration également avec l’utilisateur.
Une autre validation doit aussi être envisagée lors
de l’achèvement du travail de développement, une fois
que la qualité technique du système est démontrée. Elle
permettra de garantir la logique et la complétude du
système.

� Les tests de vérification
Ils permettent de réaliser des contrôles pour la
qualité technique du système.
Il s’agit de relever les éventuels défauts de
conception et de programmation (revue de code, tests
des composants,...).
Il faut instaurer ces tests tout au long du cycle de
développement et non à la fin pour éviter des reprises
conséquentes du travail (programmes de tests robustes ;
Logiciels de tests).

� Maintenance et évolution
Deux sortes de maintenances sont à considérer :
 Une maintenance corrective, qui consiste à
traiter les “buggs ”.
 Une maintenance évolutive, qui permet au
système d’intégrer de nouveaux besoins ou des
changements technologiques.

Le développement d’un logiciel repose sur les activités
suivantes :
� Détermination des besoins (quel est le cahier des
charges ?)
� Analyse (que fera le logiciel ?)
� Conception (comment le fera-t-il ?)
� Implémentation (quel code exécutera-t-il ?)
� Test (sera-t-il conforme à l’analyse et au cahier des
charges ?)
Une organisation de ces activités forme un processus de
développement.
Résumé des différentes étapes du développement logiciel

36
Chap 2 :

37
Permet d’élaborer le cahier des charges ou le document
de spécification des besoins du logiciel
� permet de structurer les besoins des utilisateurs,
les objectifs correspondants d'un système
� On recense, l'ensemble des fonctionnalités d'un
système en examinant les besoins fonctionnels de
chaque acteur.

38
Détermination des besoins
Besoins (« requirement ») = exigence de ce que le système
devrait satisfaire
� Détermination des besoins attendus par chaque acteur :
� le QUI ?
� le QUOI ?

39
Détermination des besoins
• Besoins fonctionnels
– À quoi sert le système
– Ce que doit faire le système, les fonctions utiles
– Description des données manipulées
• Besoins non fonctionnels : des restrictions ou des
contraintes qui pèsent sur un service du système
– description des contraintes,
– Pour chaque fonction et pour le système global, il est possible
d’exprimer différents types de contraintes.
Exemple : portabilité, compatibilité, fiabilité, sécurité, …
Les différents types de besoins

40
Méthodologie :
1. Identifier les acteurs,
a. humains ou systèmes connexes
b. principaux ou secondaires
2. Etablir le diagramme de contexte statique
3. Identifier les cas d'utilisation (UC)
4. Description des UC
a. graphiquement
b. textuellement

41
2.1. Les diagrammes de
contexte statique

42
Le diagramme de contexte statique
• Le diagramme de contexte statique permet de positionner le
système dans son environnement selon un point de vue matériel.
• Le système est donc décrit physiquement est non pas en termes
de fonctionnalités
• De plus, pour chaque type d’élément matériel extérieur au
système, il est précisé le nombre minimal et maximal, appelés
cardinalités, qui sont mis en jeu

43
cas d’utilisation

• Le diagramme de cas d’utilisation décrit les
fonctionnalités d’un système d’un point de vue utilisateur,
sous la forme d’actions et de réactions ; l’ensemble des
fonctionnalités est déterminé en examinant les besoins
fonctionnels de tous les utilisateurs potentiels.
• Le but est d’identifier :
– les catégories d’utilisateurs : chacune d’entre elles, appelée acteur,
est susceptible de mettre en oeuvre une ou plusieurs fonctionnalités
du système ;
– les besoins du système : chaque fonctionnalité, appelée cas
d’utilisation, doit répondre à l’un des besoins nécessités par une
ou plusieurs catégories d’utilisateurs.
44
Le diagramme des cas d’utilisation (Use cases)

• Le diagramme des cas d’utilisation se base sur le
cahier des charges pour être construit ; il fait donc
partie, en termes de gestion de projet, de la
spécification du système.
• Processus de construction du diagramme de cas
d’utilisation
45

46
Les diagrammes UML

47
1. Acteur : entité (humain ou machine) externe qui agit sur le système
(opérateur, composant interne…) :
Identification des acteurs
•permettant d’en déterminer les limites
•jouant un rôle par rapport à lui
•déclenchant un stimulus initial entraînant une réaction du système
•Un acteur est décrit précisément
en quelques lignes :

48
1. Acteur
Identification des acteurs
4 catégories d’acteurs :
•acteurs principaux : personnes utilisant les fonctions principales du
système. Dans le cas d'un distributeur de billets, il s'agit des clients.
•acteurs secondaires : personnes qui effectuent des tâches administratives ou
de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la
personne qui recharge la caisse du distributeur.
•matériel externe : dispositifs matériels autres que les ordinateurs comme les
périphériques. Dans le cas d'un distributeur de billets, il s'agit de
l'imprimante, du lecteur de carte, de la trieuse de billets.
•autres systèmes : les systèmes avec lesquels le système interagit. Dans le
cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère
l'ordinateur central qui relie tous les distributeurs.

49
La Modélisation des besoins en UML
2. Use case : ensemble d’actions réalisées par le système, en
réponse à une action d’un acteur. L’ensemble des uses cases décrit
les objectifs (le but) du système.
Exemple. identification, retrait de liquide.
• Scénarios d’un CU
Séquence particulière de messages dans le CU pendant une interaction
particulière (“chemin” dans le cas d’utilisation),

50
Description détaillée de chaque cas d’utilisation
� Chaque cas d ’utilisation doit être décrit en détail
� Commencer par les CU prioritaires
� Description utile pour la suite du développement
� Description détaillée plus ou moins formelle
� langue naturelle mais structurée,
� vocabulaire précis,
� ...
Le diagramme des cas d’utilisation (Use case)

51
Informations à décrire
� Quand le CU commence, pré-conditions
� Quand le CU se termine, post-conditions
� Le chemin correspondant au déroulement normal
� Les variantes possibles et les cas d’erreurs (les points d’extensions)
� Les interactions entre le système et les acteurs
� Les informations échangées
� Les éventuels besoins non fonctionnels

52
Exemple de description détaillée d’un CU
Précondition :
Le distributeur contient des billets, il est en attente d ’une
opération, il n’est ni en panne, ni en maintenance
Début : lorsqu’un client introduit sa carte bancaire dans le
distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l ’argent a pu être retiré, la somme d’argent sur le
compte est égale à la somme d’argent qu’il y avait avant,
moins le montant du retrait. Sinon la somme d ’argent sur
le compte est la même qu’avant.
Retirer
de l’Argent
Retirer
de l’Argent

53
Retirer
de l’Argent
Scénario nominal :
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifie si la carte est valide
(3) le système demande au client de taper son code
(4) le client tape son code confidentiel
(5) le système vérifie que le code correspond à la carte
(6) le client choisi une opération de retrait
(7) le système demande le montant à retirer
…
Variantes :
(A) Carte invalide : au cours de l ’étape (2) si la carte est
jugée invalide, le système affiche un message d ’erreur,
rejète la carte et le cas d ’utilisation se termine.
(B) Code erroné : au cours de l ’étape (5) ...

54
Contraintes non fonctionnelles :
(A) Performance : le système doit réagir dans un délai
inférieur à 4 secondes, quelque soit l’action de l ’utilisateur.
(B) Résistance aux pannes : si une coupure de courant
ou une autre défaillance survient au cours du cas
d ’utilisation, la transaction sera annulée, l ’argent ne sera
pas distribué. Le système doit pouvoir redémarrer
automatiquement dans un état cohérent et sans
intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer
plus de 1000 retraits d ’argent simultanément
...
Retirer
de l’Argent
Retirer
de l’Argent

55
•Relations entre les cas d’utilisation
-« utilise» ou « include »: définit le fait qu’un use case contient le
comportement défini dans un autre use case.
Cas d'utilisation B
<< Utilise >>
Cas d'utilisation A
-« étend » ou « extend »: définit le fait qu’une instance d’un use case peut
être augmentée avec un comportement quelconque défini dans un use case
étendu
Cas d'utilisation A Cas d'utilisation B
<< Etend >>
- « généralisation » Un cas A est une généralisation d’un cas B si B
est un cas particulier de A.

56
•Relations entre les cas d’utilisation

57
•Relation d’héritage entre les acteurs
secrétaire
médecin
Consulter fiche patient
Remplir fiche
consultation
créer fiche patient

Erreurs usuelles - rôles
58

Erreurs usuelles - factorisation
59
Gérer
client

61
contexte dynamique

62
Le diagramme de contexte dynamique
• Le diagramme de contexte dynamique permet de positionner
le système dans son environnement selon le point de vue des
communications.
• Il reprend les éléments du contexte statique et précise les
échanges d’informations qui sont réalisés entre le système et les
éléments matériels extérieurs au système.
• Le système est donc décrit physiquement et logiquement.

63
séquence système

64
Le diagramme de séquence
Les diagrammes UML
Deux différents types de diagrammes de séquence :
• Diagramme de séquence système au niveau de l’analyse
dynamique
�représentation des différents scénarios des cas d’utilisation
� interaction entre les acteurs et le système (une boite noire) selon un
ordre chronologique
•Diagramme de séquence détaillé au niveau de la conception
� représentation des collaborations entre des objets pour la réalisation d’un
cas d’utilisation, selon un point de vue temporel.
� représentation de la chronologie des envois de messages entre les objets.
S. Mesfar

65
Les diagrammes UML
Du diagramme de séquence système à la conception
S. Mesfar

66
Les diagrammes UML
• Il y a autant de diagrammes de séquence qu’il y a de scénarios
• Un Scénario montre une séquence particulière d’interactions
entre objets, dans un seul contexte d’exécution du système
• Un scénario peut être vu comme une réponse à un besoin ou
une partie d’un besoin du diagramme des Uses Cases.
• On y fait intervenir des objets / système complet, des
messages et des événements
Représentation de Scénarios
objet1 : Classe objet2 : Classe
Objets de type Classe
S. Mesfar

67
Les diagrammes UML
�l'ordre d'envoi d'un message est déterminé par sa position sur
l'axe vertical du diagramme ; le temps s'écoule "de haut en bas"
de cet axe : La ligne de vie. La disposition des objets sur l'axe
horizontal n'a pas de conséquence particulière sur la sémantique
du diagramme.
S. Mesfar

Numérotation des messages
• Les messages peuvent être numérotés séquentiellement
A B
1: Message
A B
1: Message 1
C
1.1: message 2
Les diagrammes UML
S. Mesfar 68

Durée d’activation(période d’activation)
– correspond au temps pendant lequel un objet effectue une action
– est représentée par une bande rectangulaire :
• Le long de la ligne de vie de l’objet
• Dont les extrémités représentent le début et la fin de l’activité.
Un objet
Durée
d’activation
Objet 1 Objet 2
Remarque : souvent quand l’objet est en activité continue, on néglige
la représentation de cette période d’activation
Les diagrammes UML
S. Mesfar 69

70
Les diagrammes UML
Notation Graphique
Objet
S. Mesfar
Appelant: Ligne téléphonique: Appelé:
décroche()
tonalité
numérotation()
indication sonnerie
indication sonnerie()
décroche

Transmission de données
• Les messages peuvent véhiculer des données entre les acteurs et le
système ou entre les objets
A B
1: Message (donnee1, donnee2)
Les diagrammes UML
S. Mesfar 71

72
Les diagrammes UML
Représentation graphique Système comme une boite noire
S. Mesfar

73
Les diagrammes UML
•Spécificités des diagrammes de séquences
�un objet peut s’envoyer un message,
Un objet:
Message
réflexif
S. Mesfar

74
Les diagrammes UML
Représentation graphique enrichie
S. Mesfar

75
Les diagrammes UML
•Spécificités des diagrammes de séquences
�un message peut entraîner la création ou la
destruction d’autres objets,
Créer
Détruire
Un objet:
Un autre
objet:
S. Mesfar

Les types de messages
Dans un diagramme de séquences trois principaux types de
messages sont distingués :
•message synchrone (flèche avec une extrémité pleine)
Bloque l’émetteur jusqu'à prise en compte du message par le destinataire.
Le flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient
passif et le récepteur actif) à la prise en compte du message.
•message asynchrone (flèche avec une extrémité non pleine)
N'interrompt pas l'exécution de l’émetteur. Le message envoyé peut être
pris en compte par le récepteur à tout moment ou ignoré (jamais traité).
Les diagrammes UML
S. Mesfar 76

Les réponses aux messages
Dans le cas des envois synchrones,
le retour peut être implicite en fin
d'activités et ne nécessitera pas de
représentation particulière
Dans le cas des envois asynchrones,
le retour doit être explicite
Les diagrammes UML
S. Mesfar 77

Les types de messages
Sd diagramme1
Objet1: Objet2: Objet3::client
Message 1( )
Message 2( )
Message 3( )
Message 5( )
Message 6( )
Retour Message 3( )
Message
synchrone
Message
asynchrone
Message 4( )
Activation
d’un objet
Les diagrammes UML
S. Mesfar 78

Exemple
Les diagrammes UML
S. Mesfar 79

Comité de
programme
Comité
d'organisation
PAPIERAuteur RAPPORTLecteur
Appel( )
Enregistrer le papier
Papier enregistré
Affecter_lecteur( )
Note( )
Rédiger( )
Envoi
Enreg_papier(true)
Evalué( )
Papier évalué
Exemple2
Les diagrammes UML
S. Mesfar 80

Exemple3
Les diagrammes UML
S. Mesfar 81

Autres types de messages
Dans un diagramme de séquence, il peut y avoir
d’autres types de messages tels que:
Les diagrammes UML
•message minuté (timeout) : Bloque l'expéditeur pendant un
temps donné (qui peut être spécifié dans une contrainte), en
attendant la prise en compte du message par le récepteur.
L'expéditeur est libéré si la prise en compte n'a pas eu lieu
pendant le délai spécifié.
• message dérobant : Le message est mis en attente dans une
liste d'attente de traitement chez le récepteur.
S. Mesfar 82

S. Mesfar 83
Les diagrammes UML
Pseudo-code
L’ajout de pseudo-code sur la partie gauche du diagramme
permet la représentation des boucles et des branchements
alternatifs
� les diagrammes de séquence peuvent représenter la forme
générale d’une interaction , au-delà de la seule prise en
compte d’un scénario particulier
�

S. Mesfar 84
Les diagrammes UML
Pseudo-code
�

Diagramme de séquences :
Fragment d’interaction ou fragments combinés
Un fragment d’interaction se représente globalement
comme un diagramme de séquence dans un rectangle avec
indication dans le coin à gauche du nom du fragment.
Un port d’entrée et un port de sortie peuvent être indiqués
pour connaître la manière dont ce fragment peut être relié au
reste du diagramme. Dans le cas où aucun port n’est indiqué
c’est l’ensemble du fragment qui est appelé pour exécution
Les diagrammes UML
S. Mesfar 85

Fragment d’interaction
Les diagrammes UML
S. Mesfar 86

Un fragment d’interaction dit combiné correspond à
un ensemble d’interactions auquel on applique un
opérateur.
Un frag combiné se représente globalement comme un
diagramme de séquence avec indication dans le coin à
gauche du nom de l’opérateur.
13 opérateurs ont été définis dans UML : alt, opt, loop,
par, strict/weak, break, ignore/consider, critical, negative,
assertion et ref.
Les diagrammes UML
S. Mesfar 87

L’opérateur alt :
correspond à une instruction de test avec une ou plusieurs alternatives
possibles. Il est aussi permis d’utiliser les clauses de type sinon.
Les diagrammes UML
S. Mesfar 88

L’opérateur opt :
L’opérateur opt (optional) correspond à une instruction de test sans
alternative (sinon).
Les diagrammes UML
S. Mesfar 89

L’opérateur loop
correspond à une instruction de boucle qui permet d’exécuter une
séquence d’interaction tant qu’une condition est satisfaite.
Il est possible aussi d’utiliser une condition portant sur un nombre
minimum et maximum d’exécution de la boucle en écrivant : loop min,
max. Dans ce cas, la boucle s’exécutera au minimum min fois et au
maximum max fois
Les diagrammes UML
S. Mesfar 90

L’opérateur par
L’opérateur par (parallèle) permet de représenter deux séries d’interactions
qui se déroulent en parallèle.
Les diagrammes UML
S. Mesfar 91

Les opérateurs strict et weak sequencing
Les opérateurs strict et weak permettent de représenter une série
d’interactions dont certaines s’opèrent sur des objets indépendants :
� L’opérateur strict est utilisé quand l’ordre d’exécution des opérations
doit être strictement respecté.
� L’opérateur weak est utilisé quand l’ordre d’exécution des opérations
n’a pas d’importance.
Les diagrammes UML
S. Mesfar 92

Les opérateurs strict et weak sequencing
Les diagrammes UML
S. Mesfar 93

Les opérateurs break
L’opérateur break permet de représenter une situation exceptionnelle
correspondante à un scénario de rupture par rapport au scénario général. Le
scénario de rupture s’exécute si la condition de garde est satisfaite.
Les diagrammes UML
S. Mesfar 94

Les opérateurs ignore et consider
Les opérateurs ignore et consider sont utilisés pour des fragments
d’interactions dans lesquels on veut montrer que certains messages peuvent
être soit absents sans avoir d’incidence sur le déroulement des interactions
(ignore), soit obligatoirement présents (consider).
Les diagrammes UML
S. Mesfar 95

Les opérateurs ignore et consider
Les diagrammes UML
S. Mesfar 96

Les opérateurs critical
L’opérateur critical permet d’indiquer qu’une séquence d’interactions
ne peut être interrompue compte tenu du caractère critique des
opérations traitées.
On considère que le traitement des interactions comprises dans la
séquence critique est atomique.
Les diagrammes UML
S. Mesfar 97

L’opérateur critical
Les diagrammes UML
S. Mesfar 98

Les opérateurs neg
L’opérateur neg (negative) permet d’indiquer qu’une séquence d’interactions
est invalide.
Les diagrammes UML
S. Mesfar 99

Les opérateurs assert
L’opérateur assert (assertion) permet d’indiquer qu’une séquence
d’interactions est l’unique séquence possible en considérant les messages
échangés dans le fragment.
Toute autre configuration de message est invalide.
Les diagrammes UML
S. Mesfar 100

Les opérateurs ref
L’opérateur ref permet d’appeler une séquence d’interactions décrite par
ailleurs constituant ainsi une sorte de sous-diagramme de séquence.
Les diagrammes UML
S. Mesfar 101

102
3.3. Les diagrammes
d'activités

Digramme d'activités
UML permet de représenter graphiquement le comportement d'une
méthode ou le déroulement d'un cas d'utilisation, à l'aide de
diagrammes d'activités (une variante des diagrammes d'états-
transitions).
• Une activité représente une exécution d'un mécanisme, un
déroulement d'étapes séquentielles.
• Le passage d'une activité vers une autre est matérialisé par une
transition.
• Les transitions sont déclenchées par la fin d'une activité et
provoquent le début immédiat d'une autre (elles sont
automatiques).
Le diagramme d'activités
Les diagrammes UML

Digramme d'activités
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.
• Buts :
1. Décrire le comportement générique d’un cas d’utilisation
2. Décrire en détail le comportement d’une opération
3. Modéliser les processus métiers
Les diagrammes UML

Le diagramme d’activités est organisée par rapport aux
actions et destinée à représenter le comportement interne d’une
opération ou d’un cas d ’utilisation.
Mesurer température
Chauffer Refroidir
AérerArrêter chauffage
[trop froid] [trop chaud]
« synchronisation »
Les diagrammes UML

• Exemple de Diagramme d'activités :
Les diagrammes UML

Le but du diagramme d'activités
• Diagramme d'activités est utilisé pour:
– Modéliser un workflow dans un use case ou entre
plusieurs use cases.
– Spécifier une opération (décrire la logique d’une
opération)
• Le diagramme d'activités est le plus approprié
pour modéliser la dynamique d’une tâche, d’un
use case lorsque le diagramme de classe n’est
pas encore stabilisé.
Les diagrammes UML

Notion du diagramme d'activités
Diagramme d'activités =
• ensemble d'activités liés par:
– Transition (sequentielle)
– Transitions alternatives (conditionnelle)
– Synchronisation (disjonction et conjonctions
d'activités)
– Itération
• + 2 états: état de départ et état de terminaison
• Swimlanes: représente le lieu, le responsable des
activités.
Les diagrammes UML

•Etat de départ
•Etat de terminaison
•Transition
•Transition Alternative
[ ] [ ]
Les diagrammes UML

Synchronisation disjonctive et
conjonctive
Les diagrammes UML

Itération
Les diagrammes UML

Exemple de Diagramme d'activités :
Swimlanes / partitions
Ou couloirs d’activités
Les diagrammes UML

Les diagrammes UML
Exemple de Diagramme d'activités :

Les nœuds de contrôle
• Il existe plusieurs types de nœuds de contrôle:
– nœud initial(initial node);
– nœud de fin d'activités(final node);
– nœud de décision(decision node);
– nœud de fusion(merge node);
– nœud de bifurcation(fork node);
– nœud d’union(join node).
Les diagrammes UML

Les diagrammes UML

diagramme d'activités
• Partitions /
swimlanes
ou couloirs
d’activités
Les diagrammes UML

118
Analyse statique
L’analyse statique permet de représenter l’ensemble des
classes, d’interfaces et de paquetages ainsi que leurs
relations.
• Une classe décrit un ensemble d’objets (instances de la
classe).
• Une association décrit un ensemble de liens (instances
de l’association).

119
classes d’analyse

120
Le diagramme de classes
Les diagrammes UML
Utilisation
• Lors de l’analyse et de la conception:
– Définitions formelles des objets qui composent le système à partir des
cas d’utilisation et des diagrammes d’interaction (séquence ou
collaboration).
– Bases conceptuelles pour les diagrammes d’état-transition, de
déploiement, ...
• Lors de l’implémentation :
– Génération automatique des structures statiques du système (classes,
relations, ...).

121
Les diagrammes UML
�Le plus important de la modélisation O.O.
�Le seul obligatoire lors d’une telle modélisation
� fournit une représentation abstraite des objets du système qui vont
interagir ensemble pour réaliser les cas d’utilisation
�Vue statique : les éléments principaux sont : les classes et leurs relations

122
Les diagrammes UML
Notion de classe
Définition :
Une classe est une description d’un ensemble d’objets ayant une
sémantique, des attributs, des méthodes et des relations en commun.
Un objet est une instance d’une classe.
Objet de type VoitureClasse

• Une classe est une description abstraite d’un ensemble
d’objets ayant :
– des propriétés similaires,
– un comportement commun,
– des relations communes avec d’autres objets
– des sémantiques communes
• Chaque classe possède :
– une composante «statique» : attributs ou champs possédant une valeur
– une composante «dynamique» :
méthodes qui représentent le
comportement commun des
objets de la classe
Liste des attributs
Liste des méthodes
Nom de la classe
123S. Mesfar
Le diagramme de classes : Qu’est ce qu’une classe ?
Les diagrammes UML

124
Les diagrammes UML
Notion de classe
Attribut = propriété nommée d ’une classe
la portée standard d’un attribut est limité à un objet
• Syntaxe
– visibilité nom : type = valeur initiale
• Visibilité
– + public : propriété ou classe visible partout
– # protégé : propriété ou classe visible dans la classe et par tous ses descendants
– - privé : propriété ou classe visible uniquement dans la classe
– ~ package : propriété ou classe visible uniquement dans le paquetage où la
classe est définie
• Attribut de classe
– quand cette portée s’applique à la classe elle même, on parle d’attribut de classe
(représenté par le symbole $ ou souligné)
• Attribut dérivé
– attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté par le
symbole /)

125
Les diagrammes UML
Notion de classe
Méthode = service que l’on peut demander à un objet pour réaliser un
comportement
• Syntaxe
– visibilité nom (paramètres) : type retour
• Mêmes notions que l’attribut
– visibilité
– méthode de classe

126
Les diagrammes UML
Notion de classe
Notation Complète
Visibilité
Static
Dérivé
Paramètre
Retour
Initialisation
Nom de la Classe
Fenetre
+ taille : Rectangle = 100,100
- visible : Boolean = true
couleur : Color = blue
#$ tailleMax : Rectangle
#$ tailleMin : Rectangle
/#$ tailleMoyenne : Rectangle
+ afficher() : Position
+ cacher()
# setTaille(taille : Rectangle)
}
}Attributs
Méthodes

• Un diagramme de classes représente la structure du
système sous la forme de classes et de relations entre ces
classes
• Un diagramme d’objets illustre les objets et les liens qui
les unissent
127S. Mesfar
Le diagramme de classes et le diagramme d’objets
Les diagrammes UML

Le concept d’encapsulation
• L'encapsulation est un mécanisme consistant à rassembler les données
et les méthodes au sein d'une structure en cachant l'implémentation de
l'objet c-à-d en empêchant l'accès aux données par un autre moyen que
les méthodes proposés pour la manipulation de l’objet.
� L'encapsulation permet donc de garantir l'intégrité des données
contenues dans l'objet.
• L'encapsulation permet de définir des niveaux de visibilité des
éléments de la classe. Ces niveaux de visibilité définissent les droits
d'accès aux données selon que l'on y accède par une méthode de la
classe elle-même, d'une classe héritière, ou bien d'une classe
quelconque.
S. Mesfar 128
Les diagrammes UML

Le concept d’encapsulation
– Quatre niveaux de protection :
• Public (+) : accès à partir de toute entité interne ou
externe à la classe
• Protégé (#) : accès à partir de la classe ou des sous-
classes
• Privé (-) : accès à partir des opérations de la classe
• Package (~ ou rien) : accès à partir des classes du même
package
129S. Mesfar
Les diagrammes UML

S. Mesfar 130
Héritage
• Héritage
– Mécanisme de transmission des propriétés (attributs, comportement)
d’une classe vers ses sous classes
– Ce qui est générique est défini au niveau de la super-classe, ce qui est
spécifique est défini au niveau de la sous-classes
• Généralisation/spécialisation
– Généralisation : mise en commun des propriétés communes entre
différentes classes dans une super-classe.
– Spécialisation : création d’une sous-classe par mise en avant de
propriétés spécifiques non communes à toutes les classes de la super-
classe
Les diagrammes UML

S. Mesfar 131
Héritage : exemple
Généralisation
Spécialisation
personne
étudiantpersonnel
EnseignantAdministratif
Les diagrammes UML

Exemple d’héritage
132S. Mesfar
Les diagrammes UML

S. Mesfar 133
Héritage multiple
� une classe peut hériter des propriétés de plusieurs
super-classes
personne
étudiantpersonnel
EnseignantAdministratif
Doctorant
Les diagrammes UML

Exemple d’héritage multiple
134S. Mesfar
Les diagrammes UML

Contraintes de généralisation
• Une classe peut être spécialisée selon plusieurs critères
• Certaines contraintes peuvent être posées sur les relations de
généralisation
• Par défaut, la généralisation symbolise une décomposition
exclusive
135S. Mesfar
Les diagrammes UML

{disjoint} ( = { exclusif } )
• La contrainte {Disjoint} (ou
{exclusif}) indique la
participation exclusive d’un objet
à l’une des collections
spécialisées
136S. Mesfar
Les diagrammes UML

{chevauchement} (={ inclusif })
• La contrainte
{chevauchement} (ou
{inclusif}) indique la
participation possible d’un
objet à plusieurs collections
spécialisées
137S. Mesfar
Les diagrammes UML

{Complète} ≠ {Incomplète}
• La contrainte {Complète} indique la généralisation est
terminée : tout ajout de sous-classe est alors impossible
• à l’inverse, la contrainte {Incomplète} indique une
généralisation extensible
138S. Mesfar
Les diagrammes UML

Le polymorphisme
• Alors que l'héritage concerne les classes (et leur hiérarchie), le
polymorphisme est relatif aux méthodes des objets.
• On distingue généralement trois types de polymorphisme :
1. Le polymorphisme ad hoc (également appelé surcharge) : permet de définir
des opérateurs dont l'utilisation sera différente selon le type des paramètres qui
leur sont passés � par exemple, il est possible de surcharger l'opérateur + et de
lui faire réaliser des actions différentes selon qu'il s'agit d'une opération entre
deux entiers (addition) ou entre deux chaînes de caractères (concaténation)
2. Le polymorphisme paramétrique (également appelé généricité) : représente la
possibilité de définir plusieurs fonctions de même nom mais possédant des
paramètres différents (en nombre et/ou en type) � Il rend ainsi possible le choix
automatique de la bonne méthode à adopter en fonction du type de donnée
passée en paramètre
S. Mesfar 139
Les diagrammes UML

Le polymorphisme
3. Le polymorphisme d'héritage (également appelé redéfinition) :
représente la possibilité de redéfinir une méthode dans des classes héritant
d'une classe de base. Il est alors possible d'appeler la méthode d'un objet
sans se soucier de son type intrinsèque � faire abstraction des détails des
classes spécialisées d'une famille d'objet, en les masquant par une interface
commune (qui est la classe de base).
– Par exemple, un jeu d'échec comporte plusieurs objets roi, reine, fou, cavalier,
tour, pion, héritant chacun de l'objet pièce.
La méthode mouvement() pourra, grâce au polymorphisme d'héritage, d’effectuer
le mouvement approprié en fonction de la classe de l'objet référencé au moment de
l'appel. Cela permettra notamment au programme d’appeler pièce.mouvement()
sans avoir à se préoccuper de la classe de la pièce.
S. Mesfar 140
Les diagrammes UML

Exemple de polymorphisme d’héritage
S. Mesfar 141
Les diagrammes UML

• Une association représente une relation entre les classes
d’objets
Classe A Classe B
Société Personne
Voiture Personne
Classe A
142S. Mesfar
Le diagramme de classes : Les associations
Les diagrammes UML

• Une association qui contient des attributs et
qui ne participe pas à des relations avec
d’autres classe est appelée classe attribuée.
Classe A Classe B
Classe C
Attributs
143S. Mesfar
Les diagrammes UML

• Une association ternaire entre salle, étudiant et enseignant est
réifiée comme une classe cours ayant deux attributs : début et fin
Enseignant
Salle
Classe
Cours
Début
Fin
144S. Mesfar
Les diagrammes UML

• Généralement, on note les associations par une forme verbale, soit
active, soit passive
Classe A Classe B
Société Personne
Voiture Personne
Forme
verbale
< travaille pour
Est la
proprièté de > 145
S. Mesfar
Les diagrammes UML

Nommage des rôles
• Toute association binaire possède 2 rôles
• un rôle définit la manière dont une classe intervient dans une
relation
• Le nommage des associations et le nommage des rôles ne sont
pas exclusifs l’un de l’autre
• Intérêt des rôles dans le cas où plusieurs associations lient deux
classes : distinction des concepts attachés aux associations
Société Personne< travaille pour
employeur employé
Avion PersonnePilote
Passagers
146S. Mesfar
Les diagrammes UML

Association réflexive
• Nommage des rôles indispensable à la clarté du
diagramme
Personne
Enfants
Parents 2
*
147S. Mesfar
Les diagrammes UML

Multiplicité des associations
• La multiplicité est une information portée par le rôle, qui
quantifie le nombre de fois où un objet participe à une instance
de relation
• Multiplicité = indique le nombre d’instances d’une classe qui
peut être mise en relation avec une seul instance de la classe
associée
– 1 : obligatoire
– 0..1 : optionnel
– 0..* ou * : quelconque
– 1..* : au moins 1
– 1..5, 10 : entre 1 et 5, ou 10
148S. Mesfar
Les diagrammes UML

Multiplicité des associations
• 1 : Chaque personne travaille pour une et une seule société
(toutes les personnes ont un emploi)
• 0 .. * : Une société emploie de zéro à plusieurs personnes
Société Personne< travaille pour
employeur employé
1 0..*
149S. Mesfar
Les diagrammes UML

Contraintes sur les associations
• Contrainte d’association : porte sur une relation ou sur un groupe de
relations (notée {contrainte })
• Par exemple, placée sur un rôle, la contrainte {ordonnée} définit
une relation d’ordre entre les objets de la collection (les comptes)
qui sont liés à une personne
Personne ComptePropriétaire
{ordonnée}1
0..n
150S. Mesfar
Les diagrammes UML

Contraintes sur les associations
• La contrainte {sous-ensemble} indique qu’une collection est incluse
dans une autre collection
• La contrainte {Ou-exclusif} précise que, pour un objet donné, une
seule association parmi un groupe d’associations est valide
Classe Personne
Université Personne
{Sous ensemble}
Parents d’élève
Délégués
*
*
{OU-exclusif}
Enseignants
Étudiants
*
* 151
S. Mesfar
Les diagrammes UML

Restriction des associations
• La restriction (dite qualification en UML) d’une association
consiste à sélectionner un sous-ensemble d’objets parmi
l’ensemble des objets qui participent à une association réalisée
au moyen d’une clé, ensemble d’attributs particuliers.
• Un objet qualifié et une valeur de qualificatif génèrent un objet
cible lié unique
152S. Mesfar
Les diagrammes UML

Association particulière : Agrégation
• Une agrégation est une association non symétrique : l’une des extrémités
joue un rôle prédominant par rapport à l’autre
• Elle se justifie lorsque une classe B « fait partie » intégrante d’une
classe A.
• Exemple:
153S. Mesfar
Livre MotChapitre
1..* 1..*1..* 1..*
Les diagrammes UML

Agrégation particulière : Composition
• La composition est une forme particulière d’agrégation
• Le composant est « physiquement » contenu dans l’agrégat
• La composition implique une contrainte sur la valeur de la
multiplicité du coté de l’agrégat : (0 ou 1)
154S. Mesfar
Les diagrammes UML

Agrégation particulière : Composition
• La composition peut être modélisée au moyen d’attributs
• La notation par composition doit être retenue lorsque d’un
attribut participe à des relations
155S. Mesfar
Les diagrammes UML

156
Composition
Les diagrammes UML

157
Les diagrammes UML
Une Université contient au moins
un département.
Des départements peuvent avoir
différents professeurs.
Détruire une université détruit
ses départements,
mais en aucun cas ne met fin à la
vie des professeurs.
En C++ :
class Professeur;
class Departement { ...
private: // Agrégation
Professeur* enseignants[5]; .
.. };
class Universite { ...
private: // Composition
Departement facultes[20];
... };

158
4.2. Les diagrammes
d’objets

Un diagramme de d’objets :
• Représente les liens structurels entre instances de classes
• Facilite la compréhension de structures complexes
• Trois représentations possibles des instances :
159S. Mesfar
Le diagramme d’objets
Les diagrammes UML

• les valeurs des attributs sont optionnelles ainsi que les liens
entre objets
160S. Mesfar
Les diagrammes UML

Diagramme d’objets : liens entre objets
• Les liens des associations réflexives peuvent relier
un objet à lui même
161S. Mesfar
Les diagrammes UML

• Les liens d’arité supérieure à 2 ou la multiplicité peuvent
être représentés :
162S. Mesfar
Les diagrammes UML

• Les objets composés de sous-objets peuvent être visualisés :
• Les objets composites sont instances de classes composites :
163S. Mesfar
Les diagrammes UML

Diagramme d’objets : structures complexes
• Les diagrammes d’objets facilitent la compréhension et
l’élaboration d’un diagramme de classes :
164S. Mesfar
Les diagrammes UML

Rappel des concepts de base
• Classe
– attribut
– méthode
• Association
– rôle
– cardinalité
– Agrég./Comp./Associative/Qualifiée
o1
o2
o1
o2
o3
o4
o5
o1
o2
o3
 Objet  Lien  Inclusion
ensembliste
 Héritage
M1
M0
La conception
Les diagrammes UML

De quoi parle-t-on ?
Analyse
Objets du
monde
réel
Objets
du
logiciel
Algorithme
du monde réel
(scénario)
Comment ‘logique’ ?
Conception
Objets
du
langage
Algorithme
du logiciel
(scénario)
Comment ‘physique’ ?
Code
Modèle conceptuel Modèle logique Modèle physique
La conception
Les diagrammes UML

• Deux niveaux de conception :
– Logique : indépendante de l’environnement de
réalisation.
– Physique : liée à des particularités des langages de
programmation ou de l’environnement d’exécution
168
La conception
Les diagrammes UML

169
� Un des principaux soucis de l’activité de conception est de développer un design
qui facilite l’ajustement du système aux changements.
Pendant la conception:
 Importante qualité logicielle en jeu � évolutivité
 anticipation du changement � Modularisation
La phase de conception vise à :
 déterminer quels seront les composants du logiciel à développer,
 préciser les caractéristiques de ces composants,
 concevoir les algorithmes permettant à ces composants d’effectuer
les activités dont ils sont responsables.
La conception
Les diagrammes UML

170
package

Chapitre 9: Architecture et conception de logiciel
171
Différentes façons de subdiviser un
système
– Un système distribué est divisé en clients et serveurs
– Un système est divisé en sous-systèmes
– Un sous-système peut être subdivisé en paquetages
– Un paquetage est composé de classes
– Une classe est composée de méthodes
Le diagramme de package
Les diagrammes UML

Packages
Le diagramme de package
Les diagrammes UML

Soit le cas ’’Réservation de vols dans une agence de voyages’’
1° Des compagnies aériennes proposent différents vols.
2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.
4° Une réservation concerne un seul vol, et un seul passager.
5° Une réservation peut être annulée ou confirmée.
6° Un vol a un aéroport de départ et un aéroport d’arrivée.
7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
8° Un vol peut comporter des escales dans des aéroports
9° Une escale a une heure d’arrivée et une heure de départ.
10° Chaque aéroport dessert une ou plusieurs villes
Le diagramme de package – Etude de cas
Les diagrammes UML

CompagnieAerienne VolPropose
1..*
� Modélisation de la phrase :
1° Des compagnies aériennes proposent différents vols.
CompagnieAerienne et Vols sont 2 objets métiers : 2 classes
• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs
CompagnieAerienne VolPropose
1..*
affréteur
1..*
Les diagrammes UML

� Modélisation de la phrase :
2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
� Tout objet peut avoir un état (diagramme d’états).
� Dans un diagramme de classes tout concept dynamique est modélisé en opération.
� Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( )
� Dans quelle classe ? Responsabilité d’une classe
CompagnieAerienne Propose
1..*
affréteur
1..*
Vol
état (ouvert, fermé)
1..*
affréteur
1..*
Vol
ouvrirVol( )
fermerVol( )
� Les opérations sont déclarées dans l’objet dans lequel elles doivent s’exécuter
� Les autres pourront déclencher ces opérations par envoi de messages
� Le classe CompagnieAerienne a une association avec la classe vol.
Les diagrammes UML

� Modélisation des phrases :
7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
� Les dates et les heures de départ et d’arrivée ne représentent que des valeurs : attributs.
1..*
affréteur
1..*
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
� Pour savoir si un élément doit être représenté en attribut ou en objet :
� S’il n’ y a que sa valeur qui est intéressante : c’est plutôt un attribut.
� Si plusieurs questions peuvent concerner l’élément, alors il faut le représenter en objet.
Les diagrammes UML

� Modélisation peu parlante.
� Par quoi peut-on représenter l’élément ‘’Aéroport’’ ?
3 réponses sont envisageables :
1. Soit avec une classe et une association de multiplicité 2
{ ordered}
2
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
aeroportDepart
aeroportArivvee
Aéroport
nom
Les diagrammes UML

� Modélisation non correcte. Tout aéroport peut être de départ et d’arrivée.
2. Soit avec 2 classes
1
Vols
ouvrirReservation()
fermerReservation()
dateDepart
heureDepart
dateArrivee
heureArrivee
aeroportDepartr
aeroportArivvee
Aéroport
nom
AeroportDepart
AeroportArrivee1
Les diagrammes UML

� Le rôle de chaque association précise son sens.
2. Soit avec 2 associations
1
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Aéroport
Nom
…
1
Départ
Arrivée
Les diagrammes UML

10° Chaque aéroport dessert une ou plusieurs villes
Aéroport dessert
1..*
Ville
0..*
� Si on considère que desservir une ville signifie l’aéroport le plus proche, il n’ en y a qu’un : la
multiplicité est de 1
� Si on considère que desservir une ville signifie les aéroports dans un rayon de 35 km : la
multiplicité est de 0..*
� On ne peut pas savoir la multiplicité de ‘’Aéroport’’
Les diagrammes UML

Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Aéroport
nom1
1
Depart
Arrivee
Escale
heureArrivee
heureDepart
0..*
� Une escale a les propriétés heure d’arrivée et heure de départ, c’est donc un objet.
� Quelles sont alors les multiplicités entre ‘’Vols’’ et
‘’Escale’’, entre ‘’Escale’’ et ‘’Aeroport’’ et entre
‘’Aeroport’’ et ’Vols’’ ?
0..*
0..*
1
1
0..*
Les diagrammes UML

� ‘’Escale’’ a peu d’informations propres. Elle n’est qu’une partie de ’’Vol’’ .
� On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n’est pas totalement un aéroport.
� La meilleure solution serait de la modéliser comme une classe d’association entre et ’Vols’’ et ‘’Aéroport’’.
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Aéroport
nom
1
1
Départ
Arrivée
Escale
heureArrivee
heureDepart
Escale
0..*0..*
0..*
0..*
{Ordered}
Les diagrammes UML

4° Une réservation concerne un seul vol, et un seul passager.
5° Une réservation peut être annulée ou confirmée.
� La réservation et le passager sont 2 concepts métier : 2 classes d’objets
� Un réservation concerne un seul vol et un seul passager: donc 2 associations entre ‘’Vol’’ et ’’Réservation’’ et entre
’’Réservation’’ et ‘’Passager’’.
� La 5° phrase se traduit par l’ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’.
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Passager
1
1
concerne
Réservation
Annuler( )
Confirmer( )
concerne
Les diagrammes UML

3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.
� Il faut discerner un client d’un passager
a effectué
0..*
0..*
0..* Vol
Passager
1
1
concerne
Réservation
Annuler( )
Confirmer( )
concerne
Client 1
Les diagrammes UML

� Le diagramme des classe complet est :
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Aéroport
nom
1
1
départ
arrivée
InfosEscale
heureArrivee
heureDepart
escale
0..*0..*
0..*
0..*
{ordered}
Ville
0..*
Passager
1
concerne
Réservation
Annuler( )
Confirmer( )
Client
a effectué
0..*
1
0..*
1
concerne
CompagnieAerinne
Propose
1..*
1..*
nom Prénom
adresse
téléphone
e-mail
nom
nom Prénom
nom
date
numéro
Les diagrammes UML

� Diagramme des classe complet et annoté
InfosEscale
heureArrivee
heureDepart
Vol
ouvrirVol( )
fermerVol( )
dateDepart
heureDepart
dateArrivee
heureArrivee
Aéroport
nom
1
1
départ
arrivée
escale
0..*0..*
0..*
0..*
{ordered}
Ville
0..*
Passager
1
concerne
Réservation
Annuler( )
Confirmer( )
Client
a effectué
0..*
1
0..*
1
concerne
Propose
0..1
1..*
nom Prénom
adresse
tél
e-mail
nom Prénom
nom
{frozen}
{frozen}
CompagnieAerinne
nom
numéro
date
numéro
Les diagrammes UML

� Le diagramme des classe complet devient :
InfosEscale
heureArrivée
heureDépart
‘’ métaclasse ‘’
VolGenerique
ouvrirVol( )
fermerVol( )
jour
heureDépart
heureArrivée
/durée
périodevalidité
Aéroport
nom
1
1
départ
arrivée
escale
0..*0..*
0..*
0..*
{ordered}
Ville
0..* 1
concerne
Réservation
Annuler( )
Confirmer( )
Client
a effectué
0..*
1
0..*
1
concerne
Propose
0..1
1
nom Prénom
adresse
téléphone
e-mail
Passager
nom Prénom
nom
{frozen}
{frozen}
CompagnieAérienne
nom
numéro
date
numéro
Vol
ouvrirVol( )
fermerVol( )
dateDépart
dateArrivée
{frozen}{AddOnly}
décrit
0..* 1
1..*
0..*
propose
Affréteur
Les diagrammes UML

� Le diagramme des classes peut être réorganisé en packages
InfosEscale
heureArrivee
heureDepart
‘’ metaclasse ‘’
VolGenerique
ouvrirVol( )
fermerVol( )
jour
heureDepart
heureArrivee
/durée
periodevalidite
Aéroport
nom
1
1
départ
arrivée
escale
0..*0..*
0..*
0..*
{ordered}
Ville
0..* 1
concerne
Réservation
Annuler( )
Confirmer( )
Client
a effectué
0..*
1
0..*
1
concerne
Propose
0..1
1..*
nom Prénom
adresse
tééphonel
e-mail
Passager
nom Prénom
nom
{frozen}
{frozen}
CompagnieAerinne
nom
numéro
date
numero
Vol
ouvrirVol( )
fermerVol( )
dateDepart
dateArrivee
{frozen}{AddOnly}
décrit
0..* 1
1..*
0..*
propose
Affréteur
Les diagrammes UML

� Réduire la dépendance mutuelle afin d’augmenter la modularité et
l’évolutivité d’une application
0..* 1
concerne
{frozen}
Réservation
Annuler( )
Confirmer( )
date
numéro
Réservations
Vol
ouvrirVol( )
fermerVol( )
dateDepart
dateArrivee
Vol
Les diagrammes UML

Réservations
Réservation
Annuler( )
Confirmer( )
Client
a effectué
0..*
1
0..*
1
concerne
nom Prénom
adresse
téléphone
e-mail
Passager
nom Prénom
{frozen}
date
numéro
Vol
InfosEscale
heureArrivee
heureDepart
‘’ metaclasse ‘’
VolGenerique
ouvrirVol( )
fermerVol( )
jour
heureDepart
heureArrivee
/durée
periodevalidite
Aéroport
nom
1
1
départ
arrivée
escale
0..*0..*
0..*
0..*
{ordered}
Ville
Propose
0..1
1
nom
CompagnieAerinne
nom
numéro
Vol
ouvrirVol( )
fermerVol( )
dateDepart
dateArrivee
{frozen}{AddOnly}
decrit
0..* 1
1..*
0..*
propose
Affréteur
0..* 1
concerne
{frozen}
Les diagrammes UML

Généralisation et réutilisation
� On veut élargir ce domaine aux voyages par bus que des transporteurs assurent.
� Un voyage en bus à une ville de départ et un ville d’arrivée avec des dates et des heures
associées.
� Un trajet peut comporter des arrêts dans des villes intermédiaires.
� Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers
VoyageEnBus
OuvrirVoyage( )
fermerVoyage( )
dateDepart
dateArrivee
VoyagesBus
ReservationsBus
ReservationBus
Annuler( )
Confirmer( )
date
numéro
0..* 1
concerne
{frozen}
Les diagrammes UML

concerne
VoyagesBus
InfosArret
heureArrivee
heureDepart
VoyageEnBus
ouvrirVoyage( )
fermerVoyage()
dateDepart
heureDepart
dateArrivee
heureArrivee
/durée
1
1
départ
arrivée
arrêt
0..*0..*
0..*
0..*
{ordered}
Propose
0..1
1
Voyagiste
nom
référence
Ville
nom
ReservationsBus
0..*
1..*
concerne
Client
nom Prénom
adresse
téléphone
e-mail
Passager
nom Prénom
{frozen}
ReservationBus
Annuler( )
Confirmer( )
date
numéro
a effectué
0..*
1
{frozen}
Les diagrammes UML

Fusion des 2 modèles
1. Il faut isoler les classes communes dans des packages
2. Il faut factoriser les propriétés communes
AVION
Vols
ReservationVols
BUS
ReservationBus
VoyagesBus
Lieux
�
Les diagrammes UML

Il faut isoler les classes communes dans des packages
�
Vol
(from Vols)
ReservationVol
(from ReservationsVols)
ReservationBus
(from ReservationsBus)
VoyageEnBus
(from VoyagesBus)
concerne concerne
{frozen} {frozen}
1 1
Réservations
0..* 1
concerneClient
nom Prénom
adresse
tél
e-mail
Passager
nom Prénom
Réservation
Annuler( )
Confirmer( )
date
numéro
{frozen}
a effectué
0..*1
Classe
abstraite
Les diagrammes UML

VolsVoyagesBus
LieuxPackage réutilisable
ReservationsBus
Réservations
ReservationsVols
Packages spécialisés
Package généralisé
Les diagrammes UML

196
classes de conception

Stéréotypes
• Mécanisme d’extensibilité
• Sémantique du concept est insuffisante � le
stéréotype permet la métaclassification
�Ajouter de nouvelles classes sans perdre la
sémantique
� Faciliter l’unification des sous-systèmes et
catégories
Le diagramme de classe : de l’analyse à conception
Les diagrammes UML

198
Stéréotype : définition
• Un stéréotype permet d’étendre les classes déjà existantes en leur
donnant une signification sémantique différente.
• Si la classe A est un stéréotype de la classe B, alors A se comporte
comme B tout en ayant une signification sémantique différente.
• Représentation UML: <<stéréotype>>
Nom de la Classe
Les diagrammes UML

199
Utilisation des stéréotypes
Stéréotypes prédéfinis pour les classes d’analyse (proposés par Jacobson):
• Boundary ou frontière ou interface
• Control ou contrôle
• Entity ou entité
Représentation de
Jacobson
Nom du stéréotype
Les diagrammes UML

200
Stéréotypes… : boundary
• La classe stéréotypée <<Boundary>> modélise la communication entre les
acteurs et les composantes internes du système (les interfaces
homme/machine, les interfaces des systèmes (protocole de
communication,…) , interfaces des matériels (écran, clavier, imprimante,…))
<<boundary>>
InterfaceRechercheSimple
Auteur
ISBN
Titre
Rechercher()
Les diagrammes UML

201
Stéréotypes… : Entity
• La classe stéréotypée <<Entity>> modélise les informations persistantes
du système. Exemples : classes qui contiennent des informations d’un
étudiant, d’un employé, …
<<Entity>>
Livre
code :entier
titre : chaîne
ISBN : entier
nbrexemplaires:entier
Getcode()
GetTitre()
FindByISBN (ISBN:entier)
setNbrexemp(nbreexemplaires:entier)
Les diagrammes UML

202
Stéréotypes… : control
«Control classes are generally used to represent coordination, sequencing,
transactions, and control of other objects. And it is often used to
encapsulate control related to a specific use case »
[I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development
Process”, Addison Wesley, 1999]
Les diagrammes UML

203
Stéréotypes… : control
• La classe stéréotypée <<control>> assure la coordination entre classes
• Elle contrôle le séquencement, ou coordonne l'exécution des objets contrôlés.
• Elle contrôle la concurrence entre classes contrôlées,
• Elle est l'implantation d'un objet intangible,
• Au départ , on crée une classe "control" pour chaque use-case; cette classe gère le
flot d'évènements dans le use-case,
• Au fur et à mesure de l'avancement de l'analyse, les classes "control« peuvent être
supprimées, découpées ou regroupées.
<<control>>
CTRLrecherche
rechercherLivres()
Les diagrammes UML

204
<<control>>
CTRLrecherche
rechercherLivres()
• Classes stéréotypées en relation
<<Entity>>
Livre
auteur :entier
titre : chaîne
ISBN : entier
nbrexemplaires:entier
Getcode()
GetTitre()
FindByISBN (ISBN:entier)
setNbrexemp(nbreexemplaires:entier)
<<boundary>>
InterfaceRechercheSimple
Auteur
ISBN
Titre
Rechercher()
0..*
0..*
<Déclencherrech
Les diagrammes UML

205
• Les associations entre les classes stéréotypées suivent des règles assez
strictes :
– Les « boundary » ne peuvent être reliées qu’aux « control »
– Les « control » ont accès aux « boundary », aux « entity » et aux autres
contrôles
– Les « entity » ont accès aux autres « entity » et ne sont reliées qu’aux «
control »
� Pour aller plus loin : utiliser des partons de conception (les design
patterns)
Les diagrammes UML

206
Les diagrammes UML

Exemple de la localisation d’un DAB
207
Les diagrammes UML

Conception détaillée
Deux niveaux de conception :
- une étape logique: indépendante de l’environnement de réalisation:
• Conception détaillée des classes: trouver la meilleure manière de concevoir les
structure logique,
• Conception détaillée des associations (typage, portée, rémanence/persistance):
– assurer la gestion des liens
– traiter les classes associatives
– optimiser la navigation
• Délégation: dépendance des relations d’agrégation et de composition.
• Raffiner la généralisation/spécialisation (héritage simple ou multiple):
– propriétés structurelles
– Interface
– propriétés comportementales
- une étape physique: liée à des particularités des langages de programmation ou de
l’environnement d’exécution
Raffinementdesdiagrammesstructurels
208
Le diagramme de classe de conception
Les diagrammes UML

Conception détaillée des classes
• Définir le type des attributs identifiés en analyse.
– Type de base + composé
• Structure
• Enumération
• Spécifier les Structures de Données.
• Spécifier les visibilités des attributs et méthodes + prise en
compte des propriétés (ordered, addOnly, frozen)
• Spécifier les méthodes + celles spécifiques à l’implantation
• Montrer les dépendances + Classes spécifiques
Les diagrammes UML

Structure
– Définition : Ensemble d’attributs pouvant être regroupés.
<<structure>>
Date
jour
mois
années
<<structure>>
Adresse
numRue
rue
codePostal
ville
pays
210
Les diagrammes UML

Enumération
– Définition : Ensemble de littéraux d’énumération, ordonné.
<<enumeration>>
Jour
Lundi
Mardi
Mercredi
Jeudi
Vendredi
Samedi
Dimanche
<<enumeration>>
Titre
Secretaire
President
Tresorier
VicePresident
Membre
Les diagrammes UML

Visibilité des éléments
• Restreindre l'accès aux éléments d'un modèle
• Contrôler et éviter les dépendances entre classes (et paquetages)
+ public visible à l’extérieur de la classe
# protégé visible que dans la classe et ses sous-classes
 privé visible dans la classe uniquement
~ package visible dans la package uniquement
$ élément de classe
Remarques:
• Utile lors de la conception et de l'implémentation, pas avant !
-N'a pas vraiment de sens dans le modèle d’analyse-
• La sémantique exacte dépend du langage de programmation !
212
Les diagrammes UML

Déclaration d'attributs
[/] [ visibilité ] nom [ : type ] [card ordre] [ = valeur-initiale ] [ { props... } ]
exemples: age
+age
/age
- solde : Integer = 0
# age : Integer [0..1]
# numsecu : Integer {frozen}
# motsClés : String [*] {addOnly}
$nbPersonne : Integer
 Adapter le niveau de détail au niveau d'abstraction
 La non précision de visibilité � privée
Les diagrammes UML

Déclaration d'opérations
[ visibilité ] nom [ ( params ) ] [ : type ] [ { props... } ]
getAge()
+ getAge() : Integer
- updateAge( in date : Date ) : Boolean
# getName() : String [0..1]
+getAge() : Integer
+addProject()
+$main( in args : String [*] {ordered} )
 Adapter le niveau de détail au niveau d'abstraction
 La non précision de visibilité � public
Les diagrammes UML

Conception détaillée des classes :
classes spécifiques
• Classe utilitaire
� Exemple: fonctions mathématiques d’une bibliothèque
« Utilitaire »
Math
Math
Les diagrammes UML

217
Contraintes de gestion de l’association
Par exemple :
• { ordered } : les éléments de la collection sont ordonnés
• { frozen } : fixé lors de la création de l ’objet, ne peut pas changer
• { addOnly } : impossible de supprimer un élément
RelevéDeCompte
Ligne
Opération
*{ordered,addOnly}
lignes
Les diagrammes UML

218
Rôle : traduction
B
*
R
A B
1
A
R
bs
rs
*
b
1
a
rolea
carda
carda
rolea
Les diagrammes UML

219
Classe associative: traduction
B
*
A B
1
A
R
bs
*
b
1
a
as
*
*
Les diagrammes UML
R

Relation ternaire: traduction
Les diagrammes UML

B
*
{ordered}
R
Role ordonné :
traduction générale par index
A B
1
A
R
bs
rs
ib : integer
*
b
Pour tout a, tous les rs ont un indice ib différent et couvrant l'intervalle
de 1 au nombre de bs.
1
a
rolea
carda
carda
rolea
Les diagrammes UML

Pour tout a, tous les bs ont un indice iRb
différent et couvrant l'intervalle de 1 au
nombre de bs.
B
*
{ordered}
R
Rôle ordonné 1 - * : traduction par
index
A B
*
A
bs
bsa
a
1
iRb : integer
1
Les diagrammes UML

224
Navigabilité d’une Association
�La navigabilité permet de spécifier dans quel(s) sens il est possible
de traverser l'association à l'exécution.
�On interdit la navigation par une croix (X) du côté qui n'est pas
atteignable.
�On peut représenter les associations navigables dans un
seul sens par des attributs. Les attributs sont toujours
navigables.
Les diagrammes UML

exist
getAll
nb
empty
Spécifier les méthodes pour la gestion des liens
set
get
a b
R
M1
M0
0..10..1
Remarque :
i. Les méthodes (ajout/suppression) doivent préserver la cohérence des
cardinalités et les contraintes (exemple : AddOnly)
ii. Les méthodes de navigation doivent être cohérentes avec le sens de
navigation
iii. En cas de cardinalité > 1 � possibilité de prévoir un attribut de type
collection (surtout à définir lors de l’implémentation !! )
remove
removeAll
removeIdx
add
setAll
insert
a b
R
M1
M0
0..*0..1
Les diagrammes UML

Classes de conception
Les diagrammes UML

232
5.3. Notions d’abstraction
et d’interfaces

233
Le diagramme de classes Notion de classe abstraite
Les diagrammes UML
Une classe abstraite est une classe dont au moins une
méthode est abstraite
Une méthode abstraite est définie uniquement par son intitulé
sans code
abstract void calcul_long();
Dans les classes dérivées, la méthode abstraite doit être décrite
 La méthode abstraite ne peut pas être private
On ne peut pas créer un objet d’une classe abstraite
Une classe abstraite est un type, il est possible de définir des
variables ou paramètres de ce type; mais il faut affecter un objet
d’une classe concrète, descendante

234
Les diagrammes UML
But d’une classe abstraite
Une classe abstraite permet de définir les caractéristiques
communes à plusieurs classes.
Une classe abstraite permet à un développeur :
de fournir à d'autres développeurs une partie de l'implémentation
d'une classe
de laisser aux autres développeurs la manière d'implémenter le
reste de la classe
d'imposer aux autres développeurs d'implémenter certaines
méthodes s'ils veulent pouvoir utiliser ses classes

• Exemple: deux classes Cercle, Carre qui
possèdent des méthodes communes:
– float surface()
– void afficheInfo()
dont les implémentations sont très différentes
235
Les diagrammes UML

• Solution :
abstract class Figure{
private String nom;
public String getNom( ){
return nom; }
public abstract void afficheinfos( );
public abstract float surface( );
}
236
Les diagrammes UML

• Les règles usuelles d'héritage s'appliquent aux
classes abstraites.
• Les classes dérivées de Figure peuvent
implémenter complètement, partiellement, ou
pas du tout, les méthodes abstraites de Figure.
• Suite de la solution :
Figure f;
f = new Cercle (…);
f.surface( ); // utiliser la liaison dynamique
...
237
Les diagrammes UML

• Si A est déclarée comme classe abstraite
alors on ne peut pas créer d'instance de la
classe.
• En revanche, on peut (on devrait) déclarer
des variables de type A, et les instancier par
n'importe quel objet de n'importe quelle
classe concrète (non abstraite) dérivée de A.
238
Les diagrammes UML

239
Le diagramme de classes Notion d’interface
Les diagrammes UML
Une interface est une classe abstraite ayant les caractéristiques
suivants:
toutes les méthodes sont abstraites et public, alors qu’une classe
abstraite peut avoir des méthodes non abstraites
tous les attributs sont static, alors qu’une classe abstraite peut
avoir des attributs ordinaires
toute classe peut hériter de plusieurs interfaces
une interface peut hériter d’une ou plusieurs interfaces mais elle
ne peut pas hériter d’une classe
il n’est pas nécessaire d’indiquer abstract pour les méthodes et
static pour les attributs

240
Les diagrammes UML
« interface »
NomInterface
NomClasse
ou NomClasse
Une classe qui implémente une interface doit définir le corps (les
instructions) de toutes ses méthodes abstraites
implémente

interface Chapeau{
void ajoute(Object o);
Object tire();
boolean estVide();
}
class ChapeauDoubleFond implements Chapeau{... }
class ChapeauTripleFond implements Chapeau{... }
class TourCartes{
…
public void ajouteChapeau(Chapeau c){... }
} 241
Les diagrammes UML

• Le code de TourCartes n'est pas lié à une
implémentation particulière de Chapeau.
TourCartes t=new TourCartes();
Chapeau c=new ChapeauDoubleFond();
t.ajouteChapeau(c);
• Le seul moment où est mentionné le choix
d'implémentation est lors de la construction de l'objet.
242
Les diagrammes UML

• Intérêt :
– Séparation interface publique/implémentation
– Permet une forme d’héritage multiple :
• Par exemple, une classe C2 peut étendre une classe C1
et implémenter une interface I
• Rôles :
– rôle des interfaces: déclaration des méthodes
publiques
– rôle des classes: implémentation de ces méthodes
243
Les diagrammes UML

Une démarche couramment utilisée pour bâtir un diagramme de
classes consiste à :
1. Trouver les classes du domaine étudié.
Cette étape empirique se fait généralement en collaboration avec
un expert du domaine. Les classes correspondent généralement à
des concepts ou des substantifs du domaine.
2. Trouver les associations entre classes.
Les associations correspondent souvent à des verbes, ou des
constructions verbales, mettant en relation plusieurs classes,
comme << est composé de >>, << pilote >>, << travaille
pour >>.
S. Mesfar 244
Etapes de l’élaboration d’un diagramme de classes
Les diagrammes UML

3. Trouver les attributs des classes.
Les attributs correspondent souvent à des substantifs, ou des
groupes nominaux, tels que << la masse d’une voiture >> ou
<< le montant d’une transaction >>. Les adjectifs et les valeurs
correspondent souvent à des valeurs d’attributs.
NB: Souvent, on ajoute des attributs à toutes les étapes du cycle
de vie d’un projet (implémentation comprise).
4. Organiser et simplifier le modèle en éliminant les classes
redondantes et en utilisant l’héritage.
5. Itérer et raffiner le modèle.
Un modèle est rarement correct dès sa première construction. La
modélisation objet est un processus non pas linéaire mais
itératif.
S. Mesfar 245
Etapes de l’élaboration d’un diagramme de classes
Les diagrammes UML

246
5.4 : Les Diagrammes de
collaboration / communication
S. Mesfar

Notation
• Les diagrammes de collaboration montrent des
interactions entre objets, en insistant plus
particulièrement sur la structure spatiale statique qui
permet la mise en collaboration d’un groupe d’objets.
• Les diagrammes de collaboration expriment à la fois
le contexte d’un groupe d’objets (au travers des objets
et des liens) et l’interaction entre ces objets (par la
représentation de l’envoi de messages).
� Les diagrammes de collaboration sont une extension
des diagrammes d’objet.
S. Mesfar 247
Le diagramme de communication / collaboration
Les diagrammes UML

Notation
•Les diagrammes de collaboration sont un recoupement
des diagrammes d’objets et des diagrammes de
séquences.
•Chaque objet intervient de la même façon que dans les
diagrammes de séquence
•Les messages sont obligatoirement numérotés
S. Mesfar 248
Les diagrammes UML

Notation
Objet 1
Objet 2
Objet 3
1 : message
4 : message
2 : message
3 : message
S. Mesfar 249
Les diagrammes UML

Exemple
S. Mesfar 250
Les diagrammes UML

Rôles et connecteurs
Le rôle permet de définir le contexte d'utilisation de l'interaction.
�Si la ligne de vie est un objet, celui-ci peut avoir plusieurs rôles
au cours de sa vie.
Les relations entre les lignes de vie sont appelées connecteurs .
�Un connecteur se représente de la même façon qu'une
association mais la sémantique est plus large : un connecteur est
souvent une association transitoire.
S. Mesfar 251
Les diagrammes UML

Notation (…)
La place de l’utilisateur
� La notation permet de faire figurer un acteur dans un
diagramme de collaboration afin de représenter le
déclenchement des interactions par un élément externe au
système. Grâce à cet artifice, l’interaction peu être décrite de
manière plus abstraite sans entrer dans les détails des objets de
l’interface utilisateur.
� Le premier message est envoyé par l’acteur, représenté par un
symbole graphique (type bonhomme) semblable au modèle des
cas d’utilisation, ou bien par un objet muni d’un stéréotype qui
précise sa qualité d’acteur.
S. Mesfar 252
Les diagrammes UML

Représentation des messages
Les flèches représentant les messages sont tracées à côté des
connecteurs qui les supportent.
Attention
Bien faire la distinction entre les messages et les connecteurs : on
pourrait avoir un connecteur sans message, mais jamais
l'inverse.
S. Mesfar 253
Les diagrammes UML

Multiplicité
Les connecteurs permettent de rendre compte de la
multiplicité.
S. Mesfar 254
Les diagrammes UML

Numéros de séquence des messages
Pour représenter les aspects temporels, on adjoint des numéros de
séquence aux messages.
�Des messages successifs sont ordonnés selon un numéro de
séquence croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...).
�Des messages envoyés en cascade (ex : appel de méthode à
l'intérieur d'une méthode) portent un numéro d'emboîtement avec
une notation pointée
•1.1, 1.2, ... pour des messages appelés par une méthode dont
l'appel portait le numéro 1
•2.a.1, 2.a.2, ... pour des messages appelés par une méthode
dont l'appel portait le numéro 2.a
S. Mesfar 255
Les diagrammes UML

Equivalence avec un diagramme de
séquence
S. Mesfar 256
Les diagrammes UML

Equivalence avec un diagramme de
séquence
S. Mesfar 257
Les diagrammes UML

Messages simultanés
Lorsque des messages sont envoyés en parallèle, on les numérote
avec des lettres
•1.a, 1.b,... pour des messages simultanés envoyés en réponse à
un message dont l'envoi portait le numéro 1
S. Mesfar 258
Les diagrammes UML

S. Mesfar 259
Classes
Collaboration
Les diagrammes UML

Opérateurs de choix et de boucle
Pas d'opérateurs combinés dans les diagrammes de communication
•*[<clauseItération>] représente une itération.
�La clause d'itération peut être exprimée dans le format
i:=1..n
•[<clauseCondition>] représente un choix. La clause de
condition est une condition booléenne. Elle représente la
condition d’arrêt
S. Mesfar 261
Les diagrammes UML

Syntaxe des messages
�Syntaxe complète des messages est :
[<numeroSéquence>][<expression>]:<message>
�« message » a la même forme que dans les diagrammes de
séquence, « numéroSéquence » représente le numéro de
séquencement des messages et « expression » précise une itération
ou un branchement conditionnel.
�Exemples :
�2 : affiche(x,y) : message simple.
�1.3.1 : trouve("Hadock") : appel emboîté.
�4 [x < 0] : inverse(x,couleur) : conditionnel.
�3.1 *[i:=1..10] : recommencer() : itération.
S. Mesfar 262
Les diagrammes UML

Collaborations et interactions
�Les collaborations donnent lieu à des interactions
�Les interactions documentent les collaborations
�Les collaborations organisent les interactions.
�Les interactions se représentent indifféremment par des
diagrammes de communication ou de séquence
S. Mesfar 263
Les diagrammes UML

UML - Le langage Objet unifié
x : ClasseA y : ClasseB
[ x ] 1: message
message soumis à la condition x
x : ClasseA
y : ClasseB
1.a : message1
z : ClasseC1.b : message2
message1 et message 2 en parallèle
x : ClasseA
y : ClasseB
1.1 : message1
z : ClasseC1.2 : message2
message1.1 et message1.2 envoyés
successivement vers y et z
1 : * [ 1..n ] message
message envoyé n fois
x : ClasseA : ClasseB
// 1: message message envoyé en parallèle à plusieurs
instances de la classe B
1.a, 2.c / 5: message message envoyé à y lorsque 1.a et 2.c sont
satisfaits (synchronisation) : Voir diag. d’activités
1 : a : = message
a récupère la valeur renvoyée par l’exécution du
message (récupération d’un résultat)S. Mesfar
Les diagrammes UML

Buts :
1. Décrire l’interaction des objets entre eux
2. Illustrer les scénarios des use cases
3. Valider les choix d’analyse et de conception
(prototypage)
4. Aider au raffinement des diagrammes de classes de
conception
265 S. Mesfar
Les diagrammes UML

266
5.5 : Les Diagrammes
Etats-transitions
S. Mesfar

Concepts liés à la phase d’analyse
� Un état réfère l’ensemble des valeurs qui décrit
un objet à un moment spécifique.
� En d’autres termes, l’état d’un objet est
déterminé par les valeurs associées à ses
attributs.
� Quand les messages sont reçus, les opérations
associées aux classes des objets considérés
amènent des modifications de ces valeurs.
267
Le diagramme Etats-Transitions
Les diagrammes UML

CoursUML-SlimMesfar-Total

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à CoursUML-SlimMesfar-Total

Similaire à CoursUML-SlimMesfar-Total (20)

CoursUML-SlimMesfar-Total