Plan : - Glossip | Plus besoin de chercher … · Web viewPour installer la base de données dans le serveur qui contiendra notre application, il suffit d’importer le scripts précédemment

Rapport de projet de fin d’année :

Royaume du MarocUniversité Mohammed V - Souissi

Ecole Nationale Supérieure d’Informatique et d’Analyse des

Systèmes - E.N.S.I.A.S.

Application de gestion financière

d’un établissement universitaire

Réalisé par :

Abdelouahid BenlamlihOmar Haji

Encadré par :

M. Ismail Kassou

Sommaire

Sommaire

SOMMAIRE........................................................................................................................................................- 2 -

TABLE DES FIGURES....................................................................................................................................- 1 -

INTRODUCTION...............................................................................................................................................- 2 -

1. CHAPITRE 1 : CONTEXTE DU PROJET...........................................................................................- 3 -

1.1. CAPTURE DES BESOINS...................................................................................................................- 4 -1.1.1. Présentation du contexte du projet..................................................................................- 4 -1.1.2. Périmètre du projet................................................................................................................- 4 -1.1.3. Besoins.....................................................................................................................................- 5 -1.1.4. Objectif du projet...................................................................................................................- 5 -

1.2. CAHIER DES CHARGES.....................................................................................................................- 5 -1.3. PLANIFICATION DES TACHES...........................................................................................................- 6 -

2. CHAPITRE 2 : ANALYSE ET CONCEPTION.................................................................................- 7 -

2.1. MODÈLE EN CASCADE......................................................................................................................- 8 -2.2. DÉMARCHE DE MODÉLISATION : UML............................................................................................- 9 -2.2.1. INTRODUCTION.............................................................................................................................- 9 -2.2.2. MISE EN ŒUVRE D’UML.............................................................................................................- 9 -

2.2.2.2. Diagramme de classes.......................................................................................................- 10 -2.2.2.3. Diagramme d’objets............................................................................................................- 11 -2.2.2.4. Diagramme d’états-transitions.........................................................................................- 11 -2.2.2.5. Diagramme d’activités........................................................................................................- 11 -

2.3. IDENTIFICATION DES CAS D’UTILISATION......................................................................................- 12 -2.4. SCÉNARIOS DES PRINCIPAUX CAS D’UTILISATION........................................................................- 14 -2.5. DIAGRAMMES DE SÉQUENCES.......................................................................................................- 15 -2.6. DIAGRAMMES DE CLASSES............................................................................................................- 17 -2.7. LIMITATIONS DE LA CONCEPTION..................................................................................................- 17 -

3. CHAPITRE 3 : RÉALISATION............................................................................................................- 18 -

3.1. TECHNOLOGIES UTILISÉES............................................................................................................- 19 -3.1.1. J2EE : présentation.............................................................................................................- 19 -3.1.2. Le modèle MVC........................................................................................................................- 19 -3.1.3. La démarche de développement STRUTS...............................................................................- 21 -3.1.4. Apache Tomcat.........................................................................................................................- 23 -3.1.5. les pages JSP............................................................................................................................- 24 -3.1.6. Mysql........................................................................................................................................- 24 -

3.2. PRÉSENTATION DE QUELQUES INTERFACES.................................................................................- 25 -

4. CHAPITRE 4 : DÉPLOIEMENT..........................................................................................................- 28 -

4.1. DÉPLOIEMENT DE LA BASE DE DONNÉES......................................................................................- 28 -4.2. DÉPLOIEMENT DE L’APPLICATION................................................................................................- 28 -

CONCLUSION.................................................................................................................................................- 29 -

Webographie....................................................................................................................................................- 30 -

2

Année universitaire 2006/2007

Sommaire

3

Tables des figures

Table des figures

FIGURE 1 : DIAGRAMME DE GANTT.........................................................................................- 6 -

FIGURE 2 : CYCLE DE VIE EN CASCADE...................................................................................- 8 -

FIGURE 3: DIAGRAMME DE CAS D'UTILISATION......................................................................- 12 -

FIGURE 4: DIAGRAMME DE SÉQUENCE, CONSULTATION D'UN BON DE COMMANDE.................- 15 -

FIGURE 5: DIAGRAMME DE SÉQUENCE, CONSULTATION D'ETATS...........................................- 16 -

FIGURE 6 : DIAGRAMME DE SÉQUENCE, AJOUT D'UN BON DE COMMANDE............................- 16 -

FIGURE 7 : DIAGRAMME DE CLASSES.....................................................................................- 17 -

FIGURE 8 : ARCHITECTURE DU MODÈLE MVC......................................................................- 19 -

FIGURE 9 : MODÈLE MVC....................................................................................................- 20 -

FIGURE 10 : ARCHITECTURE STRUTS...................................................................................- 21 -

FIGURE 11 : AUTHENTIFICATION...........................................................................................- 25 -

FIGURE 12 : MENU D'ACCUEIL..............................................................................................- 25 -

FIGURE 13 : DÉTAILS DES PROGRAMMES D'EMPLO................................................................- 26 -

FIGURE 14 : GESTION DES PRODUITS ET SERVICES................................................................- 26 -

FIGURE 15 : LISTE DES PROGRAMME D'EMPLOI.....................................................................- 27 -

Figure 16 : liste des devis....................................................................................................- 27 -

Introduction

Introduction

La gestion financière d’un établissement universitaire subit plusieurs contraintes et règles pour assurer la transparence, la traçabilité des opérations et mouvements de comptes. Cette discipline incorpore divers modules de gestion de budget, de stocks, de personnel et gestion de projets, d’où l’importance et la taille d’un projet de développement d’une solution de gestion financière. Sa particularité est que la plus grande partie des recettes financières viennent directement sous formes de budget de l’état, ce qui impose un double contrôle en aval et en amont à chaque mouvement d’argent, dépense ou engagement. En plus des recettes de l’état, l’université tire profit des différentes formations, projets qu’elle accueille au sein de ses établissements.

Dans le cadre du projet de fin de la deuxième année, nous avons développés la partie de l’application de gestion financière qui s’occupe de la gestion des programmes d’emploi. Notre partie s’occupe des différents programmes d’emploi des recettes d’un établissement universitaire, elle assure le suivi, l’archivage des différents mouvements de dépense et peut présenter un rapport de la situation. Les diverses informations sont saisies par un utilisateur. Lors de chaque opération, il devra saisir les différentes informations relatives aux différentes formes que prennent les dépenses. A tout moment, les différents comptes doivent être équilibrés et toute dépense ou engagement d’argent sera justifié par l’application.

Dans le présent rapport, nous décrivons en détail les différentes étapes de développement du projet. Dans le premier chapitre, nous décrivons les détails et le contexte du projet, les besoins auxquels la solution doit répondre, nous établissons un cahier des charges qui formule les spécifications des besoins, et enfin nous présenterons la planification des tâches et leur déroulement durant toute la période de notre projet de fin d’année. Dans le chapitre suivant, on analyse les entités du projet, les différents cas d’utilisation et scenarii modélisés par le langage UML et qui nous amènerons à la conception d’un modèle de données sur lequel est basée l’application. Enfin dans le dernier chapitre, nous présentons et justifions nos choix technologiques de développement, puis nous terminons par quelques captures d’écran présentant les principales interfaces et scénarios d’utilisation.

2

Introduction

3

Chapitre 1 : Contexte du projet

1.Chapitre 1 : Contexte du projet

4


1.1. Capture des besoins

1.1.1. Présentation du contexte du projet

Dans un établissement universitaire, un grand nombre d’opérations est effectués dans le cadre de projets scientifiques, formations ou bien simplement d’entretien de l’établissement et rémunération du personnel. Ces opérations génèrent un abondant flux d’opérations financières, de mouvements de comptes et changements de crédit des différents budgets. Avec les différentes formes que peuvent prendre les recettes (budget de l’état, formations, projets…) et les dépenses (marché, bon de commande, régie...), la gestion financière et l’archivage des mouvements et leurs justificatifs devient très complexe.

Il devient compliqué alors d’avoir des états sur la situation financière lors d’établissement du budget annuel ou encore la consultation des budgets précédents. Le contrôle de performance d’une telle gestion est ainsi lésé par la délicatesse de gestion et d’extraction de l’information en temps voulu.

Notre application va devoir faciliter la saisie d’information. Les données relatives aux différentes formes de dépenses (Marché, Régie, Bon de commande, Frais de remboursement) seront stockées dans une base de données. Ces informations là pourront être consultées pour usage ultérieur ou modifiées si besoin est.

1.1.2. Périmètre du projet

Une application de gestion financière incorpore plusieurs modules de gestion budgétaire, comptable, de stock, de personnel et de projets. La taille d’une telle application devient alors très grande et nécessite des compétences et un temps considérable de développement.

Dans le cadre de notre projet de fin d’année, nous nous limiterons à la gestion de programme d’emploi, une sorte de mini budget qui repartie les recettes d’un projet mené à l’école selon différentes rubriques. Ainsi nous avons géré 4 formes que peuvent prendre les dépenses dans ce genre de budget : « Bon de commande », « Appel d’offre et marché », « Régie » pour l’argent liquide, et autres « Remboursement de frais » (frais de mission, repas ou services …)

5


1.1.3. Besoins

A travers nos réunions avec notre professeur encadrant et qui s’avèrent l’utilisateur potentiel direct de l’application nous avons pu recueillir et capturer les différents besoins tout en limitant le diamètre du projet :

Besoin d’informations : avoir instantanément l’état financiers des différents programmes d’emploi pour l’établissement d’un nouveau programme d’emploi ;

Génération de formulaire : générer des formulaires pré remplis avec les différentes informations recueillies par l’application pour être signé (ordre de paiement de paiement, bon de commande …) ;

Mesure de l’efficacité des procédures : pouvoir mesurer combien prend de temps le traitement d’un document depuis sa création jusqu'à sa validation par les responsables et l’université.

1.1.4. Objectif du projet

Notre projet vise à assurer en premier lieu le suivi des différents Programmes d’emploi, et assurer l’archivage de leurs mouvements de dépenses. Ainsi, chaque dépense devra être saisie, selon son type, dans l’application pour pouvoir assurer à tout moment un équilibre entre les crédits des différentes rubriques et les dépenses correspondantes.

En deuxième lieu, la solution doit offrir un moyen d’extraire l’information instantanément à propos de chacun des programmes d’emploi. Elle vise à présenter un rapport d’état de la situation financière des programmes d’emploi, l’argent payé, l’argent engagé et enfin l’argent non-engagé est qui est toujours disponible.

1.2. Cahier des charges

Pour initier notre projet, il a fallu dresser une liste de besoins qui constitueront le cahier des charges. Les besoins que nous avons pu distinguer sont de deux types et sont comme suit :

Besoins fonctionnels :

Génération de rapport d’état

Saisie d’opérations de dépenses sous 4 formes

Saisie de nouveaux programme d’emploi et leurs rubriques avec le crédit allouer a chacune.

Besoins non fonctionnels :

Intégrité des données : assurer la disponibilité et la fiabilité de l’information fournie par l’application.

Sécurité : authentification obligatoire pour éviter la falsification de documents.

6


1.3. Planification des taches

Le cycle de vie de du développement de l’application est un modèle en cascade qui va de l’initialisation à la réalisation en passant par la conception et l’analyse. Le diagramme de Gantt ci-dessous montre la planification de tâches tout au long du projet. Ceci dit, nous avons souvent été amené à revoir quelques phases telles l’élaboration du cahier de charges mais surtout l’analyse des données. En effet, l’élaboration du modèle conceptuel de donnée et du diagramme de classes a nécessité plusieurs retouches. Nous avons été amené à délaisser le projet durant la période de préparation mais on continuait à se familiariser avec les outils de travail (struts, eclipse, langage jsp…).

7


Figure 1 : Diagramme de Gantt

8

Chapitre 2 : Analyse et Conception

2. Chapitre 2 : Analyse et Conception

9


2.1. Modèle en cascade

Nous avons adopté un modèle de cycle de vie en cascade pour le développement de notre application. Ce type de modèle est bien adapté à notre projet puisqu’il s’agit d’une application d’une durée moyenne. Le modèle en cascade présente l’avantage de nous permettre de valider chaque phase pour passer à la suivante. Même si, au cours du projet, nous étions obligé parfois de revenir à l’une des phases pour remédier à un problème ou corriger une erreur de conception ou de modélisation par exemple.

Le principe de modèle en cascade est de découper le projet en phases distinctes sur le principe du non-retour. Lorsqu’une phase est achevée, son résultat sert de point d'entrée à la phase suivante. Ce modèle, développé dans les années 1970 par W. ROYCE a servi pendant des années de modèle de référence.

Figure 2 : Cycle de vie en cascade

L'avantage de ce modèle est de proposer au fur et à mesure une démarche de réduction des risques, en minimisant au fur et à mesure l'impact des incertitudes. L'impact d'une incertitude dans la phase de développement étant plus faible que l'impact d'une incertitude dans les phases de Conception ou de Spécifications, plus le projet avance, plus les risques diminue.

Néanmoins, cette démarche, basée sur un processus de contrôle qualité en fin de chaque phase, a l'inconvénient d'exclure l'utilisateur dès la phase de conception car trop technique. Le contrôle qualité significatif survient alors en fin de projet, et, à ce moment, si l'utilisateur s'aperçoit que le système ne répond pas correctement aux besoins exprimés, il peut être trop tard.

Le modèle en cascade est adapté aux projets de durée inférieure à l'année, sur des projets à forte composante règlementaire, comme les projets de back-office.

Pour de grands systèmes, cette démarche présente également l'inconvénient de ne pas permettre de mener, en parallèle, le développement de modules d'applications.

10


2.2. Démarche de modélisation : UML

2.2.1. Introduction

Nous avons adopté tout au long du projet le langage UML comme langage de modélisation et de conception. Ce choix est justifié d’une part par le fait que nous voulions mettre en pratique les nouvelles connaissances acquises tout au long de la deuxième année et d’une autre part par le fait qu’UML est un langage de modélisation de plus en plus utilisé grâce à la puissance des outils qu’il offre et l’efficacité de ses méthodes.

La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces etc.

Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues : les articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises d’ouvrage une compétence, un professionnalisme qui ne sont pas aujourd’hui répandus.

2.2.2. Mise en œuvre d’UML

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter, de 5 L’OMG (Object Management Group) est une association américaine à but non lucratif créée en 1989 dont l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA communiquer les divers aspects d’un système d’information (aux graphiques sont bien sûr associés des textes qui expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.

Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues

11


partielles, analogues chacune à une photographie d’une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave.

UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :

Diagrammes structurels ou diagrammes statiques (UML Structure) :

– diagramme de classes (Class diagram) ;

– diagramme d’objets (Object diagram) ;

– diagramme de composants (Component diagram) ;

– diagramme de déploiement (Deployment diagram) ;

– diagramme de paquetages (Package diagram) ;

– diagramme de structures composites (Composite structure diagram).

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) :

– diagramme de cas d’utilisation (Use case diagram) ;

– diagramme d’activités (Activity diagram) ;

– diagramme d’états-transitions (State machine diagram) ;

– Diagrammes d’interaction (Interaction diagram) ;

– diagramme de séquence (Sequence diagram) ;

– diagramme de communication (Communication diagram) ;

– diagramme global d’interaction (Interaction overview diagram) ;

– diagramme de temps (Timing diagram) .

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’oeuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution technique.

2.2.2.1. Diagramme de cas d’utilisationLe diagramme de cas d’utilisation représente la structure des grandes

fonctionnalités nécessaires aux utilisateurs du système. C’est le premier diagramme du modèle UML, celui où s’assure la relation entre l’utilisateur et les objets que le système met en oeuvre.

2.2.2.2. Diagramme de classesLe diagramme de classes est généralement considéré comme le plus

important dans un développement orienté objet. Il représente l’architecture conceptuelle du système : il décrit les classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage) ou une relation organique (agrégation).

12


2.2.2.3. Diagramme d’objetsLe diagramme d’objets permet d’éclairer un diagramme de classes en

l’illustrant par des exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à différents cas possibles.

2.2.2.4. Diagramme d’états-transitionsLe diagramme d’états-transitions représente la façon dont évoluent (i.e. cycle

de vie) les objets appartenant à une même classe. La modélisation du cycle de vie est essentielle pour représenter et mettre en forme la dynamique du système.

2.2.2.5. Diagramme d’activitésLe diagramme d’activités n’est autre que la transcription dans UML de la

représentation du processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation : il montre l’enchaînement des activités qui concourent au processus.

Diagramme de séquence et de communication Le diagramme de séquence représente la succession chronologique des opérations réalisées par un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre. On peut représenter les mêmes opérations par un diagramme de communication, graphe dont les noeuds sont des objets et les arcs (numérotés selon la chronologie) les échanges entre objets. En fait, diagramme de séquence et diagramme de communication sont deux vues différentes mais logiquement équivalentes (on peut construire l’une à partir de l’autre) d’une même chronologie. Ce sont des diagrammes d’interaction.

13


2.3. Identification des Cas d’utilisation

Figure 3: Diagramme de cas d'utilisation

On peut distinguer sur la figure huit cas d’utilisation :

« consultation d’états » : ce use case permet à l’utilisateur d’accéder à une synthèse des données stockées dans la base de données. Il peut ainsi voir les totaux calculés des programmes d’emplois, des ordres de payements… etc.,

« traitement PE » : ce use case sert à la gestion des programmes d’emplois. Ajouter, supprimer ou modifier un PE font partie des scénarios de ce cas d’utilisation ;

« remboursement frais » : gestion des remboursements de frais (Ajout, modification, suppression des données) ;

« traitement marché » : gestion des marché (Ajout, modification, suppression) ;

« traitement régie » : gestion des régies (Ajout, modification, suppression) ;

14


« Traitement bcde » : gestion de bons de commande (Ajout, modification, suppression) ;

« traitement OP » : gestion des ordres de paiement (Ajout, modification, suppression) ;

« identification » : ce use case permet l’authentification des utilisateurs avant l’accès aux données.

Les relations « include » : ces relations signifient qu’on ne peut pas démarrer les cas d’utilisation avant l’authentification de l’utilisateur à travers le use case « identification ».

Les relations « extends » : prenons l’exemple de la relation « extends » entre le use case « traitement OP » et le use case « traitement régie ». La flèche signifie qu’il se peut qu’on veuille traiter un ordre de paiement pendant qu’on est entrain de traiter une régie. « Traitement OP » est optionnel dans ce cas.

15


2.4. Scénarios des principaux cas d’utilisation

A partir du cahier des charges et de l’analyse des besoins, nous avons pu dresser les cas d’utilisations cités ci-dessus. Les détails relatifs aux différents scénarios de chaque cas d’utilisation sont présentés ci-dessous :

« identification » : on peut imaginer deux scénarios possibles pour ce cas d’utilisation ; L’échec de la connexion ou bien le succès de la connexion. Le premier scénario traite le cas où l’on n’arrive pas à identifier l’utilisateur dans la base de données. Un message d’erreur est alors renvoyé à l’utilisateur pour notification et l’accès échoue. Dans le second cas, l’utilisateur entre son login et son mot de passe et après vérification que ceux-ci existent bien dans la base de données on passe à la page d’accueil et l’utilisateur peut passer aux autres use case.

« traitement PE » : On peut distinguer 3 scénarios correspondant à l’ajout, à la suppression ou à la modification d’un programme d’emploi. Ajout : l’utilisateur saisit les données à travers un formulaire et après validation les informations sont enregistrées dans la base de données. Modification : on demande à l’utilisateur le PE qu’il veut modifier et après on lui présente un formulaire qui contient les anciennes valeurs du PE qu’il pourra modifier et enregistrer. Suppression : l’utilisateur entre le PE qu’il veut supprimer, on lui adresse alors un message pour confirmer et la suppression est ensuite effectuée dans la base de données.

« traitement OP » : Ce cas d’utilisation permet l’ajout de données relatives à un ordre de paiement, de les modifier ou bien de les supprimer. En plus de ces scénarios, on peut aussi affecter un OP à un Marché, Régie, RF (Remboursement Frais) ou un BCDE (bon de commande).

« traitement BCDE» : Ajout, suppression et modification. Durant les trois scénarios cités, l’utilisateur aura probablement besoin de sélectionner un ou plusieurs produit pour les affecter au bon de commande.

« traitement marché », « traitement Régie », « traitement RF » : ces trois use case se traitent de la même manière avec les scénarios d’ajout, de modification et de suppression. Comme on peut affecter un OP à un Marché, une Régie ou un RF, on doit prévoir un scénario pour affecter ces trois derniers à un OP. L’utilisateur pourra alors faire l’affectation de deux manières différentes.

« consultation d’Etats » : c’est le cas d’utilisation qui permet d’avoir une vue globale sur les données présentes dans la base de données. Les totaux y sont présents et l’utilisateur pourra y faire la distinction entre les différents états de l’argent géré (engagée non payée, engagée payé, non engagée, restant).

16


2.5. Diagrammes de séquences

Nous présentons ici quelques diagrammes de séquence présentant les différents scénarios des cas d’utilisation :

Figure 4: diagramme de séquence, consultation d'un bon de commande

17


Figure 5: diagramme de séquence, Consultation d'Etats

Figure 6 : Diagramme de séquence, Ajout d'un bon de commande

18


2.6. Diagrammes de classes

Le diagramme de classe suivant illustre les composantes de l’application et la base de données. Notons bien que la classe utilisateur n’a aucune relation avec aucunes des autres tables. Ceci est dû au fait que cette classe est une classe de conception, elle n’intervient que durant l’authentification et ne nécessite pas des liens avec les autres classes.

Figure 7 : Diagramme de classes

2.7. Limitations de la conception

Ce paragraphe présente une brève description de notion et processus qui ne pouvaient pas être modélisées lors de la conception du diagramme de classes.

L’émission d’un bon de commande n’est établie qu’après réception des trois devis et sélection du titulaire. Ce bon de commande est rédigé en fonction du devis sélectionner. Le diagramme de classe (cardinalités) montre qu’un seul devis correspond à un bon de commande mais en fait c’est le devis sélectionné.

Il y a aussi le processus relatifs au Marché qui consiste à l’émission d’un appel d’offres, de l’établissement de liste des candidats, l’ouverture des plis et les différentes dates importantes. L’application présente une transparence totale par rapport à ces informations là puisqu’elle ne s’intéresse qu’au Marché retenu et les informations relatives…

19

Chapitre 3 : Réalisation

3.Chapitre 3 : Réalisation

20


3.1. Technologies utilisées

3.1.1. J2EE : présentation

J2EE (Java 2 Enterprise Edition) est une norme proposée par la société Sun, portée par un consortium de sociétés internationales, visant à définir un standard de développement d'applications d'entreprises multi niveaux, basées sur des composants.

On parle généralement de «plate-forme J2EE» pour désigner l'ensemble constitué des services (API) offerts et de l'infrastructure d'exécution. J2EE comprend notamment :

Les spécifications du serveur d'application, c'est-à-dire de l'environnement d'exécution : J2EE définit finement les rôles et les interfaces pour les applications ainsi que l'environnement dans lequel elles seront exécutées. Ces recommandations permettent ainsi à des entreprises tierces de développer des serveurs d'application conformes aux spécifications ainsi définies, sans avoir à redévelopper les principaux services.

Des services, au travers d'API, c'est-à-dire des extensions Java indépendantes permettant d'offrir en standard un certain nombre de fonctionnalités. Sun fournit une implémentation minimale de ces API appelée J2EE SDK (J2EE Software Development Kit).

Dans la mesure où J2EE s'appuie entièrement sur le Java, il bénéficie des avantages et inconvénients de ce langage, en particulier une bonne portabilité et une maintenabilité du code. De plus, l'architecture J2EE repose sur des composants distincts, interchangeables et distribués, ce qui signifie notamment :

Qu'il est simple d'étendre l'architecture ;

Qu'un système reposant sur J2EE peut posséder des mécanismes de haute disponibilité, afin de garantir une bonne qualité de service. ;

Que la maintenabilité des applications est facilitée ;

3.1.2. Le modèle MVC

Le modèle MVC cherche à séparer les couches présentation, traitement et accès aux données. Une application web respectant ce modèle pourrait être architecturée de la façon suivante :

Figure 8 : Architecture du modèle MVC

21


Une telle architecture est appelée 3-tiers ou à 3 niveaux :

l'interface utilisateur est le V (la vue) ;

la logique applicative est le C (le contrôleur) ;

les sources de données sont le M (Modèle).

L'interface utilisateur est souvent un navigateur web mais cela peut être également une application autonome qui via le réseau envoie des requêtes HTTP au service web et met en forme les résultats que celui-ci lui renvoie. La logique applicative est constituée des scripts traitant les demandes de l'utilisateur. La source de données est souvent une base de données mais cela peut être aussi de simples fichiers plats, un annuaire LDAP, un service web distant,... Le développeur a intérêt à maintenir une grande indépendance entre ces trois entités afin que si l'une d'elles change, les deux autres n'aient pas à changer ou peu. Nous verrons que ce modèle de base donne naissance à des architectures présentant des couches plus fines que celles définies ci-dessus. Lorsqu'on cherche à appliquer ce modèle avec des servlets et pages JSP, on obtient l'architecture suivante :

Figure 9 : Modèle MVC

Dans le bloc [Logique Applicative], on distingue

le bloc [Couche de contrôle] est composé d'une ou plusieurs servlets et de classes annexes. Elle assure l'interface avec le client :

o le client fait une demande

o la couche contrôle la fait exécuter par la couche métier

o selon le résultat de cette exécution, la couche contrôle envoie telle ou telle vue en réponse au client.

Le rôle de la couche de contrôle s'arrête à cela. On ne doit pas y trouver des classes qui devraient relever de la couche métier.

le bloc [Couche métier] regroupe les classes Java nécessaires à la logique métier. Cette couche est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être utilisable aussi bien avec une interface console,

22


une interface web, une interface de client riche. Elle doit ainsi pouvoir être testée en-dehors de l'interface web et notamment avec une interface console.

le bloc [Couche d'accès aux données] qui regroupe les classes Java capables de fournir les données nécessaires à la couche métier, souvent des données persistantes (BD, fichiers,...). Ce bloc doit être indépendant de la couche métier et doit pouvoir être testé indépendamment de celle-ci par exemple avec une application console indépendante.

le bloc [Couche de présentation] formé des pages JSP qui constituent les vues de l'application.

Les quatre entités précédentes définissent assez bien la structure de nombreuses applications web en quatre couches.

3.1.3. La démarche de développement STRUTS

Les créateurs de la méthodologie STRUTS ont cherché à définir une méthode de développement standard qui respecte l'architecture MVC pour les applications web écrites en java. Il y a deux aspects au projet STRUTS :

la méthode de développement. Nous verrons qu'elle est, dans son esprit, proche de celle décrite ci-dessus pour les servlets et pages JSP

les outils qui nous permettent d'appliquer cette méthode de développement. Ce sont des bibliothèques de classes Java que l'on trouve sur le site de la fondation Apache (www.apache.org).

L'architecture MVC utilisée par STRUTS est la suivante :

Figure 10 : Architecture STRUTS

23


Le contrôleur est le coeur de l'application. Toutes les demandes du client transitent par lui. C'est une servlet générique fournie par STRUTS. On peut dans certains cas être amené à la dériver. Pour les

cas simples, ce n'est pas nécessaire. Cette servlet générique prend les informations dont elle a besoin dans un fichier le plus souvent appelé struts-config.xml.

si la requête du client contient des paramètres de formulaire, ceux-ci sont mis par le contrôleur dans un objet Bean. Une classe est dite de type bean si elle observe des règles de construction que nous verrons un peu plus loin. Les objets bean ainsi créés au fil du temps sont stockés dans la session ou la requête du client. Ce point est configurable. Ils n'ont pas à être recréés s'ils l'ont déjà été.

dans le fichier de configuration struts-config.html, à chaque URL devant être traitée par programme (ne correspondant donc pas à une vue JSP qu'on pourrait demander directement) on associe certaines informations :

o le nom de la classe de type Action chargée de traiter la requête. Là encore, l'objet Action instancié peut être conservé dans la session ou la requête.

o si l'URL demandée est paramétrée (cas de l'envoi d'un formulaire au contrôleur), le nom du bean chargé de mémoriser les informations du formulaire est indiqué.

muni de ces informations fournies par son fichier de configuration, à la réception d'une demande d'URL par un client, le contrôleur est capable de déterminer s'il y a un bean à créer et lequel. Une fois instancié, le bean peut vérifier que les données qu'il a stockées et qui proviennent du formulaire, sont valides ou non. Une méthode du bean appelée validate est appelée automatiquement par le contrôleur. Le bean est construit par le développeur. Celui-ci met donc dans la méthode validate le code vérifiant la validité des données du formulaire. Si les données se révèlent invalides, le contrôleur n'ira pas plus loin. Il passera la main à une vue dont il trouvera le nom dans son fichier de configuration. L'échange est alors terminé. On notera que le développeur peut demander à ce que la validité du formulaire ne soit pas vérifiée. Il fait cela également dans le fichier struts-config.html. Dans ce cas, le contrôleur n'appelle pas la méthode validate du bean.

si les données du bean sont correctes, ou s'il n'y a pas de vérification ou s'il n'y a pas de bean, le contrôleur passe la main à l'objet de type Action associé à l'URL. Il le fait en demandant l'exécution de la méthode execute de cet objet à laquelle il transmet la référence du bean qu'il a éventuellement construit. C'est ici que le développeur fait ce qu'il a à faire : il devra éventuellement faire appel à des classes métier ou à des classes d'accès aux données. A la fin du traitement, l'objet Action rend au contrôleur le nom de la vue qu'il doit envoyer en réponse au client.

le contrôleur envoie cette réponse. L'échange avec le client est terminé.

Commence à se dessiner la méthodologie de développement STRUTS :

la définition des vues. On distingue les vues qui sont des formulaires et les autres.

o chaque vue formulaire donne naissance à une définition dans le fichier struts-config.xml. On y définit les informations suivantes :

24


le nom de la classe Bean qui contiendra les données du formulaire ainsi que l'indication sur le fait que les données doivent être vérifiées ou non. Si elles doivent être vérifiées et qu'elles s'avèrent invalides, on doit indiquer la vue à envoyer en réponse au client dans ce cas.

le nom de la classe Action chargée de traiter le formulaire.

le nom de toutes les vues susceptibles d'être envoyées en réponse au client une fois que la requête a été traitée. La classe Action choisira l'une d'elles selon le résultat du traitement.

o chaque vue fait l'objet d'une page JSP. Nous verrons que dans les vues notamment les vues formulaires, on utilise parfois une bibliothèque de balises propres à Struts.

l'écriture des classes Javabean correspondant aux vues formulaires.

l'écriture des classes Action chargées de traiter les formulaires.

l'écriture des éventuelles classes métier ou d'accès aux données.

3.1.4. Apache Tomcat

Apache Tomcat est un conteneur de servlets J2EE. Issu du projet Jakarta, Tomcat est désormais un projet principal de la fondation Apache. Tomcat implémente les spécifications des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la configuration et la gestion, mais peut également être configuré en éditant des fichiers de configuration XML. Comme Tomcat inclut un serveur HTTP interne, il est aussi considéré comme un serveur HTTP. C'est le compilateur Jasper qui compile les pages JSP pour en faire des servlet. Le moteur de servlet Tomcat est souvent employé en combinaison avec un serveur Web Apache ou d'autres serveurs Web.

Tomcat a été écrit en langage Java, il peut donc s'exécuter via la JVM (machine virtuelle java) sur n'importe quel système d'exploitation.

L'installation par défaut de Tomcat comprend les répertoires suivants :

bin : Scripts et exécutables pour différentes tâches : démarrage (startup), arrêt, etc. ;

common : Classes communes que Catalina et les applications Web utilisent ;

conf : Fichiers de configuration au format XML et les DTD que ces fichiers XML utilisent ;

logs : Journaux des applications Web et de Catalina ;

server : Classes utilisées seulement par Catalina ;

shared : Classes partagées par toutes les applications Web ;

webapps : Répertoire contenant les applications web ;

work : Fichiers et répertoires temporaires.

25


Nous avons travaillé avec la version 6 qui comprend les fonctionnalités suivantes :

implémente les spécifications Servlet 2.5 et JSP 2.1 ;

support de Java 5

amélioration de l'usage mémoire

3.1.5. les pages JSP

Le JavaServer Pages ou JSP est une technologie basée sur Java qui permet aux développeurs de générer dynamiquement du code HTML, XML ou tout autre type de page Web. La technologie permet au code Java et à certaines actions prédéfinies d'êtres ajoutés dans un contenu statique.

La syntaxe du JSP ajoute des balises XML, appelées actions JSP, qui peuvent être utilisées pour appeler des fonctions. De plus, la technologie permet la création de bibliothèques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au XML. Les bibliothèques de balises offrent une méthode indépendante de la plate-forme pour étendre les fonctionnalités d'un serveur HTTP.

Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java. Un compilateur JSP peut générer un servlet Java en code source Java qui peut à son tour être compilé par le compilateur Java, ou peut générer le pseudo-code Java interprétable directement.

3.1.6. Mysql

MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées. Il est multi-threads, multi-utilisateurs. C'est un logiciel libre développé sous double licence en fonction de l'utilisation qui en est faite : dans un produit libre (open-source) ou dans un produit propriétaire. Dans ce dernier cas, la licence est payante, sinon elle est libre.

3.1.7. PowerAMC

AMCDesignor (c'est son nom d'origine) a été conçu à la base pour pallier au manque d'outil de modélisation graphique pour Oracle (d'où le or final). Il était basé sur la méthodologie Merise. Lors de son rachat par Powersoft, l'application a été traduite en anglais et le module modèle conceptuel de données a été refondu pour la méthodologie IE (Information engineering), plus exactement selon la méthode Yourdon-DeMarco. 2 versions apparurent donc parallèlement:

PowerAMC, méthodologie Merise, application en français ;

PowerDesigner, méthodologie IE, application en anglais .

Sybase, lors de son rachat de Powersoft, essaya de supprimer la version francophone, mais face à la levée de bouclier des analystes merisiens, la tentative fut un échec. Dans leur version actuelle (v.11.1), PowerDesigner et PowerAMC ne se différencient plus que par la langue. L'application est multi-méthodes depuis sa

26


refonte (version 7) et gère même les 9 diagrammes UML et les Processus métiers dans sa version la plus complète.

Cet outil nous a permis d’une part de faire la conception de modèle de données de l’application et le diagramme de classe et d’une autre part de générer les scripts SQL de la base de données.

3.2. Présentation de quelques interfaces

Figure 11 : Authentification

Figure 12 : Menu d'accueil

27


Figure 13 : Détails des programmes d'emplo

Figure 14 : Gestion des produits et services

28


Figure 15 : Liste des programme d'emploi

Figure 16 : liste des devis

29

Chapitre 4 : Déploiement

4.Chapitre 4 : Déploiement

4.1. Déploiement de la base de données

Lors de la conception de la base de données Power AMC met à notre disposition des fonctions automatique de génération de scripts SQL. Le script SQL contient alors les requêtes de création de la base de données, la création des tables, et la création des contraintes fonctionnels.Pour installer la base de données dans le serveur qui contiendra notre application, il suffit d’importer le scripts précédemment générer dans la console du serveur de base de données.

4.2. Déploiement de l’application

Pour déployer l’application sur le serveur d’application TomCat 6 nous avons générés , grâce à l’IDE MyEclipse un fichier .WAR qui contient les classes et servlet de l’application.Pour déployer l’application, nous déposons le fichier WAR dans le dossier « webbapps » du dossier d’installation de TomCat dans le serveur cible. Au démarrage du serveur TomCat il déploiera automatiquement le fichier et l’application sera disponible dans la configuration par défaut sous l’adresse http://localhost:8080/{nom_fichier_war}/authentification.jsp.Enfin il reste a définir un nom de domaine pour l’application pour quelle soit accessible a partir du réseau local et simplifier cette adresse.

30

http://localhost:8080/%7Bnom_fichier_war%7D/authentification.jsp

Chapitre 4 : Déploiement

Conclusion

Rappelons que l’objectif de notre travail était de concevoir et réaliser une application de gestion des opérations financières d’un établissement universitaire. Il s’agit d’un système mono utilisateur pour la saisie de données et la synthèse de l’information.

Pour mener ce travail, nous avons effectué un choix d’outils appropriés à savoir : UML comme langage de modélisation et J2EE comme outils de développement. Après une étude conceptuelle du système, Nous avons procédé à la réalisation de certains aspects de cette application. Notre réalisation, permet à l’utilisateur d’enregistrer les différentes opérations de gestion dans une base de données.

Nous avons eu quelques difficultés en ce qui concerne le développement J2EE vu que c’est un environnement nouveau pour nous. Nous avons notamment cherché des solutions aux différents problèmes survenus. Les outils que nous avons utilisés nous ont permis de voir en détails la plupart des aspects du développement web en java.

L’application ainsi réalisée est une combinaison de solution mises en œuvre lors des différentes phases d’analyse, de conception et de réalisation. L’application reste cependant limitée du point de vue de l’interface graphique. Elle n’offre pas une interface conviviale pour l’utilisateur et donc et cadre de travail agréable. Il reste encore beaucoup de perspectives pour le développement de cette application. On pense tout de suite aux états de sortie et aux imprimés. En effet un utilisateur doit pouvoir imprimer les documents dont il a besoin pour effectuer une opération. On peut aussi penser à développer un module pour effectuer des statistiques sur tout ce qui concerne les bons de commandes émis, les marchés publiés, les recettes…etc.

31

Webographie

Webographie

http://www.developpez.com/

http://fr.wikipedia.org/

http://www.labo-sun.com/

http://java.sun.com/javaee/

32

http://java.sun.com/javaee/

http://www.labo-sun.com/

http://fr.wikipedia.org/

http://www.developpez.com/

Documents

Plan : - Glossip | Plus besoin de chercher … · Web viewPour installer la base de données dans le serveur qui contiendra notre application, il suffit d’importer le scripts précédemment