heg Haute école de gestion

de Neuchâtel

UML – Langage unifié pour la

modélisation objet

14/11/01 UML R01 V1-1a 1

heg Haute école de gestion Démarche
de Neuchâtel

Ce document de révision du cours UML a été réalisé sur

la base de l’ouvrage:

Le guide de l’utilisateur UML

Booch / Rumbaugh / Jacobson
Eyrolles (traduction française) [BRJ-00]

14/11/01 UML R01 V1-1a 2

heg Haute école de gestion L’importance de la modélisation
de Neuchâtel

Qu’est qu’un modèle?

Un modèle est une simplification de la réalité
Pourquoi modéliser?
Les modèles permettent de mieux comprendre
le système que l’on développe

Nous construisons des modèles pour les systèmes

complexes parce que nous ne sommes pas en
mesure d’appréhender de tels systèmes dans leur
intégralité.
14/11/01 UML R01 V1-1a [BRJ-00 p5-7] 3
heg Haute école de gestion Les quatre principes de modélisation
de Neuchâtel

1. Le choix des modèles à créer a une forte

influence sur la manière d’aborder un
problème et sur la nature de sa solution.
2. Tous les modèles peuvent avoir différents
niveaux de précision.
3. Les meilleurs modèles ne perdent pas le sens
de la réalité.
4. Parce qu’aucun modèle n’est suffisant à lui
seul, il est préférable de décomposer un
système important en un ensemble de petits
modèles presque indépendants.

14/11/01 UML R01 V1-1a [BRJ-00 p8-9] 4

heg Haute école de gestion UML - Langage
de Neuchâtel

UML est un langage conçu pour:

– visualiser
– spécifier
– construire
– documenter
les artefacts d’un système à forte composante
logicielle

14/11/01 UML R01 V1-1a [BRJ-00 p14] 5

heg Haute école de gestion Processus de développement (de) logiciel
de Neuchâtel

Un processus correctement défini aide à

choisir:
– les artefacts à produire
– les procédures à développer
– les intervenants chargés de leur création et
de leur gestion
– la manière d’employer ces artefacts pour
évaluer et diriger le projet dans son
ensemble

14/11/01 UML R01 V1-1a [BRJ-00 p14] 6

heg Haute école de gestion UML - 3 sortes de briques
de Neuchâtel

• Eléments • Diagrammes
– structurels – de classes
– comportementaux – d’objets
– de regroupement – de cas d’utilisation
– d’annotation – de séquence
• Relations – de collaboration
– de dépendance – d’états-transition
– d’association – d’activités
– de généralisation – de composants
– de réalisation – de déploiement

14/11/01 UML R01 V1-1a [BRJ-00 p18] 7

heg Haute école de gestion Les éléments structurels
de Neuchâtel

• Conceptuels (représentent des concepts intellectuels

– Les classes
– Les interfaces
– Les collaborations
– Les cas d’utilisation
– Les classes actives
• Physiques (représentent des réalisations concrètes)
– Les composants
– Les noeuds
14/11/01 UML R01 V1-1a [BRJ-00 p19] 8
heg Haute école de gestion Les éléments comportementaux
de Neuchâtel

• Les interactions
– Les messages

• Les automates à états finis (machines états-

transition
– Les états

14/11/01 UML R01 V1-1a [BRJ-00 p22] 9

heg Haute école de gestion Les éléments de regroupement, d’annotation
de Neuchâtel

• Les paquetages

• Les notes

14/11/01 UML R01 V1-1a [BRJ-00 p23] 10

heg Haute école de gestion Les relations
de Neuchâtel

• La dépendance
Cible

• L’association

• La généralisation
Parent

• La réalisation

Contrat
14/11/01 UML R01 V1-1a [BRJ-00 p24] 11
heg Haute école de gestion Architecture
de Neuchâtel

Vocabulaire Assemblage du
Fonctionnalité système
Vue de Gestion de
Vue
conception configuration
d’implémentation

Comportement Vue des cas

d’utilisatio
Vue des n Vue de
processus déploiement
Performance Topologie du
Capacité à monter en charge système
Débit Distributiuon
Livraison
Installation

14/11/01 UML R01 V1-1a [BRJ-00 p34] 12

heg Haute école de gestion Architecture
de Neuchâtel

Logical View Component View

Vue de Vue
conception d’implémentation

Use Case View Vue des cas

d’utilisatio
Vue des n Vue de
processus déploiement

A créer! Deployment View

14/11/01 UML R01 V1-1a [BRJ-00 p34] 13

heg Haute école de gestion Architecture
de Neuchâtel

Utilisateur final Programmeurs

Vocabulaire Assemblage du
Fonctionnalité système
Vue logique Vue Gestion de
d’implémentation configuration

Analystes/Testeurs
Vue des cas
Comportement d’utilisatio
Vue des n Vue de
processus déploiement
Ingénieurs système
Intégrateurs systèmes Topologie du
Performance système
Capacité à monter en charge Distributiuon
Débit Livraison
Installation

14/11/01 UML R01 V1-1a [PK-00 p81] 14

heg Haute école de gestion Modélisation des éléments non-logiciels
de Neuchâtel

1. Modéliser sous forme de classes les

abstractions que l’on porte sur les éléments
2. Créer de nouvelles briques à l’aide de
stéréotypes

14/11/01 UML R01 V1-1a [BRJ-00 p59] 15

heg Haute école de gestion Relation de dépendance
de Neuchâtel

La plupart du temps, les dépendances servent à

montrer qu’une classe en utilise une autre comme
argument dans la signature d’une opération. On
parle alors de relation d’utilisation: si la classe
utilisée change, l’opération de l’autre classe peut
en être affectée…

14/11/01 UML R01 V1-1a [BRJ-00 p66] 16

heg Haute école de gestion Diagramme d’activités
de Neuchâtel

L’illustration d’une chose intrinsèquement

dynamique (comme le comportement d’un
système) à l’aide de diagrammes (qui sont des
artefacts intrinsèquement statiques, surtout
lorsqu’on les dessine sur une feuille de papier, un
tableau blanc ou au dos d’une enveloppe) présente
des limites pratiques évidentes. Sur l’écran de
l’ordinateur, on peut animer les diagrammes
comportementaux afin qu’ils simulent un système
exécutable…

14/11/01 UML R01 V1-1a [BRJ-00 p105] 17

heg Haute école de gestion Modélisation d’un schéma logique de BD
de Neuchâtel

Les diagrammes de classes UML constituent un

surensemble de diagrammes entités-associations
(E-A), un outil de modélisation courant pour la
conception des bases de données. Alors que les
digrammes E-A classiques sont centrés sur les
données, les diagrammes de classes vont un peu
plus loin et permettent également la modélisation
de comportements. Dans la base de données
physique, ces opérations logiques sont en général
transformées en déclencheurs (triggers) ou en
procédures stockées ( stored procedures).
14/11/01 UML R01 V1-1a [BRJ-00 p118] 18
heg Haute école de gestion Portée des attributs de classes
de Neuchâtel

La portée d’une caractéristique précise si cette

caractéristique apparaît dans chaque instance du
classificateur ou s’il n’y a qu’une seule instance de la
caractéristique pour toutes les instances du classificateur.

Dans l’exemple ci-dessus:

header a une portée « instance »
uniqueID a une portée « classificateur » ou constante de classe

14/11/01 UML R01 V1-1a [BRJ-00 p133] 19

heg Haute école de gestion Modélisation de la sémantique d’une classe
de Neuchâtel

+ Informel
• Responsabilités
• Sémantique globale
• Spécification du corps de chaque opération
• Spécification des pré et postconditions de
chaque opération (texte structuré)
• Définir un automate à états finis
• Spécifier une collaboration
• Spécification des pré et postconditions de
chaque opération (langage OCL)
+ Formel

14/11/01 UML R01 V1-1a [BRJ-00 p142] 20

heg Haute école de gestion Interfaces et classes abstraites
de Neuchâtel

Les interfaces ressemblent aux classes abstraites

(par exemple, ni les unes ni les autres ne peuvent
avoir d’instances directes), mais elles en sont
assez différentes pour être des éléments de
modélisation distincts en UML. Les classes
abstraites peuvent avoir des attributs, ce qui n’est
pas le cas des interfaces. De plus, ces dernières
chevauchent les fontières des modèles. Une même
interface peut être réalisée à la fois par une classe
(une abstraction logique) et par un composant
(une abstraction physique qui fournit une
manifestation de la classe).
14/11/01 UML R01 V1-1a [BRJ-00 p171] 21
heg Haute école de gestion Les interfaces et les frontières des modèles
de Neuchâtel

Abstraction
logique

Abstraction
physique

14/11/01 UML R01 V1-1a [BRJ-00 p171] 22

heg Haute école de gestion Paquetages et classes
de Neuchâtel

Il existe une différence importante entre les classes

et les paquetages: les classes sont des abstractions
d’éléments rencontrés dans un problème ou dans
une solution, alors que les paquetages sont des
mécanismes utilisés pour organiser ces éléments
dans un modèle. Les paquetages n’ont aucune
identité (ce qui signifie que les instances de
paquetages n’existent pas et qu’ils sont invisibles
dans le système en exécution), tandis que les
classes ont une identité (elles ont des instances,
qui sont les éléments d’un système en exécution).
14/11/01 UML R01 V1-1a [BRJ-00 p189] 23
heg Haute école de gestion Objets concrets et objets prototypes
de Neuchâtel

La différence sémantique entre objets concrets et

objets prototypes est subtile et ne concerne
vraiment que les concepteurs confirmés…
Les objets concrets apparaissent dans des
représentations statiques, telles que des
diagrammes d’objets, des diagrammes de
composants et des diagrammes de déploiement,
alors que les objets prototypes apparaissent dans
des diagrammes d’interaction et des diagrammes
d’activités.

14/11/01 UML R01 V1-1a [BRJ-00 p205] 24

heg Haute école de gestion Objets et rôles
de Neuchâtel

Les objets qui participent à une interaction sont des éléments

concrets ou des prototypes…
– Objet concret: Jean Dupont, le caissier
– Objet prototype: un caissier
On peut trouver des instances de classes, de composants, de
nœuds et de cas d’utilisation dans le contexte d’une
interaction. Même si, par définition, les classes abstraites et
les interfaces ne peuvent pas avoir d’instances directes, il est
possible de trouver des instances de ces éléments dans une
interaction. Elles ne représentent pas des instances directes
de la classe abstraite ou de l’interface, mais peuvent indiquer,
respectivement, des instances indirectes (prototypes) de
n’importe quels enfants concrets de la classe abstraite ou une
classe concrète qui réalise cette interface

14/11/01 UML R01 V1-1a [BRJ-00 p221] 25

heg Haute école de gestion Les messages
de Neuchâtel

Un message est la spécification d’une

communication entre objets, qui transporte des
informations et qui s’affiche dans le but de
déclencher une activité. La réception d’une
instance de message peut être considérée comme
une instance d’un événement.
Lorsqu’on transmet un message, l’action qui en
résulte est un énoncé exécutable qui forme une
abstraction d’une procédure de calcul. Cette
action peut conduire à un changement d’état.

14/11/01 UML R01 V1-1a [BRJ-00 p223] 26

heg Haute école de gestion Les actions déclenchées par les messages
de Neuchâtel

call invoque une opération pour un objet.

Un objet peut s’envoyer un message,
qui résulte en l’invocation locale
d’une opération
return renvoie une valeur à l’émetteur
send envoie un signal à l’objet
create crée un objet
destroy détruit un objet. Un objet peut se
détruire lui-même
14/11/01 UML R01 V1-1a [BRJ-00 p223] 27
heg Haute école de gestion Application des cas d’utilisation
de Neuchâtel

On peut appliquer les cas d’utilisation à un

système dans son intégralité. On peut également
les appliquer à une partie d’un système, aux sous-
systèmes ainsi qu’aux classes individuelles et aux
interfaces.

14/11/01 UML R01 V1-1a [BRJ-00 p235] 28

heg Haute école de gestion Les relations entre cas d’utilisation
de Neuchâtel

Un cas d’utilisation peut comporter des variantes.

Dans tous les systèmes intéressants, on trouve des
cas d’utilisation qui sont des versions spécialisées
d’autres cas d’utilisation, des cas d’utilisation qui
font partie intégrante d’autres cas d’utilisation et
des cas d’utilisation qui élargissent le
comportement d’autres cas d’utilisation essentiels.

14/11/01 UML R01 V1-1a [BRJ-00 p235] 29

heg Haute école de gestion Généralisation, inclusion et extension
de Neuchâtel

14/11/01 UML R01 V1-1a [BRJ-00 p242] 30