CONCLUSION
L'étude préalable appelée techniquement
ingénierie des exigences ou analyse et spécification des besoins,
constitue une phase capitale dans le cas où toute la suite du projet
25
dépend d'elle, elle doit être faite avec beaucoup
de rigueur et plus d'attention pour que le projet réussisse avec un
grand succès.
Dans ce chapitre, on a exposé les problèmes de
la société et de l'existant, puis nous avons fait les critiques
sur la façon actuelle d'archiver les données et enfin on a fait
une approche de solution qui consiste à concevoir et à
développer une application qui facilitera les services
énumérés précédemment.
Après avoir fixé nos objectifs, pour atteindre
notre but on doit suivre plusieurs étapes ces dernières
constituent une partie du cycle de vie de tout projet informatique. Ainsi dans
l'étape suivante on va se consacrer sur le choix des méthodes et
outils de la réalisation.
26
Chapitre III. CONCEPTION
INTRODUCTION
La plupart des nouveaux langages sont orientés objet.
Le passage de la programmation fonctionnelle à l'orienté objet
n'était pas facile. L'un des soucis était d'avoir une idée
globale en avance de ce qu'on doit programmer.
L'algorithmique qui était utilisé dans la
programmation fonctionnelle ne pourrait pas suffire à lui seul. Le
besoin d'avoir des méthodes ou langages pour la modélisation des
langages orientés objet se faisait sentir. Ainsi plusieurs
méthodes ou langages ont vu le jour. En occurrence UML qui nous a permis
de faire la conception de notre application.
UML (Unified Modeling language) se définit comme un
langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier et documenter des
systèmes, esquisser des architectures logicielles, concevoir des
solutions et communiquer des points de vue15.
De nos jours UML2 possède treize diagrammes qui sont
classés en deux catégories: les diagrammes structurels
(dynamique) et les diagrammes comportementaux (statique). L'utilisation de ces
treize diagrammes est laissée à l'appréciation de tout un
chacun selon la méthode choisie, cela, même si le diagramme de
classe est souvent considéré comme le point central dans un
développement orienté objet16.
Nous avons appliqué les principes de la méthode
agile choisie en essayant de modéliser 80% du problème avec
seulement 20% d'UML.
III.1. PRESENTATION DE LA METHODE UTILISEE
Pour l'analyse et la conception du nouveau système,
nous avons fait recours à la démarche ou processus agile dite de
80/20, qui utilise la notation UML, c'est-à-dire modéliser 80% du
problème en utilisant 20% d'UML.
La notion de méthode agile est née à
travers un manifeste signé en 2001 par 17 personnalités du
développement logiciel17. Ce manifeste prône quatre
valeurs fondamentales :
? « Personnes et interactions plutôt que processus
et outils » : dans l'optique agile, l'équipe est bien plus
importante que les moyens matériels ou les procédures.
15 Pascal ROQUES, UML pour le web. P.4
16 Idem, P.5
17 Pascal Roque, op.cit., P.12
27
? « Logiciel fonctionnel plutôt que documentation
complète » : il est vital que l'application fonctionne. Le reste,
et notamment la documentation technique, est secondaire, même si une
documentation succincte et précise est utile comme moyen de
communication.
? « Collaboration avec le client plutôt que la
négociation du contrat » : le client doit être
impliqué dans le développement. On ne peut se contenter de
négocier un contrat au début du projet, puis de négliger
les demandes du client.
? « Réagir au changement plutôt que suivre
un plan » : la planification initiale et la structure du logiciel doivent
être flexibles afin de permettre l'évolution de la demande du
client tout au long du projet.
Cette méthode se situe à mi-chemin entre UP
(Unified Processus «processus unifié»), un cadre
générale très complet des processus de
développement, et XP (eXtreme Programming), une approche minimaliste
centrée sur le code.
Avec cette méthode, nous n'utilisons pas les treize
types de diagrammes proposés par UML 2, mais seulement un tiers, en
insistant particulièrement sur les diagrammes de classes et le diagramme
de séquence. Cette limitation volontaire ne diminue en rien la puissance
de la démarche, mais, elle nous permet une réduction
significative du temps d'apprentissage de la modélisation avec UML, tout
en restant largement suffisante pour une bonne modélisation de notre
système.
Pour ce faire, on va commencer par les diagrammes de cas
d'utilisation (Use Case) qui permet de donner une vue globale de l'application.
Pas seulement pour un client non avisé qui aura l'idée de sa
future application mais aussi le développeur s'en sert pour le
développement des interfaces.
En deuxième lieu on va présenter la chronologie
des opérations par les diagrammes de séquences.
Et finir par les diagrammes statiques, qui sont celles de
classe de conception, de classe participantes et le modèle physique.
| 
