Génie Logiciel - Cours 5 - analyse

COURS IGL

COURS 5
ANALYSE Cours 5 :
Analyse

Mostefai Mohammed Amine – m_mostefai@esi.dz
Batata Sofiane – s_batata@esi.dz 1

Cours 5 – Analyse OBJECTIFS DU COURS

Objectifs du cours

 Appréhender l’activité d’analyse
 Se familiariser avec les pratiques et les livrables de

Cours IGL, Copyright © 2011, ESI
l’analyse
 Utiliser UML pour exprimer les résultats de l’analyse
 Découverte des diagrammes de classe, d’activité, de
séquence et d’état

2

INTRODUCTION
Section 1 : Section 2 : Les Section 3 : Les AU GÉNIE
Introduction classes classes d’analyse LOGICIEL

Cours 5
Analyse
Section 4 : Section 5 : Section 6 :
réalisation des Diagrammes de Diagrammes
cas séquence d’activité

Section 7 :
Diagramme
d’états-
transitions
3


COURS IGL

Cours N° 5
Analyse
Section 1 : Introduction

4


SECTION 1 -
Cours 5 – Analyse INTRODUCTION

L’activité d’analyse
 L’analyse et l’expression de besoins sont très dépendants
 Il y a une ambiguïté entre l’analyse et l’expression de
besoins

 L’analyse permet de clarifier les besoins d’une manière
détaillée
 Il y a une ambiguïté entre l’analyse et la conception
 L’analyse et la conception répondent à la question
«comment »
 L’analyse se focalise sur l’aspect métier des
fonctionnalités tandis que la conception se focalise sur
l’aspect technique
 Dans UP, le gros de l’analyse se fait durant la phase
d’analyse de besoins et d’élaboration
5

SECTION 1 -


Modèle d’analyse

Classes(Vocabulair

e, aspect statique)

L’analyse Produit

Interactions
(aspect
dynamique)

6

SECTION 1 -


 L’analyse produit un modèle appelé modèle d’analyse
 Le modèle est composé de deux sous -modèles : le

vocabulaire et les interactions
 Le vocabulaire désigne les concepts du domaine. Il
concerne tous les acteurs et entités manipulées par ou
dans le systèmes
 Le vocabulaire ne concerne pas uniquement les concepts
mais aussi les relations entre concepts
 Les interactions représentent les activités impliquant
plusieurs entités ou acteurs (du vocabulaire) afin de
réaliser un objectif métier précis. Généralement, les
interactions détaillent les cas d’utilisation.

7

SECTION 1 -

L’activité d’analyse - Exemple

« à l’ESI, pour effectuer un stage, l’étudiant doit
chercher un encadreur interne ou dans une entreprise

externe et un sujet à réaliser. Une fois le sujet trouvé,
l’étudiant le dépose au niveau du service des stages. Ce
dernier s’occupe de la validation du sujet en faisant
appel à un enseignant de l’ESI ».

8

SECTION 1 -

L’activité d’analyse - Exemple

 Le vocabulaire devra contenir les concepts suivants :
enseignant, étudiant, encadreur, entreprise, sujet, service

de stage et stage
 Il y a plusieurs interactions à souligner : l’interaction de
recherche de sujet qui implique l’étudiant, l’entreprise, le
sujet et l’encadreur. L’interaction de validation qui
implique l’étudiant, le service de stages et l’enseignant.

9

SECTION 1 -

Construire le modèle d’analyse - Règles

 Se limiter aux concepts métier, s’éloigner des
considérations techniques

 Le langage du modèle d’analyse utilise le même langage
que le métier
 Le modèle capture une vision globale sur un concept ou
un processus, ne pas aller trop dans le détail
 Le modèle doit toujours être compréhensible et utile au
client
 Plus le modèle est simple, plus il est meilleur

10

SECTION 1 -

Formalisation du modèle d’analyse

 Le vocabulaire et les interactions peuvent être formalisés
de plusieurs manière (par exemple, en langage naturel)

 UML est un excellent moyen de formaliser le modèle
d’analyse
 Le diagramme de classes et le diagramme d’objets
permettent de formaliser le vocabulaire
 Les diagrammes d’interaction peuvent formaliser les
interactions

11

COURS IGL

Cours N° 5
Analyse
Débat (05 Mns)

12


COURS IGL

Cours N° 5
Analyse
Section 2 : Objets et classes

13


SECTION 2 – OBJETS
Cours 5 – Analyse ET CLASSES

L’objet

Etat Comportement Objet

14


L’objet

 Rumbaugh définit l’objet comme étant une entité discrète
ayant une limite bien définie qui possède un état et un

comportement
 Un objet représente une entité du monde réel
 L’état de l’objet est l’ensemble des valeurs de ses
attributs
 Le comportement d’un objet est représenté par les
opérations qu’il peut effectuer. Souvent les opérations
conduisent à un changement de l’état d’un objet
 L’objet a un identifiant unique qui permet de le
distinguer des autres objets.

15


L’objet

Etat Comportement
• Numéro de série (Identifiant) • Allumer()
• Marque • Eteindre()
• Modèle • Connecter()
• Allumée • Filmer()
• Mode (Photo / Vidéo) • PrendreUnePhoto()
• Connectée à un ordinateur
• Liste des photos en mémoire
• Capacité
• Photo en cours
16


Notation UML

 Le diagramme qui est utilisé pour la représentation des
objets est le diagramme d’objets

17


Notation UML des objets

Nom de l’instance compteTest :Compte
Cle = 80
Numero = 11256
Attributs Proprietaire = [Mokhtar]
Solde = 150000

18


Notation UML des objets

 Les noms sont écrits en souligné
 Les noms des objets commencent par une minuscule. Si

c’est un nom composé, le début de chaque mot suivant
commence par une majuscule. Par exemple :
compte11256:Compte ou clientFavori:Client. Le symbole
« : » sépare le nom de l’instance du nom de sa classe.
 Le nom de l’objet peut être anonyme (ne comporte que le
nom de la classe. Par exemple : :Compte ou :Client.
 L’objet peut ne pas avoir de classe : par exemple amine ou
compteTest.

19


Notation UML des objets - Liens

 Un lien lie deux instances entre objets
 L’objet est une instance d’une classe et le lien est une

instance d’une association

20


Notation UML des objets - Liens

Objets
compteTest :Compte

Cle = 80
Numero = 11256
Proprietaire = [Mokhtar]
Solde = 150000

Possède

amine :Personne

Lien

21


Notation UML des objets - Exemple

azouaou :Enseignant
mostefai :Enseignant
Nom = Mostefai
Prenom = Mohammed Amine

igl :Module conduiteDeProj et : mcsi :Module
Annee = 3csc Module

22


Objets – Notation UML - Diagrammes

 Un diagramme d’objets présente des objets et leurs
relations à un instant T

 Le diagramme d’objets est idéal pour donner des
exemples sur des situations particulières
 Les liens bidirectionnels entre A B quand A et B
s’envoient des messages
 Un lien unidirectionnel entre A vers B indique que A
peut envoyer un message vers B mais pas l’inverse

23


Objets – Notation UML - Diagrammes
Grade

EXEMPLE

EstGradé

Employe
Emploie

*
Departement
1

*

EstConstituéeDe

Ecole 1

24


Objets – Notation UML - Diagrammes Diagramme

object Pédagogie Nom du diagramme

mca :Grade
Lien Unidirectionnel

cherid :Employe balla :Employe mostefai :Employe

+Directrice Etudes +Responsable CPI +Enseignant

pg :Departement directionDesEtudes :Departement

esi :Ecole

Lien Bidiectionnel Rôle
25


Diagramme d’objet – Quand l’utiliser ?

 Les diagrammes d’objets sont utilisés pour donner des
exemples sur des situations complexes mettant en

relation plusieurs concepts

 Les diagrammes d’objet sont facultatifs et souvent les
diagrammes de classes sont suffisants pour décrire le
domaine.

26


Les classes

 Rumbaugh définit la classe comme étant un descripteur
d’un ensemble d’objets qui partagent les mêmes

attributs, méthodes, relations et comportement
 La classe est le modèle d’un ensemble d’objets similaires
 Dans l’exemple précédent : Mostefai et Azouaou sont
deux instances de la classe « Enseignant »
 Un objet appartient à une seule classe
 La classe définit la structure d’un objet (aspect statique)
, son comportement (aspect dynamique) et ses relations

27


Les classes

 Rumbaugh définit la classe comme étant un descripteur
d’un ensemble d’objets qui partagent les mêmes

attributs, méthodes, relations et comportement
 La classe est le modèle d’un ensemble d’objets similaires
 Dans l’exemple précédent : Mostefai et Azouaou sont
deux instances de la classe « Enseignant »
 Un objet appartient à une seule classe
 La classe définit la structure d’un objet (aspect statique)
, son comportement (aspect dynamique) et ses relations

28


Modélisation orientée objet

Comment classifier ces animaux ? 29


Modélisation orientée objet

 Ce n’est pas facile d’avoir une conception objet du monde
réel

 Les classes résultantes proviennent du point de vue de
travail
 Les classes de l’exemples précédent peuvent être :
(Animal) ou (AnimalTerrestre / AnimalMarin) ou
(AnimalDomestique / AnimalSauvage) ou
(AnimalComestible / AnimalNonComestible) ou (Poisson
/ Mammifière / Crustacé …)

30


Classes et objets

 L’objet instancie la classe
 UML définit l’instanciation comme une relation de

dépendance avec le stéréotype « instantiate »

31


Classes et objets

Module

- Annee: string
- AssurePar: Enseignant
- Nom: string

«instantiate» «instantiate» «instantiate»

mcsi :Module igl :Module conduiteDeProj et :
Module
Annee = 3csc

32


Classes – Notation UML

Stéréotype

«entity»
Nom de la classe Compte

- cle: string
- numero: string
Attributs - proprietaire: Personne
- solde: double = 0

Opérations + retirer(double) : boolean
+ verser(double) : boolean
tags
Métadonnées Auteur = Amine
Date = Octobre 2011

33


Classes – Notation UML - Nom

 De préférence, utiliser la convention UpperCamelCase. Le
nom de classe est en minuscules et la première lettre en

majuscules. Si le nom de la classe est composite, le nom
de chaque mot composant est en minuscule et la
première lettre en majuscule. Par exemple : Agent,
Compte, LigneFacture, MandatPostalValide.
 Eviter les abbrévitiations : par exemple utiliser
FactureValideDetaillee au lieu de FactureVD.
 Ne pas utiliser des noms verbaux car les classes
représentent des « choses ».

34


Classes – Notation UML - Visibilité

 La visibilité s’applique aussi bien aux attributs qu’aux
opérations

 Durant la phase d’analyse, la visibilité n’est pas
importante
 Les langages de programmation peuvent avoir une
interprétation différente de la visibilité

35


Classes – Notation UML - Visibilité

 Le tableau suivant liste les visibilités utilisées dans UML
Visibilité Nom Description

+ Visibilité Accès depuis la même classe et à l’extérieur de
publique la classe
- Visibilité privée Accès depuis la même classe uniquement

# Visibilité Accès depuis la même classe et les classes
protégée descendantes
~ Visibilité paquet Accès depuis la même classe et toutes les
classes appartenant au même paquet

36


Classes – Notation UML - Types

 Le type peut être un type défini par UML ou l’un des
types suivants : boolean, byte, char, double, float, int,

long, short

37


Classes – Notation UML - Attributs

 Les attributs sont formulés en utilisant la syntaxe
suivante :

Visibilité Nom_Attribut : type [multiplicité] = valeur_initiale

38



 Le type peut être un type défini par UML ou l’un des
types suivants : boolean, byte, char, double, float, int,

long, short
 La valeur initiale indique la valeur de l’attribut quand
une instance de la classe est créée
 Un attribut est dit statique s’il appartient à la classe, pas
à une instance en particulier. Les attributs statiques sont
noté en souligné.

39


C l a s s e s – N o t a t i o n U M L – At t r i b u t s , m u l t i p l i c i té

 La multiplicité indique les attributs multiples.
 Les multiplicités sont équivalentes aux tableaux mais ont

plus de sémantique.
 Exemple 1 : int valeurs[7]. La classe contient exactement
7 valeurs.
 Exemple 2 : int valeurs[2..*] : la classe contient au moins
2 valeurs.
 Exemple 3 : int valeurs[2..7] la classe contient au
minimum 2 valeurs et au maximum 7 valeurs.
 Exemple 4 : int valeurs [0..1] la classe contient une
valeur ou null.

40



EXEMPLE

Etudiant
+ matricule : int
# nom : string
# prenom : string
~modules : int [2..9]
- age :int = 18
- chambreAffectee : Chambre [0..1]
+ tuteursDeSuivi : Tuteur [2]
+ nombreEtudiants : int
+ inscriptions : Inscription [1..*]

41


Classes – Notation UML - Opérations

 Les opérations sont formulés en utilisant la syntaxe
suivante :

Visibilité Nom_Operation (direction nom_paramètre:
type = valeur_défaut,….) : type_retour

42



 Les opérations sont nommées en utilisant une formulation
lowerCamelCase

 De préférence, utiliser des expressions verbales pour les
opérations
 Les paramètres sont nommés en utilisant lowerCamelCase
 Ne pas utiliser des expressions verbales pour les paramètres
 Des valeurs par défaut peuvent être renseignées pour une
opération.
 Les opérations statiques sont soulignées

43



DIRECTION DES PARAMÈTRES
Direction Description

in p Le paramètre p est un paramètre d’entrée. p est utilisé par
l’opération mais n’est pas modifié par l’opération.
inout p Le paramètre p est un paramètre d’entrée / sortie. p est utilisé
par l’opération et sa valeur peut être changée par l’opération.
out p Le paramètre p est un paramètre de sortie. La valeur de p
pourrait être modifiée par l’opération.
return p Le paramètre p est un paramètre de retour. L’opération doit
retourner la valeur de p.

44



EXEMPLE

Compte

+ verser(montant :double, soldeApres :double*) : void
+ retirer(montantOperation :double, soldeApres :double*) : void
~ caclulerCharges(tauxCalcul :double) : double

45


Classes – Notation UML - Stéréotypes

 Les stéréotypes représentent un mécanisme pouvant
étendre UML

 Un stéréotype peut cibler une classe, un attribut ou une
opération
 Plusieurs dizaines de stéréotypes sont utilisés mais les
plus connus sont : actor, boundary, entity et control.
 Le stéréotype « acteur » représente un acteur
 Le stéréotype « entity » représente une entité. Une entité
est un concept métier, par exemple
« Compte », « Client », « Fournisseur »,…

46



 Le stéréotype « control » représente un contrôleur. Un
contrôleur est un intermédiaire entre les limites et les

entités. Le contrôleur se charge de l’exécution des
commandes provenant de la limite.
 Le stéréotype « boundary » représente une limite du
système qui s’interface avec l’acteur. Par exemple,
interface utilisateur.

47



InterfaceWeb GestionnaireCommandes Commande Utilisateur

«control»
«entity» «actor»
«boundary» GestionnaireCommandes
InterfaceWeb Commande Utilisateur

48



Commande LigneCommande Produit Client

GestionnaireCommandes

InterfaceWeb

Utilisateur 49


Classes – Notation UML - Associations

 Une association est une relation entre deux classes
 Une association entre deux classes se traduit par un lien

entre deux instances de ces classes
 Une association décrit une relation qui a une
sémantique entre les deux classes
 Une association peut être entre une classe et elle -même.
L’association est dite réflexive.
 La direction détermine la navigation d’un objet vers un
autre.

50



EXEMPLE
Enseigne

Enseignant Module

* *

«instantiate» «instantiate»

Mostefai :Enseignant IGL :Module

51


Direction
Nom de l’association

Employe Module
Enseigne
* *

Multiplicité
52



Societe +Employeur +Employé Personne

1 *

Rôle
53



NOMS DES ASSOCIATIONS
 Utiliser des phrases verbales

 Il n’est pas recommandé d’utiliser les noms et les rôles.
Utiliser soit le nom soit le rôle.
 Donner des noms explicites et lisibles.

54



MULTIPLICITÉ
Multiplicité Signification

0..1 Zéro ou 1
1 Exactement 1
0..* Zéro ou plusieurs
* Zéro ou plusieurs
1..* 1 ou plusieurs
1..9 1à9
9 Exactement 9
1.5, 8, 20..* 1 à 5, exactement 8 ou plus de 20
55



MULTIPLICITÉ
 La multiplicité détermine le nombre d’objets impliqué

dans une association à un instant T

56



MULTIPLICITÉ – EXEMPLE 1

Une voiture possède exactement 4 pneus

Voiture Pneu

1 4

Un pneu appartient à exactement une voiture

57




Une société peut avoir 0, 1 ou plusieurs employés

Société Employe

1 *

Un employé est employé par exactement 1 société

58




Une société doit avoir au moins un employé

Société Employe

0..1 1..*

Un employé peut être employé dans une seule société ou aucune

59




Une société peut avoir plusieurs employés (ou zéro)

Société Employe

1..* *

Un employé peut être employé dans au moins une société

60




Université Enseignant

Emploie
1 *

1 1

AssurerCours AssurerTD

0..3 0..4

Module

61



Un employé a un ou 0 supérieur

Employe
+Subordonnes 0..*

+Superieur 0..1

Un employé peut avoir 0 ou plusieurs subordonnés

62



Un employé a un ou 0 supérieur

Employe
+Subordonnes 0..*

+Superieur 0..1

Un employé peut avoir 0 ou plusieurs subordonnés

63



koudil :Employe

balla :Employe

mostefai :Employe batata :Employe azouaou :Employe

64



Navigation – Exemple 1
Société vers Employé est navigable

Societe Employe

1 *

Employé vers Société est navigable

65



Employé vers Grade est navigable

Employe Grade

* 1

Grade vers Employé n’est pas navigable

66



Employé vers Grade est navigable

Employe Grade

*
X 1

Grade vers Employé n’est pas navigable

67



Société vers Employé est navigable

Societe Employe

1 *

Employé vers Société est navigable

68



Associations et attributs
 Les attributs peuvent être un autre moyen de représenter

une association
 Les associations à multiplicité multiple peuvent être
représentées par des tableaux ou des collections
 Lors de la génération de code, les associations sont
générées en tant qu’attributs

69



Associations et attributs – Exemple 1
Employe

+ grade: Grade

Employe Grade

* 1
Grade

70



Associations et attributs – Exemple Employe
+ grade: Grade

Employe +grade Grade + societe: Societe
* 1

+employes *
Grade

+societe 1

Societe
Societe
+ employes: Employe [0..*]

71



Classes d’association
 Parfois, quand il y a une association entre deux classes,

l’attribut ne peut être dans aucune des classes.
 Exemple ci-dessous : où mettre la note ?

Etudiant Module

* *

72



Classes d’association
 Les classes d’association sont de vraies classes qui

peuvent avoir des attributs, opérations et même d’autres
opérations
Etudiant Module

* *

Note
+ valeur: double

73



Classes d’association - Exemple

Etudiant Module

* *

Note Enseignant
+ valeur: double
* *

74


Classes – Notation UML - Dépendance

 En plus des associations, les classes peuvent être liées
par des relation de dépendance

 Plusieurs cas peuvent induire à une dépendance entre
une classe A et une classe B : A manipule B dans une
opération, B est un paramètre dans une opération de A, B
est le type de retour d’une opération, A appelle une
méthode B, …etc.
 La dépendance n’est pas réservée aux classes, elle peut
être utilisée avec les paquets et les cas d’utilisation

75


Classes – Notation UML - Dépendance

A

B

76


Classes – Notation UML - Héritage

 L’héritage est une relation entre une classe générale et
une classe plus spécifique

 Entre les deux, une relation de substitution : on peut
substituer toute utilisation de l’élément général par
l’élément plus spécifique
 L’héritage est symbolisé par le lien de généralisation
 La classe spécialisée hérite de tous les attributs et les
opérations de la classe parente

77



EXEMPLE 1
Engin
+ marque: string

+ modele: string
Généralisation
+ getPoids() : double

Voiture Camion Bus
+ nombrePlaces: int

VoitureTouristique VoitureUtilitaire
+ chargeUtile: double

78



 Parfois une classe ne peut exister que par l’existence des
classes descendantes

 Une classe peut aussi déférer l’implémentation d’une
opération à ses classes descendantes
 Une opération qui est sans implémentation dans la classe
actuelle est une opération abstraite
 Une classe qui contient une ou plusieurs opérations
abstraites est dite classe abstraite

79



Méthodes abstraites
EXEMPLE – Classes abstraites

Photo
+ points: Point [1..*]
Méthodes concrètes
+ getNombrePoints() : int
+ Dessiner() : void
+ getTaille() : int

PhotoJPEG PhotoPNG PhotoTIFF
+ Dessiner() : void + Dessiner() : void + Dessiner() : void
+ getTaille() : int + getTaille() : int + getTaille() : int

80



LE POLYMORPHISME
 Une opération polymorphique est une opération qui

possède plusieurs implémentations
 Par exemple, n’importe quel compte accepte les retraits
et les versements. Par contre, les comptes entreprises ont
un comportement différent des comptes particuliers. Les
comptes entreprises acceptent les soldes négatifs.

81



EXEMPLE – Polymorphisme

Compte

+ Verser() : void
+ Retirer() : void

CompteParticulier CompteEntreprise

+ Verser() : void + Verser() : void
+ Retirer() : void + Retirer() : void

82


Paquets

QU’EST-CE QU’UN PAQUET ?
 Un paquet UML est un élément de groupage qui contient

plusieurs éléments UML dont éventuellement d’autres
paquets
 Les paquets servent à organiser les éléments UML
 Les paquets définissent des « frontières sémantiques »
du modèle
 Chaque élément UML appartient à exactement un paquet.
Les éléments de haut niveau appartiennent à un paquet
implicite appelé « root » ou « topLevel »

83


Paquets – Notation UML

Paquet

84


Paquets – Notation UML

85


Paquets – Espaces de noms

 Le paquet définit une frontière où les noms des éléments
doivent être uniques

 Si un élément doit référer à un autre élément se trouvant
dans un autre paquet, il doit utiliser un « nom qualifié ».
 Le nom qualifié se fait en préfixant le nom de l’élément
par les noms des paquets qui le contiennent
 Par exemple, si un paquet P1 contient un sous -paquet P2
contenant une classe C1, le nom qualifié de C1 est
P1:P2:C1.

86


Paquets – Dépendance

 Un paquet P1 dépend de P2 si un élément de P1 utilise
d’une manière ou d’une autre un élément de P2

87


Paquets – Dépendance

Commun::Personne

Employe

88

COURS IGL

Cours N° 5
Section 2, Classes et Objets, Analyse

Débat (05 mns)

89


COURS IGL

Cours N° 5
Analyse
Section 3 : Classes d’analyse

90


SECTION 3 –CLASSES
Cours 5 – Analyse D ’A N A LY S E

Les classes d’analyse

 Les classes d’analyse sont les classes découvertes durant
l’activité d’analyse

 Les classes d’analyse correspondent à des concepts
« réels »
 L’analyse fait ressortir les éléments suivants d’une classe
: Nom, Attributs les plus importants, Opérations les plus
importantes, stéréotypes (non techniques)
 Les éléments suivants ne sont pas importants dans
l’analyse : métadonnées, paramètres des opérations,
visibilité

91

SECTION 3 – CLASSES

Sources de recensement

Modèle de Modèle des cas

spécifications d’utilisation

Toute autre source
d’information
relative au
domaine

92


Représentation d’une classe d’analyse

 Les classes d’analyse sont représentés en utilisant le
diagramme des classes

 L’ensemble des classes sont appelés « vocabulaire »,
« glossaire métier » ou « taxonomie du domaine »
 Les classes d’analyse sont une représentation de haut
niveau : elles sont caractérisées par un nom, des attributs
et éventuellement des opérations.
 Le nom de la classe est obligatoire.
 Les noms des attributs sont obligatoires. Leurs types
facultatifs.
 Les paramètres et les types de retour des opérations ne
sont montrés que s’ils apportent une compréhension au
système
93



 La visibilité est généralement omise
 Les stéréotypes ne sont montrés que s’ils augmentent la

représentativité
 Les métadonnées ne sont montrés que s’ils augmentent
la représentativité

94



EXEMPLE

Compte
numero
proprietaire
solde
verser()
retirer()

95



CARACTÉRISTIQUES D’UNE BONNE CLASSE D’ANALYSE
 Son nom reflète son objectif

 C’est une abstraction d’un élément clairement
identifiable dans le domaine
 A un ensemble limité et clair de responsabilités
 A une grosse cohésion
 A un faible couplage

96


Techniques de recensement

Technique Technique
des noms / des
verbes stéréotypes

97


Technique des noms / verbes

 Technique simple qui analyse du texte pour trouver des
classes, des attributs et des opérations

 Les noms et les phrases nominales représentent les
classes et les attributs
 Les verbes et les phrases verbales représentent les
opérations
 Difficultés avec les termes difficiles, les synonymes et les
homonymes
 Difficulté à trouver les classes « cachées »
 S’il y a des termes qui ne sont pas compris, voir avec les
experts du domaine

98


Technique des noms / verbes

Collecte d’information Analyse des
• Spécifications formelles informations
• Cas d’utilisation • Noms et phrases
• … nominales
• Verbes et phrases verbales

99


Technique des noms / verbes - Exemple

Spécifications
Le système doit permettre à
Noms
l’utilisateur de consulter le
solde de son compte Système
Verbes
Le système doit permettre à Compte
Verser
l’utilisateur de verser de Utilisateur
l’argent dans son compte Retirer
Argent
Le système doit permettre à Consulter
l’utilisateur de retirer
l’argent de son compte

100


Technique des noms / verbes - Exemple

Compte

+ solde: double

+ verser(double) : void
+ retirer(double) : void
+ consulter() : double
«Actor»
Utilisateur

101


Technique des stéréotypes

 Cette technique se concentre sur trois stéréotypes :
« boundary », « entity » et « control »

 Cette technique est complémentaire avec la technique
des verbes / noms

102


Technique des stéréotypes

Trouver les
Trouver les Trouver les
limites
contrôleurs entités
(boundary)

103


Technique des stéréotypes - Limites

 Les classes « boundary » représentent les limites du
système

 Ces classes communiquent avec les acteurs
 Trois types de classes « boundary » : classes d’interface
utilisateur, classes qui s’interfacent avec d’autres
systèmes et des classes qui s’interfacent avec un
matériel externe (périphérique,…)
 Ces classes doivent rester de haut niveau (ne pas
s’occuper des détails)

104


Technique des stéréotypes - Contrôleurs

 Les contrôleurs sont responsable de la coordination des
action permettant d’accomplir un cas d’utilisation

 Si un contrôleur est trop compliqué, il est suggéré de le
diviser en plusieurs contrôleurs

105


Technique des stéréotypes - Entités

 Représentent les concepts manipulés par le système
 Utilisés par plusieurs cas d’utilisation et plusieurs

contrôleurs
 Ces classes sont souvent persistantes (enregistrées dans
des fichiers ou des BDD)

106


Technique des stéréotypes - Exemple

1. Le système doit permettre à l’utilisateur de s’inscrire
2. Le système doit permettre à l’utilisateur connecté de

consulter les formations assurés, leurs dates et les
formateurs associés
3. Le système doit envoyer un message mensuellement qui
avertit les utilisateurs inscrits des nouvelles formations

107


Technique des stéréotypes - Exemple

Acteurs Entités Contrôleurs Limites

InscriptionManager
Formation

Utilisateur
InterfaceInscription

NotificationManager
Formateur

108


Paquets d’analyse

 Les classes d’analyse sont regroupées dans des « paquets
d’analyse »

 Les classes se trouvant dans le même paquet sont des
classes ayant un certain lien sémantique
 Un bon regroupement des paquets produit une haute
« cohésion » à l’intérieur d’un paquet et un faible
« couplage » entre paquets

109


Paquets d’analyse - Exemple

110

COURS IGL

Cours N° 5
Section 3 : Classes d’analyse Analyse

– Débat (05 Mns)

111


COURS IGL

Cours N° 5
Analyse
Section 4 : Interactions

112


SECTION 4 –
Cours 5 – Analyse INTERACTIONS

Introduction

 Les classes d’analyse représentent la structure statique
du système

 Les interactions expriment comment les instances de ces
classes interagissent pour réaliser une fonction du
système
 Les interactions expriment l’aspect dynamique du
système

113

SECTION 4 –
Cours 5 – Analyse INTERACTIONS

Objectifs des interactions

 Trouver quelles classes qui interagissent pour un cas
d’utilisation donné

 Trouver les messages envoyés entre les classes pour
réaliser un certain comportement (attributs, opérations,
relations)
 Eventuellement, mettre à jour les modèles de besoins et
d’analyse
 Ne pas créer d’interactions pour tous les cas d’utilisation,
Uniquement pour les CUs les plus importants et les plus
complexes

114

SECTION 4 –
Cours 5 – Analyse R É A L I S AT I O N D E S C A S
D ’ U T I L I S AT I O N

Diagrammes comportementaux

 Les diagrammes comportementaux est la meilleure
façon de représenter les interactions

 Les diagrammes de séquence illustrent une séquence de
messages ordonnée dans le temps
 Le diagramme de communication décrit les relations
entre objets dans un contexte donné
 Le diagramme d’activité décrit le flux d’actions menant
à la réalisation d’une fonction métier
 Le diagramme d’état démontre le changement d’état
d’une entité dans le temps

115

COURS IGL

Cours N° 5
Section 4 : Interactions, Analyse

débat (05 mns)

116


COURS IGL

Cours N° 5
Section 5 : Diagrammes de Analyse

séquence

117


SECTION 5 –
Cours 5 – Analyse DIAGRAMMES DE
SÉQUENCE

Présentation

 Les diagrammes de séquence (DSQ) décrivent une action
ordonnée dans le temps

 Les DSQ document les CU et font partie du modèle
d’analyse
 Les DSQ sont composés de trois concepts principaux : les
lignes de vie, les messages et les fragments

118

SECTION 5 –
SÉQUENCE

Lignes de vie

 Une ligne de vie représente un seul participant dans une
interaction

 Une ligne de vie peut représenter un objet, une instance
d’une classe ou un acteur
 Pour représenter une interaction, des messages lient les
lignes de vie

119

SECTION 5 –
SÉQUENCE

Lignes de vie – Représentation UML

Objet :Employe

Utilisateur

120

SECTION 5 –
SÉQUENCE

Messages

 Un message représente une communication entre deux
lignes de vie durant une interaction

 Un message peut s’agir de l’appel d’une opération
 Un message peut s’agir de la création ou de la
destruction d’instance
 Un message peut s’agir d’envoi d’un signal
 Quand une ligne de vie reçoit un message, ça correspond
généralement à l’appel d’une opération ayant la même
signature
 Quand une ligne de vie reçoit un message, elle obtient
sont activation. L’activation change de ligne de vie à
travers le temps.
121

SECTION 5 –
SÉQUENCE

Messages

Type de message Description

Message synchrone L’émetteur attend que le récepteur termine l’opération

pour passer à l’étape suivante
Message asynchrone L’émetteur envoie le message puis continue son
exécution sans attendre la fin chez le récepteur
Message de retour L’émetteur récupère l’activation suite à l’avoir perdu en
envoyant un message au destinataire
Message de création Le message provoque la création du destinataire

Message de destruction Le message provoque la destruction du destinataire

Message found L’émetteur de ce message ne fait pas partie de
l’interaction.
Message lost Le destinataire ne reçoit jamais ce message. Peut
indiquer des situation d’erreur. 122

SECTION 5 –
SÉQUENCE

Messages

LV1 LV2
Message
Synchrone

MessageSynchrone(P1, P2, P3)

Message de
retour
MessageRetour()

Message
Asynchrone MessageAsynchrone(P4, P5)

Activation

123

SECTION 5 –
SÉQUENCE

Messages
LV

Message De
Création

object:Classe

AppelOperation()
Message De
Destruction

Suppression()

124

SECTION 5 –
SÉQUENCE

Messages

LV1 LV2
Message Found

AppelExterne()

Appel()

Message Lost
AppelPerdu()

125

SECTION 5 –
SÉQUENCE

DSQ - Exemple

AppliquerUnEffet

Utilisateur AjouterUnAlbum

ConsulterUnAlbum

DupliquerAlbum

126

SECTION 5 –
SÉQUENCE

DSQ - Exemple

MiseAjourStatistiqueAlbums

Temps

127

SECTION 5 –
SÉQUENCE

DSQ - Exemple

«actor»
Utilisateur

Album

1 *

Photo

AlbumManager

InterfaceAlbums

StatManager

128

SECTION 5 –
SÉQUENCE

Diagrammes de séquences - Exemple

CU: AppliquerUnEffet
ID: 1
Description brève : Appliquer un effet spécial à une photo d’un album. Chaque effet est identifié

par un numéro.
Acteurs primaires : Utilisateurs
Acteurs secondaires : Aucun
Préconditions : le client doit être authentifié
Enchaînement principal
1. L’utilisateur sélectionne un album
2. L’utilisateur sélectionne la photo désirée de l’album
3. L’utilisateur applique l’effet désiré en indiquant son numéro.

Postconditions :
Enchaînement s alternatifs :

129

SECTION 5 –
SÉQUENCE

DSQ – Appliquer un effet
Lignes de vie

:Album :Photo

Utilisateur
AlbumManager
getAlbum(id:int)

:Album Activation

getPhoto(idPhoto :int) :Photo

:Photo

appliquerEffet(idEffet :int)

Messages
130

SECTION 5 –
SÉQUENCE

DSQ – Appliquer un effet

:Album :Photo

Utilisateur
AlbumManager
getAlbum(id:int)

:Album

getPhoto(idPhoto :int) :Photo

:Photo

appliquerEffet(idEffet :int)

131

SECTION 5 –
SÉQUENCE

DSQ – Ajouter un album

CU: AjouterUnAlbum
ID: 2
Description brève : Création d’un nouvel album par l’utilisateur

1. Le CU démarre quand l’utilisateur clique sur le bouton « nouveau »
2. L’utilisateur donne un nom à l’album
3. L’utilisateur enregistre l’album

Postconditions :

132

SECTION 5 –
SÉQUENCE

DSQ – Ajouter un album

Utilisateur
AlbumManager
ajouterAlbum() :Album

:Album

:Album

renommer(String)

enregistrerAlbum(Album)

133

SECTION 5 –
SÉQUENCE

DSQ – Consulter un album

CU: Consulter un album
ID: 3
Description brève : L’utilisateur consulte un album et les photos qui le composent

1. Le CU démarre quand l’utilisateur clique sur l’album sélectionné
2. L’album adapte son affichage selon la résolution
3. L’album affiche les photos le composant selon la résolution

Postconditions :

134

SECTION 5 –
SÉQUENCE


:Album

Utilisateur
InterfaceAlbums AlbumManager
clic(album :Album)

getAlbum(id :int) :Album
Activations
:Album réflexives

getResolution() :int

afficher(resolution :int)

adapter(resolution :int)

135

SECTION 5 –
SÉQUENCE


:Album

Utilisateur
InterfaceAlbums AlbumManager
clic(album :Album)

getAlbum(id :int) :Album

:Album

getResolution() :int

afficher(resolution :int)

adapter(resolution :int)

136

SECTION 5 –
SÉQUENCE

Fragments

 Un DSQ peut être composé de plusieurs fragments
 Un fragment est caractérisé par un nom

 Un fragment peut contenir un ou plusieurs messages
 Un fragment est composé d’un opérateur et de un ou
plusieurs opérandes
 L’opérateur décide comment les opérandes sont
exécutées
 Un fragment peut être caractérisé par une ou plusieurs
conditions
 Les fragments peuvent être imbriqués

137

SECTION 5 –
SÉQUENCE

Fragments – Opérateurs

Opérateurs Nom Description

opt optionnel L’opérande n’est exécutée que si la
condition est vérifiée
alt Alternatives Plusieurs alternatives. Uniquement
l’opérande dont la condition est vérifiée
s’exécute
loop Itération Itère l’ exécution tant que la condition est
vérifiée
ref Référence Réfère à une autre interaction

138

SECTION 5 –
SÉQUENCE

DSQ – Dupliquer un album

CU: DupliquerUnAlbum
ID: 4
Description brève : L’utilisateur crée un nouvel album portant le même nom et contenant les

mêmes photos
1. Le CU démarre quand l’utilisateur clique sur le bouton dupliquer
2. Le système crée un nouvel album
3. Le système donne le même nom au nouvel album
4. Si l’album original contient des photos et s’il n’est pas verrouillé
4.1 Copier les photos de l’album original vers la copie
Postconditions :

139

SECTION 5 –
SÉQUENCE


original :Album
Nom
Utilisateur
AlbumManager

dupliquerAlbum(int)

getAlbum(int) :
Opérateur Album Fragment
getPhotos() :Photo[*]
liste= :Photo[*]

Copie :Album
Condition
renommer(String)

opt Copier

Opérande [Si liste n'est pas vide est si l'album n'est pas verrouillé]
copierPhotos(liste)

140

SECTION 5 –
SÉQUENCE


original :Album

Utilisateur
AlbumManager

dupliquerAlbum(int)

getAlbum(int) :
Album
getPhotos() :Photo[*]
liste= :Photo[*]

Copie :Album

renommer(String)

opt Copier
[Si liste n'est pas vide est si l'album n'est pas verrouillé]
copierPhotos(liste)

141

SECTION 5 –
SÉQUENCE

DSQ – MAJ Statistiques Album

CU: MAJ statistiques
ID: 5
Description brève : Chaque jour, des statistiques sont mises à jour pour tous les albums. Si

l’album est public, on prend le nombre de visite et les miniatures sinon on prend uniquement le
nombre de visites.
1. Le CU démarre chaque fin de journée
2. Le système récupère la liste des albums
3. Pour chaque album
3.1 si l’album est public,
3.1.1 prendre le nombre de visites et les miniatures
3.2 sinon
3.1.2 prendre le nombre de visites
Postconditions :
142

SECTION 5 –
SÉQUENCE

DSQ – MAJ Statistiques Album

:Album

StatManager AlbumManager

getAllAlbums() :Album[*]

:Album[*]

loop iterationAlbums
[pour chaque album]

alt albumCond
[Album public]
getNombreVisites() :int

getMiniatures() :Photo[*]

[Album privé]
getNombreVisites() :int

143

SECTION 5 –
SÉQUENCE

DSQ – Exemple
«actor»
Utilisateur

Album

+ getPhoto(int) : Photo
+ renommer(String) : void
+ afficher(int) : void
+ adapter(int) : void
+ getPhotos() : Photo[*]
+ copierPhotos(Photo[*]) : void
+ getNombreVisites() : int *
1
+ getMiniatures() : Photo[*]
Photo

AlbumManager + appliquerEffet(int) : void

InterfaceAlbums

StatManager

144

COURS IGL

Cours N° 5
Section 5 : Diagrammes de Analyse

séquence, débat (05 mns)

145


COURS IGL

Cours N° 5
Section 6 : Diagrammes Analyse

d’activité

146


SECTION 6 –
Cours 5 – Analyse DIAGRAMME
D ’A C T I V I T É

Présentation

 Les diagrammes d’activité (AD) représentent des
processus en tant qu’une activité composée de plusieurs

nœuds connectés.
 Dans UML 1, les AD étaient des sous -ensembles des
diagrammes d’état. Dans UML 2, c’est des diagrammes à
part entière.
 Une activité peut être attachée à n’importe quel élément
du modèle (cas d’utilisation, classe, …). Une activité
modélise essentiellement un comportement.

147

SECTION 6 –

Présentation

 Les diagrammes d’activité sont idéaux pour représenter
des processus métier.

 Les ADs n’ont pas besoin de connaître la structure
statique du modèle (classes, objets) ce qui permet leur
utilisation dans les premiers moments de l’analyse.
 Les ADs sont très simples à comprendre par le client.

148

SECTION 6 –

Activités

 Les activités sont des réseaux composés de nœuds et de
connecteurs.

 Il y a trois types de nœuds : des nœuds d’action, des
nœuds de contrôle et des nœuds d’objet.
 Un « nœud d’action » représente une unité de travail
atomique (indivisible)
 Un « nœud de contrôle » contrôle le flux au sein d’une
activité
 Un « nœud d’objet » représente un objet manipulé dans
l’activité.

149

SECTION 6 –

Activités

 Les connecteurs représentent le flux entre les nœuds.
 Il y a deux types de connecteurs : des connecteurs de

contrôle et des connecteurs d’objet.
 Un connecteur de contrôle représente le flux d’activité
 Un connecteur d’objet représente le flux d’objet
 Une activité démarre avec un nœud spécial appelé nœud
initial
 L’activité se termine avec un nœud spécial appelé nœud
final

150

SECTION 6 –

Activités

EffectuerUneCommande

Acheteur

ValiderUneCommande

Vendeur

151

SECTION 6 –

Diagramme d’activité

Nœud initial

Chercher Des Produits

Nœuds d’action Connecteurs
Sélectionner Les Produits

Enregistrer La Commande

Nœud final
152

SECTION 6 –

Diagramme d’activité

Chercher Des Produits

Sélectionner Les Produits

Enregistrer La Commande

153

SECTION 6 –

Fonctionnement

 Le diagramme d’activité suit une séquence déterminée
par un jeton

 Le jeton transite du nœud initial vers le nœud final
 Le jeton peut être un des éléments suivants : le flux
actuel, un objet ou des données
 L’état d’un AD est déterminé par ses jetons
 Les jetons transitent d’un nœud à l’autre via les
connecteurs

154

SECTION 6 –

Partitions

 Les activités sémantiquement liées peuvent être
regroupées en « partitions »

 Une partition désigne généralement le rôle exécutant
l’action en cours
 Les partitions rendent les ADs plus faciles à lire et plus
expressifs
 Les partitions peuvent être représentées d’une manière
horizontale ou verticale
 Exemple : pour valider une facture, le gestionnaire lance
la validation, le magasinier prépare le stock et enfin, le
comptable vérifie le paiement

155

SECTION 6 –

Partitions
Partitions

Gestionnaire Magasinier Comptable

Lancer la validation

Préparer le stock

Vérifier le virement

156

SECTION 6 –

Partitions

Gestionnaire Magasinier Comptable

Lancer la validation

Préparer le stock

Vérifier le virement

157

SECTION 6 –

Décisions et fusions

 Un nœud de décision a un connecteur en entrée et deux
(ou plusieurs e sortie)

 Le chemin à suivre par le jeton est celui de la condition
vérifiée du nœud de décision
 Plusieurs chemins sortent du nœud de décision
 Un nœud de fusion fusionnent les connecteurs sortis d’un
nœud de décision
 Exemple : une fois une commande reçue, si le stock est
disponible faire l’inventaire du reste, sinon lancer un
approvisionnement

158

SECTION 6 –


Recevoir Commande
Nœud de
décision

Stock disponible
[Non]
[Oui]

Mettre à jour
inventaire
Approvisionner

Nœud de fusion

Notifier

159

SECTION 6 –


Recevoir Commande

Stock disponible
[Non]
[Oui]

Mettre à jour
inventaire
Approvisionner

Notifier

160

SECTION 6 –

Activités parallèles

 Dans un AD, on peut créer des flux parallèles en utilisant
le nœud « fork »

 Pour fusionner les flux parallèles, un nœud « join » est
utilisé
 Exemple : après réception d’une commande, deux activité
sont lancées en parallèle, une pour la vérification du
paiement et l’autre pour la préparation du stock

161

SECTION 6 –


Nœud fork

Recevoir Commande

Préparer Stock Vérifier Paiement

Nœud join

162

SECTION 6 –


Recevoir Commande

Préparer Stock Vérifier Paiement

163

SECTION 6 –

Nœuds d’objet

 Les nœuds d’objet sont des nœuds spéciaux qui indiquent
que des instances d’une classe données sont disponible à

un point donné du temps
 Exemple, dans une activité industrielle, la spécification
produit un cahier de charges et le développement produit
un prototype

164

SECTION 6 –

Nœuds d’objet

Spécification

Nœud d’objet cahier des charges

Développement

prototype

165

SECTION 6 –

Nœuds d’objet

 Lorsque les activités produisent beaucoup d’objets, il
serait intéressant de les organiser en PINS

 Par exemple, pour l’authentification, le username et le
mot de passe sont des objets produits

166

SECTION 6 –

Nœuds d’objet

Authentifier
Entrer
Utilisateur
Utilisateur
Vérifier
Utilisateur

Entrer Mot De
Mot De Passe
Passe
Vérifier Mot DePasse

Sans utilisation des PINs

167

SECTION 6 –

Nœuds d’objet

Entrer Authentifier

Utilisateur
Utilisateur
Vérifier
Utilisateur

Entrer Mot De
Passe
Mot de Vérifier Mot DePasse
passe

Avec utilisation des PINs

168

SECTION 6 –

Quand utiliser le diagramme d’activité ?

 Pour modéliser des processus parallèles
 Pour modéliser des processus métier indépendamment

de la structure statique (classes d’analyse)

169

COURS IGL

Cours N° 5

d’activité, Débat (05) mns

170


COURS IGL

Cours N° 5

d’états-transitions

171


SECTION 7 –
Cours 5 – Analyse D I A G R A M M E D ’ É TAT S
TRANSITIONS

Introduction

 Un diagramme d’états-transitions (DET) modélise le
cycle de vie d’un objet dit objet réactif

 Un objet réactif est un objet qui change d’état suite à un
évènement donné
 Une machine d’état représente un nombre fini de ces
états

172

SECTION 7 –
TRANSITIONS

Introduction

 Les DETs sont composés de trois éléments principaux :
états, transitions et évènements

 Un état représente une condition dans laquelle se trouve
un objet à un instant T
 Un évènement est une action particulière qui se
déclenche sous des conditions spécifiques
 Une transition est le mouvement d’un état vers un autre
suite à un évènement donné

173

SECTION 7 –
TRANSITIONS

Exemple

 Une lampe est initialement éteinte. Si on l’allume, elle
passe dans l’état allumée. Si on l’éteint, elle repasse dans

l’état éteinte. Si elle saute, elle passe définitivement à
l’état final défectueux

174

SECTION 7 –
TRANSITIONS

Exemple

Etat initial Etat

[Allumer]
Eteinte Allumée
[Eteindre]

[Sauter]

Transition Etat final

175

SECTION 7 –
TRANSITIONS

Etats

 Durant le temps, un objet peut envoyer un message à un
autre objet qui peuvent changer sont état

 L’état d’un objet est déterminé par ses attributs, ses
relations à d’autres objets et les activités dans
lesquelles il est impliqué
 Il ne faut modéliser que les états qui ajoutent de
l’expressitivité au système
 Les états de jonction (pseudo-états) peuvent connecter
plusieurs transitions
 Un pseudo-état de choix exprime un ou plusieurs choix
mutuellement exclusifs

176

SECTION 7 –
TRANSITIONS

Etats

Pseudo-état de
jonction

Disponible [déterioration] Indisponible

[rendu] [prêté]

En prêt

Pseudo-état de
choix
Perdu

177

SECTION 7 –
TRANSITIONS

Etats

Disponible [déterioration] Indisponible

[rendu] [prêté]

En prêt

Perdu

178

SECTION 7 –
TRANSITIONS

Quand utiliser le DET ?

 Pour modéliser des entités réactives (dont les états
changent)

179

COURS IGL

Cours N° 5
d’états-transitions, débat
(05 mns)

180


Cours 3 – Introduction à UML BIBLIOGRAPHIE

Bibliographie

 UML Distilled 3rd Edition, Martin Fowler, 2003, Addison
Wesley

 UML2 and the Unified Process, Second Edition, Addison
Wesley 2005

 Wikipedia : Unified Modeling Language,
http://fr.wikipedia.org/wiki/Unified_Modeling_Language

181

Génie Logiciel - Cours 5 - analyse

Contenu connexe

Tendances (20)

Similaire à Génie Logiciel - Cours 5 - analyse (11)

Plus de Mohammed Amine Mostefai (20)

Génie Logiciel - Cours 5 - analyse