16/10/2021

Modélisation Orienté Objet

82

COO

• La Conception Orientée Objet (COO) est la méthode qui conduit à

des architectures logicielles fondées sur les objets du système, plutôt
que sur une décomposition fonctionnelle.
• C’est la structure du système lui donne sa forme.
• On peut partir des objets du domaine (briques de base) et remonter
vers le système global : approche ascendante.
• Attention, l’approche objet n’est pas seulement ascendante

83

1
 16/10/2021

Objet

• Un objet représente une entité du monde réel (ou du monde virtuel

pour les objets immatériels) qui se caractérise par une identité, des
états significatifs et un comportement.
• Objet = Etat + Comportement + Identité
• Un objet sans état ou sans comportement peut exister
marginalement, mais dans tous les cas, un objet possède une
identité.
• Exemple : une personne, une voiture, une maison, ...

84

Objet: État

• L’état regroupe les valeurs instantanées de tous les attributs d’un

objet sachant qu’un attribut est une information qui qualifie l’objet
qui le contient.
• Chaque attribut peut prendre une valeur dans un domaine de
définition donné.
• L’état d’un objet, à un instant donné, correspond à une sélection de
valeurs, parmi toutes les valeurs possibles des différents attributs.

85

2
 16/10/2021

Objet :Comportement

• Le comportement regroupe toutes les compétences d’un objet et

décrit les actions et les réactions de cet objet.
• Les opérations (méthodes).

86

Objet : Identité

• En plus de son état, un objet possède une identité qui caractérise

son existence propre. L’identité permet de distinguer tout objet de
façon non ambiguë, et cela indépendamment de son état.
• Cela permet, entre autres, de distinguer deux objets dont toutes les
valeurs d’attributs sont identiques.
• L’identité est un concept, elle ne se représente pas de manière
spécifique en modélisation.
• Chaque objet possède une identité de manière implicite.

87

3
 16/10/2021

Classe: Définition

• Une classe est l’abstraction d’un ensemble d’objets qui possèdent

une structure identique (liste des attributs) et un même
comportement (liste des opérations).
• Exemple : employé , entreprise, personne...
• Un objet est une instance d’une et une seule classe.

88

Classe: Exemple

89

4
 16/10/2021

Classe: Exemple

90

Classe: Exemple

91

5
 16/10/2021

Analyse et conception orientées objet

• Analyse orientée objet : Méthode d’analyse qui examine les besoins

en termes de classes et d’objets trouvés dans l’espace du problème.
• Conception orientée objet : Méthode de conception qui mène à
une décomposition orientée objet et utilise une notation pour
représenter les différents aspects du système en cours de conception

92

Analyse et conception orientées objet

• La modélisation orientée objets comporte quatre éléments

principaux :
• l’abstraction : représentation des caractéristiques essentielles d’un objet qui
permettent de le distinguer de tous les autres;
• l’encapsulation : processus de compartimentation des éléments d’une
abstraction qui constituent sa structure et son comportement;
• la modularité : capacité qu’a un système d’être décomposé en un ensemble de
modules cohérents et faiblement couplés;
• l’héritage : ordonnancement d’abstractions.

93

6
 16/10/2021

Concepts de l’approche objet: Abstraction

• Le pilier de l’approche orienté objet :

• Processus consistant à identifier une entité en mettant en évidence ses
caractéristiques pertinentes du point de vue de son utilisation.
• Caractéristiques essentielles d’une entité qui la distingue de tous les autres types
d’entités; une abstraction définit la frontière relative à la perspective de
l’observateur.
• La voiture pour un mécanicien est considérée du point de vue de sa
mécanique alors que le concessionnaire va appréhender son
équipement et son prix : (mécanique / produit).

94

95

7
 16/10/2021

Concepts de l’approche objet: Encapsulation

• L’encapsulation est un mécanisme consistant à rassembler les

données et les méthodes au sein d’une structure en cachant
l’implémentation de l’objet, c’est-à-dire en empêchant l’accès aux
données par un autre moyen que les services proposés.
• L’encapsulation permet donc de garantir l’intégrité des données
contenues dans l’objet.

96

Concepts de l’approche objet: Encapsulation

97

8
 16/10/2021

Concepts de l’approche objet: Encapsulation

• Il existe trois niveaux distincts d’encapsulation :

• Niveau privé : Le niveau le plus fort ; la partie privée de la classe est totalement
opaque.
• Niveau protégé : Le niveau intermédiaire; les attributs placés dans la partie
protégée sont visibles par les classes dérivées de la classe fournisseur. Pour
toutes les autres classes, les attributs restent invisibles.
• Niveau publique : Les attributs sont visibles pour toutes les classes

98

Concepts de l’approche objet: Encapsulation

• Exemple:

99

9
 16/10/2021

Concepts de l’approche objet: Modularité

• Un module est une construction séparée.

• L’utilisation de modules permet de contrôler la complexité de
grosses applications.
• La modularité est la propriété d’un système qui a été décomposé en
ensemble de modules regroupant des abstractions logiquement
reliées et faiblement couplés.

100

Concepts de l’approche objet: Héritage

• L’héritage est un mécanisme de transmission des propriétés d’une

classe (ses attributs et méthodes) vers une sous-classe.
• Une classe peut être spécialisée en d’autres classes, afin d’y ajouter
des caractéristiques spécifiques ou d’en adapter certaines.
• Plusieurs classes peuvent être généralisées en une classe qui les
factorise, afin de regrouper les caractéristiques communes d’un
ensemble de classes.
• La spécialisation et la généralisation permettent de construire des
hiérarchies de classes.
• L’héritage peut être simple ou multiple.
• L’héritage évite la duplication et encourage la réutilisation.

101

10
 16/10/2021

Concepts de l’approche objet: Héritage

102

Concepts de l’approche objet: Polymorphisme

• Le polymorphisme signifie qu’une même opération peut se

traduire différemment selon l’objet sur lequel elle s’applique.
• Le polymorphisme augmente la généricité du code.

103

11
 16/10/2021

Concepts de l’approche objet: Polymorphisme

• L’opération déplacer dans un jeu d’échec : le déplacement dépend

du type de pièce.

104

Concepts de l’approche objet: Polymorphisme

105

12
 16/10/2021

Exercice:

• Modéliser la classe Véhicule.

• Attributs
• Méthodes
• Modéliser la classe Voiture qui hérite de Véhicule.
• Nouveaux attributs et méthodes

106

Corrigé

107

13
 16/10/2021

Unified Modeling Language

108

Unified Modeling Language

• UML n’est pas une méthode dans la mesure où elle ne présente aucune
démarche. A ce titre UML est un formalisme de modélisation objet.
• UML n’est donc pas une méthode ou un processus; en raison de la
diversité des cas particuliers.
• UML propose un ensemble de notations pour que chacun ait à sa
disposition les éléments nécessaires à la conception d’une application.
• UML est donc un métalangage : il fournit les éléments permettant de
construire le modèle;
• les éléments de modélisation (les concepts manipulés par le langage),
• la sémantique de ces éléments (leur définition et le sens de leur utilisation).

109

14
 16/10/2021

Unified Modeling Language

• Un diagramme UML fournit une représentation visuelle d'un

aspect d'un système.
• Les diagrammes UML illustrent les aspects quantifiables d'un
système qui peuvent être décrits visuellement, tels que les relations,
le comportement, la structure ou la fonctionnalité.
• Par exemple: un diagramme de classes décrit la structure du
système ou les détails d'une implémentation, tandis qu'un
diagramme de séquence montre l'interaction entre des objets dans le
temps.

110

Unified Modeling Language

• Dans un diagramme UML, les éléments du diagramme

représentent visuellement les discriminants dans un système ou
une application.
• Ces discriminants sont la représentation schématique d'un élément
source. Les diagrammes UML fournissent des vues d'éléments
source, mais les éléments de diagramme n'ont pas de valeur
sémantique.

111

15
 16/10/2021

Unified Modeling Language

• Les diagrammes UML peuvent aider les architectes et

développeurs du système à comprendre une application, à y
collaborer et à la développer.
• Les architectes et gestionnaires de haut niveau peuvent utiliser des
diagrammes UML pour visualiser un système ou un projet complet
et pour séparer des applications en composants plus petits en vue du
développement.

112

Unified Modeling Language

• Les développeurs du système peuvent utiliser des diagrammes UML

pour définir, visualiser et documenter les applications ce qui
améliore l'efficacité de leur travail et la conception des
applications.
• Les diagrammes UML peuvent aussi aider à identifier des patterns
de comportement, ce qui peut fournir des opportunités de
réutilisation et de rationalisation des applications.

113

16
 16/10/2021

Unified Modeling Language

• La représentation visuelle d'un système fournie par les diagrammes

UML peut offrir une vue à la fois globale et détaillée du concept et
de la conception d'une application.
• Vous pouvez utiliser divers types de diagramme pour modéliser un
système ou une application selon le système, le public visé et le
détail du modèle que vous créez.
• En fonction des diagrammes choisis, vous pouvez sélectionner le
détail et le niveau d'abstraction affichés par les diagrammes.

114

4+1 vues de Kruchten

115

17
 16/10/2021

4+1 vues de Kruchten

• Le modèle "4+1" vues, dit de Kruchten, d’un système informatique

permet d’organiser la description du système en plusieurs vues
complémentaires, chacune présentant le système selon un point de
vue différent.
• L’utilisation de vues permet de traiter séparément les intérêts des
divers groupes d’intervenants (architectes, utilisateurs,
développeurs, chefs de projets, etc.) et ainsi de mieux séparer les
préoccupations fonctionnelles et les préoccupations
extrafonctionnelles.

116

4+1 vues de Kruchten

• Ce modèle est composé de cinq vues.

• La vue « logique » décrit les aspects statiques et dynamiques d’un
système en termes de classes, d’objets, de connexions et de
communications. Elle se concentre sur l’abstraction et
l’encapsulation.
• La vue « processus » capte les aspects de concurrence et de
synchronisation, et les décompose en flux d’exécution (processus, fil
d’exécution, etc.). Elle se rapporte aux objets actifs et aux
interactions.

117

18
 16/10/2021

4+1 vues de Kruchten

• La vue « développement » représente l’organisation statique des

modules (exécutable, codes source, paquetages, etc.) dans
l’environnement de développement.
• La vue « physique » décrit les différentes ressources matérielles et
l’implantation logicielle tenant compte de ces ressources. Donc, elle
se rapporte aux nœuds physiques d’exécution et au placement des
objets sur les nœuds.

118

4+1 vues de Kruchten

• La dernière vue, appelée « cas d’utilisation », se concentre sur la

cohérence en présentant des scénarios d’utilisation qui mettent en
œuvre les éléments des quatre premières vues.
• Les scénarios sont une abstraction des exigences fonctionnelles de l’application.
Cette dernière vue valide en quelque sorte les autres vues et assure la cohérence
globale.
• C’est aussi cette dernière vue qui est construite en premier, juste après
l’établissement du cahier des charges, pour fixer les contours du système à
réaliser avec ses fonctionnalités appelées, dans la terminologie UML, des cas
d’utilisation.

119

19
 16/10/2021

Les diagrammes

• La spécification UML définit deux types principaux de diagramme

UML : les diagrammes de structure et les diagrammes de
comportement.

120

Les diagrammes

• Les diagrammes de structure montrent la structure statique du

système et de ses parties à différents niveaux d'abstraction et de mise
en œuvre et comment ils sont liés les uns aux autres. Les éléments
d'un diagramme de structure représentent les concepts significatifs
d'un système et peuvent inclure des concepts abstraits, réels et de
mise en œuvre.
• Les diagrammes de comportement montrent le comportement
dynamique des objets dans un système, qui peut être décrit comme
une série de changements apportés au système au fil du temps.

121

20
 16/10/2021

Les diagrammes

122

123

21
 16/10/2021

Les 5 vues et les diagrammes

124

Les Diagrammes selon les axes de mod´elisation

125

22
 16/10/2021

Notations UML

126

Notations UML

• Classeur:
• Un classeur est un élément de modèle qui est doté d’une identité, possède des
caractéristiques structurelles (attributs, participation à des relations) et
comportementales (opérations).
• Un classeur se représente par un rectangle, en traits pleins, contenant
éventuellement des compartiments.
• Les acteurs et les cas d'utilisation sont des classeurs.

127

23
 16/10/2021

Notations UML

• Paquetage (package):
• Un paquetage est un regroupement d’éléments de modèle ou de diagrammes.
• Il permet ainsi d'organiser des éléments de modélisation en groupes. Il peut
contenir tout type d'élément de modèle : des classes, des cas d'utilisation, des
interfaces, des diagrammes… et même des paquetages imbriqués.
• Un paquetage se représente comme un dossier avec son nom inscrit dedans.
• Il est possible de représenter explicitement le contenu d'un paquetage: le nom
du paquetage est placé dans l'onglet.

128

Notations UML

• Paquetage (package):
• Les éléments contenus dans un paquetage doivent représenter un ensemble
fortement cohérent et sont généralement de même nature et de même niveau
sémantique.
• Tout élément n'appartient qu'à un seul paquetage.
• Les paquetages constituent un mécanisme de gestion important des problèmes
de grande taille.
• Ils permettent d'éviter les grands modèles plats et de cloisonner des éléments
constitutifs d'un système évoluant à des rythmes différents ou développés par
des équipes différentes.

129

24
 16/10/2021

Notations UML

• Paquetage (package):

130

Notations UML

• Stéréotype:
• Annotation s’appliquant sur un élément de modèle
• Utilisation particulière d’éléments de modélisation avec interprétation
(sémantique) particulière
• Modification de la signification d’un élément
• Il est représenté par une chaîne de caractères entre guillemets (<< >>) dans, ou
à proximité du symbole de l'élément de modèle de base.
• Prédéfinis : actor, includes, use case, interface, include ... class Stéréotype par
défaut d’un classeur.

131

25
 16/10/2021

Notations UML

• Stéréotype:

132

Notations UML

• Commentaires:
• Une note contient une information textuelle comme un commentaire, un corps
de méthode ou une contrainte.
• Elle est représentée par un rectangle dont l'angle supérieur droit est plié. Le
texte contenu dans le rectangle n'est pas contraint par UML.
• Une note n'indique pas explicitement le type d'élément qu'elle contient, toute
l'intelligibilité d'une note doit être contenue dans le texte même.
• On peut relier une note à l'élément qu'elle décrit grâce à une ligne en pointillés.
Si elle décrit plusieurs éléments, on dessine une ligne vers chacun d'entre eux.

133

26
 16/10/2021

Notations UML

• Commentaires:

134

Diagramme de Cas d’utilisation

(Use Case)

135

27
 16/10/2021

Contexte

• Avant de développer un système, il faut savoir précisément à QUOI

il devra servir, cad à quels besoins il devra répondre.
• Modéliser les besoins permet de :
• Faire l’inventaire des fonctionnalités attendues;
• Organiser les besoins entre eux, de manière à faire apparaître des relations
(réutilsations possibles, ...).
• Avec UML, on modélise les besoins au moyen de diagrammes de
cas d’utilisation.

136

Contexte

• Quelles fonctionnalités avons-nous besoin d’inclure et exclure ?

• Qui va utiliser le système ?
• Quels sont les produits et / ou les résultats que le système fournit ?
• Quelles informations l’acteur doit-il consulter, créer, sauvegarder,
• modifier ou supprimer ? etc,

137

28
 16/10/2021

Définition

• Les cas d’utilisation (use cases) ont été formalisés par Ivar
Jacobson. Les cas d’utilisation décrivent, sous la forme
d’actions et de réactions, le comportement d’un système du
point de vue d’un utilisateur.
• Un cas d’utilisation est une manière spécifique d’utiliser un
système. C’est l’image d’une fonctionnalité du système,
déclenchée en réponse à la stimulation d’un acteur externe

138

Objectifs de UC

• Il s'agit de la solution UML pour représenter le modèle conceptuel.

• Les use cases permettent de structurer les besoins des utilisateurs et
les objectifs correspondants d'un système.
• Ils centrent l'expression des exigences du système sur ses utilisateurs :
ils partent du principe que les objectifs du système sont tous motivés.
• Ils se limitent aux préoccupations "réelles" des utilisateurs ; ils ne
présentent pas de solutions d'implémentation et ne forment pas un
inventaire fonctionnel du système.

139

29
 16/10/2021

Objectifs de UC

• Ils identifient les utilisateurs du système (acteurs) et leur interaction

avec le système.
• Ils permettent de classer les acteurs et structurer les objectifs du
système.
• Ils servent de base à la traçabilité des exigences d'un système dans
un processus de développement intégrant UML.
• Les cas d’utilisation représentent le premier modèle à concevoir

140

Définition

• Un diagramme de cas d’utilisation décrit :

• Les acteurs
• Les cas d’utilisation
• Le système

141

30
 16/10/2021

Composants: Cas d’Utilisation

• Un cas d’utilisation est l’expression d’un service réalisé de bout en

bout, avec un déclenchement, un déroulement et une fin, pour
l’acteur qui l’initie.
• 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.

142

Composants: Cas d’Utilisation

• Les uses cases peuvent être structurés.

• Les uses cases peuvent être organisés en paquetages (packages).
• L'ensemble des use cases décrit les objectifs (le but) du système

143

31
 16/10/2021

Composants: 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.

144

Composants: Acteur

• Acteur : entité externe qui agit sur le système (opérateur, autre

système...)
• L'acteur peut consulter ou modifier l'état du système.
• En réponse à l'action d'un acteur, le système fournit un service qui correspond à
son besoin.
• Les acteurs peuvent être classés (hiérarchisés)

145

32
 16/10/2021

Composants: Acteur

• Attention: Un acteur correspond à un rôle, pas à une personne

physique.
• En plus des utilisateurs, les acteurs peuvent être :
• Des périphériques manipulés par le système (imprimantes...);
• Des logiciels déjà disponibles à intégrer dans le projet;
• Des systèmes informatiques externes au système mais qui interagissent avec lui,
etc.
• Pour faciliter la recherche des acteurs, on se fonde sur les frontières
du système.

146

Composants: Acteur

• Il existe plusieurs type d’acteurs :

• Acteurs principaux : Fonctions principales du système
• Acteurs secondaires : Administration / maintenance ...
• Périphériques externes : Matériel, ...
• Systèmes externes : Autres systèmes

147

33
 16/10/2021

Composants: Acteur

• L’acteur est dit « principal » pour un cas d’utilisation lorsque le cas

d’utilisation rend service à cet acteur. Les autres acteurs sont dits «
secondaires ».
• Un cas d’utilisation a au moins un acteur principal, et un ensemble
– éventuellement vide – d’acteurs secondaires.
• Un acteur principal obtient un résultat observable du système tandis
qu’un acteur secondaire est sollicité pour des informations
complémentaires.

148

Composants: Acteur

• La même personne physique peut jouer le rôle de plusieurs acteurs

(Chef d’agence est un client de la banque).
• Plusieurs personnes peuvent jouer le même rôle, et donc agir
comme un même acteur (plusieurs personnes peuvent jouer le rôle
d’administrateur).

149

34
 16/10/2021

Cas d’utilisation

150

Cas d’utilisation : Exemple

151

35
 16/10/2021

Exemple: Guichet

• Modéliser un cas d’utilisation d’une borne interactive (guichet

automatique) qui permet d’accéder à une banque

152

Exemple: Guichet

153

36
 16/10/2021

Relations

• UML définit trois types de relations standardisées entre cas

d’utilisation :
• Une relation d’inclusion : formalisée par la dépendance «include »
• Une relation d’extension : formalisée par la dépendance « extend »
• Une relation de généralisation / spécialisation

154

Relations: Inclusion

• Un cas A inclut un cas B si le comportement décrit par le cas A

inclut le comportement du cas B : le cas A dépend de B.
• Lorsque A est sollicité, B l’est obligatoirement, comme une partie
de A. Cette dépendance est symbolisée par le stéréotype « include »

155

37
 16/10/2021

Relations: Inclusion

156

Relations: Extension

• On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque

le cas d’utilisation B peut être appelé au cours de l’exécution du cas
d’utilisation A.
• Exécuter A peut éventuellement entraîner l’exécution de B.
• Contrairement à l’inclusion, l’extension est optionnelle. Cette
dépendance est symbolisée par le stéréotype « extend ».

157

38
 16/10/2021

Relations: Généralisation

• Une relation de généralisation/spécialisation : les cas d’utilisation

descendants héritent de la description de leur parent commun.
Chacun d’entre eux peut néanmoins comprendre des interactions
spécifiques supplémentaires.

158

Relations: Résumé

• Généralisation : A est généralisation de D si celui-ci en est un cas

particulier.
• Inclusion : A include B; lorsque A est sollicité, B l’est
obligatoirement.
• Extension : B extend C ; lorsque B peut être appelé au cours
d’exécution de C. L’extension intervient à un point précis :
extension point, associé éventuellement à une contrainte.

159

39
 16/10/2021

Relations: Résumé

160

Relations entre acteurs

• Un acteur A est une généralisation d’un acteur B si l’acteur A peut

être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

161

40
 16/10/2021

Relations entre acteurs: Exemple

162

Relations entre acteurs: Exemple

163

41
 16/10/2021

Exercice
• Dans un établissement scolaire, on désire gérer la réservation des salles
de cours ainsi que du matériel pédagogique (ordinateur portable ou/et
Vidéo projecteur). Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du matériel).
• Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants).
• Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.
• Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la formation
et il peut éventuellement le consulter aussi.
• Etablir le diagramme des uses cases pour les acteurs et opérations cités
ci-dessus
164

165

42
 16/10/2021

Exercice

• Dans un magasin, le processus de vente est le suivant : le client

entre, passe dans les rayons, demande éventuellement des
renseignements ou procède à des essais, prend des articles (si le
stock est suffisant), passe à la caisse où il règle ses achats (avec tout
moyen de paiement accepté).
• Il peut éventuellement bénéficier d’une réduction.
• Modéliser cette situation par un diagramme de cas d’utilisation

166

Solution

167

43
 16/10/2021

Les scénarios

• Les cas d’utilisation se déterminent en observant et en précisant,

acteur par acteur, les séquences d’interaction -les scénarios- du point
de vue de l’utilisateur.
• Un cas d’utilisation regroupe une famille de scénarios d’utilisation
selon un critère fonctionnel.
• Les cas d’utilisation sont des abstractions du dialogue entre les acteurs
et le système: ils décrivent des interactions potentielles, sans entrer
dans le détail de chaque scénario.

168

Les scénarios

• Les cas d’utilisation doivent être vus comme des classes dont les
instances sont les scénarios. Chaque fois qu’un acteur interagit avec le
système, le cas d’utilisation instancie un scénario; ce scénario correspond
au flot de messages échangés par les objets durant l’interaction
particulière qui correspond au scénario.

169

44
 16/10/2021

Description des cas d'utilisation

• On précise le contenu d'un cas d'utilisation en déroulant tous les

scénarios possibles.
• Un scénario est un chemin particulier au travers de la description
abstraite et générale fournie par le cas d'utilisation. En pratique, on
ne décrit que les scénarios les plus représentatifs.
• On peut décrire un scénario à l'aide d'un diagramme de
d’interaction (diagramme de séquence, diagramme de collaboration)
où un acteur est un objet particulier.

170

Règles de mise en œuvre des cas d’utilisation

• La description des cas d’utilisation comprend:

• Le début du cas d’utilisation.
• La fin du cas d’utilisation.
• L’interaction entre le cas d’utilisation et les acteurs.
• Les échanges d’informations (paramètres des interactions).
• La chronologie et l’origine des informations.
• Les répétitions de comportement.
• Les situations optionnelles.

171

45
 16/10/2021

Description d’un « use case »

• Rédiger la description textuelle du « use case »,

• Définir un diagramme montrant les relations entre les acteurs
et le « use case »

172

Description textuelle du « use case »

• Identification du « use case » : nom du use case

• Auteur : nom de l ’auteur et/ou du service
• Date de description ou de mise à jour : suivre le « versionning »
• Objet : présenter en quelques phrases l ’objectif du use case
• Acteurs : liste des acteurs qui interviennent pour la réalisation
• Contexte opérationnel : présentation générale
• Description : description détaillée des traitements
• Cas particuliers : exceptions, interdictions, refus...

173

46