Conception et développement d'un site web dynamique dans une société d'électricité, cas de la SNEL/NK

III.4. CHOIX DE SOLUTION ENVISAGEE

Au regard des avantages et inconvénients des deux systèmes (manuel et informatique), nous pensons que le système informatique est mieux indiqué pour le paiement des factures du courant électrique pour la SNEL/DPNK, car l'inconvénient évoqué peut être contourné.

Vu la complexité et le volume de l'information a traitée nous leur proposons aussi une solution informatique qui peut les aider à améliorer leurs travail, cette solution est fiable, car elle tient compte de l'intérêt général, présentant plus d'avantage par rapport aux autres. Le type de système informatique adopté a cette situation est un système informatique qui s'effectue au niveau de chaque poste de travail, les ordinateurs sont indépendants les uns des autres donc ne sont pas en réseau informatique.

Ainsi nous opterons pour la solution automatique ou informatique et en temps réel pour des raisons suivantes :

· La prise en charge par la machine (ordinateur) tous les traitements afin d'éviter les erreurs et fournir les résultats fiables dans un bref délai à l'intérieur du pays comme à l'extérieur du pays ;

· Accéder aux données à l'intérieur du pays ou à l'extérieur du pays ;

· Les énormes avantages et procédures beaucoup plus satisfaisants.

CONCLUSION

Par la technique d'ingénierie des exigences ou d'analyse et de spécification des besoins constituent une phase capitale dans le cas où toute la suite du projet dépend d'elle, elle doit être faite avec beaucoup de rigueur et plus d'attention pour que le projet soit fiable pour tous.

QUATRIEME CHAPITRE : LA MODELISATION du projet

IV.1. PRESENTATION DE LA METHODE UML

IV.1.1. INTRODUCTION

Il est évident que les méthodes et les outils choisis pour concevoir et développer une application doivent être en fonction de l'environnement et du domaine d'application de celle-ci. Cela est bien expliqué par le génie logiciel.

L'informatisation est le phénomène le plus important de notre époque. Elle s'immisce maintenant dans la plus part des objets de la vie courante et ce, que ce soit dans l'objet proprement dit (Par exemple, aujourd'hui, 90% des nouvelles fonctionnalités des automobiles sont apportées par l'électronique et l'informatique embarquées. Il y a, ou aura à terme, du logiciel partout : ampoules, four à micro ondes, tissus des vêtements, stylos et livres, etc.), ou bien dans les processus de conception ou de fabrication de cet objet. ^19(*)

IV.1.2. GENESE DE LA METHODE UML

 UML (Unified Modeling Language, traduisez "langage de modélisation objet unifié") est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT (Object Modeling Technique), Booch et OOSE (Object Oriented Software Engineering).
Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement^20(*).

En l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable. La presse spécialisée foisonne d'articles exaltés et à en croire certains, utiliser les technologies objet sans UML relève de l'hérésie. Lorsqu'on possède un esprit un tant soit peu critique, on est en droit de s'interroger sur les raisons qui expliquent un engouement si soudain et massif ! UML est-il révolutionnaire?

L'approche objet est pourtant loin d'être une idée récente. Simula, premier langage de programmation à implémenter le concept de type abstrait à l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers compilateurs C++ date du début des années 80 et de nombreux langages orientés objets "académiques" ont étayés les concepts objets (Eiffel, Objective C, Loops...).

Il y donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer "objet", c'est bénéficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasi-automatique dès lors qu'on cherche à concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes.

Oui, mais... Tout n'est pas si rose. Beaucoup on cédé aux sirènes de l'orienté objet et leur aveuglement a fait couler bien des projets... ^21(*)

C'est ainsi que, l'unification progressant par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d'accord pour la construction d'une méthode unifiée, Unified Method 0.8^22(*) ;

En 1996, Jacobson les rejoignant pour produire UML 0.9 (notez le remplacement du mot méthode par le mot langage, plus modeste). Les acteurs les plus important dans le monde du logiciel s'associent alors à l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis à l'OMG (Object Management Group) qui adoptant UML1.1 comme langage de modélisation des systèmes d'information à objets en Novembre 1997.

Signalons que la version en cours est UML 2.0 dès la fin 2006 et les travaux d'amélioration se poursuivent^23(*).

UML est donc non seulement un outil intéressant mais une norme qui s'impose en technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine, acteurs qui ont d'ailleurs contribué à son élaboration^24(*).

* ¹⁹ Laurent AUDIBERT, op.cit, P.11

* ²⁰ Laurent AUDIBERT, cours d'UML 2.0, IUT. Tiré du site http://www-lipn.univ-paris13.fr/audibert/pages/enseignement/cours.htm , consulté le 12 février 2009.

* ²¹ http://www.msn.fr consulté le 16/08/2010

* ²² Idem

* ²³ Laurent AUDIBERT, Ibidem

* ²⁴ Laurent AUDIBERT, Idem