Modélisation avec UML

SARA KOULALI
Approche orientée objet

UML_GI2 S. KOULALI 2
De la programmation par Goto à la
programmation structurée
Branchement par Goto
Un simple test sur les valeurs des données:
Plus l'application est importante, plus le programme est gros et
complexe:
Programmation structurée
Décomposition d'une tâche en terme de sousprogrammes.
Analyse du problème de manière descendante ("TopDown").

UML_GI2 S. KOULALI 3
Coût des logiciels par rapport aux
résultats

UML_GI2 S. KOULALI 4
Critères de qualité d’un logiciel
Les facteurs de qualité d'un code [Object Oriented Software Construction,
[Link], Prentice Hall, 1997],
Correct : Le logiciel est capable de produire exactement les fonctions qu'on lui
demande par les spécifications.
Robuste : Le logiciel est capable de bien fonctionner dans des conditions anormales.
Extensible : Il est possible de modifier le logiciel simplement pour l'adapter à des
modifications dans les spécifications.
Réutilisable : Le logiciel peut être utilisé intégralement ou en partie dans de nouvelles
applications.
Compatible : C'est la possibilité de combiner le code du logiciel à d'autres codes.
Portable : C'est la facilité d'exécuter le logiciel sur différentes plates-formes.
Efficace : Cela se traduit par la bonne utilisation des ressources (temps, mémoire, etc.)

UML_GI2 S. KOULALI 5
Approche orientée objet
 Idée de base de A.O.O. repose sur l'OBSERVATION de la façon dont nous
procédons dans notre vie de tous les jours.
 Nous sommes entourés d'objets que nous manipulons, il nous importe peu de
savoir comment ils sont fabriqués.
 Dans le domaine du développement d'applications, rien n'existe sauf les
DONNÉES.
Construire les mécanismes qui:
structurent ces données;
les régissent => afin de les utiliser.

UML_GI2 S. KOULALI 6
Programmation Orientée Objet
Programmation dans laquelle les programmes sont organisés comme des
ensembles d'objets coopérant ensemble.
Ensemble hétérarchique de composants (les objets) indépendants
(encapsulation) dont la collaboration dynamique fonde les fonctionnalités du
système.

UML_GI2 S. KOULALI 7
L’approche OO : avantages
Stabilité dans la modélisation par rapport aux entités du monde réel
Adéquation avec un cycle itératif de développement
Équilibre traitement / données
Possibilité de réutiliser / porter des éléments d’un autre développement
Simplicité du modèle – 5 concepts :
◦ Objets, messages, classes, encapsulation héritage et polymorphisme

UML_GI2 S. KOULALI 8
L’approche OO : avantages
Développer des logiciels fondés
◦ Sur la modélisation des objets du monde réel
◦ Sur l’emploi de ce modèle pour bâtir une conception indépendante de tout
langage organisé autour de ces objets (C++, Eiffel, Java, SmallTalk,…)
Meilleure compréhension des besoins
Conception plus propre
Système plus facile à maintenir

UML_GI2 S. KOULALI 9
Concepts objets
Objets
◦ État
◦ Comportement
◦ Identité

Relations entre objets

◦ Message
◦ Interface
◦ abstraction

Classe / instance
Héritage
Polymorphisme

UML_GI2 S. KOULALI 10
Objet
Entité fermée douée de mémoire et de capacité de traitement,
agissant sur réception d'un message,
pouvant fournir un résultat.
 objet: voiture, répond au message: tourner la clé de contact

Un objet est formé de :

 données => définissent ce qu'il est,
 programmes ou procédures => définissent ce qu'il peut faire,

UML_GI2 S. KOULALI 11
Objet
Un objet est un regroupement dans une entité indépendante de
données et de procédures qui manipulent ces données. Ces
procédures sont appelées MÉTHODES.
 Les données sont séparées du monde extérieur par les méthodes.
Ces dernières définissent l'interface de l'objet ~ notion
d'ENCAPSULATION.

UML_GI2 S. KOULALI 12
Objet
Un objet est composé de 2 parties:
Partie interface: opérations qu'on peut faire dessus (partie publique)
Partie interne: données sensibles de l'objet (partie privée)
Les utilisateurs de l'objet ne voient que la partie interface.
Retrait: objet permet le retrait de l'argent,
Résultat: l'argent retiré,
Méthodes (processus): aucune idée (peu importe).

UML_GI2 S. KOULALI 13
Encapsulation
regroupement de code et de données,
dissimulation d'information au monde extérieur,
Parmi les avantages:
meilleure modularité => les communications entre objets sont traitées par les opérations
d'interface.
meilleure sécurité => certaines parties de l'objet sont inaccessibles et n'ont d'ailleurs pas à
être connues.
simplicité apparente pour l'utilisateur => Il n'y aura pas d'impact sur l'utilisateur de l'objet, si
le contenu de ce dernier est amené à changer, à condition que l'interface ne soit pas
modifiée.

UML_GI2 S. KOULALI 14
Communication avec les objets
MESSAGE:
transporte l'information nécessaire aux demandes à satisfaire,
moyen UNIQUE de communication avec les objets (impossible d'accéder
directement aux données encapsulées d'un objet).
contient:
nom de l'objet destinataire,
énoncé de la demande (exemple: le nom d'une fonction),
les arguments nécessaires (pour réaliser la demande)

UML_GI2 S. KOULALI 15
UML_GI2 S. KOULALI 16
Communication avec les objets
Faculté qu'ont des objets différents de réagir différemment en réponse au
même message.
Marcher sur la queue d'un chat => il miaule,
Marcher sur la queue d'un chien => il aboie.

Même nom de fonction, plusieurs implantations:

Fonction: opération addition (+)
addition des nombres entiers : 1+2=3
addition des nombres complexes: 1+2i + 3+4i = 4+6i

UML_GI2 S. KOULALI 17
Relations entre objets : messages
Système = ensemble d’objets en relation
◦ Dynamique du système : collaboration entre objets
◦ Interaction non structurée par passage de messages
◦ La communication entre objets est la grande différence entre l’approche
fonctionnelle et l’approche objet
Le concept de message
◦ Le message est le support d’une relation de communication qui relie, de façon
dynamique, les objets qui ont été séparés par le processus de décomposition
La notion de message est un concept abstrait mis en œuvre :
◦ Appel de procédure, événement discret, interruption,…

UML_GI2 S. KOULALI 18
Relations entre objets : messages
Interface d’un objet :contrôle de la modularité
◦ Interface = méthodes invocables par l’extérieur
◦ L’état de l’objet ne peut être modifié par l’extérieur qu’en
invoquant une méthode de l’interface
◦ L’objet peut refuser de répondre à une invocation externe
Abstraction de données
◦ Un objet est complètement défini par son interface
◦ Les autres objets n’ont pas à connaître l’implémentation
interne de l’objet pour communiquer avec lui

UML_GI2 S. KOULALI 19
Classe
Une classe est une définition d’un type d’objets
Elle décrit un groupe d’objets ayant les mêmes propriétés et le même
comportement afin d’en faciliter la gestion
Classe = maquette d’objets

UML_GI2 S. KOULALI 20
Classe : instanciation
Instance
◦ Tout objet d’une classe est appelé instance de la classe
◦ La classe décrit la structure de ses instances : elles auront les mêmes attributs et
méthodes que la classe
◦ Mais chaque instance à ses propres valeurs d’attributs
Cycle de vie d’une instance
◦ Création d’instance : constructeur – méthode de classe qui ne sera pas dans le
comportement de l’instance
◦ L’état courant d’une instance est défini en contexte et en toute indépendance par
l’objet créé

UML_GI2 S. KOULALI 21
UML_GI2 S. KOULALI 22
Hiérarchie de classes : héritage
Héritage
◦ Mécanisme de transmission des propriétés (attributs, comportements) d’une
classe vers ses sous-classes / classes filles
◦ Chaque sous-classe hérite les propriétés (attributs, comportements) de sa
super-classe
◦ Ce qui est générique est défini au niveau de la super- classe / classe mère
◦ Ce qui est spécifique est défini au niveau de la sous-classe

Exemple
◦ Êtres vivants, animaux, mammifères, chats, chat siamois

UML_GI2 S. KOULALI 23
UML_GI2 S. KOULALI 24
Hiérarchie de classes : héritage
Généralisation / Spécialisation
◦ Généralisation : mise en commun des propriétés communes entre
différentes classes dans une superclasse
◦ La généralisation est aussi appelée relation « est un » car chaque
instance de la sous-classe est aussi une instance de sa super-classe
◦ Spécification : création d’une sous-classe par mise en avant des
propriétés spécifiques non communes à toutes les (classes)
instances de la super-classe

UML_GI2 S. KOULALI 25
Hiérarchie de classes : héritage

UML_GI2 S. KOULALI 26
Hiérarchie de classes : propriétés
L’héritage est transitif au travers des niveaux de spécialisation
Une instance d’une sous-classe est simultanément une instance de toutes ses
classes ancêtres
L’état d’une instance prend une valeur pour tous les attributs de toutes ses
classes ancêtres
Toute opération sur toute classe ancêtre est applicable à toute instance d’une
sous-classe
Chaque sous-classe n’hérite pas seulement toutes les propriétés de ses
ancêtres mais possède aussi ses propres attributs et opérations spécifiques

UML_GI2 S. KOULALI 27
Hiérarchie de classes : propriétés
La notion d’héritage est différente pour les attributs et les
méthodes
oAttributs : ils sont hérités tels quel sans modification
oMéthodes : une méthode héritée peut être redéfinie dans la sous-classe
Exemple :
oArticle Obtenir_Prix_TTC {renvoie Prix_HT*1.055}
oArticle_de_Luxe Obtenir_Prix_TTC {renvoie Prix_HT*1.196}

UML_GI2 S. KOULALI 28
Classe abstraite
Classe ne permettant pas d’instancier d’objets
Une telle classe possèdent des sous -classes concrètes, i.e. instanciables
Elle sert à factoriser des attributs et des comportements communs, même si
ceux-ci ne sont totalement définis que dans les sous-classes concrètes.
Exemple
o Classe Vivant
o Classe Animal

Utilité
o Représentation de concepts fondamentaux pour l’application

UML_GI2 S. KOULALI 29
Héritage multiple
Un héritage est simple lorsqu’une classe n’hérite que d’une seule autre classe
Un héritage est multiple lorsqu’une classe hérite de plusieurs autres classes

Les héritages multiples permettent souvent d’avoir différents points de vue sur
les classes

UML_GI2 S. KOULALI 30
Héritage multiple
Conflits entre propriétés héritées
◦ Héritage d’un même nom d’attribut (ou de méthodes) par 2 sur
classes
◦ Exemple : filières d’inscription et d’enseignement
◦ Solution : interdiction de conflits de noms d’attributs, priorités entre classes
◦ Si plusieurs « chemin» d’héritage existe entre Cl-b et Cl-a, Cl-b
hérite plusieurs fois des caractéristiques de CL-a
◦ Exemple : Doctorant hérite 2 fois de Personne
◦ Solution : supprimer des liens d’héritage, ou résoudre les problèmes de conflit de nom s’ils
ont lieu

UML_GI2 S. KOULALI 31
Polymorphisme
Surcharge
◦ Définition : redéfinition d’une méthode héritée pour pouvoir lui donner une
implantation différente
◦ Utilité : la méthode garde la même sémantique – spécialisation tout en
gardant le même comportement vis à vis de l’extérieur : méthode polymorphe
Polymorphisme : liaison dynamique
◦ Elle se produit lors de l’envoi d’un message à un objet : l’objet réagit en
recherchant la méthode à partir de sa classe puis en remontant dans la
hiérarchie de ses super -classes
◦ Conséquences : déclenchement de traitements différents suivant le contexte
(i.e. classe réceptrice)

UML_GI2 S. KOULALI 32
Polymorphisme
Avantages
◦ Conception :un seul nom de méthode pour des
traitements équivalents mais spécifiques
◦ Adaptabilité :nouveau besoin = nouvelle sous-classe avec
surcharge pour adaptation à ce besoin spécifique

UML_GI2 S. KOULALI 33
L’approche OO : avantages
Stabilité dans la modélisation par rapport aux entités du monde réel
Adéquation avec un cycle itératif de développement
Équilibre traitement / données
Possibilité de réutiliser / porter des éléments d’un autre développement
Simplicité du modèle – 5 concepts :
◦ Objets, messages, classes, héritage et polymorphisme

UML_GI2 S. KOULALI 34
L’approche OO : avantages
Développer des logiciels fondés
◦ Sur la modélisation des objets du monde réel
◦ Sur l’emploi de ce modèle pour bâtir une conception indépendante de tout langage organisé autour de
ces objets (C++, Eiffel, Java, SmallTalk,…)

Meilleure compréhension des besoins

Conception plus propre
Système plus facile à maintenir

UML_GI2 S. KOULALI 35
Introduction à UML
Unified Modeling
Language

UML_GI2 S. KOULALI 36
UML : Unified Method Language
Langage pour spécifier, visualiser, construire, et documenter
Langage visuel et expressif de modélisation
◦ Exploitable par des méthodes d’analyse/conception différentes
◦ Adapté à toutes les phases du développement
◦ Compatible avec toutes les techniques de réalisation

Indépendant de tout langage de programmation et de toute

méthode de développement
Orienté objet
les approches Objet et UML s’appliquent sur tout le cycle de
développement
UML_GI2 S. KOULALI 37
UML : Unified Modeling Language
Mécanismes d’extension et de spécialisation en vue d’étendre les concepts de base
Base formelle pour la compréhension du langage
Encourage l’utilisation d’outils OO
Supporte les concepts de développement de haut niveau : patterns, composants et frameworks

UML devient un standard de facto, puisque l'industrie l'adopte en tant qu'ingrédient pour toute
méthode ou outil.

UML_GI2 S. KOULALI 38
 Origines d’UML
Issu en 1996 de la pratique industrielle et de la modélisation des systèmes logiciels.
Unification des méthodes objets de J-B-R
◦ Ivar Jacobson (OOSE) : expressive pour l’analyse des besoins grâce aux cas d’utilisation,
◦ Grady Booch (BOOCH'93) : expressive durant les phases de design et d’implantation des projets,
◦ James Rumbaugh (OMT) : expressive pour l’analyse et la conception de systèmes d’information à base de données,
Normalisation OMG en 1997. En 2007: UML 2.1.2
Méthodes
◦ Fonctionnelles : années 60
Inspirée de l’architecture des ordinateurs
études des fonctions en séparant les données du code.
◦ Objets : années 80
Modélisation objet avec composition et décomposition
des objets ayant des propriétés et des comportements
◦ Méthodes qui couvrent le cycle de vie d’un logiciel.
UML : de nouvelles techniques sans rejeter les méthodes existantes
UML_GI2 S. KOULALI 39
UML_GI2 S. KOULALI 40
UML contributions

41
Introduction
UML: langage de modélisation
Méta-modèle UML
◦ définit la structure des modèles UML
◦ permet la description du modèle concerné par l’application.
◦ une notation UML avec des éléments de la notation extensibles à condition d’en définir la sémantique

Construction de modèles objets ou autres

Utilisation de la notation graphique
◦ une solution visuelle
◦ limite les ambiguïtés
◦ indépendance par rapport aux langages

UML_GI2 S. KOULALI 42
Exemple
-> métamodèle -> Classe, Attribut, Opération

-> modèle -> Fournisseur

Identification, nomFournisseur, adresseFournisseur
commander()

-> objet -> « Dupont »

« 40222 », « ChipsAndChips », « 13 rue Parmentier »
« commander(12005A,13) »

UML_GI2 S. KOULALI 43
Démarche de conception et d’analyse
Analyse du pb: processus unifié UP
◦ guidée par les besoins des utilisateurs du système
◦ centrée sur l'architecture logicielle
◦ itérative et incrémentale

Utilisation d’un langage de modélisation UML

◦ permet d'améliorer progressivement les méthodes de travail,
◦ préserve les modes de fonctionnement,
◦ boîte à outils

L’itération peut se faire à toutes les phases

◦ étude préalable
◦ construction
◦ tests  et mise au point

UML_GI2 S. KOULALI 44
 Processus unifié
Langage de modélisation UML + Processus unifié UP
◦ UP: Processus de développement proposé par J-B-R
◦ Processus:
◦ Recensement des cas d’utilisation
◦ Construction de l’architecture du système dès le débutavec
◦ Principe d’itérations et incrémentations
◦ Évaluation des risques à toutes les étapes

« on part des cas d’utilisations connus, on construit un premier modèle

d’architecture; on complète et affine par itérations et incrémentations et on
évalue par étape les risques pour faire les meilleurs choix »

UML_GI2 S. KOULALI 45
Processus unifié
Les utilisateurs décrivent les cas d’utilisation
◦ Recensement des besoins
◦ Description des composants ou objets
◦ Description des modes opératoires
◦ Recensement des contraintes
◦ Interactions entre les besoins et les contraintes
◦ Construction d’une architecture du système en adéquation

Progression de la construction en complétant et affinant l’étude

◦ Ajouts, compléments, détails des cas d’utilisation
◦ Description plus détaillée des composants
◦ Ajustement de l’architecture

Utilisation de maquettes et prototypes

UML_GI2 S. KOULALI 46
Processus unifié
Evaluation permanente du système en terme de bon choix : le bon produit, une bonne
construction, le bon prix, les bonnes performances….
◦ Évolution
◦ Amélioration
◦ Validation ou rejet des solutions
◦ Objectif: minimiser les risques au fur et à mesure de la spirale de développement

UML_GI2 S. KOULALI 47
Processus unifié
Phases du processus UP:
◦ Étude d’opportunité
◦ Mesures des risques
◦ Définitions des limites
◦ Construction d’une maquette des premiers cas d’utilisation
◦ Décision
◦ Réalisation
◦ Première version
◦ Proposition d’architecture, développements, tests
◦ Rentabilité: décision
◦ Puis processus incrémental et itératif jusqu’au produit final
◦ Mise en exploitation

UML_GI2 S. KOULALI 48
Processus unifié
Les activités dans les phases:
◦ Expression des besoins
◦ Analyse
◦ Conception
◦ Implémentation
◦ Tests

« les activités sont celles des méthodes connues mais ces activités se déroulent selon les phases UP »

RUP: Rational Unified Process.

Version UP de la société Rational Software

UML_GI2 S. KOULALI 49
les règles UML
Développement orienté objet
UML langage de modélisation
◦ Règles d’écriture et de représentation graphiques normalisées
◦ Neuf diagrammes (UML 2.1.2: 13 diagrammes )

Méta-modèle des concepts et notations des diagrammes

◦ Construire les outils de modélisation selon les règles UML et adaptés à l’étude
◦ Règles
◦ Stéréotypes;
◦ Notes;
◦ Contraintes;
◦ règles d’écriture des noms et expressions: nom, étiquette valeur d’un composant;
◦ Paquetage.

UML_GI2 S. KOULALI 50
 les règles UML
Stéréotypes
◦ Adaptation du modèle aux éléments de l’application
◦ Nouveau type d’élément défini depuis un type du modèle
◦ Application principale aux classes
◦ Distinction d’utilisation entre guillemets
Ex: classe Client stéréotypée « clientA »

Notes
◦ Commentaires d’un élément UML

Client
« clientA » Pour tous
stéréotype commentaire

UML_GI2 S. KOULALI 51
les règles UML
Contrainte Écriture des noms et des
◦ Note sémantique pour un élément expressions
◦ Écriture entre { } ◦ Nom: identifiant d’un élément, chaîne
◦ Aussi langage OCL Objet Constraint Language de caractères
d’UML ◦ Expression: valeur
Elève Cours
assister noms
NomEleve
[Link]

expressions
{un élève doit
être Inscrit} After (7 minutes)
Date = 7 juillet 2005
contrainte

UML_GI2 S. KOULALI 52
les règles UML
Paquetage
◦ Décomposition du système en paquetages
◦ Ensemble logique d’éléments du modèle
◦ Nommage du paquetage
◦ Relations entre paquetages

Elèves U.E Profs

UML_GI2 S. KOULALI 53
Terminologie UML
La terminologie d’UML inclut trois sortes de briques :
Des éléments - abstractions essentielles à un modèle
Des relations - liens entre éléments
Des diagrammes - représentation graphique d’un ensemble d’éléments qui constituent un
système

UML_GI2 S. KOULALI 54
 Terminologie UML
Les éléments (abstractions essentielles à un modèle) peuvent être :
– Structurels – parties les plus statiques, ils représentent des éléments
conceptuels ou physiques (classes, interfaces, cas d’utilisation, composants,
noeuds)

UML_GI2 S. KOULALI 55
 Terminologie UML
– Comportementaux – parties dynamique (interactions, automates à
états finis)

UML_GI2 S. KOULALI 56
 Terminologie UML
– De regroupement – parties organisationnelles, ce sont les boîtes qui compose le
modèle (paquetages, frameworks, sous-systèmes)

–D’annotation – parties explicatives, ce sont les commentaires qui peuvent

accompagner tout élément à des fins d’explication, de description ou de remarque
(notes)

UML_GI2 S. KOULALI 57
Terminologie UML
Les relations (liens entre éléments) sont :
– La dépendance – relation sémantique entre 2 éléments selon
laquelle un changement apporté à l’un (elt indépendant)

UML_GI2 S. KOULALI 58
Terminologie UML
– L’association – relation structurelle qui décrit un ensemble de
liens, un lien constituant une relation entre différents objets

UML_GI2 S. KOULALI 59
 Terminologie UML
– La généralisation – relation de
spécialisation / généralisation selon
laquelle les attributs de l’élément
spécialisé (l’enfant) peuvent se
substituer aux attributs de l’élément
généralisé (le parent).
L’enfant partage la structure et le
comportement du parent

UML_GI2 S. KOULALI 60
Terminologie UML
– La réalisation - relation sémantique entre classificateurs, selon
laquelle un classificateur spécifie un contrat dont l’exécution est
garantie par un autre classificateur

UML_GI2 S. KOULALI 61
Terminologie UML
Les diagrammes (représentation graphique d’un ensemble
d’éléments qui constituent un système)
◦ Servent à visualiser un système sous différentes perspectives
◦ Pour un système complexe, ils peuvent ne représenter qu’une vue partielle du
système
◦ Sont classés selon trois vues principales du système

UML_GI2 S. KOULALI 62
3 vues de modélisation

UML_GI2 S. KOULALI 63
UML, différentes vues

64
UML, différentes vues (suite)
Vue Cas d'utilisation :
◦ Décrit le système comme un ensemble de transactions du point de vue
de l'utilisateur. Créée lors de la phase d'initialisation
Vue Logique :
◦ Contient une collection de conteneur, classes et relations. Créée lors de
la phase d'analyse et raffinée lors de la phase de développement
Vue Composants :
◦ Contient une collection de conteneur, et de programmes

65
UML, différentes vues (suite)
Vue Déploiement :
◦ Décrit l'architecture matérielle. Contient une collection d'unités et de
processus. Créée lors de la phase d'analyse
Vue Implantation :
◦ Contient une collection de modules et sous-modules (conteneur).Créée lors de
la phase d'analyse et affinée lors de la phase de développement

66
Diagrammes d’UML
L’UML spécifie treize types de diagrammes de modélisation des systèmes.

Chaque diagramme modélise une caractéristique de la structure ou du

comportement du système.

67
Diagrammes d’UML

Diagramme de cas d’utilisation :

◦ Décrit les fonctions du système selon le point de vue ses
futurs utilisateurs (Jacobson)

68
 Diagrammes d’UML
Diagramme de classes :
◦ structure des données du système définies comme un ensemble de relations entre classes

Diagramme d’objets :
◦ illustration des objets et de leur relations

Diagramme de collaboration :
◦ représentation des interactions entre objets

Diagramme d’états-transitions :
◦ représentation du comportement des objets d’une classe en terme d’états et de transitions d’états

Diagramme d’activités :
◦ structure d’une opération en actions

Diagramme de structure composite (depuis UML 2.x) : permet de décrire sous forme de
boîte blanche les relations entre composants d'une classe.

69
Diagrammes d’UML
Diagramme des paquetages
Diagramme de communication (depuis UML 2.x) : représentation simplifiée d'un
diagramme de séquence se concentrant sur les échanges de messages entre les objets.
Diagramme global d'interaction (depuis UML 2.x, cf. Interaction Overview Diagram) :
permet de décrire les enchaînements possibles entre les scénarios préalablement
identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité).
Diagramme de temps (depuis UML 2.x, cf. Timing Diagram) : permet de décrire
les variations d'une donnée au cours du temps.
Diagrammes d’UML :
Diagramme de séquence :
◦ représentation des interactions temporelles entre objets dans la réalisation
d’une opération
Diagramme de déploiement :
◦ description du déploiement des composants sur les dispositifs matériels

Diagrammes de composants :
◦ architecture des composants physiques d’une application

71
 Chapitre II
DIAGRAMMES DE CAS
D’UTILISATION
72
Les cas d’utilisation

Les cas d'utilisation servent de fil conducteur

pour l'ensemble du projet. Comprend
Exprime
Ils permettent de modéliser les besoins des Analyste
clients. Utilisateur

Ils précisent le but à atteindre. cas d'utilisation

Ils permettent d'identifier les fonctionnalités Réalise

principales (critiques) du système. Conçoit

vérifie
Programmeur
Testeur
Architecte

73
Définition de cas d’utilisation
Un cas d’utilisation
correspond à une manière spécifique d’utiliser
le système
est la représentation d’une fonctionnalité,
déclenchée en réponse à une stimulation du système.
facilite la structuration des besoins des utilisateurs.
exprime les limites et les objectifs du système

Cas d'utilisation
Acteur

74
Définition de cas d’utilisation (suite)

Un cas d’utilisation
est un ensemble des actions réalisées par le système
en réponse à une action d’un acteur.
est une suite d’interactions entre un acteur et
le système
correspond à une fonction visible par l’utilisateur

75
Définition d’acteur
Acteur : entité externe qui agit sur le système
prend les décisions contrairement à un élément
logiciel
possède un rôle par rapport au système (utilisateur
ou un autre système)

Retirer de l'argent
Porteur de carte
Guichet

76
Acteur (représentation en UML)
Pour chaque acteur :
• choisir un identificateur représentatif du rôle
• éventuellement accompagné d’une brève description
textuelle : Un guichetier est un
employé de la
banque jouant un rôle
d’interface entre le
système informatique
et les clients qu’il
reçoit au comptoir

Guichetier

77
Acteur (suite)
Ils peuvent être :
•soit des humains ;
•soit des logiciels ;
On distingue  :
◦les acteurs primaires : ceux sont les utilisateurs du
système ;
◦les acteurs secondaires : ceux qui interviennent pour le bon
fonctionnement du système.

78
Exemple de diagramme de cas d’utilisation
Retirer de l'argent

Déposer de l'argent

Client de la
banque
Effectuer des virements entre
comptes
Consulter le solde d'un compte

Employé de Ravitailler le distributeur

caisse

Agent de Réparer le distributeur

maintenance

79
Exemple de diagramme de cas d’utilisation
Système

Créer compte Déposer argent

Client

Guichetier
Consulter compte

Retirer de l'argent du
distributeur
Retirer de l'argent
Banque centrale

Gérer les comptes

80
Description d’un Use Case
Il existe plusieurs façons de décrire un use case.
 Description textuelle (informelle) :
Exemple :
Use case : “ Retrait en espèce ” :

1. Le guichetier saisit le n° de compte du client.

2. L’application valide le compte auprès du système central.
3. L’application demande le type d’opération au guichetier.
4. Le guichetier sélectionne un retrait d’espèces de 2000 DH.
5. Le système “ guichetier ” interroge le système central pour s’assurer que
le compte est suffisamment approvisionné.
6. Le système central effectue le débit du compte.
7. Le système notifie au guichetier qu’il peut délivrer le montant demandé.

81
Descriptions à l’aide de diagrammes de séquences

Saisie compte
Validation compte
Demande type d’opération

Retrait liquide (2000DH)

Vérification solde compte

Autorisation délivrance Débit compte

t Guichetier Système guichet Système central

82
Descriptions à l’aide de diagrammes de collaborations
(6) Débit compte

(4) Retrait espèces (2000DH)

Système Central
Guichetier

(5) vérification solde compte

(7) Autorisation
(3) Demande type délivrance
d’opération

(2) Validation compte

(1) Saisie compte
Système guichetier

83
Comment trouver les acteurs
Pour Dégager les acteurs d’un Système , on peut
poser les questions suivantes:
◦ Qui utilise le système.?
◦ Qui maintient le système?
◦ Qui administre le système?
◦ Quels autres systèmes qui interagit avec le système?
◦ Qui a besoin d'information venant du système?
Diagramme de contexte statique
Bien que ce diagramme ne fait pas partie des
diagrammes UML « Officiels », on l’a très souvent
trouvé utile, il permet de spécifier le nombre
d’instances d’acteurs connectés au système à un
moment donné.

Association
0..1 0..*
actor4
Multiplicité actor1
System
0..1
0..*
actor2 actor3
Éléments d’un Diagrammes de cas d’utilisation
1. les acteurs
2. les cas d’utilisation
3. Une relation d’association
Un chemin de communication entre un acteur et un cas d’utilisation est représenté un trait continu.
Types d’associations entre cas d’utilisations
Il existe principalement deux types de relations :
◦ l’inclusion et l’extension
◦ la généralisation/spécialisation.
La relation uses (ou include)
Une relation d’inclusion définit que le cas d’utilisation
contient le comportement définit dans
un autre cas d’utilisation.

88
Relation extends entre cas d’utilisation
Une relation d’extension définit que l’instance d’un cas
d’utilisation peut être augmentée avec un
comportement quelconque définis dans un cas
d’utilisation étendu. Il faut spécifier le point
d’extension sur le cas d’de destination.
Les deux UC peuvent s’exécuter indépendamment

90
Les points d’extension précisent des conditions sur
l’exécution des cas d’utilisation étendus.
 Relation de
Généralisation/Spécialisation
Cette relation entre deux cas d’utilisation, signifie que
le cas d’utilisation spécialisé est plus spécifique que le
cas d’utilisation général. Le spécialisé hérite de toutes
les propriétés et les associations du cas d’utilisation.

Paiement

Chèque Espèce
Carte crédit
Relation de
Généralisation/Spécialisation
 En pratique, l'arborescence des cas
d'utilisations correspondra à
l'arborescence du menu de l'application
Héritage (Généralisation/Spécialisation)
La généralisation est une association
ascendante du spécial au général
La spécialisation est une association
descendante du général au spécial

Paiement
Spécialisation

Généralisation
Chèque Espèce
Carte crédit
Exemple :
Le Versement bancaire peut se faire par dépôt d’argent par chèque
ou dépôt d’argent en espèce. (Spécialisation)

Le dépôt d’argent par chèque ou le dépôt d’argent en espèce se sont

des Versements Bancaires. (Généralisation)
N.B : La même phrase dite inversement.
 Exemples d’associations
Virement bancaire
Exemple Généralisation/Spécialisation

Porteur
de carte
Virement par
internet

Exemple Inclusion Exemple Extension

Consulter boite
Emails enregistrer
client
« include »

« extend»
Identification
renommer le fichier
 Description textuelle d’un cas
d’utilisation
Une description textuelle couramment utilisée se compose de
trois parties.
1- La première partie permet d’identifier le cas d’utilisation
Nom : Utiliser un verbe à l’infinitif (ex : Retirer de l’argent).
Objectif : Une description résumée permettant de comprendre l’intention
principale du cas d’utilisation.

Acteurs primaires: Ceux qui vont réaliser le cas d’utilisation

Acteurs secondaires : Ceux qui vont collaborer

Dates : Les dates de créations et de mise à jour de la description courante .

Responsable : Le nom des responsables.
Version : Le numéro de version.
2. La deuxième partie contient la description du fonctionnement du cas sous la forme d’une séquence de
messages échangés entre les acteurs et le système. Elle contient Toujours une séquence nominale qui
décrit le déroulement normal du cas. À la séquence Nominale s’ajoutent fréquemment des séquences
alternatives (des embranchement dans la séquence nominale) et des séquences d’exceptions (qui
interviennent quand une erreur se produise).

Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant que ce cas

d’utilisation puisse être déclenché.

Des scénarios : Ces scénarii sont décrits sous la forme d’échanges d’évènements entre l’acteur et le

système. On distingue le scénario nominal, qui se déroule quand il n’y a pas d’erreur, des scénarios

alternatifs qui sont les variantes du scénario nominal et enfin les scénarii d’exception qui décrivent les

cas d’erreurs.
Des postconditions : Elle décrivent l’état du système à l’issue des
différents scénarios.

La troisième partie (optionnelle): Elle contient des spécifications

non fonctionnelles, (spécifications
matérielle et technique portant sur le temps de réponse, outils,
Mono Multitâche…
 Description textuelle d’un cas
Exemple :
Scénario nominal d’utilisation

Actions acteurs principal Actions Système

1 2
Enchaînements alternatifs : 3

A1 : nom d’enchaînement
- Le point de démarrage à partir d’un point x du scénario nominal
- Les actions numérotées du système avec des numéros
- Le scénario nominal reprend au point y
Enchaînements des erreurs :
- E1 : Nom d’erreur
- Le point de démarrage à partir d’un point x du scénario nominal
- Les actions numérotées du système suite à cette erreur

Remarque :
Les enchaînements alternatifs et d’erreurs sont causé par l’utilisateur
Une erreur arrête le scénario. une alternative permet de reprendre
le scénario nominal.
Exemple: Les cas d’utilisation d’une vente de produits

Chercher produit <<include>>

Recherche prix

Nombre total <<include>>

Caissier Taxes (TVA)

Paiement

Chèque Espèce

Carte crédit

105
Description du cas d’utilisation: retirer de l’argent de
l’ATM
: GAB
: Porteur de CB : SA Visa
Description Visa
introduction carte Visa
du scénario demande de code

principal à code(valeur)
demande d'autorisation
l’aide d’un autorisation(solde)
diagramme de demande de montant
montant retrait(valeur)
séquence : demande de ticket
ok
éjection de carte
récupération de la carte
éjection de billets
récupération billets + tickets

106
 [non Ok pour 2 fois]

Vérification du
Demande
code
d'aurorisation
[ok]
[carte valide] [non Ok pour la 3e fois]
[retrait refusé]
[carte non valide]

Transaction annulée [retrait autorisé]

[montant<=solde] Détermination
Vérification de du montant
la carte Ejection de
la carte

[motant>solde]
[carte non repris après 15s]
[carte récupérée]
Description
[ticket demandé] du cas
Ejection d’utilisation à
des billets Impressio
ndu ticket l’aide d’un
[billets non récupéré après 30s]
diagramme
d’activités:
[billets récupérés]

Fin nominal
107
Cas d’utilisation et scénarios
Le système = ensemble de cas d’utilisation
Un cas d’utilisation = ensemble de scénarios (chemins d’exécution
possibles)
Un scénario est une séquence d’événements, et c’est un chemin
particulier d’exécution
On peut dire que: un scénario est une instance d’un cas
d’utilisation.
Une instance d’acteur crée un scénario
Un cas d’utilisation peut être décrit à l’aide d’un diagramme
d’activités
Un scénario peut être décrit à l’aide d’un diagramme de séquences

108
Uses Cases et Devis
 Un uses cases permet de produire un devis au
préalable, en déterminant le degré de difficulté
de chaque fonctionnalité ou cas d’utilisation et
après estime le coût et le délai de réalisation
 Chapitre III
DIAGRAMMES DE CLASSE ET
DIAGRAMMES D’OBJETS

110
Classe et Objet
Une classe est une description abstraite (modèle) d’un ensemble
d’objets ayant :
-des propriétés similaires,
-un comportement commun,
-des relations communes avec d’autres objets
-des sémantiques communes

Un objet est représentation individuelle(instance) d’une classe.

UML_GI2 S. KOULALI 111

Représentation d’une classe en
UML

Note: Les compartiments d’une classe peuvent être omis si leur contenu n’est pas
intéressant dans le contexte d’un diagramme

UML_GI2 S. KOULALI 112

Représentation d’une classe en
UML
Exemple :

UML_GI2 S. KOULALI 113

Attributs de classes
Un attribut de classe définit une propriété commune aux objets d’une
classe.

Les noms d’attributs d’une classe sont uniques.

Chaque objet, instance d’une classe, a sa propre identité, Indépendante

des valeurs de ses attributs.
L’identification d’un objet est donc facultative.
UML_GI2 S. KOULALI 114
Attributs de classes
Exemple:

UML_GI2 S. KOULALI 115

Opérations de classe
Une opération définit une fonction appliquée à des objets d’une
classe.

 Elle représente le service que la classe doit fournir à ces utilisateurs

UML_GI2 S. KOULALI 116

Opérations de classe
Exemple:

UML_GI2 S. KOULALI 117

Accessibilité aux attributs et
opérations d’une classe
Trois niveau de protection:
•Public (+) : accès à partir de toute
entité interne ou externe à la classe
•Protégé (#) : accès à partir de la
classe ou des sous-classes
•Privé (-) : accès à partir des opérations
de la classe

UML_GI2 S. KOULALI 118

Associations
Les associations représentent les liens unissant les
instances des classes

UML_GI2 S. KOULALI 119

Classe association
Une association peut être transformée en une classe
appelée classe associative ou classe association, lorsque
elle possède des attributs ou des opérations.

UML_GI2 S. KOULALI 120

Classe attribuée
Une association qui contient des attributs et qui ne
participe pas à des relations avec d’autres classe est
appelée classe attribuée.

UML_GI2 S. KOULALI 121

Nommage des associations
Nom de l’association en italique au milieu de la ligne
On note en général les association par une forme verbale, soit active,
soit passive

UML_GI2 S. KOULALI 122

Nommage des rôles
Toute association binaire possède 2 rôles :
-un rôle définit la manière dont une classe intervient dans une relation
-Le nommage des associations et le nommage des rôles ne sont pas
exclusifs l’un de l’autre

- Intérêt des rôles dans le cas où plusieurs associations lient deux classes : distinction
des concepts attachés aux associations

UML_GI2 S. KOULALI 123

Nommage des rôles
Exemple:

UML_GI2 S. KOULALI 124

Association réflexive

UML_GI2 S. KOULALI 125

Multiplicité des associations
La multiplicité est une information portée par le rôle, qui
indique le nombre d’objets successibles de participe à une
association

UML_GI2 S. KOULALI 126

Multiplicité des associations

UML_GI2 S. KOULALI 127

Contraintes sur les associations

UML_GI2 S. KOULALI 128

Contraintes sur les associations
La contrainte {sous-ensemble} indique qu’une
collection est incluse dans une autre collection

UML_GI2 S. KOULALI 129

Contraintes sur les associations

UML_GI2 S. KOULALI 130

Association particulière: agrégation
Une agrégation est une association non symétrique : l’une des extrémités joue un
rôle prédominant par rapport à l’autre.

Elle se justifie dans les cas suivants :

-Une classe B « fait partie » intégrante d’une classe A
- Les valeurs d’attributs de la classe B se propagent dans les valeurs d’attributs de la
classe B
-Une action sur la classe A implique une action sur la classe B
- Les objets de la classe B sont subordonnés aux objets de la classe A
UML_GI2 S. KOULALI 131
Association particulière : agrégation

-En tant que « propriétaire », une personne est un agrégat

d’immeubles …
-Les immeubles dont elle est propriétaire font partie de la description
d’une personne

UML_GI2 S. KOULALI 132

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

UML_GI2 S. KOULALI 133

Agrégation particulière :
Composition

UML_GI2 S. KOULALI 134

Généralisation - Spécialisation
Définition : relation (irréflexive, antisymétrique, transitive) entre une classe plus générale et une
classe plus spécifique (signifie “est un” ou “est une sorte de”). Ce n’est pas une association.

Exemple : un animal est un concept plus général qu’un chat ou un chien. Inversement un chien
est un concept plus spécialisé qu’un animal. La classe Animal est une généralisation de la classe
Chat ou la classe Chien. La classe Chien est une pécialisation de la classe Animal.

UML_GI2 S. KOULALI 135

Héritage simple
Définition: L’héritage est mécanisme permettant à une classe
d’utiliser les membres de sa classe mère sans avoir à les redéfinir.

UML_GI2 S. KOULALI 136

Héritage multiple
Définition : mécanisme permettant à une classe d’avoir plusieurs classes
mères.
Les super-classes n’ont pas forcément d’ancêtres communs

UML_GI2 S. KOULALI 137

Classe abstraite
Définition : classe non instanciable définissant au moins un mécanisme général
instanciable par des classes filles.
Représentation UML: définition de la classe avec la propriété {abstrait}

ou si une de ses opérations (héritée ou non) possède la propriété {abstrait= vrai}.

UML_GI2 S. KOULALI 138

Classe abstraite (suite)
On définit une classe abstraite lorsque :
il est impossible de connaître l’implantation d’une méthode

(abstraction d’une opération).

Exemple : l’opération manger() de la classe Animal n’a pas de
sens sémantique propre; il s’agit d’une propriété existant chez
tous les animaux; il est impossible de préciser le comportement
de ce service au niveau de la classe Animal.

L’instanciation d’une classe n’a aucun sens sémantique ou

pratique.
UML_GI2 S. KOULALI 139
Interface
Définition : description d’un ensemble d’opérations
utilisées pour spécifier un service offert par une classe.
Ne contient ni attribut, ni association, ni implémentation
des opérations (les opérations sont abstraites).
Une classe réalisant une interface doit :
soit implémenter les opérations de l’interface,
soit définir les opérations de l’interface comme des opérations abstraites

(implémentables par les classes filles).

UML_GI2 S. KOULALI 140

Interface(suite)
 Représentation UML:
 classe ayant le stéréotype <<interface>>, ou par un
cercle pour faire référence à l’interface utilisée dans la
classe,
 flèche d’héritage en pointillés pour la réalisation d’une

interface par une classe,

 flèche de dépendance en pointillés pour l’utilisation.

UML_GI2 S. KOULALI 141

Contraintes de généralisation
-Une classe peut être spécialisée selon plusieurs critères
-Certaines contraintes peuvent être posées sur les relations de
généralisation

UML_GI2 S. KOULALI 142

 La contrainte de généralisation :
{Disjoint}
La contrainte {Disjoint} (ou {exclusif}) indique la
participation exclusive d’un objet à l’une des collections
spécialisées.

UML_GI2 S. KOULALI 143

La contrainte de généralisation:
{Inclusif}
- La contrainte {chevauchement} (ou {inclusif}) indique la
participation possible d’un objet à plusieurs collections
spécialisées

UML_GI2 S. KOULALI 144

 La contrainte de généralisation:
{Complète} ≠ {Incomplète}
-La contrainte {Complète} indique la généralisation est terminée : tout
ajout de sous-classe est alors impossible.
-A l’inverse, la contrainte {Incomplète} indique une généralisation
extensible

UML_GI2 S. KOULALI 145

Diagramme d’objets
Un diagramme d’objets représente les liens structurels entre
instances des classes
Il Facilite la compréhension de structures complexes
Trois représentations possibles des instances

UML_GI2 S. KOULALI 146

Diagramme d’objets
Les valeurs des attributs sont optionnelles ainsi que les liens entre
objets

UML_GI2 S. KOULALI 147

Diagramme d’objets
Les liens, instances des associations réflexives, peuvent relier un
objet à lui même.

UML_GI2 S. KOULALI 148

Diagramme d’objets
 Les objets composés de sous-objets peuvent être visualisés :

UML_GI2 S. KOULALI 149

Diagramme d’objets: structures
complexes
Les diagrammes d’objets facilitent la compréhension et l’élaboration
d’un diagramme de classes :

UML_GI2 S. KOULALI 150

Résumé

UML_GI2 S. KOULALI 151

UML_GI2 S. KOULALI 152