3.3 MODELISATION UML
La modélisation étant un moyen efficace de bien
définir et analyser les besoins pour espérer aboutir au
résultat escompté, nous avons jugé important de
présenter le langage de modélisation que nous avons choisis UML.
Nous commencerons par sa définition, ensuite par ses différentes
vues d'abstraction du monde réel.
3.3.1. Définition et principe d'UML
UML, Unified Modeling Language, langage de modélisation
objet unifié est une démarche orientée objet. Elle est
née comme nous l'avons dit de la fusion de trois méthodes
orientées objet Booch, OMT Object Modeling Technique et OOSE Object
Oriented Software Engineering, conçues respectivement par Grady Booch,
James Rumbaugh et Ivar Jacobson.
Les 3 experts ont focalisé leur attention sur les deux
aspects : modélisation et
formalisation afin de concevoir un langage de
modélisation standard et universel utilisé notamment pour le
développement informatique en langage objet.
La modélisation et la formalisation à l'aide
d'un vocabulaire standardisé et de surcroît orienté objet
conferent à la méthode tout son intérêt. La
formalisation et la modélisation facilitent en effet la
définition du problème à traiter et la
compréhension par l'ensemble des principales parties prenantes, sous
réserve que chaque partie maitrise son formalisme.
Une fois le modèle bien défini, il est plus
aisé de s'y référer lors du développement afin de
s'assurer de la conformité de ce dernier. Un outil précieux qui
explique à lui seul l'essor de la démarche UML.
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
3.3.2. Le formalisme UML
Les spécifications d'UML son disponibles sur le site de
Rational Software (RATIONAL 1999). UML est un langage de modélisation de
données orienté objet basé sur l'utilisation de neuf types
de diagrammes : les diagrammes de classes, les diagrammes d'objets, les
diagrammes de composants, les diagrammes de déploiement, les diagrammes
de cas d'utilisation, les diagrammes de collaboration, les diagrammes de
séquence, les diagrammes d'étatstransitions et les diagrammes
d'activités.
Les parties statiques d'un système sont décrites
à l'aide des quatre premiers diagrammes, tandis que les cinq autres
servent à détailler les aspects dynamiques du même
système.
Au sein des diagrammes statiques, on distingue ceux
décrivant les aspects conceptuels d'un système, et ceux
décrivant les aspects physiques ou d'implémentation. Nous nous
limiterons ici à la présentation du formalisme des 04 diagrammes
suivant : Cas d'utilisation, Séquences, Classes et déploiements
qui à notre avis suffisent pour modéliser un système de
l'ensemble des points de vue.
a) Diagrammes des cas d'utilisation
Il représente les fonctions du système du point
de vue de l'utilisateur et décrit sous la forme d'actions et de
réactions, le comportement d'un système. Il sert enfin à
structurer les besoins des utilisateurs et les objectifs correspondants du
système. Il faudra ici distinguer les acteurs, les cas d'utilisation et
enfin le diagramme des cas d'utilisation proprement dit.
- Les acteurs
UML parle d'acteur et non d'utilisateur pour décrire
les entités externes qui interagissent avec le système en
envoyant des événement comme par exemple « saisir les
coordonnées géographiques d'un site », « cliquer sur le
bouton Ok » ou encore envoyer un Fichier KML. Les acteurs reçoivent
aussi des informations de la part du système comme par exemple «
affichage d'une carte géographique ». Bref un acteur
représente un rôle que les utilisateurs du futur système
auront à jouer. L'inventaire objectif de tous les potentiels acteurs
d'un système est capital pour le succès de l'interface et donc du
système à produire.
Un acteur sera représenté par le bonhomme suivant
dont l'étiquette devra porter son nom :
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
Figure 13. Un acteur
- Les cas d'utilisation
Les cas d'utilisation représentent les actions possibles
entre un ou plusieurs acteurs avec le
système. Le cas d'utilisation est
représenté par une ellipse, portant en contenu un texte le
décrivant. Un exemple est matérialisé par la figure
ci-dessous :
- Les diagrammes des cas d'utilisation
Lorsque tous les acteurs et tous les cas d'utilisation ont
été inventoriés ainsi que les différentes types de
relations entre eux l'ensemble dans un package forme le diagramme des cas
d'utilisation matérialisé comme indique l'exemple ci-dessous.
Figure 14. Diagramme des cas d'utilisation.
b) Diagramme des séquences
Il se concentre sur la séquence temporelle des
interactions entre les objets. Avec les objets «
acteur » et « système », il permet de
représenter le déroulement des scénarios (instances des
cas d'utilisation).
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
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. Ils
peuvent servir à illustrer un cas d'utilisation. L'ordre d'envoi d'un
message est déterminé par sa position sur l'axe vertical du
diagramme ; le temps s'écoule "de haut en bas" de cet axe.
Dans un souci de simplification, on représente l'acteur
principal à gauche du diagramme, et les acteurs secondaires
éventuels à droite du système. Le but étant de
décrire comment se déroulent les actions entre les acteurs ou
objets.
Remarque : Le diagramme des séquences
peut être représenté en considérant le
système comme une espèce de boite noire lors de la phase
d'analyse. Mais lorsqu'il faudra passer à la conception, il sera
nécessaire d'éclater cette boite noire par des objets
logiciels.
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
Figure 15. Exemple de Diagramme des séquences avec
le système vu comme
une boite noire
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
Figure 16. Exemple de Diagramme des séquences du
point de vue conception
c) Diagramme des activités
Les diagrammes d'activité sont utilisés pour
documenter le déroulement des opérations dans un système,
du niveau stratégique au niveau opérationnel. L'usage
général des diagrammes d'activité permet de faire
apparaître les flots de traitements induits par les processus internes
par rapport aux évènements externes.
Processus
|
Description
|
Symbole représentatif
|
Etat d'activité
|
l'état d'activité marque une action
faite par un objet. Il est représenté par
un rectangle arrondi.
|
|
|
Transition
|
quand un état d'activité est accompli,
le traitement passe à un autre état
d'activité. Les transitions sont utilisées
pour marquer ce passage. Les transitions sont
modélisées par des
flèches
|
|
|
Couloir (Swimlane)
|
Dans un diagramme d'activité,
on peut placer les activités dans des couloirs
(Swimlanes) qui représentent des
systèmes. Les objets sont énumérés au dessus de la
colonne, et les barres verticales séparent les colonnes pour former les
swimlanes.
|
|
|
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
Etat initial
|
l'état initial marque le point
d'entrée la première activité. Il est
représenté, comme dans le diagramme d'état, par un cercle
plein. Il ne peut y avoir qu'un seul état initial sur un diagramme.
|
|
Etat final
|
L'état final marque la fin du déroulement des
opérations modélisées. Il peut y avoir des états
finaux multiples sur un diagramme. Ils sont
représentés par un cercle plein entouré d'un
autre cercle.
|
|
Barre de
|
Souvent, certaines activités
|
|
Synchronisation
|
peuvent être faites en
parallèle. Pour dédoubler le
traitement "Fork", ou le reprendre quand des
activités multiples ont été accomplies
|
|
|
("join"), des barres de
synchronisation sont utilisées.
|
|
|
Celles ci
sont modélisées par des rectangles pleins, avec des
transitions multiples
entrantes ou sortantes.
|
|
Tableau 2 : Description des Scénarios
Uml
Figure 17. Exemple Diagramme des
activités
Paul TATSO Mémoire de Master II IASIG Université
Douala/AUF Novembre 2011
|