CHAPITRE DEUXIEME:
METHODOLOGIES ET TECHNIQUES DU TRAVAIL
Cette section du travail est consacrée à
l'étude des méthodes qui seront utilisées, nous allons
procéder à la modélisation de notre système. Par la
modélisation, nous créerons un modèle qui est construit
pour quelque chose (notre système) car il est facile à comprendre
que la chose physique elle-même. A plus de la modélisation et de
la simulation, nous allons également procéder au prototypage et
terminer par l'expérimentation dans notre laboratoire.
II.1 La modélisation
La modélisation est une représentation formelle
d'un phénomène. Formellement, nous allons utiliser des diagrammes
pour créer notre modèle comme les diagrammes en UML. Notre
modèle ne contiendra que les aspects essentiels et pertinents du
problème de notre recherche.
Plusieurs techniques peuvent nous aider dans la
modélisation, la MERISE définit par ROMAIN BARTOLO comme
étant une méthode d'analyse et de conception structurelle qui a
vu jour en 1978 et qui est très rependue en France. C'est une technique
qui vise à remplacer un système manuel d'une organisation par un
système automatisé du traitement de l'information, et tant
d'autres techniques. Malheureusement cette technique n'est pas orienté
objet, raison pour laquelle a ce qui concerne notre travail de recherche, nous
ferons recours a une celle qui est orienté objet, l'UML (Unified
Modeling Language), adopté et standardisé par l'Object Management
Group depuis 1997, UML est aujourd'hui un outil de communication
incontournable, utilisé sur des centaines de projets de par le monde ;
en conséquence, la connaissance d'UML est désormais une des
compétences qui sont exigées quasi systématiquement lors
d'un recrutement. Pourtant, trop nombreux sont encore les concepteurs qui
s'imaginent, à tort, posséder cette compétence parce
qu'ils connaissent la représentation graphique d'une classe
d'association, d'une activité ou d'un état, tandis qu'ils ne
savent pas expliquer ni défendre leur emploi dans un modèle,
même simple. C'est que, malgré la rigueur apportée à
la spécification d'UML, il y a parfois différentes façons
de représenter une même idée, ou, à l'inverse, une
idée donnée pourra être représentée avec plus
ou moins de précision selon que l'on aura utilisé telle ou telle
particularité syntaxique d'UML. (Pascal Roques 2005)
18
Pour ne pas mélanger les problèmes, cette
section est découpée suivant les trois points de vue classiques
de modélisation : fonctionnel, statique et dynamique, en insistant pour
chacun sur le ou les diagrammes UML prépondérants mais qui seront
plus détaillés de façon concrète pour notre
système dans le chapitre suivant.
Figure no5: Axes de l'UML
· Du point de vue fonctionnel :
Après avoir identifié les acteurs qui interagissent avec
le système, nous y développons un premier modèle UML de
haut niveau, pour pouvoir établir précisément les
frontières du système. Dans cette optique, nous allons identifier
les cas d'utilisation et construire un diagramme reliant les acteurs et les cas
d'utilisation de notre système. Ensuite, nous préciserons le
point de vue fonctionnel en détaillant les différentes
façons dont les acteurs peuvent utiliser le système. À cet
effet, nous allons rédiger des descriptions textuelles de cas
d'utilisation, ainsi que dessiner des diagrammes UML complémentaires
(comme les diagrammes de séquence ou d'activité).
19
Les cas d'utilisation
Comme l'affirme Grislin(2008), nos cas d'utilisation
décrivent les fonctionnalités fournies par le
système à nos acteurs. Le modèle de notre
système du point de vue de son utilisation, présentera
des fonctionnalités qui répondront à ces
questions:
Que devrait faire notre système ?
- Présenter les interactions entre le système et
nos acteurs
- Présenter les réactions du système aux
événements extérieurs
Les cas d'utilisation définiront :
Les limites du système (interne au système/
externe)
Le comportement attendu du système
Pour chaque acteur interagissant avec notre système,
nous spécifierons: Quels sont les services attendus ?
Dans quel cas l'acteur utilise le système ?
En sachant que le service = fonctionnalités Service
? action !!!! Représentation par :
· cas sur le diagramme
· liens acteurs-cas
· du texte
· Du point de vue statique : Le
diagramme de classes a toujours été le diagramme le plus
important dans toutes les méthodes orientées objet. C'est celui
que les outils de génération automatique de code utilisent en
priorité. C'est également celui qui contient la plus grande gamme
de notations et de variantes, d'où la difficulté d'utiliser
correctement tous ces concepts. Dans le chapitre suivant, nous allons:
· Identifier les concepts du domaine et les
modéliser en tant que classes,
· Identifier les associations pertinentes entre les
concepts,
· Réfléchir aux multiplicités
à chaque extrémité d'association,
· Ajouter des attributs aux classes du domaine.
20
· Du point de vue dynamique : En
commençant par identifier les acteurs et les cas d'utilisation, nous
dessinerons tout d'abord un diagramme de séquence « système
». Puis, nous réaliserons un diagramme de communication particulier
(que nous appellerons diagramme de contexte dynamique) afin de
répertorier tous les messages que les acteurs peuvent envoyer au
système et recevoir. Après ce travail préliminaire, nous
nous embarquerons dans une description en profondeur de la dynamique
souhaitée du système. Nous insisterons tout
particulièrement sur le diagramme d'états qui est à notre
avis trop souvent sous employé, alors que c'est un diagramme
extrêmement utile pour décrire avec précision des
comportements complexes, et ce dès l'analyse. UML a repris le concept
bien connu de machine à états finis, qui consiste
à s'intéresser au cycle de vie d'une instance
générique d'une classe particulière au fil de ses
interactions avec le reste du monde, dans tous les cas possibles. Cette vue
locale d'un objet, qui décrit comment il réagit à des
événements en fonction de son état courant et comment il
passe dans un nouvel état, est représentée graphiquement
sous la forme d'un diagramme d'états
| 
