|
Développement d'une application web pour l'optimisation du processus d'archivage et d'accès aux données d'une entreprise (cas de Bell equipement)( Télécharger le fichier original )par Freddy ILUNGA KADIATA Université Protestante de Lubumbashi (UPL) - Graduat 2015 |
CONCLUSIONL'é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. CONCEPTIONINTRODUCTIONLa 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 UTILISEEPour 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. III.2. CAPTURE DES BESOINS Avant la modélisation de notre système, il est important de capturer les besoins de l'utilisateur qui sont émis en termes des fonctionnalités du futur système. Le futur système devra permettre aux utilisateurs d'effectuer les actions suivantes : - enregistrer les archives 28 - rechercher des archives - centraliser les archives - consulter les archives - générer des rapports périodiques III.3. DIAGRAMME DE CAS D'UTILISATION Le diagramme de cas d'utilisation fait partie des diagrammes comportementaux d'UML. Les cas d'utilisations constituent un moyen de recueillir et de décrire les spécifications et les exigences des acteurs ou les besoins des acteurs du système. La représentation d'un cas d'utilisation met en jeu trois concepts : l'acteur, le cas d'utilisation et l'interaction entre l'acteur et le cas d'utilisation. Il convient pour nous d'expliquer d'abord ces concepts avant de poursuivre : ? Acteur : Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié18. Un acteur peut consulter et/ou modifier directement l'état du système, en émettant et/ou en recevant des messages susceptibles d'être porteurs de données. ? Cas d'utilisation : Un cas d'utilisation (use case) représente un ensemble de séquences d'actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier19. Un cas d'utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système. ? Interaction : une interaction permet de décrire les échanges entre un acteur et un cas d'utilisation. Elle signifie simplement «participe à». Dans cette partie nous verrons comment structurer, relier et classer ces cas d'utilisation ainsi que les représentations graphiques UML associées. Nous aborderons enfin l'impact de cette étude sur la planification du système à mettre en place. Suivant les besoins de notre système on peut présenter deux acteurs. Il s'agit de l'archiviste, du département de finance. La manière d'accéder aux services de l'application pour 18 Pascal Roque, op.cit., P.41 19 19 Pascal Roque, op.cit., P.42 archivé. 29 les uns et les autres est la même. La différence réside sur les droits d'accès et les limites de chacun.
Figure 7 : Diagramme de cas d'utilisation Description textuelle Archiver document Acteur principale : Archiviste ? Objectifs : L'archiviste veut archiver un document qu'il reçoit. ? Précondition ? L'archiviste doit recevoir un document venant de l'administration ? L'archiviste doit s'authentifier avec succès ? Post conditions ? Nouveau document archivé ? Document classé ? Scénario nominal
30 Alternative 1. a. L'archiviste constate le manque de certaines informations sur le document :
Gérer archive Acteur principal : Archiviste ? Objectif : L'archiviste peut vouloir générer des rapports, modifier certains droits d'accès sur les archives, voir l'évolution du trafic, modifier ou supprimer une archive. ? Précondition ? Au moins une archive doit être disponible ? L'archiviste doit s'authentifié avec succès ? Post condition Le rapport a été généré/ l'archive a été modifié/ l'archive a été supprimé/ les droits d'accès ont été modifiés/ l'archiviste a vu l'évolution du trafic. ? Scénarios nominal
télécharger. 31 b. «modifier archive»
c. «voir l'évolution ou modifier les droit d'accès »
Alternative 1. b. l'archiviste saisie des données erronées, le système renvoi un message d'échec. 2. c. l'archiviste modifie les droits d'accès d'un archive utilisé, le système lui signifie que l'archive est ouvert et qu'il est impossible de le modifie. Consulter Archive Acteur principal : Administration Acteur secondaire : Archiviste ? Objectif : l'administration veulent disposer d'un document qui a été archive. ? Précondition ? Au moins une archive disponible ? L'administration doit s'authentifier avec succès ? Post conditions ? Archive consulté ? Aucun Résultat ? Scénarios nominal
32 5. Le service de finance ouvre l'archive téléchargé Alternative 3 .a. Le système n'a pas trouvé l'archive correspondant à la recherche : 1. le affiche le message aucun archive trouver et lui propose d'effectuer une nouvelle recherche. III.4. DIAGRAMMES DE SEQUENCE SYSTEME Il s'agit d'une explication détaillée d'un cas d'utilisation. Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique. 33 Authentification :
Figure 8: diagramme de séquence « Authentification » Archiver document :
Figure 9:diagramme de séquence « Archiver document » 34 Consulter archive :
Figure 10: diagramme de séquence « consulter archive » 35 Gérer archive :
Figure 11: diagramme de séquence « gérer archive » III.5. DIAGRAMMES DE CLASSES Précédemment nous avons parlé de deux grandes catégories de diagrammes UML (statique et dynamique), l'un des diagrammes statique nous intéresse beaucoup pour pouvoir implémenter le code, il s'agit du diagramme des classes. Ce modèle nous permet d'avoir une vue statique de l'application. Il nous montre les relations entre les différentes entités (classes), composant de notre application. Il nous mène vers la solution finale. À partir de ce diagramme on retrouve les corps de différentes classes de notre application. Mieux encore en utilisant la technique de la retro-ingénierie (voir Annexe 3) on obtient une grande partie du code finale. Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d'une telle modélisation20. 20 Laurent AUDIBERT, op.cit., P.35 36 Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d'utilisation. Il s'agit d'une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation Orienté Objets donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier. III.5.1. MODELE DU DOMAINE C'est un diagramme de classes dépourvu de ses méthodes. Il correspond à la sémantique des données sur lesquelles reposent tous les traitements du domaine. Il s'agit simplement de créer une représentation visuelle des objets du monde réel dans un domaine donné. Si l'on emploie la notation UML, il s'agit d'un ensemble de diagrammes de classes dans lesquels on fait figurer les éléments suivants :
A partir des éléments décrits dans le chapitre précédent, nous pouvons établir notre modèle du domaine comme suite: 37
Figure 12 : Modèle du domaine III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES Le diagramme de classes participantes est important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation, le modèle du domaine et la maquette IHM, et d'autre part, la jonction entre, les diagrammes de conception logiciel que sont : les diagrammes d'interaction et les diagrammes de classes de conception. Il s'agit ici de diagrammes de classes UML qui décrivent, cas d'utilisation par cas d'utilisation, les trois principales classes d'analyse et leurs relations. Le diagramme de classe participante modélise trois types de classes d'analyse : les dialogues, les contrôles et les entités. ? Les classes de dialogues : ces sont des classes qui possèdent les attributs et les méthodes ; ou les attributs représentent les champs de saisi ou les résultats et les opérations représentent les actions de l'utilisateur sur l'IHM. ? Les classes d'entités : elles ne posséderont que les attributs, les attributs qui sont des informations persistantes de l'application c'est-à-dire qu'elles survivent à l'exécution d'un cas d'utilisation particulier et qu'elles permettent à des données et des relations d'être stockées dans des sources de données. ? Les classes de contrôles : celles qui vont posséder des opérations, Ces opérations montrent la logique de l'application, ou les comportements du système informatique. Elles jouent le pont entre les classes de dialogues et les classe de contrôles. 38
Figure 14 : Diagramme de classe participante Archiver document 39 c. Cas d'utilisation Gérer Archives
Figure 15: Diagramme de classe participante Gérer Archive III.6. CONCEPTION OBJET PRELIMINAIRE Nous allons attribuer des responsabilités précises de comportement aux classes d'analyse en construisant une vue statique complétée sous forme de diagrammes de classes de conception préliminaire, indépendamment des choix technologiques que nous avons choisis. La conception préliminaire nous a permis d'affiner et compléter les diagrammes de classes participantes obtenus précédemment pour :
III.6.1. DIAGRAMME D'INTERACTION L'expression diagramme d'interactions englobe principalement deux types de diagrammes UML spécialisés, qui peuvent servir tous les deux à exprimer des interactions de messages similaires : ? les diagrammes de communication ? les diagrammes de séquence. 40 Pour le cas de notre travail nous ne représenterons qu'un certains nombres de diagramme d'interaction par acteur ou par scenario nominale. ? Diagramme d'interaction des cas d'utilisations du service de finance Consulter archive
Figure 16 : Diagramme de séquence du scénario nominale recherche rapide
Figure 17: Diagramme de séquence scénario Erreur de recherche 41
Figure 18:Diagramme de séquence de la suite du scenario nominale de recherche rapide ? Diagramme d'interaction des cas d'utilisations de l'archiviste Archiver Document
Figure 19: Diagramme de séquence du scenario nominale Archivage avec succès 42 III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION PRELIMINAIRE
Figure 21: Diagramme de classe de conception Archiver nouveau document 43 c. Cas d'utilisation Gérer Archive
Figure 22: Diagramme de classe de conception Gérer Archive III.7. MODELE PHYSIQUE DES DONNEES Ce modèle nous permet d'avoir une idée sur les tables qui composent notre base. Evidemment il y'a des règles qui permettent de passer d'un modèle à un autre (voir Annexe 2). Le MPD (Modèle physique de données) est un autre raffinement qui vise à produire un MLD pour un SGBD spécifique. Nous avons utilisé l'outil MySQL Workbench pour produire ce modèle. 44
Figure 23: Modèle physique des données III.8. METHODES ET OUTILS POUR L'APPLICATION 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 explique par le génie logiciel. Comme nous l'avons dit tout au-dessus, nous allons mettre l'accent sur les avantages de l'approche orienté objet, les architectures n-tiers. Tous ces concepts nous ont guidés dans la réalisation de notre travail et sur les méthodes et outils appliqués. III.8.1. DEFINITION ET AVANTAGE DE L'APPROCHE ORIENTEE OBJET Ce concept de programmation orienté objet (POO), est un paradigme de la programmation élaborer par les Norvégiens Ole-Johan et Kristen Nygaard au début des années 1960. Il consiste en la définition et l'interaction de brique logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une 45 personne ou encore une page d'un livre. Il possède une structure interne, et un comportement, et il sait interagir avec ses pairs21. Parmi les avantages de cette approche, on peut citer : la possibilité de concevoir par objet une application informatique sans pour autant utiliser des outils dédiés, il facilite beaucoup dans la conception, la maintenance, la réutilisabilité des éléments (objets), l'avantage d'utiliser un objet de base afin de produire un autre qui peut être une amélioration de cet objet (phénomène d'héritage), etc. L'objet est le coeur de cette approche. Tout objet donné possède deux caractéristiques : - Son état courant (attributs) - Son comportement (méthodes) En approche orienté objet on utilise le concept de classe, celle-ci permet de regrouper des objets de même nature. Une classe est un module (prototype) qui permet de définir les attributs (champs) et les méthodes (comportement) à tous les objets de cette classe. III.8.2. CHOIX DU PRINCIPE ET DU LOGICIEL DE MODELISATION Merise et UML sont deux grands principes de « traduction » ou modélisation d'un système d'information. Néanmoins, ils ne sont pas aussi proches qu'on pourrait le penser. Le choix de l'un ou de l'autre se fait selon trois axes à savoir l'accessibilité, la précision et l'exploitabilité. Pour le premier axe (accessibilité) MERISE présente l'intérêt d'avoir des modèles logiques moins détaillés facilement compréhensibles par un utilisateur moins avisé. Tandis qu'UML conçu pour s'adapter à n'importe quel langage de programmation orientée objet (POO), présente plusieurs modèles (diagrammes) dont leurs compréhensions nécessitent une grande attention. En ce qui concerne le deuxième critère (précision), MERISE est décevant. Malgré sa clarté, il manque une précision du fait qu'elle est éloignée du langage, donc difficile à implémenter alors qu'UML intègre les éléments communs des différents langages, sa volonté 21 http//:ww.wikipedia.org/approche oriente objet 46 est d'être fidèle à la réalisation finale. Elle est beaucoup plus complète avec ses différents diagrammes. Pour en finir avec l'exploitabilité, MERISE est une méthode plus généraliste. Elle donne une vue globale de la solution sans autant rentrer dans les petits détails. Contrairement à UML qui est conçu pour l'implémentation objet avec ses différents détails et sa portabilité (s'adapte à n'importe quelle plateforme) elle est donc plus exploitable. L'une ou l'autre présente des avantages et des inconvénients. Il est réservé au concepteur de choisir la méthode la mieux adaptée pour son cas. Si on cherche la précision et l'exploitabilité comme dans notre cas UML devance de loin MERISE. Tandis que, si c'est la clarté et l'accessibilité qui sont en question MERISE est préférable. La conception de notre application mérite bien une grande précision et une exploitabilité maximale. C'est la raison pour laquelle on va retenir UML. Les différences entres les logiciels de modélisation UML sont infimes. N'empêche de mentionner quelques logiciels qui sont à notre connaissance : Modelio (open source), Visual Paradigme, PACESTAR Software. La facilité dotée au dernier (PACESTAR) de pouvoir faire des diagrammes en UML 2.0, sa rapidité et sa flexibilité sont des facteurs qui nous ont permis de l'utilisé comme logiciel de modélisation. III.8.3. CHOIX DES OUTILS DE DEVELOPPEMENT Un parmi les avantages qui nous ont permis de choisir UML comme méthode de modélisation est l'orienté objet. Cette approche influe aussi sur le choix du langage à adopter on peut rajouter quelques-uns à savoir la portabilité, la facilité, la multidisciplinarité et pas mal d'autres comme la sécurité. III.8.3.1 CHOIX DU LANGAGE DE PROGRAMMATION Dans le souci de concevoir une application web, nous avons choisi PHP comme langage d'implémentation de notre application. Apparu en 1994, PHP est un langage de programmation libre principalement utilisé pour produire des pages Web dynamiques via un serveur http, mais pouvant fonctionner comme n'importe quel langage interprété de façon 47 locale22. Le PHP propose plusieurs avantages, dont nous pouvons en citer quelques qui nous ont poussés de porter le choix sur lui: ? Le faite que c'est un langage orienté objet comme le C++, le C# ou le Java ? C'est un langage peut typer et souple avec une grande facilité d'apprentissage ? Il est multi plate-forme ? PHP est un langage Serveur Pour concevoir notre application web, nous avons utilisé le langage HTML pour la présentation des pages web, la CSS pour la mise en forme des pages web et JavaScript qui est lui un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs. III.8.3.2. CHOIX DE L'OUTIL DE DEVELOPPEMENT Pour réaliser une application web, plusieurs outils sont disponibles et la plus part d'entre elles sont gratuites. Nous avons choisis le duo PHP MySQL, ce sont deux outils qui ont fait leurs preuves dans le domaine de la conception d'application web. Pour développer une application web, certains programmes nous ont été indispensables : ? Un éditeur de texte : on a opté pour l'éditeur Sublime Texte. ? Un navigateur web : qui nous permettait de tester l'application et de le manipuler. Dans notre cas nous avons choisi Google Chrome comme navigateur web. Pour que notre ordinateur puisse lire du PHP et se comporter comme un serveur, nous avons eu besoin d'autres programmes supplémentaires comme Apache, PHP et MySQL. ? Apache : qui est un serveur web, son rôle est charger et délivrer les pages web à l'utilisateur. Apache ne gère que des pages web statiques (HTML), il faut donc le compléter aussi avec d'autres programmes. ? PHP : qui est un plug-in pour Apache qui le rend capable de traiter des pages web dynamiques en PHP. En claire la combinaison d'Apache et PHP permet à un ordinateur de lire les pages web en PHP. ? MySQL : qui est un logiciel de gestion de base des données, il permet d'enregistrer les données de manière organisée. c'est un système de gestion de base des 22 www.wikipedia.org/langage PHP/ en ligne, consulter le 10 Juillet 2015 48 données relationnelles (SGBDR) et il est disponible sur une double licence GPL et propriétaire, il utilise le langage de requête SQL pour l'accès aux données. Il existe un «Packs» tous près qui contient ces trois éléments tous réunis, c'est Wamp Server pour Windows bien qu'il en existe plusieurs, nous avons choisi celui-ci car il offre l'avantage d'être en français et a la possibilité d'être régulièrement mis à jour. III.8.4. ARCHITECTURE DE L'APPLICATION Dans les phases préliminaires du développement d'une application ou de la refonte d'un système d'information, la définition de l'architecture technique consiste à faire les choix de technologies et d'organisation de composants logiciels les plus adaptés aux besoins et aux contraintes de l'organisation d'accueil. Ces choix sont ensuite relayés au sein de notre projet, guidant la conception et permettant la transformation d'un modèle fonctionnel en application performante et robuste. ? Présentation de l'architecture à 2 niveaux L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tiers signifiant étages en anglais) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le service
Figure 24: Architecture 2 tiers (Source : www.google.com/images/deuxtiers.png) 49 ? Présentation de l'architecture à 3 niveaux Dans l'architecture à 3 niveaux (appelées architecture 3-tiers), il existe un niveau intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre:
Figure 25: Architecture 3 tiers (Source : www.google.com/images/troistiers.png) Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes des autres: on peut ainsi vouloir modifier la présentation sans modifier la logique applicative. La conception de chaque partie doit également être indépendante, toutefois la conception de la couche la plus basse est utilisée dans la couche d'au-dessus. Ainsi la conception de la logique applicative se base sur le modèle de données, alors que la conception de la présentation dépend de la logique applicative. ? Architecture adoptée Vis-à-vis de l'existant chez Bell Equipement: organisation, compétences, architecture du système d'information, nous avons choisi l'architecture 3 tiers car c'est une architecture: 50
L'application web conçu sera déployée sur une architecture 3-tiers. Cette architecture peut être décrite par la figure ci-dessous :
Figure 26: Architecture 3 tiers (Source : www.google.com/images/troisiers.png) |
|
){kind=link}
){kind=link}
){kind=link}