UML

UML

TITRE DE L’UE : Méthode d’analyse, de conception et de modélisation objet

UE 1 EC : UML
Niveau : LP2 Volume horaire présentiel :
45 H
Semestre : 4 GLAR TP estimé : 67.5 H
Crédits : 4.5
Coefficient : 3
Cours :20H TD : TP : 25 H

Objectif général : Cet enseignement vise à faire acquérir à l’étudiant les

connaissances sur les caractéristiques, les concepts de l’approche objet et de
l’évaluation des avantages de l’approche objet par rapport aux méthodes
classiques.

Objectifs spécifique : Au terme de cet enseignement, l’étudiant doit être capable :

• de structurer sa démarche informatique ;

• de cerner les méthodes d’analyse, de conception et de modélisation.

Pré Requis : Avoir des notions de base en initiation en informatique.

Méthodes pédagogiques : Cours magistral, petite révision en classe, exercices à faire à domicile,
exposés à préparer, recherche documentaire, lecture d’ouvrages et d’articles

Evaluation :
✓ Sommative (DST et Examens) ;
✓ Formative en TD et du TPE (travail personnel de l’étudiant).

BIBLIOGRAPHIE

🠶 Pascal Roques.2004, UML - Modéliser un site e-commerce. Les cahiers du

programmeur. Eyrolles,
🠶 Pascal Roques. 2006, UML2 - Modéliser une application web. Les cahiers
du programmeur. Eyrolles.
🠶 Pascal Roques. 2006, UML2 par la pratique (étude de cas et exercices corrigés).
Eyrolles, 5e édition.
🠶 Pascal Roques and Franck Vallée.2003, UML en action. Eyrolles, 2e Edition.

2
 UML

Contenu pédagogique :
Chapitre 1 Généralités
Section 1 Informatisation
Section 2 Logiciels
Section 3 Notion de qualité pour un logiciel
Section 4 Modélisation, cycles de vie et méthodes
Section 5 Méthodes d’analyse et de conception
Section 6 Méthodes fonctionnelles ou structurées
Section 7 Approche programmation orientée objet

Chapitre 2 UML
Section 1 Histoire des modélisations par objets
Section 2 UML en œuvre
Section 3 Comment présenter un modèle UML ?
Section 3 Notions générales du langage UML
Section 4 Modélisation des besoins avec UML
Section 5 UML n’est pas une méthode
Section 6 Méthode simple et générique

Chapitre 3 Diagramme de cas d’utilisation

Section 1 Éléments des diagrammes de cas d’utilisation
Section 2 Représentation d’un diagramme de cas d’utilisation

Chapitre 4 Diagramme de classes

Section 1 Notions de classe et d’instance de classe
Section 2 Représentation graphique d’une classe
Section 3 Encapsulation, visibilité, interface
Section 4 Relations entre classes
Section 5 Interfaces

Chapitre 5 Diagramme d’objets

Section 1 Présentation
Section 2 Représentation
Section 3 Relation de dépendance d’instanciation
Section 4 Élaboration et implémentation d’un diagramme d’objet

Chapitre 6 Object constraint langage (OCL)

Section 1 Expression des contraintes en UML
Section 2 Écriture des contraintes

3
 UML

Section 3 Représentation des contraintes et contraintes prédéfinies

Section 4 Intérêt d’OCL
Section 5 Illustration par l’exemple
Section 6 Typologie des contraintes OCL
Section 7 Types et opérations utilisables dans les expressions OCL
Section 8 Accès aux caractéristiques et aux objets
Section 9 Opérations sur les collections

Chapitre 7 Diagrammes d’interaction

Section 1 Présentation du formalisme
Section 2 Diagramme de communication
Section 3 Diagramme de séquence

Chapitre 8 Diagramme d’activités

Section 1 Introduction au formalisme
Section 2 Activité et Transition
Section 3 Nœud exécutable, de contrôle et d’objet
Section 6 Partitions
Section 7 Exceptions

Chapitre 9 Diagramme d’états-transitions

Section 1 Introduction au formalisme
Section 2 État
Section 3 Événement
Section 4 Transition
Section 5 Point de choix
Section 6 États composites

Chapitre 10 Diagrammes de composant et déploiement

Section 1 Introduction
Section 2 Diagramme de composant
Section 3 Diagramme de déploiement
Section 4 Objectif du diagramme de déploiement

Chapitre 11 Mise en œuvre d’UML

Section 1 Introduction
Section 4 Identification des besoins
Section 1 Modèle UML
Section 2 Cas pratiques UML / Power AMC

4
 UML

Chapitre 12 Pratique des diagrammes avec Power AMC

Section 1 Diagrammes de cas d’utilisation
Section 2 Diagrammes de classes
Section 3 Diagrammes d’objets
Section 4 Object constraint langage (OCL)
Section 6 Diagramme de séquences
Section 6 Diagramme d’activités
Section 5 Diagramme d’états-transitions
Section 7 Diagrammes d’interaction
Section 8 Diagrammes de composant et déploiement

5
 UML

Table des matières

Chapitre I : Généralités .................................................................................................................................................. 8
Section 1 : Informatisation .................................................................................................................................. 8
Section 2 : Logiciels .......................................................................................................................................... 8
Section 3 : Notion de qualité pour un logiciel ........................................................................................................... 8
Section 4 : Modélisation, cycles de vie et méthodes ............................................................................................... 8
Section 5 : Méthodes d’analyse et de conception ............................................................................................................ 9
Section 6 : Méthodes fonctionnelles ou structurées ................................................................................................. 10
Section 7 : Approche programmation orientée objet .............................................................................................. 10
Chapitre II : Langage UML ......................................................................................................................................... 11
Section 1 : Présentation d’UML.......................................................................................................................... 11
Utilisation ................................................................................................................................................................ 11
1. Diagrammes statiques ou structurels .............................................................................................................. 13
2. Diagrammes comportementaux ou dynamiques ............................................................................................. 13
3. Diagrammes d’interaction............................................................................................................................... 13
Section 2 : Merise par rapport à UML .................................................................................................................. 14
 DIAGRAMME DE CONTEXTE STATIQUE ................................................................................................... 15
Chapitre 3 Diagramme de cas d’utilisation ................................................................................................................ 18
Section1 : Éléments des diagrammes de cas d’utilisation ...................................................................................... 18
Section 2 : Représentation d’un diagramme de cas d’utilisation ....................................................................................... 18
Section3 : Relation entre cas d’utilisation .............................................................................................................. 21
Chapitre 4 : Diagramme de classe .......................................................................................................................... 23
Section 1 : Notions de classe et d’instance de classe ....................................................................................................... 23
Section 2 : Représentation graphique d’une classe ....................................................................................................... 23
Modèle conceptuel des données/diagramme de classe ............................................................................................. 27
Section2 : Les cardinalités : (Association) ............................................................................................................. 28
2. Affiner les Associations ............................................................................................................................................ 30
Chapitre 5 : Diagramme d’objet .............................................................................................................................. 31
Section1 : Notation ................................................................................................................................................ 31
Chapitre 6 : Diagramme de séquence........................................................................................................................... 32
Section1 : Convention graphique ............................................................................................................................. 32
Dialogue entre les objets ................................................................................................................................. 32
Section2 : Types de messages .................................................................................................................................. 33
Chapitre7 : Diagramme de collaboration ................................................................................................................... 34
Section1 : Présentation du formalisme ................................................................................................................... 34
Section 2 : Convention graphique ..................................................................................................................... 35
Section3 : Synchronisation des messages ................................................................................................................ 35
Chapitre 8 : Diagrammes d'activités ......................................................................................................................... 36
Section 1 : Introduction au formalisme .................................................................................................................... 36
Section 2 : La synchronisation ................................................................................................................................. 36
Chapitre 9 : Pratique des diagrammes avec Power AMC............................................................................................. 42

6
 UML

TRAVAUX PRATIQUES ........................................................................................................................................... 43

7
 UML

Chapitre I : Généralités

Section 1 : Informatisation

L'informatisation est une évolution de la société, au cours de laquelle le nombre

d'ordinateurs, d'applications logicielles et la quantité de matériels informatiques utilisés
augmentent.

L'informatisation, au sein des entreprises, peut conduire à d'importants gains de

productivité, mais aussi à une amélioration de la qualité, éventuellement après
une dématérialisation des documents.

Section 2 : Logiciels

En informatique, un logiciel est un ensemble de séquences d’instructions interprétables

par une machine et d’un jeu de données nécessaires à ces opérations. Le logiciel
détermine donc les tâches qui peuvent être effectuées par la machine, ordonne son
fonctionnement et lui procure ainsi son utilité fonctionnelle.

Section 3 : Notion de qualité pour un logiciel

La qualité du logiciel est définie par son aptitude à satisfaire les besoins des
utilisateurs. Elle est définie par l'ANSI comme "l'ensemble des attributs et
caractéristiques d'un produit ou d'un service qui portent sur sa capacité à satisfaire des
besoins donnés".

C'est quoi un logiciel de qualité ?

Un logiciel de bonne qualité est un logiciel qui fonctionne, bien sûr, mais pas
seulement, il doit aussi répondre aux attentes, être facile d'utilisation, performant, être
capable d'évoluer en fonction des besoins, et aussi bien évidemment, être maintenable.

Section 4 : Modélisation, cycles de vie et méthodes

La modélisation informatique des données est en réalité un processus de description

de la structure, des associations, des relations et des impératifs liés à des datas
disponibles. Elle permet de fixer des normes, tout en codant des modèles de gestion des
données dans une organisation.

Le cycle de vie du développement logiciel (Cycle de vie d'un projet informatique) fait
référence à la conception, le développement et le test des logiciels de qualité
optimale.

Modéliser : comprendre et représenter

Un modèle est une abstraction de la réalité

8
 UML

Abstraction : ensemble des caractéristiques essentielles d’une entité, retenu par un

observateur
Un modèle est une vue subjective mais pertinente de la réalité, un modèle ne représente
pas une réalité absolue mais reflète les aspects important de la réalité, il en donne donc
une vue juste et pertinente

Quelles sont les étapes du cycle de vie d'un logiciel ?

Les 7 phases du cycle de vie du développement logiciel :

• Recherche.
• Planification.
• Conception.
• Création de contenu.
• Développement.
• Tests.
• Déploiement et maintenance.

Section 5 : Méthodes d’analyse et de conception

9
 UML

Section 6 : Méthodes fonctionnelles ou structurées

En ingénierie, une méthode d'analyse et de conception est un procédé qui a pour

objectif de permettre de formaliser les étapes préliminaires du développement d'un
système afin de rendre ce développement plus fidèle aux besoins du client.

La phase d'analyse permet de lister les résultats attendus, en termes de fonctionnalités,

de performance, de robustesse, de maintenance, de sécurité, d'extensibilité, etc.

Section 7 : Approche programmation orientée objet

C'est quoi l'approche orientée objet ?

Aussi appelée » OOP » (object-oriented programming), la programmation objet est un
modèle de programmation informatique. Plutôt que d'organiser la conception logicielle
autour de fonctions ou de logique, elle consiste à l'organiser autour des données ou des
« objets ».
La programmation orientée objet (POO), ou programmation par objet, est
un paradigme de programmation informatique. Elle consiste en la définition et
l'interaction de briques logicielles appelées objets ; un objet représente un concept, une
idée ou toute entité du monde physique, comme une voiture, une personne ou encore une
page d'un livre.

10
 UML

Chapitre II : Langage UML

Section 1 : Présentation d’UML

Le Langage de Modélisation Unifié, de l'anglais Unified Modeling

Language (UML), est un langage de modélisation graphique à base
de pictogrammes conçu comme une méthode normalisée de visualisation dans les
domaines du développement logiciel et en conception orientée objet.
L'UML est une synthèse de langages de modélisation objet
antérieurs : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James
Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object
Management Group (OMG). UML 1.0 a été normalisé en janvier 1997 ; UML 2.0 a été
adopté par l'OMG en juillet 2005. La dernière version de la spécification validée par
l'OMG est UML 2.5.1 (2017).

Utilisation
UML est destiné à faciliter la conception des documents nécessaires au développement
d'un logiciel orienté objet, comme standard de modélisation de l'architecture logicielle.
Les différents éléments représentables sont :

• Activité d'un objet/logiciel

• Acteurs
• Processus
• Schéma de base de données
• Composants logiciels
• Réutilisation de composants.

11
 UML

UML n'étant pas une méthode, l'utilisation des diagrammes est laissée à
l'appréciation de chacun. Le diagramme de classes est généralement
considéré comme l'élément central d'UML.

REMARQUE

• Un stéréotype est une marque de généralisation notée par des guillemets, montrant
que l'objet est une variété d'un modèle.
• Un classeur est une annotation qui permet de regrouper des unités ayant le même
comportement ou structure. Un classeur se représente par un rectangle conteneur, en
traits pleins.
• Un paquet regroupe des diagrammes ou des unités.
• Chaque classe ou objet se définit précisément avec le signe « :: ». Ainsi l'identification
d'une classe X en dehors de son paquet ou de son classeur sera définie par « Paquet
A::Classeur B::Classe X ».

Les premières versions d’UML proposaient neuf (9) diagrammes spécifiques

:
Le diagramme de cas d’utilisation : qui représente les relations entre les acteurs et les
fonctionnalités du système.

Le diagramme de classe : c’est un ensemble d’éléments statiques qui montrent la structure

du modèle étudié.
-
Le diagramme d’objet : représente les objets et leurs interdépendances.

Le diagramme d’états / transitions : représente le cycle de vie des objets générés par une
classe.

Le diagramme de composants : détaille les éléments logiciels (exécutable, fichier) et leur

dépendance.

Le diagramme de déploiement : montre la répartition physique des éléments matériels

du système (processeur, périphérique) et leur connexion.

Le diagramme de séquence : détaille les messages échangés entre les acteurs et le système
selon un ordre chronologique.

Le diagramme de collaboration : représente les messages échangés entre les objets. Il

insiste plus particulièrement sur la notion organisationnelle.

Le diagramme d’activités : c’est une variante du diagramme états / transitions qui

représente le déclenchement d’événements selon certains états du système.

12
 UML

UML, dans sa version 2, s’articule autour de (14) types de diagrammes, chacun d’eux étant
dédié à la représentation des concepts particuliers d’un système logiciel. Ces types de
diagrammes sont répartis en trois groupes :
1. Diagrammes statiques ou structurels

• Diagramme de classes : montre les briques de base statiques à savoir classes,

associations, interfaces, attributs, opérations, généralisations, etc.

• Diagramme d’objets : montre les instances des éléments structurels et leurs

liens à l’exécution.

• Diagramme de packages : montre l’organisation logique du modèle et les

relations entre packages.

• Diagramme de structure composite : montre l’organisation interne d’un

élément statique complexe.

• Diagramme de composants : il montre des structures complexes, avec leurs

interfaces fournies et requises.

• Diagramme de déploiement : il montre le déploiement physique des «

artefacts » sur les ressources matérielles.

2. Diagrammes comportementaux ou dynamiques

• Diagramme de cas d’utilisation : il montre les interactions fonctionnelles

entre les acteurs et le système à l’étude.

• Diagramme d’activité : il montre l’enchaînement des actions et décisions au

sein d’une activité.

• Diagramme d’états : il montre les différents états et transitions possibles des

objets d’une classe.

3. Diagrammes d’interaction

• Diagramme de séquence : il montre la séquence verticale des messages passés

entre objets au sein d’une interaction.

13
 UML

• Diagramme de communication : il montre la communication entre objets

dans le plan au sein d’une interaction.

• Diagramme de temps : il fusionne les diagrammes d’états et de séquence pour

montrer l’évolution de l’état d’un objet au cours du temps.

• Diagramme de vue d’ensemble des interactions : il fusionne les

diagrammes d’activité et de séquence pour combiner des fragments d’interaction
avec des décisions et des flots.

• Diagramme de contexte statique :

• Diagramme de contexte dynamique :

Section 2 : Merise par rapport à UML

Merise est une méthode de conception des systèmes informatiques particulièrement

efficace pour la représentation et la modélisation des bases des données.
Merise repose sur quelques principes fondamentaux :
Une approche systémique ;
La séparation des données et des traitements ;
Une approche qui part du général vers le particulier.

• Pour l’approche systémique :

Merise découpe l’entreprise en trois sous-systèmes :
- Le système de décision ;
- Le système d’information ;
- Le système opérant.

• La séparation des données et des traitements :

La méthode Merise est caractérisée par une approche conjointe des données et des
traitements qui est formalisée par des modèles spécifiques. Le côté statique du système
est écrit par les modèles des données tandis que le côté dynamique est mise en œuvre par
les modèles de traitements.
UML décrit comme Merise les données et les traitements mais contrairement à
Merise qui les sépares UML les associes, cela est dû à l’approche objet d’UML, approche
objet qui agrège les données et les traitements.

MERISE va décrire le schéma de données, la persistance. Il s'agit des données

sauvegardées en base de données lorsque le système n'est plus en marche. De son
côté, UML est plus un “langage” de diagramme Objet. On représente les objets métiers et
les traitements (méthodes) associés.

14
 UML

Pourquoi le choix de UML ?

De plus, la modélisation UML permet de vulgariser les aspects liés à la conception et à
l'architecture, propres au logiciel, au client. Aussi, elle apporte une compréhension rapide
du programme à d'autres développeurs externes en cas de reprise du logiciel et facilite sa
maintenance.

Pourquoi UML n'est pas une méthode ?

Comme nous l'avons déjà dit, à maintes reprises, UML n'est qu'un langage de
modélisation, ce n'est pas une méthode. En effet, UML ne propose pas une démarche de
modélisation explicitant et encadrant toutes les étapes d'un projet, de la compréhension
des besoins à la production du code de l'application.

Quel est le but de UML ?

Il est destiné à l'architecture, la conception et la mise en œuvre de systèmes logiciels

complexes par leur structure aussi bien que leur comportement. L'UML a des applications
qui vont au-delà du développement logiciel, notamment pour les flux de processus dans
l'industrie.

Les limites :
• L’approche objet est moins intuitive que l’approche fonctionnelle
• L’application des concepts objets nécessite une grande rigueur

Les points forts d’UML :

Avantages et inconvénients d'UML

• UML est un langage formel et normalisé clair et précis. Encourage l'utilisation d'outils.
• UML est un support de communication performant. L’analyse devient plus facile.
Facilite la compréhension de représentations abstraites complexes.

 DIAGRAMME DE CONTEXTE STATIQUE

Le diagramme de contexte statique délimite le domaine d'étude en précisant
• ce qui est à la charge du système et
• en identifiant l'environnement extérieur au système étudié avec lequel ce dernier
communique. On représente les interactions des acteurs avec le système étudié.

C'est quoi le diagramme de contexte ?

Ce diagramme exprime l'environnement du système dans une situation donnée.
Le diagramme de contexte permet donc de définir les frontières de l'étude et de

15
 UML

préciser la phase du cycle de vie dans laquelle on situe l'étude (généralement la phase
d'utilisation).

Le diagramme de contexte statique délimite le domaine d’étude en précisant :

• ce qui est à la charge du système et
• en identifiant l’environnement extérieur au système étudié avec lequel ce dernier
communique. Ses composants sont :
• Les acteurs externes. Un acteur externe est une entité externe au système étudié qui
interagit avec le système.
• Un processus unique symbolisant le Système Information étudié :
• Echange entre le système étudié et son environnement

Les acteurs Un acteur représente un rôle joué par une personne ou une "chose" extérieure
au système étudié qui interagit avec le système étudié. Le même être humain peut avoir
alternativement plusieurs rôles (vendeur, client). D’autre part, plusieurs personnes
peuvent jouer le même rôle. Il existe deux catégories d’acteurs :

• les acteurs principaux : les acteurs qui utilisent les fonctions principales du système
(client, fournisseur). Normalement les acteurs principaux sont à la gauche dans le cadre
du diagramme de contexte statique.

• les acteurs secondaires : les acteurs qui effectuent les tâches de maintenance,
administration et paramétrage du système (manager de la BD) Il existe 3 groupes
d’acteurs :

• Les êtres humains (du moins des fonctions réalisées par des êtres humains). Par
exemple, Client, Etudiant, Gérant, Comptable, ...

• Le matériel externe, par exemple, les périphériques informatiques (capteurs,

imprimantes)

• Les systèmes informatiques avec lequel le système interagit (autres applications

informatiques). La représentation des acteurs a deux formats un pour les êtres humains
(rôle joué par des êtres humains) l’autre pour les systèmes d'information et les
périphériques.

16
 UML

DIAGRAMME DE CONTEXTE DYNAMIQUE

Ce diagramme exprime l'environnement du système dans une situation
donnée. Le diagramme de contexte permet donc de définir les frontières de l'étude et de
préciser la phase du cycle de vie dans laquelle on situe l'étude (généralement la phase
d'utilisation).

17
 UML

Chapitre 3 Diagramme de cas d’utilisation

Un cas d’utilisation (« use case ») représente un ensemble de séquences d’actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un
acteur particulier.

Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme

un tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce
que le futur système devra faire, sans spécifier comment il le fera.

Section1 : Éléments des diagrammes de cas d’utilisation

Comment les identifier ?

L’objectif est le suivant : l’ensemble des cas d’utilisation doit décrire exhaustivement les
exigences fonctionnelles du système. Chaque cas d’utilisation correspond donc à une
fonction métier du système, selon le point de vue d’un de ses acteurs.
Pour chaque acteur, il convient de :
• rechercher les différentes intentions métier avec lesquelles il utilise le système,
• déterminer dans le cahier des charges les services fonctionnels attendus du système.
Nommez les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du point de
vue de l’acteur (et non pas du point de vue du système).

Les acteurs candidats sont systématiquement :

• les utilisateurs humains directs : faites donc en sorte d’identifier tous les profils
possibles, sans oublier l’administrateur, l’opérateur de maintenance, etc. ;
• les autres systèmes connexes qui interagissent aussi directement avec le système étudié,
souvent par le biais de protocoles bidirectionnels.

Comment les analyser ?

Pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente consiste à

recenser de façon textuelle toutes les interactions entre les acteurs et le système. Le cas
d’utilisation doit avoir un début et une fin clairement identifiés. Il faut également préciser
les variantes possibles, telles que le cas nominal, les différents cas alternatifs et d’erreur,
tout en essayant d’ordonner séquentiellement les descriptions, afin d’améliorer leur
lisibilité.

Section 2 : Représentation d’un diagramme de cas d’utilisation

Comment les représenter ?

Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales)
reliés par des associations (lignes) à leurs acteurs (icône du « stick man », ou

18
 UML

représentation graphique équivalente). Chaque association signifie simplement «

participe à ». Un cas d’utilisation doit être relié à au moins un acteur.

Une fois les cas d’utilisation identifiés, il faut encore les décrire !

La représentation graphique standard de l’acteur en UML est l’icône appelée

stick man, avec le nom de l’acteur sous le dessin. On peut également figurer un acteur
sous la forme rectangulaire d’une classe, avec le mot-clé <>. Une troisième représentation
(intermédiaire entre les deux premières) est également possible avec certains outils,
comme cela est indiqué ci-après.

Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme graphique du stick
man pour les acteurs humains et une représentation rectangulaire pour les systèmes connectés.

SCÉNARIO

Un scénario représente une succession particulière d’enchaînements, s’exécutant du

début à la fin du cas d’utilisation, un enchaînement étant l’unité de description de
séquences d’actions. Un cas d’utilisation contient en général un scénario nominal et
plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d’erreur (qui se
terminent en échec).

On peut d’ailleurs proposer une définition différente pour un cas d’utilisation : «

ensemble de scénarios d’utilisation d’un système reliés par un but commun du point de
vue d’un acteur ».

19
 UML

La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par UML. Nous
préconisons pour notre part la structuration suivante :

Remarque :

ACTEUR

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.
Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou
en recevant des messages susceptibles d’être porteurs de données.

Use case : ensemble d’actions réalisé par le système en réponse à une action d’un acteur.

Activités et Eléments produits :

– 1. Identifier les Cas d’utilisation :
• Liste préliminaire des cas d’utilisation ainsi q’une description
succincte de ces cas d’utilisation et un diagramme de CU simple.
• technique : partant du diagramme de contexte dynamique, on
considère l’intention fonctionnelle de l’acteur par rapport à chaque
message. En regroupant les intentions fonctionnelles en unité
cohérente, on obtient les C.U
• L’analyse du cahier des charges permet également de déterminer
directement les services fonctionnels attendus

20
 UML

Cas d’Utilisation Acteur Principal, Messages émis/reçus par les

acteurs
Acteurs Secondaires

CU1 émet : m1, m2, …

Acteur1 (P)
reçoit : m5, m7, m8
Acteur2
……
…..

CU2

… … …

CUn

• 1. Identifier les Cas d’utilisation (fin) :

– La description succincte pourra avoir le format suivant :
• Nom du CU (<acteur principal>) :
– Exemple : ouvrir un compte client (Agent Conseil)
– Remarque : Il est conseillé de nommer le CU avec un verbe à l’infinitif suivi
d’un complément et en se plaçant du point de vue de l’acteur et non du point
de vue du système.

• Intention
– Exemple : créer un nouveau compte client (ordinaire ou d’épargne)
• Actions
– Saisir les informations identitaires du client, les informations
socioprofessionnelles, générer un nouveau compte, procéder au versement
initial etc

Section3 : Relation entre cas d’utilisation

• Relation d’utilisation : <<include>> (Caractère obligatoire)

- Le cas d’utilisation contient un autre cas d’utilisation

• Relation d’extension :<<extend>> (Caractère non obligatoire)

- Le cas d’utilisation étend (précise) les objectifs (le comportement) d’un
autre cas d’utilisation.

21
 UML

Virement par internet

<<extend>>
Client distant Virement

<<include>> <<include>>

Identification Vérification solde

Client

22
 UML

Chapitre 4 : Diagramme de classe

Section 1 : Notions de classe et d’instance de classe

Le diagramme de classes est le point central dans un développement orienté objet. En

analyse, il a pour objectif de décrire la structure des entités manipulées par les
utilisateurs. En conception, le diagramme de classes représente la structure d’un code
orienté objet ou, à un niveau de détail plus important, les modules du langage de
développement.
Section 2 : Représentation graphique d’une classe

Comment le représenter ?
Le diagramme de classes met en œuvre des classes, contenant des attributs et des
opérations, et reliées par des associations ou des généralisations.

CLASSE ET OBJET
Une classe représente la description abstraite d’un ensemble d’objets possédant les
mêmes caractéristiques. On peut parler également de type.
Exemple : la classe Voiture, la classe Personne. Un objet est une entité aux frontières
bien définies, possédant une identité et encapsulant un état et un comportement. Un objet
est une instance (ou occurrence) d’une classe.
Exemple : Christopher BANDZOUZI est un objet instance de la classe Personne. Le livre
que vous tenez entre vos mains est une instance de la classe Livre.

• ATTRIBUT ET OPÉRATION

Un attribut représente un type d’information contenu dans une classe.

Exemples : vitesse courante, cylindrée, numéro d’immatriculation, etc. sont des
attributs de la classe Voiture.

23
 UML

Une opération représente un élément de comportement (un service) contenu dans une
classe. Nous ajouterons plutôt les opérations en conception objet, car cela fait partie des
choix d’attribution des responsabilités aux objets.

ASSOCIATION

Une association représente une relation sémantique durable entre deux classes.
Exemple : une personne peut posséder des voitures. La relation possède est une
association entre les classes Personne et Voiture.
Attention : même si le verbe qui nomme une association semble privilégier un sens de
lecture, une association entre concepts dans un modèle du domaine est par défaut
bidirectionnelle. Donc implicitement, l’exemple précédent inclut également le fait qu’une
voiture est possédée par une personne.

Comment les représenter ?

Aux deux extrémités d’une association, on doit faire figurer une indication de multiplicité.
Elle spécifie sous la forme d’un intervalle d’entiers positifs ou nuls le nombre d’objets qui
peuvent participer à une relation avec un objet de l’autre classe dans le cadre d’une
association.
Exemple : une personne peut posséder plusieurs voitures (entre zéro et un nombre
quelconque) ; une voiture est possédée par une seule personne.

AGRÉGATION ET COMPOSITION

Une agrégation est un cas particulier d’association non symétrique exprimant une
relation de contenance. Les agrégations n’ont pas besoin d’être nommées : implicitement
elles signifient « contient », « est composé de ».
Une composition est une agrégation plus forte impliquant que :
• un élément ne peut appartenir qu’à un seul agrégat composite (agrégation non partagée)
;
• la destruction de l’agrégat composite entraîne la destruction de tous ses éléments (le
composite est responsable du cycle de vie des parties).

Comment les représenter ?

24
 UML

GÉNÉRALISATION, SUPER-CLASSE, SOUS-CLASSE

Une super-classe est une classe plus générale reliée à une ou plusieurs autres classes plus
spécialisées (sous-classes) par une relation de généralisation. Les sous-classes « héritent
» des propriétés de leur super-classe et peuvent comporter des propriétés spécifiques
supplémentaires.
Exemple : les voitures, les bateaux et les avions sont des moyens de transport. Ils
possèdent tous une marque, un modèle, une vitesse, etc. Par contre, seuls les bateaux ont
un tirant d’eau et seuls les avions ont une altitude…

Comment les représenter ?

Une classe abstraite est simplement une classe qui ne s’instancie pas directement mais
qui représente une pure abstraction afin de factoriser des propriétés communes. Elle se
note en italique. C’est le cas de Moyen de Transport dans l’exemple précédent.

PACKAGE
Package : mécanisme général de regroupement d’éléments en UML, qui est
principalement utilisé en analyse et conception objet pour regrouper des classes et des
associations. Les packages sont des espaces de noms : deux éléments ne peuvent pas
porter le même nom au sein du même package. Par contre, deux éléments appartenant à
des packages différents peuvent porter le même nom.
La structuration d’un modèle en packages est une activité délicate. Elle doit s’appuyer sur
deux principes fondamentaux : cohérence et indépendance.

25
 UML

Le premier principe consiste à regrouper les classes qui sont proches d’un point de vue
sémantique. Un critère intéressant consiste à évaluer les durées de vie des instances de
concept et à rechercher l’homogénéité. Le deuxième principe s’efforce de minimiser les
relations entre packages, c’est-à-dire plus concrètement les relations entre classes de
packages différents.

Comment les représenter ?

ÉTUDE D’UN SYSTÈME DE RÉSERVATION DE VOL

Cette étude de cas concerne un système simplifié de réservation de vols pour une agence de
voyages. Les interviews des experts métier auxquelles on a procédé ont permis de résumer leur
connaissance du domaine sous la forme des phrases suivantes :
1. Des compagnies aériennes proposent différents vols.
2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.
3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.
4. Une réservation concerne un seul vol et un seul passager.
5. Une réservation peut être annulée ou confirmée.
6. Un vol a un aéroport de départ et un aéroport d’arrivée.
7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée.
8. Un vol peut comporter des escales dans des aéroports.
9. Une escale à une heure d’arrivée et une heure de départ.
10. Chaque aéroport dessert une ou plusieurs villes. Nous allons entreprendre progressivement la
réalisation d’un modèle statique d’analyse (aussi appelé modèle du domaine) à partir de ces «
morceaux de connaissance.

• 4. Identifier les classes candidates.

– Définir les concepts clés du domaine d’application (concepts métiers) ;
– Ajouter les concepts « applicatifs » liés à l’informatisation.

26
 UML

– Résultats : Un diagramme « préliminaire » non exhaustif de classes participantes

pour chaque cas d’utilisation.
• Démarche : rechercher les noms communs importants dans les
descriptions textuelles des CU. Vérifier que ces noms peuvent être réifiés
en objets (identité, propriétés, comportement) puis définir les
responsabilités des objets retenus.
• Définition : Une responsabilité est le « contrat » que la classe doit remplir.
Les attributs, les opérations et les associations permettent à la classe de
remplir son contrat qui est d’un niveau d’abstraction plus élévé. Une classe
doit avoir au moins une responsabilité et en nombre réduit (<= 5) sinon la
scinder en plusieurs classes.

Modèle conceptuel des données/diagramme de classe

Le modèle conceptuel de données et le diagramme de classe partagent beaucoup de point

commun. Les différences majeures apparaissent du côté UML. Le langage UML pour
représenter une base des données ne passe pas d’un état correspondant à un modèle
conceptuel des données à un modèle logique des données. Il faut donc à l’analyste-
programmeur une bonne approche ou vision de la base des données pour la représenter
sans faille en langage UML. Le découpage MCD, MLD apporte plus de sécurité à ce
niveau-là qu’UML.

Construction graphique d’une classe :

Nom de classe Nom de classe

Attributs

Méthodes

27
 UML

• Syntaxe :

- Niveaux d’accès :
o Public +
o Potected #
o Private -
Voiture
Voiture
Immatriculation
Couleur
Marque
Propriétaire
Classe / Attributs

Démarrer
Arrêter
Conduire
Vendre

Section2 : Les cardinalités : (Association)

Les cardinalités s’expriment différemment dans le diagramme de classe. Elles

sont inversées par rapport à la méthode MERISE.
Voici un tableau donnant des éléments de comparaison :
Merise UML
0,1 0..1
1,1 1
0,n 0..* ou *
1,n 1..*

Exemple :
• Exemple en Merise

• Mère Enfant
Numéro_mere 1, n 1, 1 Numéro_enfant
Élever
Nom_mére Nom_enfant
Prénom_mére Prénom_enfant

• Voici comment le traiter en UML

28
 UML

Enfant
Mère
1 1..* +Numéro_enfant
+Numéro_mére +Nom_enfant
+Nom_mére +Prénom_enfant
+Prénom_mere

N.B : une association exprime une connexion sémantique entre deux classes.

• Association classique :

•
Personne
Entreprise
Travaillé

• Association porteuse :
L’association est porteuse de propriété :

Exemple :

Client Article
1, n : 0, n
N° client Commander N° article
Nom Libelle
Prénom Client Prix d’achat
Article
Adresse Prix de vente
N° client 0.. * 1.. * N° article
Nom Libelle
Prénom Prix d’achat
Adresse Prix de vente

Commander

Quantité

29
 UML

En UML la représentation de l’héritage est très spéciale.

2. Affiner les Associations

Examen minutieux des associations : ajout, suppression, validation itérative des
associations.
Principes pour éliminer les associations
Associations non structurelles : expriment des liens instantanés (dynamique). Un lien
structurel implique une certaine durée et stabilité.
Associations redondantes : peuvent être retrouvées par navigations à partir des autres
associations
Utiliser de façon appropriée l’agrégation et la composition
Identifier les règles de gestion et utiliser les propriétés standard de UML pour les
exprimer : {ordered}, {frozen}, {addOnly}.

30
 UML

Chapitre 5 : Diagramme d’objet

Le diagramme d'objets, dans le langage de modélisation de donnée UML, permet de

représenter les instances des classes, c'est-à-dire des objets. Comme le diagramme de
classes, il exprime les relations qui existent entre les objets, mais aussi l'état des objets,
ce qui permet d'exprimer des contextes d'exécution. En ce sens, ce diagramme est moins
général que le diagramme de classes.
- Un diagramme d’objet ne montre pas les interactions entre les objets.
-Un objet est représenté par un rectangle découpé en deux compartiments.
Sont présents :

• Le nom de l’objet
• La liste des attributs valorisés

Section1 : Notation

nomObjet : nomClasse

nomAttribut1= valeur1
…
nomAttributN= valeurN

Nom de l’objet :

• Le nom de l’objet peut être présenté selon trois formats plus ou moins
précis
• Il peut contenir :
-un nom optionnel identifiant l’objet de manière unique
-le nom optionnel de la classe à laquelle appartient l’objet

* Le nom de l’objet est souligné

Notation
Les diagrammes d'objets s'utilisent pour montrer l'état des instances d'objet avant et
après une interaction, autrement dit c'est une photographie à un instant précis des
attributs et objet existant. Il est utilisé en phase exploratoire.

31
 UML

Chapitre 6 : Diagramme de séquence

Les diagrammes de séquences sont la représentation graphique

des interactions entre les acteurs et le système selon un ordre chronologique dans la
formulation Unified Modeling Language.

Qu'est-ce qu'un diagramme de séquence comment le représenter en UML ?

Un diagramme de séquence est un diagramme UML (Unified Modeling

Language) qui représente la séquence de messages entre les objets au cours d'une
interaction. Un diagramme de séquence comprend un groupe d'objets, représentés
par des lignes de vie, et les messages que ces objets échangent lors de l'interaction.

Section1 : Convention graphique :

Le diagramme de séquence permet de montrer les interactions d'objets dans le cadre

d'un scénario d'un diagramme des cas d'utilisation. Dans un souci de simplification, on
représente l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels
à droite du système. Le but est de décrire comment se déroulent les interactions entre les
acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant de visualiser
l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets.
Les périodes d'activité des objets sont symbolisées par des rectangles, et ces objets
dialoguent à l'aide de messages.

Dialogue entre les objets

Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets.

• message simple : le message n'a pas de spécificité particulière d'envoi et de réception.

• message avec durée de vie : l'expéditeur attend une réponse du récepteur pendant un
certain temps et reprend ses activités si aucune réponse n'a lieu dans un délai prévu.
• message synchrone : l'expéditeur est bloqué jusqu'au signal de prise en compte par le
destinataire. Les messages synchrones sont symbolisés par des flèches barrées.
• message asynchrone : le message est envoyé, l'expéditeur continue son activité que le
message soit parvenu ou pris en compte ou non. Les messages asynchrones sont
symbolisés par des demi-flèches.
• message dérobant : le message est mis en attente dans une liste d'attente de
traitement chez le récepteur.

32
 UML

: nom Nom : classe

Message () New () Obj : classe

Section2 : Types de messages

Pour les cas plus complexes, on peut intégrer des algorithmes dans les diagrammes de
séquences. Par le biais de cadres d'interaction, on peut préciser les opérantes d'un
ensemble de messages :

• alt : fragments multiple alternatifs (si alors sinon)

• opt : fragment optionnel
• par : fragment parallèle (traitements concurrents)
• loop : le fragment s'exécute plusieurs fois
• region : région critique (un seul thread à la fois)
• neg : une interaction non valable
• break : représente des scenario d'exception
• ref : référence à une interaction dans un autre diagramme
• sd : fragment du diagramme de séquence en entier

33
 UML

Chapitre7 : Diagramme de collaboration

Le diagramme de collaboration fait partie des vues dynamiques du système

d’information.

Section1 : Présentation du formalisme

Un diagramme de collaboration est un diagramme d'interactions UML 1.x,

représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges
de messages entre les objets, et où la chronologie n'intervient que de façon annexe.
Il consiste en un graphe dont les nœuds sont des objets et les arcs (numérotés selon la
chronologie) les échanges entre ces objets.
Les diagrammes de collaboration ont été remplacés en UML 2.x par les diagrammes de
communication.

Un diagramme de communication est un diagramme d'interactions UML 2.0

(appelé diagramme de collaboration en UML 1), représentation simplifiée
d'un diagramme de séquence se concentrant sur les échanges de messages entre les
objets. En fait, le diagramme de séquence et le diagramme de communication sont deux
vues différentes mais logiquement équivalentes (on peut construire l'une à partir de
l'autre) d'une même chronologie, ils sont dits isomorphes.
C'est une combinaison entre le diagramme de classes, celui de séquence et celui des cas
d'utilisation. Il rend compte à la fois de l'organisation des acteurs aux interactions et de
la dynamique du système.
C'est un graphe dont les nœuds sont des objets et les arcs (numérotés selon
la chronologie) les échanges entre objets.

Les diagrammes de collaboration comportent trois composants :

Les objets (instances de classes)
Les liens entre objets (comme dans le diagramme de classe)
Les interactions entre objets sous forme d’une suite de message
Les acteurs

34
 UML

Section 2 : Convention graphique

1 : opération ()
01 : classe 0 classe 2 : classe 2

2 : opération 2 () 4 : opération 3 ()

3 : opération ()
02 : classe 03 : classe

Section3 : Synchronisation des messages

Dans un diagramme de collaboration il est possible de spécifier de manière très précise

l’ordre et les conditions d’envoi des messages. Pour chaque message il est possible
d’indiquer :
Son numéro d’ordre qui indique le rang du message c’est-à-dire son numéro d’ordre par
rapport aux autres messages. Les messages sont numérotés à l’aide des chiffres séparés
par des points ainsi il est possible de représenter le niveau d’emboitement des messages.
Le prédicat qui conditionne son envoi.

35
 UML

Chapitre 8 : Diagrammes d'activités

Le diagramme d'activité est un diagramme comportemental d'UML, permettant de
représenter le déclenchement d'événements en fonction des états du système et
de modéliser des comportements parallélisables (multi-threads ou multi-processus). Le
diagramme d'activité est également utilisé pour décrire un flux de travail (workflow).
Un diagramme d'activité permet de modéliser un processus interactif, global ou partiel
pour un système donné (logiciel, système d'information).

Le diagramme d'activité est sémantiquement proche des diagrammes de

communication (appelés diagramme de collaboration en UML 1), ou d'état-transitions,
ces derniers offrant une vision microscopique des objets du système.

Section 1 : Introduction au formalisme

Le diagramme d'activité est une représentation proche de l'organigramme ; la description

d'un cas d'utilisation par un diagramme d'activité correspond à sa traduction
algorithmique. Une activité est l'exécution d'une partie du cas d'utilisation, elle est
représentée par un rectangle aux bords arrondis.

condition Activite2
Activite1

Section 2 : La synchronisation

Les flots de contrôle parallèles sont séparés ou réunis par des barres de synchronisation.
Les activités 2 et 3 seront simultanées.

Exercice :

Recette simplifiée : commencer par casser le chocolat en morceaux, puis le faire fondre.
En parallèle, casser les œufs en séparant les blancs des jaunes.
Quand le chocolat est fondu, ajouter les jaunes d’œuf.
Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes.
Les incorporer délicatement à la préparation chocolat sans les briser.
Verser dans des ramequins individuels. Mettre au frais au moins 3 heures au réfrigérateur
avant de servir.

36
 UML

Chapitre 9 : DIAGRAMME D’ETATS

UML a repris le concept bien connu de machine à états finis, qui consiste à s’intéresser au
cycle de vie d’une instance générique d’une classe particulière au fil de ses interactions
avec le reste du monde, dans tous les cas possibles. Cette vue locale d’un objet, qui décrit
comment il réagit à des événements en fonction de son état courant et comment il passe
dans un nouvel état, est représentée graphiquement sous la forme d’un diagramme
d’états.

Un diagramme d’états pour quelles classes ?

Toutes les classes du modèle statique ne requièrent pas nécessairement une machine à
états, représentée par un diagramme d’états. Il s’agit donc de trouver celles qui ont un
comportement dynamique complexe nécessitant une description poussée. Cela
correspond à l’un des deux cas suivants :
• les objets de la classe peuvent-ils réagir différemment à l’occurrence du même
événement ?
Chaque type de réaction caractérise un état particulier ;
• la classe dit-elle organiser certaines opérations dans un ordre précis ?
Dans ce cas, des états séquentiels permettent de préciser la chronologie forcée des
événements d’activation.

Comment le construire ?
1. Représentez tout d’abord la séquence d’états qui décrit le comportement nominal d’un
objet, avec les transitions qui y sont associées.
2. Ajoutez progressivement les transitions qui correspondent aux comportements
alternatifs ou d’erreur.

Comment le représenter ?
Un diagramme d’états est un graphe orienté d’états et de transitions.

37
 UML

ÉTAT Un état représente une situation durant la vie d’un objet pendant laquelle :
• il satisfait une certaine condition ;
• il exécute une certaine activité ;
• ou bien il attend un certain événement. Un objet passe par une succession d’états durant
son existence. Un état a une durée finie, variable selon la vie de l’objet, en particulier en
fonction des événements qui lui arrivent.

Exercice
ÉTUDE D’UN PUBLIPHONE À PIÈCES Cette étude de cas concerne un système simplifié
de Publiphone à pièces.
1. Le prix minimal d’une communication interurbaine est de 0,2 euros.
2. Après l’introduction de la monnaie, l’utilisateur a 2 minutes pour composer son numéro
(ce délai est décompté par le standard).
3. La ligne peut être libre ou occupée.
4. Le correspondant peut raccrocher le premier.
5. Le Publiphone consomme de l’argent dès que l’appelé décroche et à chaque unité de
temps (UT) générée par le standard.
6. On peut ajouter des pièces à tout moment.
7. Lors du raccrochage, le solde de monnaie est rendu. À partir de ces six phrases, nous
allons progressivement : 1. Identifier les acteurs et les cas d’utilisation.

CONSEILS MÉTHODOLOGIQUES
NOTION D’ÉTAT ET DIAGRAMME DE CLASSES
La notion d’état ne doit pas apparaître directement en tant qu’attribut sur les diagrammes
de classes : elle sera modélisée dans le point de vue dynamique au moyen du diagramme
d’états. Dans le diagramme de classes UML, les seuls concepts dynamiques disponibles
sont les opérations.
COMMENT POSITIONNER LES OPÉRATIONS ?
En orienté objet, on considère que l’objet sur lequel on pourra réaliser un traitement doit
l’avoir déclaré en tant qu’opération. Les autres objets qui posséderont une référence sur
cet objet pourront alors lui envoyer un message invoquant l’opération.
OBJET OU ATTRIBUT ?
Un objet est un élément plus « important » qu’un attribut. Un bon critère à appliquer
peut s’énoncer de la façon suivante : si l’on ne peut demander à un élément que sa
valeur, il s’agit d’un simple attribut ; si l’on peut lui poser plusieurs questions, il s’agit
plutôt d’un objet qui possède à son tour plusieurs attributs, ainsi que des liens avec
d’autres objets.
À QUOI SERT LE DIAGRAMME D’OBJETS ?

38
 UML

N’hésitez pas à utiliser le diagramme d’objets pour donner un exemple, ou encore un

contre-exemple, qui permette d’affiner un aspect délicat d’un diagramme de classes.

CONVENTIONS DE NOMMAGE UML

• Les noms des attributs commencent toujours par une minuscule (contrairement aux
noms des classes qui commencent systématiquement par une majuscule) et peuvent
contenir ensuite plusieurs mots concaténés commençant par une majuscule.
• Il est préférable de ne pas utiliser d’accents ni de caractères spéciaux.
• Les mêmes conventions s’appliquent au nommage des rôles des associations, ainsi
qu’aux opérations.

ATTRIBUT DÉRIVÉ ET QUALIFICATIF

• Utilisez le concept d’attribut dérivé pour distinguer les attributs intéressants pour
l’analyste, mais redondants car leur valeur peut être déduite à partir d’autres
informations disponibles dans le modèle. Les attributs dérivés permettent à l’analyste de
ne pas faire un choix de conception prématuré.
• Utilisez à bon escient les qualificatifs, sans oublier la modification de la multiplicité de
l’autre côté de l’association.

AGRÉGATION OU COMPOSITION ?
Pour qu’une agrégation soit une composition, il faut vérifier les deux critères suivants :
• La multiplicité ne doit pas être supérieure à un du côté du composite.
• Le cycle de vie des parties doit dépendre de celui du composite (en particulier pour la
destruction).

39
 UML

Chapitre 10 : DIAGRAMME DE DEPLOIEMENT

Section 1 : Introduction
En UML, un diagramme de déploiement est une vue statique qui sert à représenter
l'utilisation de l'infrastructure physique par le système et la manière dont
les composants du système sont répartis ainsi que leurs relations entre eux. Les
éléments utilisés par un diagramme de déploiement sont principalement
les nœuds, les composants, les associations et les artefacts. Les caractéristiques
des ressources matérielles physiques et des supports de communication peuvent être
précisées par stéréotype.

Les nœuds (nodes), représentés par des cubes, sont des composants mécaniques de
l'infrastructure tel un routeur, un ordinateur, un assistant personnel... Ceux-ci peuvent
comprendre d'autres nœuds ou artefacts. Les nœuds internes indiquent
l'environnement d'exécution plutôt que l'infrastructure physique.

Les composants, représentés par des boites rectangulaires avec deux rectangles sortant
du côté gauche, sont les différentes parties du système étudié.
Les connexions sont principalement de deux types : associations ou dépendances.
Les associations, représentées par de simples lignes sont des liens de communication,
s'établissent entre les différents composants du système.
Les dépendances, représentées par des flèches vides, sont régies par les règles standard
de l'UML 2.0.
Dans ce contexte, un artefact est une manière de définir un fichier, un programme, une
bibliothèque ou une base de données construite ou modifiée dans un projet.
Ces artefacts mettent en œuvre des collections de composants qui sont consommées ou
créées durant l'une des étapes du processus de déploiement.

 DIAGRAMME DES PAQUETAGES

Les diagrammes de paquetages sont la représentation graphique des relations

existant entre les paquetages (ou espaces de noms) composant un système, dans le
langage Unified Modeling Language (UML).
Un package en UML (ou paquetage en français) sert à grouper des éléments en un
ensemble cohérent, et à fournir un espace de noms pour ces éléments. Un package peut
contenir la plupart des éléments UML : classes, objets, cas d'utilisations, composantes,
etc. Il peut également contenir d'autres packages, selon une organisation hiérarchique.
L'intérêt des packages est de permettre de structurer les diagrammes et de donner une
vision globale plus claire.

40
UML

41
 UML

Chapitre 9 : Pratique des diagrammes avec Power AMC

Réalisation des diagrammes (Cas d’utilisation, Classe, Objet, d’Etats-transitions,

Activités, Séquence, d’Interaction, de Composant et de Déploiement, Statique,
Dynamique et de Paquetage) avec le logiciel Power AMC.

(Voir amc-mcd-power amc.pdf) pour la suite et les travaux pratiques.

BIBLIOGRAPHIE

• Dan Pilone and Neil Pitman. UML 2 en concentré. O'Reilly,

2006.
• Pascal Roques. UML - Modéliser un site e-commerce. Les
cahiers du programmeur. Eyrolles, 2002.
• Pascal Roques. UML2 - Modéliser une application web. Les
cahiers du programmeur. Eyrolles, 2006.
• Pascal Roques. UML2 par la pratique (étude de cas et exercices
corrigés). Eyrolles, 5e édition, 2006.
• Pascal Roques and Franck Vallée. UML en action. Eyrolles, 2e
edition, 2003.
• James Rumbaugh, Ivar Jacobson, and Grady Booch. UML 2.0
Guide de référence. CampusPress, 2004.

42
 UML

TRAVAUX PRATIQUES

TP1 : PRATIQUES DES DIAGRAMMES UML

ÉTUDE D’UN GUICHET AUTOMATIQUE DE BANQUE

Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque

(GAB). Le GAB offre les services suivants :

1. Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de carte et un distributeur
de billets.

2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients
porteurs d’une carte de crédit de la banque adossée au GAB.

N’oubliez pas non plus que :

3. Toutes les transactions sont sécurisées.

4. Il est parfois nécessaire de recharger le distributeur, etc.

À partir de ces quatre phrases, nous allons progressivement et en utilisant UML et le processus
unifié 2TUP :

Partie I
• identifier les acteurs et le diagramme de contexte statique ;
• identifier les cas d’utilisation ;
• construire un diagramme de cas d’utilisation ;
• décrire textuellement les cas d’utilisation ;
• compléter les descriptions par des diagrammes dynamiques ;
• organiser et structurer les cas d’utilisation.

Partie II
En utilisant un outil UML représenté :
• Le diagramme de séquence système qui décrive le scénario nominal du cas d’utilisation
essentiel RETIRER DE L’ARGENT, en ne considérant que le paiement cash.

• Le diagramme de cas d’utilisation détaillé de la caisse enregistreuse. N’hésitez pas à

utiliser les relations entre cas d’utilisation pour rendre votre diagramme plus précis.
• Le diagramme d’activité système qui décrive le scénario nominal du cas d’utilisation
essentiel RETIRER DE L’ARGENT, en ne considérant que le paiement cash
• Le diagramme de classe
• Le diagramme de déploiement.
• Le diagramme d’Objet.

43
 UML

TRAVAIL DE RECHERCHE : PRATIQUES DES DIAGRAMMES UML

ÉTUDE D’UN TERMINAL POINT DE VENTE(TPV)

Cet exercice concerne un système simplifié de caisse enregistreuse de supermarché.

Le déroulement normal d’utilisation de la caisse est le suivant :

• Un client arrive à la caisse avec des articles à payer.

• Le caissier enregistre le numéro d’identification (CPU) de chaque article, ainsi que la quantité si
elle est supérieure à un.
• La caisse affiche le prix de chaque article et son libellé.
• Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
• La caisse affiche le total des achats.
• Le client choisit son mode de paiement :
– numéraire : le caissier encaisse l’argent reçu, la caisse indique la monnaie à rendre au client ;
– chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un centre
d’autorisation via la caisse ;
– carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une demande
d’autorisation à un centre d’autorisation en fonction du type de la carte.
• La caisse enregistre la vente et imprime un ticket.
• Le caissier donne le ticket de caisse au client.
Après la saisie des articles, le client peut présenter au caissier des coupons de réduction pour
certains articles. Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre
d’articles vendus au système de gestion de stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la journée.

Partie I
• Identifier les acteurs
• Le diagramme de contexte statique ;
• Le diagramme de contexte dynamique ;
• Identifier les cas d’utilisation ;
• Élaborez un diagramme de cas d’utilisation détaillé de la caisse enregistreuse. N’hésitez
pas à utiliser les relations entre cas d’utilisation pour rendre votre diagramme plus précis.
• Écrivez une description détaillée essentielle du cas d'utilisation principal :
TRAITER LE PASSAGE EN CAISSE.
• Réalisez un diagramme de séquence système qui décrive le scénario nominal
du cas d’utilisation essentiel TRAITER LE PASSAGE EN CAISSE, en ne considérant
que le paiement cash
• Réalisez le diagramme d’activité système qui décrive le scénario nominal du cas
d’utilisation essentiel TRAITER LE PASSAGE EN CAISSE, en ne considérant que le
paiement cash
• Réalisez le diagramme de classe.

Partie II

En utilisant l’argo UML ou PowerAMC représenter :

• Le diagramme de contexte statique;

44
 UML

• Le diagramme de contexte dynamique;

• Le Diagramme de cas d’utilisation ;
• Le diagramme de séquence ;
• Le diagramme d’activité ;
• Le diagramme de classe.

TP 3 SUR LES ITERATIONS RISQUES ET PLANIFICATIONS.

TP 4 SUR LES RELATIONS SUR LE DIAGRAMME DES CLASSES ET D’OBJETS.

TP 5 SUR LA BIBLIOTHEQUE (Schéma inverse de la procédure)

Exercice complémentaire

COMPLÉMENTS SUR LES RELATIONS ENTRE CLASSES Considérons les phrases

suivantes :

1. Un répertoire contient des fichiers.

2. Une pièce contient des murs.
3. Les modems et les claviers sont des périphériques d’entrée/sortie.
4. Une transaction boursière est un achat ou une vente.
5. Un compte bancaire peut appartenir à une personne physique ou morale.
6. Deux personnes peuvent être mariées.

Étape 1 – Modélisation métier (business modeling) Dans le cadre de l’amélioration qu’elle

veut apporter à son système d’information, une entreprise souhaite modéliser, dans un
premier temps, le processus de formation de ses employés afin que quelques-unes de
leurs tâches soient informatisées.
1. Le processus de formation est initialisé lorsque le responsable formation reçoit une
demande de formation de la part d’un employé. Cette demande est instruite par le
responsable qui la qualifie et transmet son accord ou son désaccord à l’intéressé.
2. En cas d’accord, le responsable recherche dans le catalogue des formations agréées un
stage qui correspond à la demande. Il informe l’employé du contenu de la formation et lui
propose une liste des prochaines sessions. Lorsque l’employé a fait son choix, le
responsable formation inscrit le participant à la session auprès de l’organisme de
formation concerné.
3. En cas d’empêchement, l’employé doit informer le responsable de formation au plus
tôt pour annuler l’inscription ou la demande.
4. À la fin de sa formation, l’employé doit remettre au responsable formation une
appréciation sur le stage qu’il a effectué, ainsi qu’un document justifiant de sa présence.
5. Le responsable formation contrôle par la suite la facture que l’organisme de formation
lui a envoyée avant de la transmettre au comptable achats.

45
UML

46
UML

47
UML

48