Introduction au langage de

modélisation UML
Denis Conan, Chantal Taconet, Christian Bac

CSC 4002
Octobre 2015
Revision : 1495
Introduction au langage de modélisation UML

Sommaire

1 Objectifs de ce cours de modélisation orientée objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Généralités sur la modélisation orienté objet et sur UML. . . . . . . . . . . . . . . . . . . . . . . . . . .4
3 Analyse, vues cas d’utilisation et processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Analyse et conception, aspects statiques de la vue logique . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Analyse et conception, aspects dynamiques de la vue logique . . . . . . . . . . . . . . . . . . . . . 61
6 Conception, aspects langage et technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7 Conception, vues développement et physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 2/132
Introduction au langage de modélisation UML

1 Objectifs de ce cours de modélisation orientée objet

■ Introduire la modélisation orientée objet

■ Introduire la modélisation à base de graphiques des systèmes informatiques
■ Introduire la notation UML
♦ Différents types de diagrammes avec leurs notations
♦ Rôles complémentaires des types de diagrammes
♦ Cohérence entre diagrammes de même type ou de types différents
■ Présenter des éléments méthodologiques d’utilisation des différents types de
diagrammes dans un processus de développement
♦ Présentation dans le cours d’une première étude de cas
♦ Mise en pratique lors des bureaux d’étude avec deux autres études de cas
♦ Évaluation de l’acquisition lors d’un examen sur table avec une quatrième étude
de cas

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 3/132
Introduction au langage de modélisation UML

2 Généralités sur la modélisation orienté objet et sur UML

2.1 Principes de la modélisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.2 Pourquoi et comment modéliser en orienté objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten . . . . . . . . 10
2.5 Phases de la modélisation, cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Rôle de l’expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Rôle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Rôle de la conception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 4/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.1 Principes de la modélisation

■ Objectif principal de la modélisation = maîtriser la complexité

■ Modéliser = abstraire la réalité pour mieux comprendre le système à réaliser / réalisé
■ Le modèle doit être relié au monde réel
♦ Par exemple : l’existant avant les travaux, le réalisé, le restant à réaliser
■ Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement
♦ Par analogie : répartition électrique de l’immeuble, de la cage d’escalier, de
l’appartement, de la pièce
■ Une seule « vue » du système n’est pas suffisante
♦ Les intervenants multiples du projet informatique possèdent des préoccupations
multiples
▶ Par analogie : plan de masse, vues de face et de côté, schéma électrique, plan
de plomberie, plan de calculs de construction

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 5/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.2 Pourquoi et comment modéliser en orienté objet

■ Relier le modèle au monde réel par la notion d’objet
■ Orienté objet = abstraire et décomposer le système informatique en objets
♦ Le monde réel est constitué d’objets physiques ou immatériels
♦ Tracer les objets virtuels de modélisation depuis les objets du monde réel
▶ Relier les objets (réels) du problème et les objets (virtuels) de la solution
♦ Favoriser les abstractions naturelles du monde réel utilisables en modélisation
▶ Objets vus comme des « boîtes noires » : seules les propriétés visibles de
l’extérieur intéressent
▶ Objets possédant un nom, qualifiables, classables, polymorphes,
dé-/composables, interagissants avec d’autres objets, etc.
■ Objectifs supplémentaire lors de la modélisation orientée objet
♦ Meilleure indépendance du modèle par rapport aux fonctions demandées
♦ Meilleure capacité d’adaptation et d’évolution du modèle lorsque des
fonctionnalités sont modifiées ou ajoutées
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 6/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.3 Unified Modelling Language (UML)

OMT−2
James Rumbaugh

UML 0.8
OOSPLA’95

Booch’93 UML 0.9 UML 1.0 UML 1.1

Grady Booch WWW Juin 96 Proposé à un Standard OMG
standard OMG ADTF fin 1997
fin 1997
Partenaires
divers
OOSE Task force
Ivar Jacobson

->UML 2.5
UML 1.2 UML 1.3 UML 1.4 UML 1.5 UML 2.0 UML 2.3 UML 2.4.1 2015
1998 2001 2003 2005 2010 2013

■ Systèmes d’informations des entreprises, Banques et services financiers,

Télécommunications, Transports, Défense et aérospatiale, Calculs scientifiques,
Applications réparties en réseau, services Web Internet, etc.

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 7/132
2 Généralités sur la modélisation orienté objet et sur UML 2.3 Unified Modelling Language (UML)

2.3.1 UML, un langage

■ UML est un langage de modélisation orientée objet
■ UML n’est pas une méthode
■ UML a été adopté par toutes les méthodes orientées objet
■ UML est dans le domaine public ; c’est un standard
■ UML est un langage pour :
♦ Visualiser
▶ Chaque symbole graphique possède une sémantique
♦ Spécifier
▶ De manière précise et complète, sans ambiguïté
♦ Construire
▶ Une partie du code des classes peut être généré automatiquement
♦ Documenter
▶ Les différents diagrammes, notes, contraintes, exigences sont conservés dans
un document
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 8/132
2 Généralités sur la modélisation orienté objet et sur UML 2.3 Unified Modelling Language (UML)

2.3.2 Les 10 principaux diagrammes UML

Principaux diagrammes étudiés

Cas Classes Machine Interaction Paquetages

d’utilisation à états

Activité Objets Composants Déploiement

Communications

Séquence

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 9/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.4 Cinq façons de voir un système informatique : les 4+1 vues

de Kruchten

Aspect dynamique : interactions (séquences, communications),

machines à états
Aspect statique: paquetages,
Aspect statique : classes,
et fichiers
objets et paquetages

Vue logique Vue développement

Vue cas
d’utilisation

Vue processus Vue physique

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution, Aspect répartition: déploiement,

processus, tâches, activités noeuds, modules

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 10/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.5 Phases de la modélisation, cycle en V

Cahier des charges Produit

S’accorder sur ce Le système est−il

qui doit être fait Expression des besoins Recette conforme au
dans le système cahier des
charges ?

Comprendre les Le système est−il

besoins, les décrire Analyse Tests de validation conforme
dans le système à l’analyse ?

Les différentes parties

du logiciel
S’accorder sur la manière dont Conception
Tests d’intégration
le système doit être construit fonctionnent−elles
correctement ensemble ?

Codage du résultat Pour un objet, chaque opération

de la conception Implantation Tests unitaires
fonctionne−t−elle correctement ?

Code exécutable

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 11/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.6 Rôle de l’expression des besoins

■ Permettre une meilleure compréhension du système

■ Comprendre et structurer les besoins du client
♦ Clarifier, filtrer et organiser les besoins, ne pas chercher l’exhaustivité
■ Une fois identifiés et structurés, ces besoins :
♦ Définissent le contour du système à modéliser
▶ Précisent le but à atteindre
♦ Permettent d’identifier les fonctionnalités principales du système

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 12/132
2 Généralités sur la modélisation orienté objet et sur UML 2.6 Rôle de l’expression des besoins

2.6.1 Exemple de cahier des charges : Studs

■ Studs : Application d’aide à la planification de réunions et à la prise de décision.

■ L’objectif est de permettre d’exprimer des préférences parmi plusieurs choix.
■ Les choix sont de deux types : (1) des plages horaires (dates avec heures de début et
de fin) et (2) des votes concernant une liste de choix.
■ L’organisatrice, crée un scrutin, renseigne les plages horaires possibles (type 1) et
ajoute les participants à la réunion.
■ Les participants peuvent exprimer dans un bulletin leurs préférences en indiquant
pour chaque plage horaire s’ils votent « pour » (ils sont disponibles et annoncent
leur intention de participer) ou « contre ».
■ L’organisatrice récupère les résultats du scrutin à la fin du vote et annonce la plage
horaire choisie.
■ La procédure est similaire pour le type 2, c.-à-d. pour les scrutins concernant des
propositions (chaînes de caractères quelconques) à choisir.

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 13/132
2 Généralités sur la modélisation orienté objet et sur UML 2.6 Rôle de l’expression des besoins

2.6.2 Règles de gestion et contraintes de l’application Studs

■ Toutes les personnes peuvent être organisatrices.
■ L’organisatrice est de facto une participante au scrutin.
■ Seule l’organisatrice est autorisée à gérer un scrutin.
■ Seuls les participants enregistrés peuvent participer au scrutin et consulter les
résultats.
■ Pour que les participants puissent voter, il faut que le scrutin soit ouvert
(dateDuJour ≥ dateDebutScrutin).
■ La durée d’ouverture du scrutin est limitée.
■ L’organisatrice doit indiquer la date de destruction automatique du scrutin.
■ Toutes ces dates permettent de gérer de manière automatique le cycle de vie d’un
scrutin.
■ Les transitions du cycle de vie peuvent aussi être effectuées à la demande de
l’organisatrice.
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 14/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.7 Rôle de l’analyse

■ Le but de l’analyse est de traduire dans un langage qui se rapproche doucement de

celui des informaticiens les modèles exprimés dans l’expression des besoins
■ Cependant, pour rester compréhensible par les clients ou utilisateurs, elle ne prend
en considération que des entités du domaine (métier)
■ Elle sert d’interface, avec l’expression des besoins, aux dialogues avec les clients et
les utilisateurs
■ L’analyse doit servir de support pour la conception, l’implantation et la maintenance
■ Le modèle de l’analyse décrit le problème (ce que doit faire le système et comment il
le fait tel que vu d’un point de vue métier) sans spécifier la solution technique (avec
les canevas logiciels)
♦ Analyse = LE-QUOI

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 15/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

2.8 Rôle de la conception

■ Le but de la conception est de fixer les choix techniques et de préparer l’implantation

■ Le modèle de la conception décrit la solution (comment le problème est résolu)
♦ Conception = LE-COMMENT
■ La conception doit servir de support pour l’implantation et la maintenance
■ Le plus souvent, le modèle de la conception n’est pas destiné à être compréhensible
par les utilisateurs mais par les développeurs

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 16/132
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML

QCM

1. Le code source d’une application est-il un modèle de l’application ?

2. UML est-il un processus de développement ?

3. Un client demandant une informatisation est-il censé comprendre les diagrammes

UML ?

4. Un développeur / programmeur est-il censé comprendre les diagrammes UML ?

5. La phase d’expression des besoins est-elle étudiée dans ce module ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 17/132
Introduction au langage de modélisation UML

3 Analyse, vues cas d’utilisation et processus

3.1 Modèle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Diagrammes d’activité * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 18/132
Introduction au langage de modélisation UML 3 Analyse, vues cas d’utilisation et processus

3.1 Modèle de l’analyse

■ Vision de l’extérieur du système, le problème :

♦ Vue cas d’utilisation = ce que fait le système, les fonctionnalités
♦ Vue processus = ce que fait le système, les règles de gestion
Aspect dynamique : interactions (séquences, communications),
machine à états
Aspect statique: paquetages,
Aspect statique : classes,
et fichiers
objets et paquetages

Vue logique Vue développement

Diagramme de cas d’utilisation Vue cas

d’utilisation

Diagramme d’activités Vue processus Vue physique

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution, Aspect répartition: déploiement,

processus, tâches, activités noeuds, modules

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 19/132
Introduction au langage de modélisation UML 3 Analyse, vues cas d’utilisation et processus

3.2 Diagrammes de cas d’utilisation

3.2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Relation de généralisation spécialisation entre acteurs. . . . . . . . . . . . . . . . . . . . . . . . .23
3.2.4 Cas d’utilisation, lien de communication et système . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5 Exemple de diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.6 Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 20/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.1 Introduction

■ Les fonctionnalités sont modélisées par des cas d’utilisation

■ Un diagramme de cas d’utilisation définit :
♦ Le système
♦ Les acteurs
♦ Les cas d’utilisation (fonctionnalités)
♦ Les liens entre acteurs et cas d’utilisation
▶ Quel acteur accède à quel cas d’utilisation ?
■ Un modèle de cas d’utilisation se définit par :
♦ Des diagrammes de cas d’utilisation
♦ Une description textuelle des scénarios d’utilisation

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 21/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.2 Acteur

■ Un acteur représente une personne, un périphérique ou un autre système qui joue un

rôle (interagit) avec le système
♦ « L’organisatrice, crée un scrutin, renseigne les plages horaires possibles et ajoute
les participants à la réunion. »
♦ « Les participants peuvent exprimer leurs préférences en indiquant pour chaque
plage horaire s’ils votent “pour” (ils sont disponibles et annoncent leur intention
de participer) ou “contre”. »

<< acteur >>

organisatrice
organisatrice

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 22/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.3 Relation de généralisation spécialisation entre acteurs

■ La généralisation spécialisation est aussi appelée héritage (EST-UN)

♦ « L’organisatrice participe au scrutin qu’elle gère. »
▶ Une organisatrice est une participante

l’acteur le plus
général

participante

le lien de
généralisation

l’acteur le plus
spécialisé

organisatrice

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 23/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.4 Cas d’utilisation, lien de communication et système

■ Un cas d’utilisation est un moyen de représenter les différentes possibilités d’un

système
■ Il correspond à une suite d’interactions entre un acteur et le système
■ Il définit une fonctionnalité utilisable par un acteur

Voter cas d’utilisation

participante lien de
communication
Ajouter un participant

Ouvrir un scrutin
limite du
système

organisatrice

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 24/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.5 Exemple de diagramme de cas d’utilisation

Voter

Consulter les résultats d’un scrutin

Se retirer d’un scrutin

Créer un scrutin
participant
Ajouter un choix

Supprimer un choix

Ajouter un participant

Retirer un participant

Ouvrir un scrutin

Fermer un scrutin

organisateur Supprimer un scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 25/132
3 Analyse, vues cas d’utilisation et processus 3.2 Diagrammes de cas d’utilisation

3.2.6 Éléments de méthodologie

■ Identifier les acteurs qui utilisent, gèrent et exécutent des fonctionnalités spécifiques
■ Organiser les acteurs par relation de généralisation spécialisation si c’est pertinent
■ Pour chaque acteur, rechercher les cas d’utilisation du système

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 26/132
 Modélisation objet élémentaire avec UML Diagrammes de cas d'utilisation

Description des cas d'utilisation 16

Le diagramme de cas d'utilisation décrit les grandes fonctions d'un

système du point de vue des acteurs, mais n'expose pas de façon
détaillée le dialogue entre les acteurs et les cas d'utilisation.
Un simple nom est tout à fait insusant pour décrire un cas
d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune
ambiguïté concernant son déroulement et ce qu'il recouvre précisément.

Pierre Gérard (P13  IUT Villetaneuse) Introduction à UML 2 DUT Informatique  S2D 32 / 342
 Modélisation objet élémentaire avec UML Diagrammes de cas d'utilisation

Description textuelle 17

Identication :
Nom du cas : Payer CB
Objectif : Détailler les étapes permettant à client de payer par carte
bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0

Pierre Gérard (P13  IUT Villetaneuse) Introduction à UML 2 DUT Informatique  S2D 33 / 342
 Modélisation objet élémentaire avec UML Diagrammes de cas d'utilisation

Description textuelle 18

Séquencements :
Le cas d'utilisation commence lorsqu'un client demande le paiement
par carte bancaire
Pré-conditions
Le client a validé sa commande
Enchaînement nominal
1 Le client saisit les informations de sa carte bancaire
2 Le système vérie que le numéro de CB est correct
3 Le système vérie la carte auprès du système bancaire
4 Le système demande au système bancaire de débiter le client
5 Le système notie le client du bon déroulement de la transaction
Enchaînements alternatifs
1 En (2) : si le numéro est incorrect, le client est averti de l'erreur, et
invité à recommencer
2 En (3) : si les informations sont erronées, elles sont re-demandées au
client
Post-conditions
La commande est validée
Le compte de l'entreprise est crédité
Pierre Gérard (P13  IUT Villetaneuse) Introduction à UML 2 DUT Informatique  S2D 33 / 342
 Modélisation objet élémentaire avec UML Diagrammes de cas d'utilisation

Description textuelle 19

Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilité : les accès doivent être sécurisés
Condentialité : les informations concernant le client ne doivent pas
être divulgués
Contraintes liées à l'interface homme-machine :
Toujours demander la validation des opérations bancaires

Pierre Gérard (P13  IUT Villetaneuse) Introduction à UML 2 DUT Informatique  S2D 33 / 342
Introduction au langage de modélisation UML 3 Analyse, vues cas d’utilisation et processus

3.3 Diagrammes d’activité *

3.3.1 Scénarios d’un cas d’utilisation * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2 Actions et choix * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3 Concurrence * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.4 Autres notations du diagramme d’activité * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 27/132
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité *

3.3.1 Scénarios d’un cas d’utilisation *

■ La description d’un cas d’utilisation se fait par des scénarios qui définissent la suite
logique des actions qui constituent ce cas
■ Il est possible de définir des scénarios simples ou des scénarios plus détaillés faisant
intervenir les variantes, les cas d’erreurs, etc.
■ La description du scénario précise ce que fait l’acteur et ce que fait le système
■ En plus de descriptions textuelles, le scénario peut être représenté en utilisant un
diagramme d’activité
■ Le diagramme d’activité permet de :
♦ Présenter « l’algorithme », c’est-à-dire les étapes de la fonctionnalité
♦ Visualiser l’aspect temporel des interactions
♦ Connaître le sens des interactions (acteur vers système ou inverse)
♦ Distinguer le cas nominal des variantes (p.ex. avec traitement des erreurs)

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 28/132
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité *

3.3.2 Actions et choix *

noeud
arête
initial

sélection type scrutin

garde
décision

[scrutin type plages horaires] [scrutin type préférences]

entrer listes plages horaires entrer liste préférences

fusion

validation création du scrutin

noeud
terminal

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 29/132
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité *

3.3.3 Concurrence *

recherche scrutin
« fork »

calcul résultat scrutin calcul liste adresses courriels

« join »

envoi résultat scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 30/132
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité *

3.3.4 Autres notations du diagramme d’activité *

attente X secondes

date / heure de démarrage

appel autre
activité

informations
transmises

X Signal X reçu par le système Y Signal Y émis par le système

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 31/132
Introduction au langage de modélisation UML 3 Analyse, vues cas d’utilisation et processus

QCM

1. Dans un diagramme de cas d’utilisation, est-il pertinent d’ajouter des cas

d’utilisation ne faisant pas partie du système ?

2. Quelles entités peuvent être dessinées dans un diagramme de cas d’utilisation ?

(a) système
(b) action
(c) acteur
(d) généralisation spécialisation

3. Dans une généralisation spécialisation entre acteurs, l’acteur spécialisé a-t-il accès à
toutes les fonctionnalités de l’acteur généralisé ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 32/132
Introduction au langage de modélisation UML

4 Analyse et conception, aspects statiques de la vue logique

4.1 Diagrammes communs à l’analyse et à la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Diagramme d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Concepts avancés du diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 33/132
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique

4.1 Diagrammes communs à l’analyse et à la conception

■ Vue logique
♦ Aspects statiques = structure du problème et de la solution
▶ Diagrammes de classes et d’objets
♦ Aspects dynamiques = comportement des éléments de la structure
▶ Diagrammes de séquence, de communications et de machine à états
Diagrammes d’interactions (séquences et communications)
Diagramme de machine à états
Diagramme de classes Aspect dynamique Aspect statique: paquetages,
et fichiers
Diagramme d’objets
Aspect statique
Vue logique Vue physique

Vue cas
d’utilisation

Vue processus Vue développement

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution, Aspect répartition: déploiement,

processus, tâches, activités noeuds, modules

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 34/132
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique

4.2 Diagramme de classes

4.2.1 Modéliser la structure logique du système dans un diagramme de classes . . . . . . 36
4.2.2 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Instanciation : création d’un objet d’une classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 Attributs et opérations de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.2.5 Attribut dérivé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.6 Association entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.7 Nom de rôle et multiplicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.8 Généralisation spécialisation ou héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.9 Généralisation spécialisation : vision ensembliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.10 Généralisation spécialisation : vision encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . .45
4.2.11 Généralisation et redéfinition d’opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.12 Méthode Polymorphique et liaison dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.13 Agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.14 Exemple de diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.15 Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 35/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.1 Modéliser la structure logique du système dans un

diagramme de classes
■ Diagramme au cœur de l’analyse et de la conception orientées objet
■ Abstraction
♦ Abstraire = ignorer / cacher des caractéristiques non significatives
♦ Ne garder que les caractéristiques d’une classe importantes pour l’intervenant
▶ Analyste versus architecte ou concepteur
■ Encapsulation comme mécanisme d’abstraction
♦ Cacher des détails en les rendant « privés » (non visibles)
▶ Par exemple, en analyse, montrer le « quoi » qui est « public » (visible)
Puis, en conception, détailler en ajoutant les éléments pour le « comment »
=⇒ Protège l’analyse des changements effectués lors de la conception dans la
partie « privée » en ne remettant pas en cause ce qui est exposé
« publiquement » au niveau métier
⋆ Par exemple, l’analyse spécifie que tel élément est un ensemble
La conception précise que c’est une liste doublement chaînée
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 36/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.2 Classe
■ Classe = famille d’objets ayant les mêmes caractéristiques et le même comportement
♦ Attributs = caractéristiques (données membres, informations, propriétés)
♦ Opérations = comportement (méthodes, fonctions, procédures, messages,
services)

Nom de la classe Attributs d’instance

de la classe

Personne Personne Personne

nom : String nom : String voter(Bulletin)
prénom : String prénom : String consulterResultat(Scrutin)
nbParticipations : Integer = 0 nbParticipations : Integer seRetirerDUnScrutin(Scrutin)
nbOrganisations : Integer = 0 nbOrganisations : Integer
Constructeur(String n, String p)
voter(Bulletin b)
consulterResultat(Scrutin s) Opérations d’instance
seRetirerDUnScrutin(Scrutin s) de la classe
Personne

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 37/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.3 Instanciation : création d’un objet d’une classe

■ Instanciation = création d’un objet à partir d’une classe

■ Objet = instance de classe

Nom Identifiant
de la classe de l’objet

Personne j:Personne

nom : String nom = "Dupont"

prénom : String prénom = "Julien"
nbParticipations : Integer = 0 nbParticipations = 7
nbOrganisations : Integer =0 nbOrganisations = 3

Constructeur(String n,String p)
voter(Bulletin b) Type Valeur
consulterResultat(Scrutin s) de l’attribut de l’attribut
seRetirerDUnScrutin(Scrutin s)

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 38/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.4 Attributs et opérations de classe

■ Le nombre total de participations est une caractéristique des personnes (classe),

donc applicable à Julien Dupont (objet)
■ L’opération getNbTotalParticipations() utilise la valeur de l’attribut
nbTotalParticipations connue par la classe
♦ Cette opération peut être appliquée directement à la classe Personne et bien sûr
aussi aux objets / instances de Personne

Attribut Personne j:Personne

d’instance
nom : String nom = Dupont
prénom = Julien
prénom : String nbParticipations = 7
Attribut nbParticipations : Integer nbOrganisation = 3
de classe nbOrganisation : Integer
nbTotalParticipations = 12
nbTotalParticipations : Integer
Constructeur(String n, String p) nom = Martin
Opération voter(Bulletin) prénom = Marie
d’instance consulterResultat() nbParticipations = 5
seRetirerDUnScrutin() nbOrganisation = 1
getNbTotalParticipations()
Opération m:Personne
de classe

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 39/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.5 Attribut dérivé

■ Attribut dérivé = attribut dépendant d’autres attributs

Personne

nom
adresse
dateNaissance
{Invariant :
/âge
âge = (dateCourante − dateNaissance) % année}

Attribut
dérivé

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 40/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.6 Association entre classes

■ Association (binaire) = relation entre (deux) classes

♦ Le sens de lecture est facultatif lorsqu’il n’y a pas d’ambiguïté

Sens de
Association Nom de lecture de
l’association l’association

organise
Personne Scrutin

:organise
m:Personne listeBDE:Scrutin

Instance Instance
de classe d’association

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 41/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.7 Nom de rôle et multiplicité

■ Nom de rôle = indication sur la participation de la classe à l’association

■ Multiplicité = contrainte sur le nombre d’objets associés

Rôle

organisateur
Personne Scrutin
1 organise *

Multiplicités
1 (par défaut)
1
1 (explicite)
3
3
0..1
0 ou 1
* 0 ou plusieurs
1..*
1 ou plusieurs
6..28
intervalle

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 42/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.8 Généralisation spécialisation ou héritage

■ Factorisation de caractéristiques (attributs et opérations)

♦ EST-UN, EST-UNE-SORTE-DE

Personne
nom
numéroSécu

Avocat Vendeur Enseignant

nombreAffaires ancienneté nombreCours
adresseCabinet nomDuStand specialité

Permanent Vacataire
numéroBureau nombreVacations

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 43/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.9 Généralisation spécialisation : vision ensembliste

Vendeur
Enseignant

Avocat Permanent
Vacataire

Personne

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 44/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.10 Généralisation spécialisation : vision encapsulation

Avocat

Vacataire Enseignant Personne

Vendeur

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 45/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.11 Généralisation et redéfinition d’opérations

MoyenTransport
désignation
vitesseLimite
age
prixHT
obtenirVitesse()
changerPrix()
obtenirÂge()
calculerAmortissement()

Camion Voiture Tramway

nombreEssieux nombrePorte nombrePassagers

capacité couleur niveauBruit
charge
calculerAmortissement() Redéfinition :
estPlein()
amortissement
incluant
les voies ferrées
VoitureEssence VoitureDiesel

nombreBougies typeInjecteur

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 46/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.12 Méthode Polymorphique et liaison dynamique

■ Méthode polymorphique :
♦ Un objet d’une classe enfant peut prendre plusieurs formes
▶ L’objet peut être utilisé partout où un objet de la classe parente est attendu
⋆ Exprimant que la classe enfant est une spécialisation de la classe parente
⋆ P.ex., void o(MoyenTransport r) accepte o(e) avec e de type Tramway
■ Liaison dynamique ou tardive :
♦ Soient une classe P et o() une opération de P
♦ Soient e un objet d’une classe E, enfant de la classe P
et o() l’opération redéfinie dans E
♦ Soit r une référence sur un objet de type P
♦ Le polymorphisme autorise à affecter à r la valeur e : r ← e
♦ Si l’opération o() est appelée sur la référence r : r.o()
et s’il y a liaison dynamique (ce qui est toujours le cas en Java p.ex.)
▶ C’est l’opération redéfinie dans la classe enfant qui est appelée
soit l’opération o() redéfinie dans E

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 47/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.13 Agrégation
■ Agrégation = une association exprimant un couplage fort lié à une relation de
subordination
♦ A-UN, EST-UNE-PARTIE-DE
■ Elle est asymétrique du type « ensemble / élément » ou « contenant / contenu »
■ Règles permettant de choisir une agrégation :
♦ Est-ce une partie de ?
♦ Les opérations appliquées à l’ensemble sont-elles appliquées à l’élément ?
♦ Les changements d’états sont-ils liés ?
■ Attention :
♦ Un élément agrégé peut être lié à d’autres classes
♦ La suppression de l’ensemble n’entraîne pas celle de l’élément
3..*
Polygone Point

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 48/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.14 Exemple de diagramme de classes

Personne * Scrutin
* nbTotalParticipations intituléScrutin
organise
nbTotalOrganisations texteCommentaireScrutin
nbParticipations * dateCréation
nbOrganisations dateDébut
prenom dateLimite
nom dateLimiteExistence
ouvertureAvancée
fermetureAvancée
destructionAvancée
nbTotalScrutin
ScrutinPlagesHoraires ScrutinPréférences
concerne

/nbChoix
concerne
nbTotal nbTotal

* *
PlageHoraire Préférence
* *
Bulletin date intituléPréférence
* heureDébut texteCommentairePréf
pourOuContre heureFin

* concerne Choix
Studs
/nbBulletinsPour
/nbBulletinsContre
*
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 49/132
4 Analyse et conception, aspects statiques de la vue logique 4.2 Diagramme de classes

4.2.15 Éléments de méthodologie

■ Analysez le texte pour rechercher les noms qui sont des classes métier et les verbes
qui les relient qui sont des associations
■ Construisez un premier diagramme de classes à partir de ces noms
■ Enrichissez ce diagramme avec les associations à l’aide des verbes obtenus
■ Affinez le diagramme en éliminant les associations redondantes,
en simplifiant le schéma dès lors qu’il respecte les spécifications de l’énoncé
■ Ne cherchez les généralisations spécialisations que lorsque les classes sont déjà bien
établies
■ Ne cherhez les agrégations qu’à la fin
■ Terminez cette première version du diagramme en ajoutant les multiplicités
■ Dans une seconde itération seulement, ajoutez les attributs et les opérations
■ Pensez à vérifier que tous les concepts métier sont présents
■ Pensez à vérifier que vous pouvez réaliser les cas d’utilisation par parcours du
graphe de classes
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 50/132
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique

4.3 Diagramme d’objets

■ Illustration des liens entre objets dans un scénario / une configuration donnée

:organise
:Personne v1:ScrutinPlagesHoraires
:org
ani
se

v2:ScrutinPlagesHoraires

:Bulletin v3:ScrutinPréférences

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 51/132
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique

QCM
1. Quelles entités peuvent être dessinées dans un diagramme de classes ?
(a) opération
(b) acteur
(c) généralisation spécialisation
(d) association

2. Une classe est-elle une instance d’objet ?

3. Dans un diagramme de classes, tous les attributs d’une classe doivent-ils être
spécifiés ?
4. Sans multiplicité spécifiée explicitement, est-il supposé par défaut « * » ?
5. La généralisation spécialisation est-elle représentée par une relation avec un triangle
blanc à une extrémité ?
6. Soit E une classe enfant de la classe parente P, tout objet de classe E peut-il être
utilisé là où un objet de type P est attendu ?
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 52/132
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique

4.4 Concepts avancés du diagramme de classes

4.4.1 Navigabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.2 Classe d’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Composition : agrégation forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.4 Classe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.6 Classe paramétrée / générique *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
4.4.7 Exemple de diagramme de classes avancé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 53/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.1 Navigabilité

■ Par défaut, une association est bidirectionnelle

■ Il est possible de réduire la portée en la rendant unidirectionnelle
■ En général, ce choix se fait dans la phase de conception

Navigabilité

Personne Scrutin
organise

Personne Scrutin
organise

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 54/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.2 Classe d’association

* *
Écrivain Paragraphe

Note
contenu
date

e:Écrivain p:Paragraphe

n:Note

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 55/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.3 Composition : agrégation forte

■ La composition est une agrégation forte qui lie les cycles de vie entre le composé
(ensemble) et les composants (éléments)
■ Le choix entre composition et agrégation peut être pris lors de la phase de
conception

4
Voiture Roue

2..5
Carrosserie Porte

Moteur Habitacle

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 56/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.4 Classe abstraite

■ Un Média peut être transporté, dupliqué, affiché. Le transport et la duplication sont
indépendants du type de Média (copie de fichiers). Par contre, tout Média peut être
affiché et ce n’est pas la même chose pour Livre, Vidéo, Graphique ou Texte. Un
Média ne peut pas définir comment il s’affiche tant qu’il ne sait pas ce qu’il est.
■ Il n’existe pas d’instance de la classe Média. Un Média n’existe qu’en tant que
Livre, Texte, Graphique ou Vidéo.
<< abstract >> Nom de la classe
Média en italique ou
auteur
titre utilisation du
dateCréation stéréotype <<abstract>>
transporter()
dupliquer()
afficher()

Livre Texte Graphique Vidéo

largeur
longueur durée
hauteur

afficher() afficher() afficher() afficher()

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 57/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.5 Interface
■ Une interface n’est pas une classe, c’est une liste d’opérations
■ Une interface, comme une classe abstraite, ne peut pas servir à créer un objet
■ Une interface exprime un savoir-faire, un contrat à respecter par les classes qui
« réalisent » cette interface
<<interface>>
Déplaçable
saPlace()
avancer()
reculer()
monter()
descendre()

Polygone Personne
sommets nom
numSécu
saPlace()
avancer() saPlace()
reculer() avancer()
monter() reculer()
descendre() monter()
descendre()

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 58/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.6 Classe paramétrée / générique *

■ Classe paramétrée / générique = paramétrée par des types

♦ Attributs génériques = typés avec le type en paramètre
♦ Opérations génériques = arguments et / ou type de retour génériques

Paramètre
E de type
ListeDeChoses

élément : E Attribut
taille : Integer générique
premierÉlément : E
dernierÉlément : E

ajouter(E) Opération
estPrésent(E) générique
retirer(E)

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 59/132
4 Analyse et conception, aspects statiques de la vue logique 4.4 Concepts avancés du diagramme de classes

4.4.7 Exemple de diagramme de classes avancé

Personne * Scrutin
* nbTotalParticipations intituléScrutin
organise
nbTotalOrganisations texteCommentaireScrutin
nbParticipations * dateCréation
nbOrganisations dateDébut
prenom dateLimite
nom dateLimiteExistence
ouvertureAvancée
fermetureAvancée
destructionAvancée
nbTotalScrutin
nbChoix
ScrutinPlagesHoraires ScrutinPréférences
concerne

concerne
nbTotal nbTotal

* *
PlageHoraire Préférence
* *
Bulletin date intituléPréférence
* heureDébut texteCommentairePréf
pourOuContre heureFin

* concerne Choix
Studs
/nbBulletinsPour
/nbBulletinsContre
*
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 60/132
Introduction au langage de modélisation UML

5 Analyse et conception, aspects dynamiques de la vue logique

5.1 Rappel : diagrammes communs à l’analyse et à la conception . . . . . . . . . . . . . . . . . . . 62

5.2 Modélisation des aspects dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Diagramme de communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Diagramme de machine à états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 61/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

5.1 Rappel : diagrammes communs à l’analyse et à la conception

■ Vue logique
♦ Aspects statiques = structure du problème et de la solution
▶ Diagrammes de classes et d’objets
♦ Aspects dynamiques = comportement des éléments de la structure
▶ Diagrammes de séquence, de communications et de machine à états
Diagrammes d’interactions (séquences et communications)
Diagramme de machine à états
Diagramme de classes Aspect dynamique Aspect statique: paquetages,
et fichiers
Diagramme d’objets
Aspect statique
Vue logique Vue physique

Vue cas
d’utilisation

Vue processus Vue développement

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution, Aspect répartition: déploiement,

processus, tâches, activités noeuds, modules

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 62/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

5.2 Modélisation des aspects dynamiques

■ Points de départ : Modèles de la vue cas d’utilisation + diagrammes de classes
■ Objectif : modéliser les algorithmes des cas d’utilisation
Voter

Consulter les résultats d’un scrutin

Se retirer d’un scrutin

Studs
Créer un scrutin
participant
Ajouter un choix
voter(...) : ...
Supprimer un choix
consulterRésultatsScrutin(...) : ...
Ajouter un participant seRetirerScrutin(...) : ...
Retirer un participant créerScrutin(...) : ...
Ouvrir un scrutin ajoutChoixAScrutin(...) : ...
Fermer un scrutin
suprimerChoixAScruting(...) : ...
organisateur
ajouterPersonneScruting(...) : ...
Supprimer un scrutin
retirerPersonneAScrutin(...) : ...
ouvrirScrutin(...) : ...
Personne * Scrutin fermerScrutin(...) : ...
* nbTotalParticipations intituléScrutin supprimerScrutin(...) : ...
organise
nbTotalOrganisations texteCommentaireScrutin
nbParticipations * dateCréation retirerPersonneAScrutin(...) : ...
nbOrganisations dateDébut
prenom dateLimite
nom dateLimiteExistence
ouvertureAvancée
fermetureAvancée
destructionAvancée
nbTotalScrutin
ScrutinPlagesHoraires ScrutinPréférences
nbChoix
concerne

concerne
nbTotal nbTotal

Modèles dynamiques
* * − diagrammes de séquence
* *
PlageHoraire Préférence − diagrammes de communications
Bulletin date intituléPréférence − diagrammes de machines à états
* heureDébut texteCommentairePréf
pourOuContre heureFin

* concerne Choix
Studs
/nbBulletinsPour
/nbBulletinsContre
*

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 63/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.2 Modélisation des aspects dynamiques

5.2.1 Algorithme : orientations procédurale et objet

Orientation procédurale Orientation objet

int get_bulletin(personne *p) {

Personne * Scrutin
* nbTotalParticipations intituléScrutin
organise
nbTotalOrganisations texteCommentaireScrutin
création, nbParticipations * dateCréation
lecture, nbOrganisations dateDébut
écriture, struct personne { prenom dateLimite
suppression nom dateLimiteExistence
... ouvertureAvancée
création, } fermetureAvancée
lecture, destructionAvancée
écriture, nbTotalScrutin
suppression ScrutinPlagesHoraires ScrutinPréférences
struct scrutin { nbChoix

concerne
concerne
... nbTotal nbTotal
création,
lecture, }
écriture,
suppression
struct bulletin { * *
PlageHoraire Préférence
... * *
} Bulletin date intituléPréférence
* heureDébut texteCommentairePréf
pourOuContre heureFin

} * concerne Choix
Studs
/nbBulletinsPour
/nbBulletinsContre
*
getBulletin(Personne p) : booléen

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 64/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.2 Modélisation des aspects dynamiques

5.2.2 Modèle dynamique de l’analyse et de la conception

■ Les différents diagrammes du modèle dynamique de l’analyse et de la conception

sont :
♦ Diagramme de séquence : ordre des interactions entre objets
♦ Diagramme de communications : répartition des interactions sur les liens entre
objets
♦ Diagramme de machine à états : comportement des objets selon leurs états

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 65/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

5.3 Diagramme de séquence

5.3.1 Modéliser l’ordre des interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.2 Participant, temps et message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin » . . . . . . . . . . . . . . . . . . . . 69
5.3.4 Syntaxe et types de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.5 Création et suppression d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.6 Fragments de séquence « ref » et « opt » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3.7 Fragment de séquence « loop » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 66/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.1 Modéliser l’ordre des interactions

■ Le diagramme de séquence capture l’aspect temporel des échanges entre

participantsa
■ Un diagramme de séquence spécifie le comportement d’un cas d’utilisation ou d’une
partie de celui-ci

a. Au sens UML du terme.

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 67/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.2 Participant, temps et message

Participants :
acteur ou objet,
voire classe

o1:C1 o2:C2
message

opération()
Barre
Message / d’activation
événement

opération2()
Appel au
même objet

Ligne
de vie

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 68/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin »

:Studs Scrutin s:Scrutin

ouvrirScrutin(intitulé)
s=chercher(intitulé):Scrutin

avancerDateOuverture()

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 69/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.4 Syntaxe et types de messages

■ Syntaxe complète
♦ attribut = nomMessage(arguments) : type_retour
▶ attribut peut être un attribut de l’objet appelant ou une variable locale
▶ nom_message est une opération de l’objet appelé

■ Synchrone : l’expéditeur est bloqué pendant le traitement

♦ Le retour d’appel est optionnel (implicite)
■ Asynchrone : l’expéditeur continue son exécution pendant le traitement du message

:Client :Serveur :AutreServeur

appelSynchrone()
appelAsynchrone()
appelAsynchrone()
synchrone
appelAsynchrone()
retour d’appel
appelSynchrone2()
asynchrone

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 70/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.5 Création et suppression d’objets

:Studs p:Personne

creationScrutin(p)
créationScrutin()
<< create(p) >>
s:Scrutin

<<new>> <<delete>> <<transient>>

<< create() >> << create() >>
c:Classe c:Classe c:Classe c:Classe
create(arguments)
<< destroy() >> << destroy() >> << destroy() >>

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 71/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.6 Fragments de séquence « ref » et « opt »

■ ref : sous-séquence détaillée dans un autre diagramme de séquence

■ opt : sous-séquence optionnelle exécutée si condition de garde est vraie

:Studs p:Personne s:Scrutin c:Choix

voter(p,s,c,poc)

ref
PeutVoter
Type du
fragment
opt [peutVoter = true]
<<create(p,s,
c,poc)>> b:Bulletin Condition
d’entrée
voter(b)
Contours du
fragment voter(b)
voter(b,poc)

poc ≡ « pour ou contre »

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 72/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.3 Diagramme de séquence

5.3.7 Fragment de séquence « loop »

■ loop : boucle un nombre maximum de fois tant que la condition est vraie
♦ loop(valeur initiale, maximum, condition)

:Studs p:Personne

pv = peutVoter(s) : boolean

cb = getBulletins() : Collection de Bulletin

av = setTo(false)

loop(1,cb.size(),av)

:Bulletin

av = aDejaVote(s) : boolean
sb = getScrutin()

av = (s == sb)

pv = not av

pv ≡ « peut voter », av ≡ « a voté »

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 73/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

QCM

1. Quelles entités peuvent être dessinées dans un diagramme de séquence ?

(a) fragment
(b) instance
(c) message
(d) condition
(e) opération

2. Un objet se distingue-t-il d’une classe parce qu’il est souligné ?

3. Pendant un message synchrone, l’expéditeur est-il bloqué en attente d’une réponse ?

4. En réponse à un message synchrone, l’appelé renvoie-t-il un seul retour d’appel ?

5. Un fragment de séquence est-il une partie optionnelle d’une séquence ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 74/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

5.4 Diagramme de communications

5.4.1 Modéliser les liens d’interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4.2 Participant, lien d’interaction, message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.4.3 Message conditionné, messages en séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.4.4 Messages emboîtés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4.5 Itération de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4.6 Collection et recherche dans une collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4.7 Messages concurrents * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.8 Choix entre séquence et communications* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 75/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.1 Modéliser les liens d’interactions

■ Le diagramme de communications montre la structure spatiale des interactions entre

participants
■ L’attention est mise sur les liens d’interactions, qui ne sont qu’implicites dans le
diagramme de séquence

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 76/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.2 Participant, lien d’interaction, message

consulter(nom,
prénom,intituléScrutin)

1:p=getParticipant(nom,prénom) : Personne
Personne :Studs

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 77/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.3 Message conditionné, messages en séquence

consulter(nom,
prénom,intituléScrutin)

1:p=getParticipant(nom,prénom) : Personne
Personne :Studs

2:s=vérifierParticipationScrutin(intituléScrutin):Scrutin [p!=null] 3:cb=getBulletins():

Collection(Bulletin) [s!=null]

p:Personne
s:Scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 78/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.4 Messages emboîtés

consulter(nom,
prénom,intituléScrutin)

1:p=getParticipant(nom,prénom) : Personne
Personne :Studs

2:s=vérifierParticipationScrutin(intituléScrutin):Scrutin [p!=null] 3:cb=getBulletins():

Collection(Bulletin) [s!=null]
2.1:s=getScrutin(intituléScrutin)

Scrutin p:Personne
s:Scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 79/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.5 Itération de messages

consulter(nom,
prénom,intituléScrutin)

1:p=getParticipant(nom,prénom) : Personne
Personne :Studs

2:s=vérifierParticipationScrutin(intituléScrutin):Scrutin [p!=null] 3:cb=getBulletins():

Collection(Bulletin) [s!=null]
2.1:s=getScrutin(intituléScrutin)

Scrutin p:Personne
s:Scrutin

4:*[i=1..cb.size()]afficherInfosBulletin()
[s!=null]
4.i.1:afficherInfosParticipant(b) [b.personne=p]
À l’itération i,
b:Bulletin
manipulation de
l’instance b
4.i.2:afficherInfosChoix(b) [b.personne=p]
:Choix

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 80/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.6 Collection et recherche dans une collection

op1()

1:p=getParticipant(nom,prénom) : Personne
Personne :Studs

2:*[!trouvé]trouvé=correspondre(intitulé):booléen

:Scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 81/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.7 Messages concurrents *

op1()

1:op2()
Personne :Studs

2.a:op3() 2.b:op4()

2.a.1:op31()

Scrutin p:Personne
s:Scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 82/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.4 Diagramme de communications

5.4.8 Choix entre séquence et communications*

■ Les plus du diagramme de séquence :
♦ Montrer l’ordre des interactions : le premier objectif du diagramme
♦ Montrer les messages asynchrones : différents types de messages
♦ Montrer les parties optionnelles, les itérations : concept de fragments
■ Les plus du diagramme de communications :
♦ Montrer les liens entre participants : le premier objectif du diagramme
▶ Lien visuel direct avec le graphe des classes du diagramme de classes
♦ Montrer les participants : l’un des objectifs du diagramme
♦ Un peu plus facile à construire et à adapter : numérotation plutôt que
séquencement
■ Les deux sont équivalents pour :
♦ Montrer la signature des messages / opérations
♦ Montrer le parallélisme
▶ Diagramme de séquence : message asynchrone et fragment par
▶ Diagramme de communications : numérotation des messages
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 83/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

QCM

1. Quelles entités peuvent être dessinées dans un diagramme de communications ?

(a) fragment
(b) message
(c) condition
(d) ligne de vie
(e) lien d’interaction

2. Est-ce que plusieurs messages peuvent transiter sur un même lien d’interaction ?

3. Un diagramme de séquence et un diagramme de communications peuvent-ils

contenir des classes ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 84/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

5.5 Diagramme de machine à états

5.5.1 Modéliser l’état des objets d’une classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.5.2 Types d’états, événement et transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5.3 Événement, condition et action d’une transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.4 Transition implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5.5 Exemple de diagramme de machine à états de la classe Scrutin . . . . . . . . . . . . . . . 90
5.5.6 Actions liées à un état . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.7 Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.5.8 État composite * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 85/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.1 Modéliser l’état des objets d’une classe

■ Certaines classes sont plus complexes et influent de manière plus importante sur le
comportement général du système
■ Il est important de décrire les événements provoquant les changements d’états des
objets de ces classes
■ Les changements d’états sont décrits dans des machines à états
■ Une machine à états décrit les états des objets d’une classe
■ Une machine à états par classe est spécifiée

■ Exemple de question de l’étude de cas Studs : peut-on (déjà, encore) voter ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 86/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.2 Types d’états, événement et transition

■ L’état d’un objet est lié aux valeurs de ses attributs et des interactions avec les
autres objets
■ Il s’agit de ne conserver que les états significatifs
■ La réponse d’un objet à un événement dépend de l’état de l’objet
■ Un objet passe dans un état donné par l’événement qui modifie ses attributs, et
quitte cet état par un autre événement qui les modifie à nouveau
Transition Événement

État initial État final

événement4
Rouge

État
événement3
événement1

événement2
Orange Vert

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 87/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.3 Événement, condition et action d’une transition

■ Syntaxe complète
♦ événement[condition]/action
■ La transition est déclenchée par un événement
■ La transition est effectivement franchie si la condition (sur l’état de l’objet) est
valide
■ Le franchissement déclenche l’exécution de l’action de la transition
♦ Cette action est considérée comme immédiate et atomique

■ Si plusieurs transitions sont franchissables, alors la transition effectivement franchie

est choisie aléatoirement

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 88/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.4 Transition implicite

Transition
implicite

EnConstruction NonCapturée

entrée : constructeur()

le joueur adverse
capture par un
artie
la p
de
tion
t ruc
des

EnDestruction destruction de la partie Capturée

entrée : destructeur()

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 89/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.5 Exemple de diagramme de machine à états de la classe

Scrutin

EnConstruction
entrée : constructeur()

[dateDuJour>=dateDebut]/annoncerOuverture()
EnAttenteOuverture ScrutinOuvert

ouverture du scrutin par l’organisatrice/

avancerOuverture()

clôture du scrutin par l’organisatrice/ [dateDuJour > dateLimite]

avancerFermeture()

[dateDuJour > dateLimiteExistence]

EnDestruction ScrutinFermé
entrée : destructeur() suppression du scrutin par l’organisatrice/
avancerDestruction()

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 90/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.6 Actions liées à un état

■ Actions exécutées à l’entrée et à la sortie d’un état

■ Action exécutée pendant toute la durée de présence dans l’état
■ Action interne déclenchée par un événement

événement[condition]/action

Transtion État n
réflexive
entry: action en entrée de l’état
do: activité pendant l’état
événement1[condition1]: action1
événement2[condition2]: action2
...
exit: action en sortie d’état

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 91/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.7 Éléments de méthodologie

■ Seuls les états quelque peu stables sont pertinents

■ Les attributs constants (possédant toujours la même valeur une fois que l’objet est
construit) n’interviennent pas dans la recherche des états
■ Les attributs qui changent de valeur aident souvent à déduire les états possibles
♦ Et particulièrement les attributs booléens
■ Il est souvent intéressant d’insérer de manière systématique un état de création de
l’objet (initialisation des attributs) et un état de destruction
■ Une attention particulière est à porter sur les événements et les actions

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 92/132
5 Analyse et conception, aspects dynamiques de la vue logique 5.5 Diagramme de machine à états

5.5.8 État composite *

Régions Sous−état

État composite 1

Sous−état 1

événement 1
Sous−état 3 Sous−état 2
événement 2

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 93/132
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique

QCM

1. Quelles entités peuvent être dessinées dans un diagramme de machine à états ?

(a) fragment
(b) message
(c) condition
(d) objet
(e) état initial
(f) transition

2. Une transition réflexive peut-elle provoquer la séquence d’actions « exit », « action

de la transition », « entry », et « do » ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 94/132
Introduction au langage de modélisation UML

6 Conception, aspects langage et technique

6.1 Rappel des phases du cycle de développement en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2 Conception des classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . . . . . . . . . . . . . . . . . . . . . 98
6.4 Traduction des associations en attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.5 Traduction des agrégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.6 Traduction des compositions * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.7 Traduction de la classe « Façade » du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations . . . . . . . . . . 104
6.9 Traduction des attributs dérivés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.10 Qualification de certaines associations * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.11 Traduction des diagrammes d’interaction en algorithmes . . . . . . . . . . . . . . . . . . . . . 110
6.12 Traduction des diagrammes de machine à états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.13 Traduction des relations de généralisation spécialisation . . . . . . . . . . . . . . . . . . . . . . 113
6.14 Traduction des classes d’association * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.15 Méthodologie : une fiche par classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 95/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.1 Rappel des phases du cycle de développement en V

Cahier des charges Produit

S’accorder sur ce Le système est−il

qui doit être fait Expression des besoins Recette conforme au
dans le système cahier des
charges ?

Comprendre les Le système est−il

besoins, les décrire Analyse Tests de validation conforme
dans le système à l’analyse ?

Les différentes parties

du logiciel
S’accorder sur la manière dont Conception
Tests d’intégration
le système doit être construit fonctionnent−elles
correctement ensemble ?

Codage du résultat Pour un objet, chaque opération

de la conception Implantation Tests unitaires
fonctionne−t−elle correctement ?

Code exécutable

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 96/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.2 Conception des classes

Collecte et définition des opérations

Collecte et définition des attributs
Modèle structurel

Décisions de conception
Diagrammes de classes de l’analyse

Diagrammes de classes
de la conception
+
1 fiche par classe

Modèle dynamique
Diagrammes de machine à états
Diagrammes de communications
Diagrammes de séquence

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 97/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.3 Rappel du diagramme de classes de l’étude de cas Studs

Personne * Scrutin
* nbTotalParticipations intituléScrutin
organise
nbTotalOrganisations texteCommentaireScrutin
nbParticipations * dateCréation
nbOrganisations dateDébut
prenom dateLimite
nom dateLimiteExistence
ouvertureAvancée
fermetureAvancée
destructionAvancée
nbTotalScrutin
nbChoix
ScrutinPlagesHoraires ScrutinPréférences
concerne

concerne
nbTotal nbTotal

* *
PlageHoraire Préférence
* *
Bulletin date intituléPréférence
* heureDébut texteCommentairePréf
pourOuContre heureFin

* concerne Choix
Studs
/nbBulletinsPour
/nbBulletinsContre
*
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 98/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.4 Traduction des associations en attributs

Personne * Scrutin

nbTotalParticipations organise intituléScrutin

nbTotalOrganisations * texteCommentaireScrutin
nbParticipations dateCréation
nbOrganisations dateDébut
prénom dateLimite
nom concerne dateLimiteExistence
ouvertureAvancée
fermetureAvancée
destructionAvancée
nbTotalScrutin
nbChoix

Traduction des associations

* de la classe Scrutin :
Bulletin organisateur : @Personne
bulletins : Collection ordonnée @Bulletin
pourOuContre
Studs Pas de référence vers un objet Studs
à cause de la navigabilité

■ Concept de « référence » :
♦ À partir d’un objet Scrutin, il est possible « d’aller vers » un objet Personne et
vers une collection d’objets Bulletin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 99/132
6 Conception, aspects langage et technique 6.4 Traduction des associations en attributs

6.4.1 Règles de traduction

■ Attribut du type référence sur un objet de la classe à l’autre extrémité de
l’association
♦ Référence notée « @ »
■ Autant d’attributs que de classes auxquelles elle est reliée
♦ Association binaire = 1 attribut
♦ Association n-aire = n − 1 attributs
■ Association unidirectionnelle = pas d’attribut du côté de la flèche
■ Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association
■ Traduction des multiplicités
♦ 1 =⇒ @Classe
♦ ∗ =⇒ Collection @Classe
♦ 0..N =⇒ Tableau[N] Classe
■ Multiplicité avec tri = Collection ordonnée @Classe
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 100/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.5 Traduction des agrégations

■ Agrégation = association, avec les mêmes règles de traduction en attribut

4
Voiture Roue

2..5
Carrosserie Porte

Moteur Habitacle

attributs ajoutés : attributs ajoutés :

roues : Tableau[4] de @Roue portes : Collection de @Porte
carosserie : @Carosserie habitacle : @Habitacle
moteur : @ Moteur

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 101/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.6 Traduction des compositions *

4
Voiture Roue

2..5
Carrosserie Porte

Moteur Habitacle

Contrôle du cycle de vie des éléments : Contrôle du cycle de vie des éléments :
constructeur() { // possiblement constructeur() { // possiblement
création objets Roue création objets Porte
création objet Carroserie création objet Habitacle
création objet Moteur }
}
desrtucteur() { // obligatoirement
destructeur() { // obligatoirement destruction objets Porte
destruction objets Roue destruction objet Habitacle
destruction objet Carosserie }
destruction objet Moteur
}

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 102/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.7 Traduction de la classe « Façade » du système

■ Un constructeur et un destructeur (cf. traduction des agrégation et composition)
■ Une opération (publique) par cas d’utilisation

Studs

+ constructeur(...)
+ destructeur(...)
+ voter(...)
+ consulterRésultatScrutin(...)
+ seRetirerScrutin(...)
+ créerScrutin(...)
+ ajouterUnChoix(...)
+ supprimerUnChoix(...)
+ ajouterUnParticipant(...)
+ retirerUnParticipant(...)
+ ouvrirUnScrutin(...)
+ fermerUnScrutin(...)
+ supprimerUnScrutin(...)

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 103/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.8 Encapsulation : visibilité / accessibilité des attributs et des

opérations

■ Doit-on voir / accéder à tous les attributs ou à toutes les opérations d’un objet ?
Non
♦ La classe définit ce qui est visible / accessible
▶ C’est le principe de l’encapsulation
♦ Un objet complexe ne peut être utilisé qu’au travers de ce qui est accessible
■ Analogie :
♦ Il n’est possible d’utiliser une voiture qu’à travers son volant, son frein, son
accélérateur, etc.
♦ L’accès au carburateur est impossible sauf par les méthodes qui le font de
manière cohérente (méthode accélérer de l’accélérateur )

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 104/132
6 Conception, aspects langage et technique 6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations

6.8.1 Encapsulation avec le concept de Visibilité

■ Les attributs sont en général inaccessibles (secrets). Ils sont alors qualifiés de :
♦ « private » : notation UML « − »
♦ Lecture ou modification uniquement possibles au travers des opérations
(p.ex. les accesseurs : getAdresse(), setAdresse())
■ Les opérations sont en général accessibles par toutes les classes. Elles sont alors
qualifiées de :
♦ « public » : notation UML « + »
■ Certains attributs doivent être accessibles par les classes enfants et inaccessibles aux
autres classes. Ils sont alors qualifiés de :
♦ « protected » : notation UML « # »
■ Certaines opérations peuvent cependant être privées (factorisation interne de
traitements) et certains attributs peuvent être publics (même si cela est non
souhaitable selon le principe d’encapsulation)

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 105/132
6 Conception, aspects langage et technique 6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations

6.8.2 Notation UML

Scrutin

− intituléScrutin : String
Attribut
− texteCommentaireScrutin : String
privé
− dateCréation : Date
− dateDébutVote : Date
− dateLimiteVote : Date
− dateLimiteExistence : Date Attribut
− ouvertureAvancée : booléen protégé
− fermetureAvancée : booléen
− destructionAvancée : booléen
# nbTotalScrutin : integer
− organisateur : @Personne
− bulletins : Collection ordonnée @Bulletin

+ ajouterBulletin(Bulletin) : void
Opération
+ nAPasDejaVote(Participant) : boolean
publique
+ getBulletins() : Collection @Bulletin
+ avancerDateOuverture(Date) : void
+ avancerDateFermeture(Date) : void
+ avancerDateLimiteExistence(Date) : void Opération
# afficherScrutin() : String protégée
+ getScrutin(String) : Scrutin

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 106/132
6 Conception, aspects langage et technique 6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations

6.8.3 Cas particulier des attributs/opérations protégés

■ Attribut/opération protégé/e =
♦ Accessible par les classes enfants
♦ Inaccessible par les autres classes
■ Par exemple, opération afficherScrutin() de la classe Scrutin
♦ La classe ScrutinPlagesHoraires peut utiliser l’opération de la classe Scrutin dans
l’algorithme de son opération afficherScrutin() :
String afficherScrutin() {
...
appela de l’opération afficherScrutin() de classe parente
...
}

a. Nous étudions dans quelques diapositives comment faire cet appel.

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 107/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.9 Traduction des attributs dérivés

■ Attribut dérivé =⇒ opération ou attribut selon qu’il est ou non recalculé à chaque
fois que sa valeur est lue (p.ex. dans un accesseur)
■ Par exemple, deux possibilités pour l’attribut nbBulletinsPour de la classe Choix
1. Définition d’un attribut dans la classe Choix
Dans l’opération voter(), incrémentation si le vote est « pour »
Lorsque demandé, fourniture de la valeur de l’attribut
Mais, attention à la suppression d’un bulletin !
2. Définition d’une opération getNbBulletinsPour()
L’opération getNbBulletinsPour parcourt tous les bulletins pour le calcul

Bulletin
pourOuContre

* concerne Choix
/nbBulletinsPour
/nbBulletinsContre
*
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 108/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.10 Qualification de certaines associations *

■ numéroCompte et nom sont des attributs des classes CompteBancaire et Fichier,

respectivement
■ numéroCompte et nom sont les clefs de leur classe respective
■ Le choix de l’association qualifiée peut être laissé à la phase de conception

gère
Banque numéroCompte CompteBancaire

gère
Répertoire nom Fichier

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 109/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.11 Traduction des diagrammes d’interaction en algorithmes

:Studs p:Personne s:Scrutin c:Choix

opt [peut_voter = true]

<<create(p,s,
c,poc)>> b:Bulletin

voter(b)

voter(b)
voter(b)

■ Impact sur la classe Bulletin

♦ Attributs constructeur(@Personne p, @Scrutin s,
@Choix c, boolean poc) {
▶ personne : @Personne
personne = p
▶ scrutin : @Scrutin
scrutin = s
▶ choix : @Choix
choix = c
▶ pourOuContre : boolean pourOuContre = poc
p.voter(b); s.voter(b); c.voter(b)
}
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 110/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.12 Traduction des diagrammes de machine à états

[dateDuJour >= dateDébut]
EnConstruction ScrutinOuvert

entrée : constructeur() ouverture du scrutin par l’organisateur/

avancerOuverture()

clôture du scrutin par l’organisateur/ [dateDuJour > dateLimite]

avancerFermeture()

[dateDuJour > dateLimiteExistence]

EnDestruction ScrutinFermé
entrée : détruire suppression du scrutin par l’organisateur/
avancerDestruction()

■ Attributs utilisés dans la machine à états ■ Valeur des attributs dans les différents états
♦ dateDébut : date ♦ EnConstruction : valeurs par défaut
♦ dateLimite : date ♦ ScrutinOuvert : ouvert = true
♦ dateLimiteExistence : date ♦ ScrutinFermé : ouvert = false et
♦ ouvert : boolean = false (dateJour > dateLimite ou fermetureA = true)
♦ ouvertureAvancée : boolean = false ♦ EnDestruction : ouvert = false et
♦ fermetureAvancée : boolean = false (dateJour > dateLE ou destructionA = true)
♦ destructionAvancée : boolean = false

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 111/132
6 Conception, aspects langage et technique 6.12 Traduction des diagrammes de machine à états

6.12.1 Quelques opérations de la classe Scrutin

constructeur(...) { vérifierAuQuotidien() {
... si ((dateJour >= dateDébut)
vérification et (ouvertureAvancée == false))
dateDébut < dateLimite < alors ouvert = true
dateLimiteExistence si ((dateJour > dateLimite)
} et (fermetureAvancée == false))
avancerOuverture() { alors ouvert = false
ouvert = true si ((dateJour > dateLimiteExistence)
ouvertureAvancée = true et (destructionAvancée == false))
} alors en destruction
avancerFermeture() { }
ouvert = false
fermetureAvancée = true
}
avancerDestruction() {
destructionAvancée = true
}

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 112/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.13 Traduction des relations de généralisation spécialisation

■ Dans les classes enfants, possibilité d’appel au constructeur de la classe parente (si
public ou protégé)
♦ Par exemple, dans la classe enfant ScrutinPlageHoraire :
constructeur(...) {
super(...) // appel au constructeur de la classe parente Scrutin
nbTotal = 0
}
♦ L’appel au constructeur de la classe parente doit être la première instruction
■ Dans les classes enfants, possibilité d’appel des opérations de la classe parente (si
publique ou protégée)
♦ Par exemple, dans la classe enfant ScrutinPlageHoraire :
afficherScrutin() { // opération redéfinie dans la classe enfant
super.afficherScrutin() // appel à l’opération de classe parente Scrutin
afficher à l’écran la valeur de l’attribut nbTotal
}

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 113/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.14 Traduction des classes d’association *

Note
contenu
date

* *
Écrivain Paragraphe

Traduction des multiplicités :

1−−−1 devient 1−−−1 et 1−−−1
*−−−* devient 1−−−* et *−−−1
1−−−* devient 1−−−* et 1−−−1
*−−−1 devient 1−−−1 et *−−−1

Écrivain Paragraphe

Note

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 114/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

6.15 Méthodologie : une fiche par classe

■ Collecter dans une fiche par classe

♦ Tous les attributs
♦ Toutes les opérations
■ Sources : cahier des charges, et diagrammes de classes, de machine à états, de
communications et de séquence
■ Homogénéisation des noms : même terme pour le même concept métier
■ La conception est une préparation de la phase de mise en œuvre
♦ Traduction des associations
▶ Attribut « d’association » = référence
♦ Traduction des attributs dérivés en attributs ou opérations
♦ Traduction des diagrammes d’interaction et de machine à états
▶ Définition des algorithmes des opérations
♦ Traduction des généralisations spécialisations
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 115/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

♦ Fixation de l’accessibilité des attributs et des opérations

▶ Propriété d’encapsulation

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 116/132
Introduction au langage de modélisation UML 6 Conception, aspects langage et technique

QCM

1. Pour traduire une association binaire, faut-il regarder le sens de lecture de

l’association ?

2. Une multiplicité « 0..1 » se traduit-elle par un attribut référence sur la classe à

l’autre extrémité de l’association binaire ?

3. La notation pour un attribut privé est-elle « − » ?

4. Étant donné une classe A contenant l’attribut a et une classe B contenant la

méthode b, si a est privé et b est publique, b peut-elle utiliser a ?

5. Un attribut dérivé peut-il être traduit par un attribut ?

6. Un message d’un diagramme de séquence est-il la plupart du temps traduit en une

opération privée ?

7. Le mot clef « super » permet-il d’appeler une opération de la classe parente ?

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 117/132
Introduction au langage de modélisation UML

7 Conception, vues développement et physique

7.1 Diagrammes de la vue développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.2 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.3 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.4 Diagramme de la vue physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7.5 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 118/132
Introduction au langage de modélisation UML 7 Conception, vues développement et physique

7.1 Diagrammes de la vue développement

■ Composant = partie de logiciel réutilisable et remplaçable

■ Paquetage = espace de nommage d’éléments de modélisation

Aspect dynamique : interactions (séquences, communications),

machines à états
Aspect statique : classes, Diagramme de composants Diagramme de paquetages
objets et paquetages

Vue logique Vue développement

Vue cas
d’utilisation

Vue processus Vue physique

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution, Aspect répartition: déploiement

processus, tâches, activités noeuds, modules

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 119/132
Introduction au langage de modélisation UML 7 Conception, vues développement et physique

7.2 Diagramme de composants

7.2.1 Composant, interfaces offertes et requises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.2.2 Composite, port, connecteurs de délégation et d’assemblage . . . . . . . . . . . . . . . . . 122

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 120/132
7 Conception, vues développement et physique 7.2 Diagramme de composants

7.2.1 Composant, interfaces offertes et requises

<<component>> <<component>> <<component>>

Component2 Component1 Component3

Interfaces Interfaces
fournies / requises
offertes

<<interface>> <<component>> <<interface>>

Interface1 Component2 Interface2

Relation de Dépendance
réalisation

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 121/132
7 Conception, vues développement et physique 7.2 Diagramme de composants

7.2.2 Composite, port, connecteurs de délégation et

d’assemblage

Ports

<<component>>
Composite1

<<component>> <<component>>

Primitif1 Composite2

Connecteurs Connecteurs Connecteurs

de délégation d’assemblage de délégation

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 122/132
Introduction au langage de modélisation UML 7 Conception, vues développement et physique

7.3 Diagramme de paquetages

7.3.1 Paquetage, espace de nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7.3.2 Relation entre paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 123/132
7 Conception, vues développement et physique 7.3 Diagramme de paquetages

7.3.1 Paquetage, espace de nommage

paquetage1 paquetage1::Classe1

Classe2
Classe6 (paquetage1)

Classe3
(from paquetage1)

Classe4 Classe5

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 124/132
7 Conception, vues développement et physique 7.3 Diagramme de paquetages

7.3.2 Relation entre paquetages

■ Imbrication de paquetages = imbrication d’espaces de nommage

■ Dépendance entre paquetages

paquetage1

paquetage2

paquetage4
paquetage3

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 125/132
Introduction au langage de modélisation UML 7 Conception, vues développement et physique

7.4 Diagramme de la vue physique

■ Placement des logiciels sur les matériels

Aspect dynamique : interactions (séquences, communications),

machines à états
Aspect statique: paquetages,
Aspect statique : classes,
et fichiers
objets et paquetages

Vue logique Vue développement

Vue cas
d’utilisation

Vue processus Vue physique

Aspect fonctionnel: cas d’utilisation,

acteurs, liens de communication

Aspect parallélisme: fils d’exécution,

processus, tâches, activités
Diagramme de déploiement

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 126/132
Introduction au langage de modélisation UML 7 Conception, vues développement et physique

7.5 Diagramme de déploiement

7.5.1 Nœud et liaison de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

7.5.2 Artefact et composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.5.3 Dépendance entre artefacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 127/132
7 Conception, vues développement et physique 7.5 Diagramme de déploiement

7.5.1 Nœud et liaison de communication

■ Ce modèle définit le diagramme de l’architecture matérielle du système

■ Il représente les différentes machines et les logiciels
■ Il montre les liens de communication entre ces différentes entités

Noeuds Lien de
communication

<<device>> <<liaison TCP/IP>> <<device>>

processeur processeur
distributeur ordinateur
central
<<liaison USB>> <<device>>
distributeur
de billets
<<liaison parallèle>>
<<liaison TCP/IP>>
<<liaison USB>>

<<device>> <<device>> <<device>>

imprimante lecteur processeur
de carte banque

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 128/132
7 Conception, vues développement et physique 7.5 Diagramme de déploiement

7.5.2 Artefact et composant

<<device>> <<liaison TCP/IP>> <<execution

environment>>
Serveur
Stockage Serveur
d’application
<<deploy>>

<<component>>
<<deploy>>
StudsComponent <<liaison HTTP>>

<<artefact>>
StudsBD <<manifest>>

<<device>>
<<artefact>> TerminalUtilisateur
Studs Server
Artefacts
StudsGUI

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 129/132
7 Conception, vues développement et physique 7.5 Diagramme de déploiement

7.5.3 Dépendance entre artefacts

■ Dépendance entre artefacts

■ Instance de nœud

<<device>>
serveurVote1:ServeurVote

<<artefact>>
StudsGUI Studs

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 130/132
Introduction au langage de modélisation UML

8 Conclusion

■ Modèle pour appréhender la réalisation d’un système informatique

■ Diagrammes UML qui permettent d’aider à la réflexion, à la discussion (clients,
architectes, développeurs, etc.)
■ Pas de solution unique mais un ensemble de solutions plus ou moins acceptables
suivant les contraintes du client, et les logiciels et matériels disponibles
■ Une solution acceptable est obtenue par itérations successives

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 131/132
Introduction au langage de modélisation UML

9 Bibliographie
■ Livres
♦ G. Booch, J. Rumbaugh, I. Jacobson, « The Unified Modeling Language User Guide »,
2nd edition, Addison-Wesley, 2005
♦ B. Charroux, A. Osmani, Y. Thierry-Mieg, « UML 2, Pratique de la modélisation », 2è
édition, Pearson Education, 2008
♦ J. Gabay, D. Gabay, « UML 2 : analyse et conception », Dunod, 2008
♦ P. Roques « UML 2 par la pratique », 6è édition, Eyrolles, 2008
♦ R. Miles et K. Hamilton, « Learning UML 2.0 : A pragmatic Introduction to UML »,
O’Reilly, 2006
♦ Object Management Group, « OMG Unified Modeling Language, Infrastructure,
Version 2.4.1 », OMG Document Number formal/2011-08-05, August 2011
♦ Object Management Group, « OMG Unified Modeling Language, Superstructure,
Version 2.4.1 », OMG Document Number formal/2011-08-06, August 2011
♦ D. Pilone, « UML 2.0 Pocket Reference », O’Reilly, 2006
♦ S.W. Ambler, « The Elements of UML 2.0 Style », Cambridge University Press, 2005
■ URL : OMG UML at http://www.omg.org/spec/UML/

Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002 132/132