ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Table des matières

Table des matières .................................................................................................................................. 1
INTRODUCTION ................................................................................................................................. 2
1. Découpage en catégories ........................................................................................................... 2
Notion de dépendance entre catégorie ......................................................................................... 4
2. Développement du modèle statique ......................................................................................... 5
2.1. Traitement des anomalies ................................................................................................. 5
2.2. Traitement des attributs ................................................................................................... 6
2.3. Traitement des opérations ................................................................................................ 7
3. Développent du modèle dynamique ......................................................................................... 9
3.1. Notion de scenario ............................................................................................................. 9
3.2. Formalisation des cas d’utilisation................................................................................. 10
3.2.1. Le digramme de séquence ................................................................................................. 10
Diagrammes états-transitions ..................................................................................................... 13
Conclusion ............................................................................................................................................ 14
Références............................................................................................................................................. 15
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

INTRODUCTION
La conception d’un système d’information est un processus regroupant un
certain nombre d’étapes indispensables. Au point où nous en sommes, toutes les
études (préliminaires, fonctionnelles et techniques) concernant les besoins du
système et de l’utilisateur ont été établis. Il revient donc ici de faire une étude
des différentes données qui en sont ressorties, d’où la « phase d’analyse ». Pour
y parvenir, nous aurons à faire un découpage en catégories, puis développer les
modèles statiques et dynamiques.

1. Découpage en catégories

Après la collecte des données, l’identification des différents intervenants et les

fonctionnalités du système à mettre sur pieds, il est nécessaire de démarrer
l’analyse de ces informations. Le découpage en catégorie constitue la première
phase de cette analyse et consiste à définir les packages. Le découpage en
catégorie consiste donc à regrouper les classes présentes dans le diagramme de
classes candidates ayant une forte affinité, en catégories de classes. Cette
phase utilise la notion de package (ensemble formé de plusieurs classes ayant
des points communs) pour définir les différentes catégories de classes. Le
découpage en catégorie permet donc une meilleure représentation de la
structure statique du système, c'est à dire qu'il permet une conformité du
logiciel avec les besoins exprimés, et la vérification du processus de
développement donc l'adéquation des méthodes mises en œuvre.
Critères de découpage : ici, la question qui nous vient à l’esprit est celle de
savoir, « comment pouvons-nous faire pour mettre plusieurs classes dans
une même catégorie ? »
Cependant, nous constatons que le point de départ pour l’élaboration de nos
critères est l’ensemble des diagrammes de classes. Donc, il convient de
regrouper les classes en catégories en respectant un certain nombre de critères de
découpage.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Diagramme de classes :

Découpage obtenu :

Exemple 2 : dans le système de la gestion de clientèle, nous pouvons

distinguer les catégories suivantes.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

• La cohérence des classes : ici, les classes sont découpées en fonction de

leurs liaisons sémantiques.
• L’évolution : ici, nous regroupons des classes a fort degré d’évolution et
inversement. C’est-à-dire que nous pouvons mettre dans une même
catégorie, des classes ayant une ressemblance évolutive. En occurrence,
les structures des classes « Employe » et « Diplome » sont susceptibles
de ne pas changer sur longue periode.Pourtant, les classes « Sanction »
et « Grade » sont susceptibles de changer de structure avec le temps.
• La durée de vie des objets : à ce niveau, on regroupe des classes dont les
instances ont une durée de vie similaires ou equivalentes.On peut par

<<category>>
<<category>> <<category>> Paiement <<category>>
Administrateur Achat en ligne Commercial
+utilisateur +commande +facture +produits
+compte-user +panier +carte bancaire +fournisseur
+rôle +client +marques
+droit +compte client +entrée stock
+sortie stock
exemple observer les instances de la classe « Diplome » (liées à une
instance de la classe « Employe») qui seront détruites lorsque l’instance
de la classe et « Employe» en question sera détruite.
• La dépendance entre les classes : c’est le cas des classes ayant besoin
des instances d’autres classes pour les caractériser ou les creer.Nous
pouvons énumérer la «catégorie Affectation », dans laquelle « la classe
Aff_fonct » dépend de la classe « Fonction ».

Notion de dépendance entre catégorie

La conséquence directe du découpage en catégories est la dépendance entre les
catégories, qui se traduit par le fait qu’une classe appartenant à une catégorie A
dépende d’une autre appartenant à une catégorie B, impliquant ainsi que A
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

dépend de B. On peut cependant conditionner l’utilisation des classes d’une

catégorie en dehors de celle-ci, grâce à sa visibilité. Celle-ci doit être publique
(précéder le nom de la classe par un +) pour qu’elle soit utilisable en dehors de
la catégorie, et privée (précéder le nom d’un -) si tel n’en n’est pas le souhait.

Les classes Congé, Aff_fonction et Sanction dépendent toutes de la classe

Date, donc leurs catégories respectives dépendent également de la catégorie
Période.
La dépendance entre catégories n’est pas transitive : ayant A, B, et C
trois catégories, si on n’a pas de dépendance entre une classe de A et une de C,
alors le fait que A dépende de B et B dépende de C, ne veut pas dire que A
dépend de C.

2. Développement du modèle statique

2.1. Traitement des anomalies

Une anomalie dans un système est le plus souvent due à une erreur dans sa
conception ou sa mise en œuvre qui cause soit un disfonctionnement ou
empêche complètement son fonctionnement. L’analyse affinée des classes a
pour objectif de ressortir et d’éliminer ses anomalies qui peuvent donc se
manifester sous plusieurs formes :
a. Redondance : elle fait référence à une duplication d’une information ou
d’un composant du système ce qui l’alourdis et donc son fonctionnement.
En occurrence, pour un système ayant des classes «Employe » et
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

«Superieur », conçues indépendamment, sans aucune liaison, on aura

une redondance dans le système car ces deux classes possèdent dans une
grande majorité les mêmes attributs et méthodes. Il serait donc préférable
de créer une seule classe et de faire un héritage.
b. Classe à la place des rôles : Ceci, fait référence au fait que, dans un
système une classe porte le nom d’une fonctionnalité (rôle) du système.
Nous pouvons en guise d’illustration, énumérer la création d’une classe
« GererEmploiye » dans un système de gestion du personnel d’une
entreprise créant une ambigüité car on n’a pas assez de détails sur ce en
quoi consiste vraiment le fait de gérer les employés ; cette anomalie peut
être corrigée en raffinant la fonctionnalité en question et par la suite en
créant des classes aux fonctionnalités atomiques.
c. Classe représentant des acteurs : l’anomalie est généralement observée
lorsque certaines classes représentent des acteurs pas toujours atomiques
c’est-à-dire assez complexes tels que la direction dans l’exemple
précédant.
D’autres concepts sont à prendre en considération tels que :
➢ La multiplicité : faire en sorte de mettre les bonnes cardinalités au
bonne endroit.
➢ Navigabilité : précisé si une association peut être traversée ou pas.
➢ Association ayant le sens d’agrégation ou de composition : préciser
et distinguer les classes qui dépendent (celles n’ont pas leur propre
cycle de vie) complètement d’autre classe (composition) et celles qui
sont indépendantes (ont leur propres cycle de vie) malgré qu’elle
appartient à une autres classe (agrégation).
Il est aussi possible d’ajouter d’autres contraintes aux extrémités des
associations telles que les contraintes d’ordre, d’ajout /suppression
d’instances ainsi qu’aux classes et aux liens

2.2. Traitement des attributs

Un attribut (propriété) est une donnée caractérisant l’objet; ce sont des

variables stockant des informations sur l’état d’un objet. Il possède un type de
données prédéfini ou défini par l’utilisateur.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Les attributs doivent être analysés pour éliminer ceux qui traduisent la même
caractéristique et ceux qui dérivées d’autres. Pour résoudre ce problème on peut
expliciter des contraintes entre des propriétés, supprimer les attributs
dérivés (attribut dont la valeur se calcule à partir des valeurs d’un ou plusieurs
autres attributs).
L’attribut dérivé doit être signalé en préfixant le nom de l’attribut avec une
barre oblique « / » afin d’indiquer au lecteur que cet attribut est redondant,
C’est une indication importante pour ceux qui implantent l’application car les
attributs dérivés demandent un traitement spécial : leur valeur change à chaque
fois que la valeur des attributs à partir desquels ils sont calculés change. Dans
notre exemple, le traitement est même un peu plus complexe car la valeur de
l’attribut <<âge>> évolue aussi en fonction d’un paramètre indépendant de
l’application : la date du jour.
Un attribut dérivé peut être représenté comme suit:

2.3. Traitement des opérations

Une fois, les cas d’utilisations et les classes candidates définis au niveau de la
capture des besoins fonctionnels, il suffit en se référant à chaque classe
potentiellement utile pour la réalisation d’un cas d’utilisation précis(classe du
diagramme de classes participantes du cas d’utilisation), de se poser la
question «Que doit faire cette classe pour réaliser ce cas
d’utilisation ? ».La réponse à cette question donne naissance à de nombreuses
méthodes, lesquelles devront être sélectionnées pour n’en garder que celles qui
sont assez importantes et mettre de côté les autres considérées comme triviales
à l’instar des fonctions de créations d’instances, de destructions, de mise à
jour des propriétés d’instances, de consultation d’informations,…etc.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Cette sélection d’opérations est réalisée dans le but de ne pas alourdir le

diagramme et de ne garder que celles qui nous seront réellement utiles.
Par ailleurs, certaines opérations sont déjà mentionnées dans les cahiers des
charges. Ainsi, il faudra les associer chacune à une ou plusieurs classes.
Toutefois, il est nécessaire d’appliquer les mêmes règles de sélections ci-haut.
En considérant le projet de gestion des ressources humaines de l’entreprise
X des chapitres précédents et les classes candidates « Conge » et
« Employe », et parallèlement, le cas d’utilisation suivi des congés, l’on se
pose la question de savoir « que doit-on faire dans la classe congé pour
réaliser le suivi des congés d’un employé ? » ; de là, nous pouvons répondre :
• Inscrire dans la base de données un congé accordé à un employé.
• Réintégrer un employé revenant d’un congé.
• Modifier les informations relatives à un congé
• Supprimer un congé.
Ces différentes réponses pourront être matérialisées comme méthodes de la
classe « Conge » comme ci-dessous.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

3. Développent du modèle dynamique

Le développement du modèle dynamique se fait en parallèle avec le
développement du modèle statique. Il permet de décrire avec plus de
détails les cas d’utilisation abordés par une partie du chapitre 4. Ces
derniers nous présentaient de manière un peu abstraite les différentes
fonctionnalités d’un SI que nous sommes entrains de modéliser. Ainsi,
nous parlerons à ce niveau de la notion de scénario et de la
formalisation des cas d’utilisation.

3.1. Notion de scenario

Nous pouvons définir un scénario comme une instance de cas d’utilisation. Les
scénarios nous permettent de mieux visualiser les différents enchaînements d’un
cas d’utilisation, l’objectif ici étant de nous permettre de pouvoir mieux
imaginer l’interface utilisateur et de mettre en évidence les différentes
interactions possibles entre les actions du système et celles de l’utilisateur.
Ainsi, chaque fois qu’un acteur déclenche un cas d’utilisation, un scénario est
créé.
A ce niveau, nous rencontrons néanmoins un problème dans la mesure où le
nombre de scénarios à retenir est difficile à réaliser ; l’exhaustivité est difficile à
atteindre car le nombre d’instances pour un seul cas d’utilisation peut être très
important.
Cependant, nous distinguons plusieurs types de scénarios parmi lesquels:
=> Les scénarios nominaux: ils décrivent les actions qui se déroulent de
manière naturelle c’est à dire qui permettent d’atteindre la fin du cas
d’utilisation en passant par le chemin prévu lors de la conception du système.
Exemple: Connexion à un compte git hub en entrant correctement les
informations demandées (cas d’utilisation de la connexion à un compte git hub).
=> Les scénarios alternatifs: ils décrivent les actions qui aboutissent à la fin du
cas d’utilisation en passant par certaines autres étapes qui sont fonction des
choix de l’utilisateur. Exemple: connexion a un compte Facebook sans avoir un
compte utilisateur.
=> Les scénarios aux limites: ils décrivent les actions qui ne peuvent plus se
reproduire, les actions dont une exécution pareille signalerait une erreur.
Exemple: Validation d’une adresse Gmail (cas d’utilisation de la création d’une
adresse Gmail).
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

=> Les scénarios d’erreur: ils décrivent les actions qui n’aboutissent pas à la
fin du cas d’utilisation parce que perturbées par un événement anormal.
Exemple: Achat en ligne d’un produit en utilisant une carte bancaire vide (cas
d’utilisation d’un achat en ligne).
Ces différents scénarios peuvent être représentés sur la figure ci-dessous.

3.2. Formalisation des cas d’utilisation

3.2.1. Le digramme de séquence
Le diagramme de séquence fait parties des diagrammes comportementaux. Il est
placé dans un rectangle qui dispose d’une étiquette sd en haut en gauche (qui
signifie sequence diagramm) suivi du nom du diagramme.
a) Notion d’objet dans un diagramme de séquence
Dans un diagramme de séquence, l’objet à la même représentation que dans le
diagramme des objets. C’est-à-dire un rectangle dans lequel figure le nom de
l’objet. Les diagrammes de séquences représentent les échanges entre les objets
mais aussi les échanges avec les acteurs.
b) La ligne de vie
Comme il représente la dynamique du système, le diagramme de séquence fait
entrer en action les instances de classes intervenant dans la réalisation d’un cas
d’utilisation particulier.
➢ A chaque objet est associé une ligne de vie (en trait pointillés à la
verticale de l’objet) qui peut être considéré comme un axe temporel (le
temps s’écoule du haut vers le bas).
➢ La ligne de vie indique les périodes d’activité de l’objet (généralement les
moments ou l’objet exécute une de ces méthodes)
➢ Lorsque l’objet est détruit, la ligne de vie s’achève par une croix
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

3.2.1. Notion de message

La notion de message est très liée au diagramme de séquence car elle définit une
communication particulière entre les lignes de vie d’un diagramme de séquence.
C’est également une communication d’un objet vers un autre. Il existe plusieurs
types de messages: les signaux ou messages asynchrones et les appels
d’opérations ou messages synchrones.

➢ Messages synchrones : Les messages synchrones provoquent chez le

destinataire le lancement d’une de ses méthodes et l’expéditeur reste
bloqué pendant toute l’exécution de la méthode en attente d’une réponse
de la part du récepteur.
Exemple : En considérant le système de gestion du personnel de l’entreprise
X des chapitres précèdent, la consultation de la liste des employés par le
responsable du personnel fait intervenir la notion de messages asynchrones dans
le cas où le responsable ne peut effectuer aucune autre opérations avant que le
système l’ aille fourni la liste.
➢ Messages asynchrones : Dans le cas des messages asynchrones,
l’expéditeur n’attend pas de réponse du récepteur avant d’envoyer un
autre message.
Exemple : En considérant également le projet de l’exemple précédant,
l’impression de la fiche de pointage d’un employé est une opération asynchrone
dans la mesure où l’utilisateur imprimant n’as pas besoin d’attendre que le
système ait fini d’imprimer la fiche pour faire d’autres tâches.

3.2.2. Situations exceptionnelles

 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Dans un système, lorsque des objets s’échangent des messages, il peut survenir
plusieurs cas exceptionnelles.

❖ Message de création/destruction d’objets : Dans un diagramme de

séquence, certains objets existent pendant tout le comportement du
système. Par contre, d’autre sont créé et/ou détruit au cours d’une
séquence. La création d’un objet est matérialiser par un message
spécifique faisant appel à un constructeur et généralement accompagné du
stéréotype <<Create>>. La destruction de l’objet est effectué après la
réception d’un message et est accompagné du stéréotype <<Destroy>>.
❖ Les auto-messages : un objet peut s’envoyer des messages à lui-même.
On parle de message on parle de message récursifs ou d’auto-messages.

❖ Les messages de groupe : Ils sont envoyés à un ensemble d’objets.

Comme exemple, nous avons la sélection d’un ensemble d’élément E
ayant des caractéristiques C communes ; le groupe d’objet ici est E et les
messages de groupes C.

3.2.3. Les différentes formalisations possibles

La formalisation des cas d’utilisation fait intervenir quatre diagrammes principaux, à savoir les
diagrammes de collaboration(qui met en evidence les interactions entre les differents objets du
système comme leur evolution), les diagrammes de séquence(déjà présenté ci-haut), d’activites (qui
permettent de mettre en exergue les differentes conséquence d’un processus sur des objets) et les
diagrammes états-transition.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Diagrammes états-transitions
Ce sont des diagrammes permettant d’expliciter les différents états que peuvent
prendre des objets en fonction des évènements qui survienent.Il est important de
noter que, ces diagrammes ne se réalise que dans le cas d’étude des états un
objet complexe.
OBJECTIFS:
• Globalement : étudier les états d’un Système
• Plus particulièrement : Comprendre le système en s’intéressant aux
classes qui présentent des traitements complexes
• On se limite aux classes qui sont cruciales pour le champ de l’étude
• On se limite aux états qui sont d’un intérêt pour le champ de l'étude
• Fournir une représentation dynamique du comportement des objets d’une
classe
• Aider à déterminer les événements qui occasionnent les transitions
• Aider à déterminer les opérations qui vont permettre ces transitions
NOTION D’ETAT:
• Un état = étape dans le cycle de vie d’un objet
• Chaque objet possède à un instant donné un état particulier
• Chaque état est identifié par un nom.
• Un état est stable et durable
• Chaque diagramme d’états-transitions comprend un état
Etat initial Etat
intermédiaire Etat final
NOTION DE TRANSITION:
• Les états sont reliés par des connexions unidirectionnelles appelées
transitions
Etat A Etat Etat B
B
• Ex : place de parking

Disponible Reservé

NOTION D’EVENEMENT
L’évènement est le facteur ou condition permettant grâce à une méthode de
l’objet de passer d’un état à un autre.
1. On peut mettre l’alarme « on » ou « off ».
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Le réveil à clairement deux états distincts : Désarmé (alarme « off ») ou Armé

(alarme « on »). Une action de l’utilisateur permet de passer d’un état à l’autre.
On suppose que le réveil est bien désarmé au départ. Notez le paramètre heure
Alarme de l’événement armé.

Conclusion

L'analyse est l’évaluation des composants d'un système pour identifier les
domaines à améliorer et donc apporter ces améliorations si besoin. Lorsqu'une
analyse du système est correctement effectuée, elle s'assure que le chemin
correct est emprunté en ce qui concerne les bases du logiciel et aide à minimiser
les erreurs. Pour accomplir donc cette tâche, il est nécessaire de procéder
d'abord, à un découpage en catégories, en regroupant les différentes classes du
système en fonction des critères vus précédemment, puis développer le modèle
statique du système à travers le traitement des anomalies, des attributs et des
opérations. Enfin le développement du modèle dynamique permet d'étudier les
différents scénarios liés aux cas d'utilisation, ainsi que l'élaboration des
diagrammes d'etats-transitions, des diagrammes de séquences, qui formalisent
les cas d'utilisation. Comme indiqué précédemment, la phase d'analyse est l'une
des phases importantes du développement de tout système grâce à la
compréhension des exigences qui répondent aux changements futurs. Une fois
cette étape achevée et générique, l'on peut donc passer à la conception
générique.
 ETAPE D’ANALYSE DANS LA METHODE UML- UNIVERSITE DE DSCHANG

Références
• Support de cours
• Site http://uml.free.fr (cours sur la méthode UML)
• Dictionnaire électronique « Français »