La “méthode” UML

89
L’approche orientée objet
logiciel
= collection d’objets dissociés, identifiés et
possédant des caractéristiques.
Une caractéristique
◦ un attribut (i.e. une donnée caractérisant l’état de l’objet),
◦ une entité comportementale de l’objet (i.e. une fonction).
 La fonctionnalité du logiciel émerge alors de
l’interaction entre les différents objets qui le
constituent.
 L’une des particularités de cette approche est qu’elle
rapproche les données et leurs traitements associés
au sein d’un unique objet.
L’approche orientée objet
Caractéristique d’un objet :
L’identité : L’objet possède une identité, qui
permet de le distinguer des autres objets,
indépendamment de son état.
Les attributs : Il s’agit des données caractérisant
l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes : caractérisent le comportement
d’un objet , ces opérations permettent de faire réagir
l’objet aux sollicitations extérieures ou modifier
certains attributs de l’objet.
L’approche orientée objet
La difficulté de cette modélisation consiste à créer
une représentation abstraite, sous forme d’objets,
d’entités ayant une existence matérielle ( voiture,
personne, …) ou bien virtuelle (client, temps, …).
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 la
fonction qu’il est censé réaliser.
La méthode UML
 UML = Unified Modeling Language peut se traduire en français
par langage unifié pour la modélisation
 C'est un langage de modélisation objet
 Il fournit les fondements pour spécifier, construire, visualiser
et décrire les composants d'un système logiciel
 UML se base sur une sémantique précise et sur une notation
graphique expressive. Il permet de modéliser de manière
claire et précise la structure et le comportement d'un
système indépendamment de toute méthode ou de tout
langage de programmation
REMARQUE : est une notation pour la résolution de
problèmes orientée objet, pas une méthode !

93
 Historique UML
UML 2.0

UML 1.3
Industrialisation

Standardisation OMG
Novembre 97 UML 1.1
Standardisation
Rational,
Janvier 97 UML 1.0 IBM, HP, Microsoft, Oracle,
ObjecTime...
Unification
Juillet 96 UML 0.9

Octobre 95 UML 0.8

Booch ‘93 OMT-2

... Fragmentation
Booch ‘91
RUP workshop, 07.07.2000
OMT - 1 OOSE ...
G. Booch
Copyright © 2000 Rational Software, all rights reserved
J. Rumbaugh
1-16
I.Jacobson

94
La méthode UML
Ilest impossible de donner une représentation
graphique complète d’un logiciel, ou de tout autre
système complexe, de même qu’il est impossible de
représenter entièrement une statue (à 3 dimensions)
par des photographies (à 2 dimensions).
Mais il est possible de donner sur un tel système des
vues partielles, et dont la conjonction donnera une
idée utilisable en pratique sans risque d’erreur grave.

95
La méthode UML
UML comporte treize types de diagrammes réparties
en deux grands groupes :
i. Diagrammes structurels ou diagrammes statiques
(UML Structure)
 diagramme de classes (Class diagram)
 diagramme d’objets (Object diagram)
 diagramme de composants (Component diagram)
 diagramme de déploiement (Deployment diagram)
 diagramme de paquetages (Package diagram)
 diagramme de structures composites (Composite structure diagram)

96
La méthode UML
ii. Diagrammes comportementaux ou diagrammes
dynamiques (UML Behavior)
◦ diagramme de cas d’utilisation (Use case diagram)
◦ diagramme d’activités (Activity diagram)
◦ diagramme d’états-transitions (State machine diagram)
 Diagrammes d’interaction (Interaction diagram)
◦ diagramme de séquence (Sequence diagram)
◦ diagramme de communication (Communication diagram)
◦ diagramme global d’interaction (Interaction overview diagram)
◦ diagramme de temps (Timing diagram)

97
La méthode UML

98
La méthode UML
 Diagramme de cas d’utilisation : représente la structure
des grandes fonctionnalités nécessaires aux utilisateurs du
système. Il s’assure de la relation entre l’utilisateur et les
objets que le système met en œuvre.
 Diagramme de classes : est considéré comme le plus
important dans un développement orienté objet. Il décrit les
classes que le système utilise, ainsi que leurs
liens(architecture conceptuelle ).
 Diagramme d’objets : permet d’éclairer un diagramme de
classes en l’illustrant par des exemples.
 Diagramme d’états-transitions : représente la façon
dont évoluent (i.e. cycle de vie) les objets appartenant à une
même classe.

99
La méthode UML
 Diagramme d’activités : il montre l’enchaînement des
activités qui concourent au processus.
 Diagramme de séquence : représente la succession
chronologique des opérations réalisées par un acteur. Il
indique les objets que l’acteur va manipuler et les
opérations qui font passer d’un objet à l’autre.
 Diagramme de communication: graphe dont les
nœuds sont des objets et les arcs les échanges entre objets.

Remarque : nous n’étudierons que quelques diagrammes de

bases (Classe, Cas d’utilisation et Séquence)

100
La méthode UML
 Ces diagrammes, d’une utilité variable selon les cas, ne sont
pas nécessairement tous produits à l’occasion d’une
modélisation.
 Les plus utiles pour la maîtrise d’ouvrage sont les
diagrammes d’activités, de cas d’utilisation, de classes,
d’objets, de séquence et d’états-transitions.
 Les diagrammes de composants, de déploiement et de
communication sont surtout utiles pour la maîtrise d’œuvre
à qui ils permettent de formaliser les contraintes de la
réalisation et la solution technique.

101
Le diagramme de classe

102
Diagrammes de classes
Objectif
 Les diagrammes de classes permettent
de spécifier la structure et les liens entre
les objets dont le système est composé.

 Décrit la structure interne du système,

sous forme de classes (attributs +
opérations) et de relations entre classes.
Ne montre pas comment utiliser les
opérations = description statique.

103
objet

Objet
 Objet = données + méthodes (opérations sur ces
données)
= entité du domaine du problème
= variable d’un type construit par le programmeur
 Un objet est composé de 2 parties :
- partie interface ou partie publique : opérations
qu'on peut faire dessus
- partie interne ou partie privée : données sensibles
de l'objet
 Les utilisateurs de l'objet(autres objets) ne voient que la
partie interface.
 Ces entités doivent être indépendantes

104
objet

exemple d'objets :
➢ la toyota_vitara_blanche immatriculée EN 123 DG du directeur
est un objet
toyota_vitara_directeur
genre : toyota
immatriculation : EN 123 DG
NbPlaces : 5
propriétaire: directeur
s_arreter()
avancer()

➢Un autre objet serait la clio du CD immatriculée AD 345 SS

Clio_du_cd 
genre : Renault
immatriculation : AD 345 SS
NbPlaces : 4
propriétaire: cd
s_arreter()
avancer()

105
Classe
 Une classe est composée d'un nom,
d'attributs et d'opérations

106
Classe
 Nom : commence par une majuscule
 Attributs : décrit une donnée de la classe
◦ Les types des attributs ainsi que les modificateurs
d'accès peuvent être précisés dans le modèle
◦ Les attributs prennent des valeurs lorsque la classe
est instanciée
◦ On distingue les attributs de classe / attribut
d’instance
 Opérations : est un service offert par la classe
 leurs initialisations ainsi que les modificateurs d'accès peuvent
être précisés dans le modèle
 On distingue les methodes de classe / methodes d’instance

107
Relations entre classes

 Une relation d'héritage est une relation de

généralisation/spécialisation permettant
l'abstraction.
 Une dépendance est une relation
unidirectionnelle exprimant une dépendance
sémantique entre les éléments du modèle
(flèche ouverte pointillée).
 Une association représente une relation
sémantique entre les objets d'une classe.
 Une relation d'agrégation décrit une relation
de contenance ou de composition.
108
Association
 Une association est une relation structurelle
entre objets.
 Une association est souvent utilisée pour
représenter les liens possibles entre objets de
classes données.
 Elle est représentée par un trait entre classes.
 Multiplicités des associations
◦ La notion de multiplicité permet le contrôle du
nombre d'objets intervenant dans chaque instance
d'une association.
 Navigabilité d'une association
◦ La navigabilité permet de spécifier dans quel(s) sens il
est possible de traverser l'association à l'exécution.
◦ On restreint la navigabilité d'une association à un seul
sens à l'aide d'une èche.

109
Agrégation

 Une agrégation est une forme particulière

d'association. Elle représente la relation
d'inclusion d'un élément dans un ensemble. On
utilise un losange vide côté de l'agrégat.
 La relation de composition décrit une
contenance structurelle entre instances. On
utilise un losange plein côté de l'élément
composite.
 NB:La composition est aussi dite agrégation
forte.

110
Héritage
 Héritage est une relation de spécialisation/généralisation.
 Exemple :
➢ automobile et camion hérite (ou dérive) de Véhicule.
➢ héritage = dérivation La classe dont on dérive est dite
classe de base ou classe mère ou superclasse. Les classes
obtenues par dérivation sont dites classes dérivées ou
classes filles ou sous-classes.

111
Héritage
 L'héritage est la possibilité de pouvoir reprendre
intégralement tout ce qui a déjà été fait et de pouvoir
l'enrichir : vision descendante.
 L'héritage est la possibilité de regrouper en un seul
endroit ce qui est commun à plusieurs : les
modifications des éléments communs ne se font qu'à
un seul endroit : vision ascendante.
 Il s'utilise dans "les deux sens":
➢ vers le haut : surtout lors de l'analyse O.O: on regroupe dans
une classe ce qui est commun à plusieurs classes.
exemple: dans la classe véhicule on regroupe les caractéristiques
communes aux camions et aux automobiles
➢ vers le bas : surtout lors de la réutilisabilité. La classe véhicule
étant définie, on peut la reprendre intégralement pour
construire la classe bicyclette

112
Encapsulation
 L'encapsulation est un principe de conception
consistant à protéger le cœur d'un système des accès
intempestifs venant de l'extérieur
 En UML l’utilisation de modificateurs d'accès sur les
attributs ou les classes :
◦ Public ou « + » : propriété ou classe visible partout
◦ Protected ou « # » : propriété ou classe visible dans la classe et
par tous ses descendants.
◦ Private ou « - » : propriété ou classe visible uniquement dans la
classe
◦ Package ou « ~ » : propriété ou classe visible uniquement dans
le paquetage
NB: Il n'y a pas de visibilité " par défaut "

113
Construction d'un diagramme de classes
1. Trouver les classes du domaine étudié : souvent,
concepts et substantifs du domaine.
2. Trouver les associations entre classes : Souvent,
verbes mettant en relation plusieurs classes.
3. Trouver les attributs des classes : Souvent,
substantifs correspondant à un niveau de
granularité plus fin que les classes. Les adjectifs et
les valeurs correspondent souvent à des valeurs
d'attributs.
4. Organiser et simplifier le modèle en utilisant
l'héritage ;
5. Tester les chemins d'accès aux classées ;
6. Itérer et raffiner le modèle. 114
Exemple de Diagramme de classe

115
 Programme

> Trouver des Classes

> Comment sélectionner les classe
> identifier les responsabilités
> Identifier les Collaborations
> Structurer la hiérarchie de l’héritage
L'exploration initiale
1. Identifier les classes dans votre système,

2. déterminer les responsabilités de chaque

classe

3. déterminer comment les objets

collaborent entre eux pour s’acquitter de
leurs responsabilités
ES
E
4.1
© Oscar Nierstrasz ESE — Responsibility-Driven Design 17
L'analyse détaillée
1. Factoriser les responsabilités communes pour
construire des hiérarchies de classes
2. Rationnaliser les collaborations entre les objets
◦ Les message sont-ils concentrés dans certaines
parties du système ?
◦ Existe-t-il des classes qui collaborent avec tout le
monde ?
◦ Existe-t-il des classes qui collaborent avec personne ?
◦ Y a-t-il des groupes de classes qui peuvent être
considérées comme des sous-systèmes ?
3. Changer les responsabilités de classe en
signatures complètement spécifiés
 Trouver des Classes
Commencez par la spécification des besoins :
Quels sont les buts du système , ses entrées attendues et les
réponses désirées ?

1. Recherchez les expressions nominaux :

 séparer en classes évidentes, candidats incertains et non-sens
 Trouver des Classes ...
2. Affiner à une liste de classes candidates. Quelques lignes
directrices sont :
◦ Modeliser les objets physiques - par exemple disques, imprimantes
◦ Modeliser les entités conceptuelles - par exemple fenêtres, fichiers
◦ Choisissez un mot pour un concept – qu’est ce que cela signifie pour
le système
◦ Méfiez-vous des adjectifs - est-ce vraiment une classe à part?
◦ Méfiez-vous des sujets implicites ou manquant - reformule à la voix
active
◦ modeliser les catégories - retarde la modélisation de l'héritage
◦ interfaces du système - par exemple, l'interface utilisateur, des
interfaces de programme
◦ Differencier les valeurs d'attribut des attributs - par exemple, point
vs. Centre
pécification des besoins d’un éditeur de
dessin
L'éditeur de dessin est un éditeur graphique interactif.
Grâce à elle, les utilisateurs peuvent créer et modifier des
dessins composés de lignes, des rectangles, des ellipses et des
textes. Des outils contrôlent le mode de fonctionnement de
l'éditeur. à un moment donné un outil seul est actif . Deux
types d'outils existent: les outils de sélection et les outils de
création.
Lorsque l'outil de sélection est actif, les éléments de dessin
existants peuvent être sélectionnés avec le curseur. Un ou
plusieurs éléments de dessin peuvent être sélectionnées et
manipulées; si plusieurs éléments de dessin sont sélectionnés,
ils peuvent être manipulés comme si ils étaient un seul
élément. Des éléments qui ont été sélectionnés de cette
manière sont désignés par la sélection courante(active). La
sélection en cours est indiquée visuellement en affichant des
points de contrôle pour l'élément. En cliquant dessus et en
faisant glisser un point de contrôle modifie l'élément avec
lequel le point de commande est associé.
Quand un outil de création est actif, la sélection courante
est vide. Le curseur change de différentes manières en fonction
de l'outil de création spécifique, et l'utilisateur peut créer un
élément du type sélectionné. Après l'élément est créé, l'outil de
sélection est actif et l'élément nouvellement créé devient la
sélection actuelle.
L'outil de création de texte modifie la forme du curseur en
I. La position du premier caractère de texte est déterminé par
l'endroit où l'utilisateur clique avec la souris
bouton. L'outil de création n'est plus actif lorsque l'utilisateur
clique sur le bouton de la souris en dehors de l'élément de texte.
Les points de contrôle pour un élément de texte sont les quatre
coins de la région dans laquelle le texte est formaté. Faire glisser
les points de contrôle modifie cette région. Les autres outils de
création permettent de créer des lignes, des rectangles et des
ellipses. Ils changent la forme du curseur à celle d'un réticule.
L'élément approprié commence à être créé lorsque le bouton de
la souris est enfoncé, et se termine lorsque le bouton de la souris
est relâché. Ces deux événements créent le point de départ et le
point d'arrêt.
L'outil de création de ligne crée une ligne à partir du point de
début au point d'arrêt . Ce sont les points de contrôle d'une ligne.
Faire glisser un point de contrôle change le point final.
L'outil de création de rectangle crée un rectangle de telle sorte
que ces points sont les coins opposés en diagonale. Ces points et
les autres coins sont les points de contrôle. Faire glisser un point
de contrôle change le coin associé.
L'outil de création d'ellipse crée un ellipse à l'intérieur du
rectangle défini par les deux points décrits ci-dessus . Le rayon
principal est une moitié de la largeur du rectangle, et le rayon
mineur est une moitié de la hauteur du rectangle. Les points de
contrôle sont au niveau des coins du rectangle de délimitation.
Faire glisser les points de contrôle change le coin associé.
Editeur de Dessin : expressions
nominales
L'éditeur de dessin est un éditeur graphique interactif. Grâce à elle, les utilisateurs
peuvent créer et modifier des dessins composés de lignes, des rectangles, des
ellipses et des textes. Des outils contrôlent le mode de fonctionnement de l'éditeur. à
un moment donné un outil seul est actif .
Deux types d'outils existent: les outils de sélection et les outils de création. Lorsque
l'outil de sélection est actif, les éléments de dessin existants peuvent être sélectionnés
avec le curseur. Un ou plusieurs éléments de dessin peuvent être sélectionnées et
manipulées; si plusieurs éléments de dessin sont sélectionnés, ils peuvent être
manipulés comme si ils étaient un seul élément. Des éléments qui ont été
sélectionnés de cette manière sont désignés par la sélection active. La sélection
active est indiquée visuellement en affichant des points de contrôle pour l'élément. En
cliquant dessus et en faisant glisser un point de contrôle modifie l'élément avec lequel
le point de commande est associé.
Quand un outil de création est actif, la sélection courante est vide. Le curseur
change de différentes manières en fonction de l'outil de création spécifique, et
l'utilisateur peut créer un élément du type sélectionné. Après l'élément est créé, l'outil
de sélection est actif et l'élément nouvellement créé devient la sélection active.
L'outil de création de texte modifie la forme du curseur en I. La position du premier
caractère de texte est déterminé par l'endroit où l'utilisateur clique avec le bouton de
la souris
Editeur de Dessin : expressions
nominales
L'outil de création n'est plus actif lorsque l'utilisateur clique sur le bouton de la
souris en dehors de l'élément de texte. Les points de contrôle pour un élément de
texte sont les quatre coins de la région dans laquelle le texte est formaté. Faire
glisser les points de contrôle modifie cette région. Les autres outils de création
permettent de créer des lignes, des rectangles et des ellipses. Ils changent la
forme du curseur à celle d'un réticule. L'élément approprié commence à être créé
lorsque le bouton de la souris est enfoncé, et se termine lorsque le bouton de la
souris est relâché. Ces deux événements créent le point de départ et le point
d'arrêt.
L'outil de création de ligne crée une ligne à partir du point de début au point
d'arrêt . Ce sont les points de contrôle d'une ligne. Faire glisser un point de
contrôle change le point final.
L'outil de création de rectangle crée un rectangle de telle sorte que ces points
sont les coins diagonalement opposés. Ces points et les autres coins sont les
points de contrôle. Faire glisser un point de contrôle change le coin associé.
L'outil de création d'ellipse crée un ellipse à l'intérieur du rectangle défini par les
deux points décrits ci-dessus . Le rayon principal est une moitié de la largeur du
rectangle, et le rayon mineur est une moitié de la hauteur du rectangle. Les points
de contrôle sont au niveau des coins du rectangle de délimitation. Faire glisser les
points de contrôle change le coin associé.
 programme

> Trouver des Classes

> Comment sélectionner les classe
> identifier les responsabilités
> Identifier les Collaborations
> Structurer la hiérarchie de l’héritage
sélectionner les classes
Modéliser des objets physiques :
◦ bouton souris [événement ou attribut]
modeliser entités conceptuelles :
◦ rectangle, ellipse, ligne
◦ dessin, élément de dessin
◦ outil, outil de création, outil de création
d’ellipse outil de création de ligne, outil de
création e rectangle, outil de sélection, outil
de création texte
◦ texte, caractère
◦ sélection actuelle
 sélectionner les classes...
Choisir un mot pour un concept :
◦ éditeur de dessin  éditeur, éditeur graphiques interactifs
◦ élément de dessin  élément
◦ élément texte  texte
◦ élément ellipse, élément ligne, élément rectangle
 ellipse, ligne, rectangle
sélectionner les classes...
Méfiez-vous des adjectifs :
◦ Outil de création d’ellipse, outil de création de ligne, outil de création
de rectangle, outil de sélection, outil de création de texte
 ont tous des besoins différents
◦ rectangle de délimitation, rectangle, region  Rectangle
 Sens commun, mais différent de l’élément Rectangle
◦ Point  point final, point de départ, point d’arrêt
◦ Point de controle
 plus qu’une coordonnée
◦ Coin 
coin associé, coin diagonalement opposé
 Pas de nouveau comportement
sélectionner les classes...
Méfiez-vous des sujets implicites ou manquant :
◦ “La sélection active est indiquée visuellement en affichant des points
de contrôle pour l'élément.”
 par quoi ? Supposer l’éditeur de dessin...
modeliser les catégories :
◦ Outil, Outil de reation
Modeliser les interfaces du systeme: — ici pas de bons candidats...
◦ utilisateur —pas besoin de modeliser un utilisateur explicitement
◦ curseur — les mouvements du curseur sont gérée par le système d’exploitation
sélectionner les classes...
Modeliser les valeurs des attributs, mais pas les attributs eux-
mêmes:
◦ hauteur du rectangle, largeur du rectangle
◦ rayon principal, rayon mineur
◦ position — du premier caractère du texte ; sans doute attribut de
Point
◦ mode de fonctionnement — attribut de l’éditeur de dessin
◦ forme du curseur , reticule, I — attributs de Curseur
◦ coin — attribut de Rectangle
◦ Moment —attribut implicite du système
 Classes Candidates
L’analyse préliminaire donne : éditeur de dessin
dessins
élément point de départ
element ligne
sélection active. point d'arrêt.
rectangle
forme du curseur point final.
element ellipse
I. coins diagonalement
outil
bouton de la souris opposés.
outil de sélection
éditeur graphique interactif. coin associé.
outil de création.
utilisateur rayon principal
élément de dessin
texte. largeur du rectangle,
point
mode de fonctionnement rayon mineur
caractère
éditeur. hauteur du rectangle.
points de contrôle
moment rectangle de délimitation.
sélection courante
curseur.
outil de création de texte
région
élément de texte
réticule.
outil de création de ligne
outil de création de rectangle
outil de création d'ellipse
130
Classes Candidates
L’analyse préliminaire donne les candidats suivants :
éditeur de dessin
dessins
element ligne
rectangle
element ellipse
outil
outil de sélection
outil de création.
élément de dessin
point
caractère
points de contrôle
sélection courante
outil de création de texte
élément de texte
outil de création de ligne
outil de création de rectangle
outil de création d'ellipse
cette liste est supposer
évoluer avec conception.
 Programme

> Trouver des Classes

> Comment sélectionner les classe
> identifier les responsabilités
> Identifier les Collaborations
> Structurer la hiérarchie de l’héritage
Responsibilités
Quelles sont les responsabilités ?
◦ la connaissance qu’un objet maintient et
fournit
◦ les actions qu’il peut effectuer
les responsabilités représentent les services publics qu’un
objet peut fournir aux clients (mais pas la façon dont ces
services peuvent être implémenté)
◦ Précisent ce qu’un objet fait et ce qu’il ne fait
pas
◦ ne décrivent pas l’interface encore, seulement
des responsabilités conceptuelles
Identifier les responsabilités
 Etudier les besoins pour la spécification :
◦ Mettre en evidence les verbes et déterminer lesquelles sont des responsabilités

◦ effectuer un parcours du système

 explorer autant que possible les scénarios possible
 identifier les actions résultant des entrées dans le système

 Etudier les classes candidates :

◦ Noms de classe  roles  responsibilités
Comment assigner une
responsabilité?
Loi de Pelrine:

 « Ne faites rien que vous pouvez

demander à quelqu'un d’autre. »

 « Ne laissez pas quelqu'un d’autre jouer

avec vous. »
Assigner une responsabilité
 Répartir uniformément le renseignement
◦ éviter la centralisation procédurale des
responsabilités
◦ gardez les responsabilités à proximité d’objets
plutôt qu’à leurs clients
 Exprimer des responsabilités aussi générale
que possible
◦ « draw yourself » vs « draw a line/rectangle
etc»
◦ conduit au partage

 Garder le comportement ainsi que de toute

information relative ensemble
◦ principe d’encapsulation
ES
E
4.1
© Oscar Nierstrasz ESE — Responsibility-Driven Design 36
Assigner une responsabilité...
 Maintenez l’information d’une chose en un
seul endroit
◦ si plusieurs objets doivent accéder aux mêmes
informations
1. un nouvel objet peut-être être introduit afin de
gérer les informations, ou
2. un objet peut être un candidat évident, ou
3. les objets multiples pourraient devoir être
regroupée en un seul

 Partager les responsabilités entre les objets

connexes
◦ décomposer les responsabilités complexes
Relations entre Classes
Des responsabilités supplémentaires peuvent être
découvertes en examinant les relations entre
classes, en particulier:

 Les relations “Is-Kind-Of” :

◦ Les classes partageant un attribut commun
partagent souvent une superclasse commune
◦ Une superclasse commune suggèrent des
responsabilités communes
Par exemple, pour créer un nouvel élément de dessin, un outil de création
doit :
1. Accepter des entrées de l’utilisateur implementé dans les sousclasses
2. determiner où les placer generique
3. Instantier l’élément implementé dans les sousclasses
Relations entre Classes ...
 La relation « Is-analogous-To » :
◦ Les similitudes entre les classes suggèrent des
superclasses encore non identifiées

 La relation « Is-Part-Of » :
◦ distingue (ne pas partager) les responsabilités
des parties et de l’ensemble

Difficultés dans l’attribution des responsabilités suggèrent :

◦ classes manquante dans la conception, ou — par exemple, groupe d’
éléments
◦ du libre choix entre plusieurs classes
Exemple de relation
 Un élément de dessin fait-partie-de is-
part-of dessin

 Un élément dessin a-connaissance-de has-

knowledge-of contrôle Points

 Un outil Rectangle est-genre-de is-kind-of

outil de création
 Programme

> Trouver des Classes

> Comment sélectionner les classe
> séances CRC
> identifier les responsabilités
> Identifier les Collaborations
> Structurer la hiérarchie de l’héritage
Collaborations
C’est quoi une collaboration?
 les collaborations sont des demandes du
client aux serveurs nécessaires pour
s’acquitter de ses responsabilités
 les collaborations peuvent découvrir des
responsabilités manquantes
 l’analyse des modes de communication
peut révéler des responsabilités non
assignées
Identifier les collaborations
Pour chaque responsibilité :
1. la classe Peut-elle s’acquitter de la responsabilité par elle même ?
2. Si ce n’est pas le cas, de quoi a t-elle besoin, et de quelle autre classe
peut-elle obtenir ce qu’elle a besoin ?

Pour chaque classe :

1. Que sait cette classe ?
2. Quelles autres classes ont besoin de ses informations ou résultats ?
rechercher des collaborations.
3. Les classes qui n’interagissent pas avec les autres doivent être jetés.
(Vérifier avec soin !)

ES
E
4.1
© Oscar Nierstrasz ESE — Responsibility-Driven Design 43
 Listing des collaborations
Dessin

Sait quels sont les éléments

qu’il contient

Maintient l’ordre entre ses Element de dessin

éléments
 Roadmap

> Trouver des Classes

> Comment sélectionner les classe
> séances CRC
> identifier les responsabilités
> Identifier les Collaborations
> Structurer la hiérarchie de l’héritage
Trouver les Classes abstraites
les classes abstraites regroupent les comportements communs partagés
par d’autres classes

 regroupe les classes possedant des attributs communs

 introduisent des superclasses pour représenter des groupes

AVERTISSEMENT : Méfiez-vous d’une classification prématurée ;

votre hiérarchie va évoluer !
 Partage de responsibilités
Les classes concrètes peuvent
être instanciés et hérités.
Les classes abstraites peuvent
seulement être hérités.

Note sur les diagrammes de

classe.

Les diagrammes de Venn

permettent de visualiser les
responsabilités partagées.

(AVERTISSEMENT : ne faisant
pas partie d’UML !)
 Heritage Multiple
Décider si une classe
sera instanciée pour
déterminer si elle est
concrète ou abstraite.

Les responsabilités des

sous-classes sont plus
nombreuses que celles de
la superclasse.
Les Intersections
représentent superclasses
communs.
Bonne Hierarchies
Les hierarchies “kind-of” :
 Les sous-classes devraient supporter les
responsabilités héritées et peut-être plus

Factoriser les responsabilités communes

aussi haut que possible:
 Les classes qui partagent les responsabilités
communes doivent hériter d’une superclasse
abstraite commune ; introduire un qui
manque
Construire de bonnes Hierarchies …
Assurez-vous que les classes abstraites
n’héritent pas de classes concrètes :
 éliminer en introduisant une superclasse abstraite
commune

Eliminer les classes qui n’apportent pas de

fonctionnalité :
 les classes devraient ajouter de nouvelles
responsabilités, ou un moyen particulier
d’implémentation des responsabilités héritées
 Hierarchies is-kind-of
les responsabilités de sous-classe
correctement formé :

C assume toutes les

responsabilités de A et B
 Hierarchies is-Kind-Of...
Les relations sous-
classe/superclasse incorrectes
 G n’assume que certaines des
responsabilités héritées de E
révisé les relations d’héritage
 introduire une superclasse
abstraite pour encapsuler les
responsabilités communes
Les cas d’utilisation

153
cas d’utilisation («use cases»)
 Permettent d’impliquer les utilisateurs dès les premiers
stades du développement pour exprimer leurs besoins.
 Décrivent les fonctionnalités offertes par le système
(le « quoi? » avant le « comment? ») :
◦ délimitation du système par l’ensemble des
fonctions qu’il offre,
◦ relations avec son environnement (acteurs).
 Modélisent à la fois les traitements (fonctionnalités) et
les communications (interactions) ≠ acteurs/flux de
Merise.

Utilisables pour tout projet

indépendamment d’UML et de l’approche objet.
154
Acteurs et cas
 cas d'utilisation: Un cas d'utilisation est un
service rendu à l'utilisateur, il implique des
séries d'actions plus élémentaires.
 Cas : interaction avec le système par un acteur
dans une certaine intention; un service rendu
par le système; une fonctionnalité.

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 n, pour l'acteur qui l'initie.
155
 Acteurs et cas
 Un acteur est une entité extérieure au système
modélisé, et qui interagit directement avec lui.
 Acteur peut être personne ou système qui interagit
avec le système étudié en échangeant de l’information.
Ex: utilisateurs directs du système (bénéficiaires des services),
responsables de son fonctionnement (ex: administrateur), autres
systèmes qui interagissent avec lui…

 Un acteur représente un rôle. La même personne

physique peut jouer le rôle de plusieurs acteurs et
plusieurs personnes physiques peuvent jouer le même
rôle et donc agir comme un même acteur.

<<actor>>

acteur humain
acteur système 156
Diagrammes de cas d’utilisation
Décrivent les interactions entre les acteurs et le système
représenté comme un ensemble de cas.
Les interactions sont orientées (avec une flèche) ou non.
Groupement éventuel des cas en
Le système paquetage(s)
cas
d’utilisation interaction
acteur X
acteur humain
« stick man »
Frontière cas
du d’utilisation acteur <<actor>>
système Y

acteur
L’acteur est source et/ou système
destination d’une interaction

157
 Relations entre cas
Inclusion : A <<include>> B : le cas A inclut obligatoirement le
cas B (permet de décomposer et de factoriser).

Extension : A <<extend>> B : le cas A est une extension

optionnelle du cas B à un certain point de son exécution.
NB: Attention au sens des flèche

Client Commander

<<include>> <<include>>
<<extend>>
Choisir Payer
articles Demander
catalogue

158
 Relations entre cas
Généralisation : le cas A est une généralisation du cas du cas B

159
Relations entre acteur
On peut également avoir de l’héritage entre acteurs et
entre cas (généralisation/spécialisation).

Créer un compte

Guichetier Fermer un compte Déposer

numéraire
Déposer de
l’argent sur un
compte
Déposer
Guichetier Annuler un chèques
Chef compte

Un ‘Guichetier Chef’ est un ‘Guichetier’ spécialisé qui peut faire tout

ce que peut faire un Guichetier et, en plus, il peut annuler un compte.
L’héritage simplifie le dessin (moins d’interactions à dessiner).
160
 Relations entre acteurs
Acteurs principaux et secondaires
 L'acteur est dit principal pour un cas d'utilisation
lorsque l'acteur est à l'initiative des échanges
nécessaires pour réaliser le cas d'utilisation.
 Les acteurs secondaires sont sollicités par le système
alors que le plus souvent, les acteurs principaux ont
l'initiative des interactions.

161
 GAB
Exemple
retirer argent avec carte VISA
<<Actor>>
<<secondary>> Système
Autorisation
Porteur retirer argent avec carte banque VISA
carte
VISA
<<extend>> <<include>> <<Actor>>
SI banque
consulter solde
Porteur
carte
banque déposer argent donner code
Gestion GAB
Recharger
Récupérer cartes
Opérateur avalées
Récupérer
chèques
162
Spécification des cas
Chaque cas d’utilisation doit être précisé par une
description textuelle qui peut être structurée en
plusieurs sections :
 conditions au démarrage (pré-conditions),
 conditions à la terminaison (post-conditions),
 étapes du déroulement normal (« nominal »),
 variantes possibles et les cas d’erreurs,
 informations échangées entre acteur et système,
 contraintes non fonctionnelles (performance, sécurité,
disponibilité, confidentialité…).
Exemple : cas RetirerArgentDistributeur

RetirerArgent
Client Distributeur
Client

163
Précondition contient des billets ; en attente d’une opération : ni en
panne, ni en maintenance.
Postcondition si de l’argent a pu être retiré, la somme sur le compte
est égale à la somme qu’il y avait avant moins le retrait. Sinon, la
somme sur le compte est inchangée.
Déroulement normal
(1) le client introduit sa carte bancaire, (2) le système lit la carte et
vérifie si la carte est valide, (3) le système demande au client de
taper son code, (4) le client tape son code confidentiel, (5) le
système vérifie que le code correspond à la carte, (6) le client
choisit une opération de retrait, (7) le système demande le
montant à retirer, etc.
Variantes
(A) Carte invalide : au cours de l’étape (2), si la carte est jugée
invalide, le système affiche un message d ’erreur, rejette la carte et
le cas d’utilisation se termine.
(B) …
Contraintes non fonctionnelles
(A) Performance : le système doit réagir dans un délai inférieur à 4
secondes, quelque soit l’action de l’utilisateur.
(B) Sécurité …
164
Les cas d’utilisations peuvent être vus comme des
classes de scénarios. Chaque scénario correspond à
une utilisation particulière, par un acteur donné, dans des
circonstances données. On peut décrire les principaux
(préparation des tests finaux de l’application).
SCENARIO 1
Pierre insère sa carte dans le distributeur x233.
Le système accepte la carte et lit le numéro de compte.
Le système demande le code confidentiel.
Pierre tape ‘xwrzhj’.
Le système détermine que ce n’est pas le bon code.
Le système affiche un message et propose à l’utilisateur de
recommencer.
Pierre tape ‘xwrzhi’.
Le système affiche que le code est correct.
Le système demande le montant du retrait.
Pierre tape 300 €.
Le système vérifie s’il y a assez d’argent sur le compte.
…

165
Mode d’emploi
 Elaborer avec les utilisateurs une description de très
haut niveau du système.
Exemple : site de commerce électronique (très simplifié)
◦ Le client parcours le catalogue.
◦ Il ajoute les objets qui l'intéressent dans son panier.
◦ Pour payer, il donne ses informations de carte bancaire et son adresse
◦ Il confirme l'achat.
◦ Le système contrôle la validité du paiement et confirme la commande.
 En déduire une liste d’acteurs et de cas.
 Construire un premier diagramme. Le structurer pour le
rendre plus clair (relations <<include>>, <<extend>>,
généralisation/spécialisation).
 Détailler chaque cas (description textuelle structurée).
 Eventuellement définir les scénarios les plus
importants qui pourront servir au moment des tests
finaux.
166
Diagrammes de Séquences (DS)

167
Objectif des diagrammes de séquence

 Les diagrammes de séquences permettent

de décrire COMMENT les éléments du
système interagissent entre eux et avec les
acteurs.
 Les objets au coeur d'un système interagissent en
s'échangent des messages.
 Les acteurs interagissent avec le système au moyen
d'IHM (Interfaces Homme-Machine).
◦ Les diagrammes de séquences décrivent de
manière plus formelle les
interactions/collaborations entre les acteurs (ou
objets) dans le système.

168
Diagrammes de séquence
 Les diagrammes de séquences permettent de
représenter des collaborations entre objets selon
un point de vue temporel, on y met l'accent sur la
chronologie des envois de messages.
 Peuvent être utilisés à différents niveaux de détail et
pour servir différents buts à plusieurs étapes du
cycle de vie du développement.
 Typiquement utilisés pour représenter l'interaction
détaillées en objets qui prend place dans un cas
d‘utilisation ou pour une opération.

169
 Scénario
 Un scénario est une suite spécifique d'événements survenant
dans le système.
 Un scénario est une séquence spécifique d'actions et
d'interactions entre les acteurs et le système.
◦ C'est une histoire spécifique de l'utilisation d'un système.
 Par exemple, le scénario d'un achat réussi d'articles en
liquide,
ou
le scénario d'un échec d'achat d'articles à cause d'un refus
de paiement à crédit.

170
 Description d’un scénario
Scénario principal : description du chemin «normal»
d’exécution du cas d’utilisation;
Exemple : Retrait-distributeur pour un client
existant et fiable,
 Scénarios secondaires : description de cas alternatifs
(plusieurs choix), de cas exceptionnels ou de cas d’erreur.
Exemple : Retrait-distributeur pour un client
donnant un code erroné

 Il y a en UML 3 représentations possibles pour un scénario :

◦ description textuelle en langage naturel
◦ diagramme de séquence
◦ diagramme de collaboration

171
 Diagrammes de séquence
 La dimension verticale montre le temps.
 Les objets impliqués dans l'interaction
apparaissent horizontalement sur la page
et sont représentés par les lignes de vie
(«lifelines»).
 Une ligne de vie représente un participant
à une interaction.
 Messages : échangés entre les lignes de vie,
présentés dans un ordre chronologique.

172
Diagrammes de séquence

173
Création et destruction de lignes de vie

 La création d'un objet est matérialisée par

une flèche qui pointe sur le sommet d'une
ligne de vie.
 La destruction d'un objet est matérialisée
par une croix qui marque la fin de la ligne
de vie de l'objet.

174
Diagrammes de Séquences (DS)
 Définissent les interactions entre Objets
selon un point de vue temporel,
 Interaction = événement / envoi de message
o1 : C1 o2 : C2 o3 : C3

Les Objets
Un message

Temps Un autre message

Ligne de Vie

175
 Diagrammes de Séquences
DS de haut niveau de Retrait-distributeur :
u : Utilisateur d : Distributeur
acteur
insérer carte
externe
demander code

entrer code ‘2341’

Accès au compte
et contrôle du code
demander montant
entrer montant 50

176
Diagrammes de Séquences (DS)

177
MERCI
178