Application web pour la gestion de la bibliothèque

Mémoire de fin d'études pour l'obtention du diplôme universitaire
d'Ingénieur en Informatique, Techniques Web et Multimédia

Application Web pour la gestion de la

bibliothèque

Soutenu le 11 Juin 2010 devant le Jury composé de :

M. Bassem BOUAZIZ : Président

M. Ahmed BEN JMEAA : Rapporteur

M. Walid MAHDI : Encadreur

M. Mohamed TMAR: Encadreur

Réalisé par : Emna GUERMAZI

A

mon père Fadhel, ma mère grouda

Vous êtes pour moi un sujet de fierté.

Vous m'avez toujours appris le sens de la responsabilité, de la raison, du devoir,
et de la confiance en soi

Au -delà des mots et des phrases, aucune parole ne saurait exprimer mon éternel
attachement, mon profond amour, ma perpétuelle affection et l'infinie gratitude
qui je vous dois

Je sais que vous étiez toujours fiere de moi et j'espere que vous le serez plus
aujourd'hui

Que Dieu vous garde et vous alloue bonne santé, bonheur, prospérité et longue
vie

A ma tres chere soeur Nesrine
Ta place dans mon coeur est particuliere.

Nulle dédicace et nulle parole ne puisse exprimer ma profonde affection à ton

égard

Je te souhaite tout le bonheur et le succès que tu mérite tant

A ma cousine Atef
En témoignage de ma sincère amitié et mon profond attachement
Que dieu t'offre une vie pleine de succes et bonheur

A mes chèrs amis
grassen , Basma, grejer, Bassem, Issal, granen, Amel

Et

A tous ceux dont l'oubli du nom n'est pas celui du coeur.

Remerciements

Nous tenons à exprimer notre profonde gratitude et notre respectueuse
reconnaissance à nos encadreurs :

Mr. Mohamed Tmar
Mr. Walid Mahdi

Qui ont bien voulu nous encadrer. Nous les remercions vivement pour leur
soutien et leurs conseils précieux.

Nos vifs remerciements s'adressent également à tous nos enseignants, nos
amis et tous ceux qui nous ont prêté mains fortes pour la réalisation du projet.

Nous remercions aussi chaleureusement

Mr. Bassem Bouaziz et Mr. Ahmed Ben Jmeaa

D'avoir accepté de juger ce travail

A TOUS, NOUS ADRESSONS UN GRAND MERCI

Table des matières

Introduction générale 9

Chapitre 1 :Etude Préalable 11

I. Définition du champ d'étude et Analyse des besoins 12

A. Définition du champ d'étude . 12

B. Présentation du domaine d'étude. 12

C. Objectifs à atteindre 13

D. Travail à réaliser 14

E. Analyse et définition des besoins 15

F. Besoins fonctionnels 16

G. Interfaçage avec d'autres applications 16

H. La plateforme physique 17

I. Planning de déroulement du projet 17

II. Etude de l'existant . 18

A. L'analyse de l'existant 18

B. Critiques de l'existant 20

III. Solutions proposées 21

A. Volet fonctionnel 21

B. Volet technique 21

C. Volet organisationnel 22

Chapitre 2 :Etude Théorique 23

I. Présentation du Web 24

II. Présentation de l'architecture d'un système Client / Serveur dans le Web 25

A. Fonctionnement d'un système Client / Serveur . 26

B. Présentation de l'architecture à deux niveaux 26

C. Présentation de l'architecture à trois niveaux 27

D. Comparaison des deux types d'architecture . 28

E. L'architecture Multi-niveaux 29

F. L'accès CGI 29

IV. La plate-forme J2EE 30

A. Les Framework utilisés 31

1. Le Framework Spring 31

2. Le Framework Struts 31

3. Le Framework Hibernate 33

V. Architecture 3-tiers et mise en place du modèle MVC 35

Chapitre 3 :Modélisation Conceptuelle 38

I. Choix de la méthode de conception 39

A. Le langage UML 39

B. Les Vues UML 39

1. Les vues statiques 39

2. Les vues dynamiques 40

C. Avantages d'UML 41

II. Architecture générale de l'application . 41

III. Conception détaillée 41

A. Les diagrammes de cas d'utilisation . 42

B. Les diagrammes de séquence 55

1. Authentification de l'administrateur . 55

2. Gestion des adhérents 55

3. Gestion des documents 57

4. Gestion des emprunts 58

5. Gestion des retours 59

6. Gestion des retards 60

A. Digramme de classe 61

Chapitre 4 :Réalisation 64

I. Environnement de développement 65

A. Environnement matériel 65

1. PC 65

B. Environnement logiciel 65

1. Eclipse 65

2. MySQL 65

3. Apache Tomcat 6.0 66

4. Rational Rose 66

5. Adobe Photoshop 7.0 66

6. Adobe DreamWeaver CS3 66

II. Implémentation 67

A. Page d'accueil .. 67

B. Recherche des documents 67

C. Bibliothèque 68

D. Gestion des documents 69

Conclusion et perspectives 71

Bibliographie 72

Webographie 72

Liste des figures

Figure 1 : Interfaces avec d'autres applications. 17

Figure 2: Système Client / Serveur. 26

Figure 3: Architecture à deux niveaux 27

Figure 4: Architecture à trois niveaux. 28

Figure 5: Architecture Multi-niveaux. 29

Figure 6: Principe des programmes CGI. 30

Figure 7: Architecture du Modèle Vue Contrôleur. 32

Figure 8: Architecture d'Hibernate. 35

Figure 9: Architecture 3-tiers et mise en place du MVC. 36

Figure 10 : Diagramme de cas d'utilisation pour la gestion de la bibliothèque. 44

Figure 11: Diagramme de séquence pour l'authentification. 55

Figure 12: Diagramme de séquence pour l'ajout d'un nouveau adhérant. 56

Figure 13: Diagramme de séquence pour la suppression d'un adhérant. 56

Figure 14: Diagramme de séquence pour l'ajout d'un nouveau document. 57

Figure 15: Diagramme de séquence pour la suppression d'un document. 58

Figure 16: Diagramme de séquence pour l'emprunt d'un document. 59

Figure 17: Diagramme de séquence pour le retour d'un document. 60

Figure 18: Diagramme de séquence en cas du retard de retour d'un document. 61

Figure 19: Digramme de classes de notre application. 62

Figure 20: Page d'accueil. 67

Figure 21: Recherche des documents. 68

Figure 22: Page réservée au bibliothécaire. 68

Figure 23: Partie réservée au bibliothécaire. 69

Figure 24: Gestion des documents. 69

Liste des tableaux

Tableau 1 : Gestion de la bibliothèque 15

Tableau 2: Planning du déroulement du projet. 18

Tableau 3: Catégories des sanctions. 20

Tableau 4: Recherche des documents selon un critère donné. 46

Tableau 5: Gestion de prêts. 48

Tableau 6: Gestion des adhérents. 49

Tableau 7: Gestion des documents. 50

Tableau 8: Gestion de retours. 52

Tableau 9: Gestion des retards 54

Tableau 10: Environnement matériel utilisé. 65

Introduction générale

L'informatique reconnaît une hausse depuis le « soit disant » bug de l'an 2000. Elle est due à l'informatisation de la majeure partie des tâches, à la puissance des processeurs qui ne cesse de grandir et surtout aux nouvelles technologies de l'information et de la communication. Ces changements posent, naturellement, un grand challenge aussi bien pour les décideurs politiques que pour les entreprises. Cette transition amènent les entreprises à repenser leurs stratégies et leurs structures, d'où cet engluement pour les développeurs java J2EE et .NET.

L'Internet est un système de communication qui permet de communiquer et de s'échanger des informations. Cette communication permet donc, de généraliser l'utilisation des outils informatiques (logiciel) plus performants avec des clients légers (navigateur web devenu plus complet et sans besoin d'installer le logiciel sur des machines individuelles). Ceci permet d'accéder aux ressources sans contraintes particulières.

La technologie java J2EE est une technologie qui utilise un ensemble d'API java :

· Servlets : Conteneur Web

· Portlets : Conteneur Web (extension de l'API Servlet)

· JSP : Framework Web

· JSF : Java Server Face, Framework Web, extension des JSP

· EJB : Composants distribués transactionnels

· JNDI : API de connexion à des annuaires, notamment des annuaires LDAP

· JDBC : API de connexion à des bases de données

· JMS : API de communication asynchrone

· JCA : API de connexion, notamment à des PGI

· JavaMail : API de gestion des mails

· JMX : Extension d'administration des applications

· JTA : API de gestion des transactions

? JAXP : API d'analyse XML

? JAXM : API de communication asynchrone par XML

· JAX-RPC : API de communication synchrone par XML, par exemple à l'aide du protocole SOAP

· JAXB : API de sérialisation par XML

· JAXR : API de gestion des registres XML, permettant d'enregistrer des Web Services en ebXML

· RMI : API de communication distante entre des objets java

· Java IDL : API de communication entre objets Java et objets non-Java, via le protocole CORBA

Cette technologie propose ainsi de pouvoir développer des applications qui pourront tourner sous différents navigateurs, tout en assurant la sécurité que procure une application métier java.

Dans ce cadre s'inscrit notre projet de fin d'études qui consiste à réaliser une application Web pour la Gestion de la Bibliothèque de l'Institut Supérieur d'Informatique et du Multimédia de Sfax.

Pour atteindre notre objectif nous avons partagé le travail comme suit : Le premier chapitre est une prise de connaissance et une analyse de l'existant pour mieux définir les besoins et les fonctions de notre application. Dans le second chapitre, nous allons faire notre choix sur les méthodes et outils à utiliser pour réaliser l'application. Le troisième chapitre sera consacré à la conception de l'application il s'agit d'une phase de modélisation théorique de l'application. Avant de clôturer, nous allons présenter les résultats obtenus dans le quatrième chapitre.



Chapitre 1 :

Étude Préalable

Introduction

Il s'agit d'une étape cruciale dans la réalisation d'une application donnée. Le futur d'un logiciel dépend beaucoup de cette phase, elle nous permet d'éviter le développement d'une application non satisfaisante. Pour cela le client et le développeur doivent être en étroites relations, voire avoir un intermédiaire entre eux.

Pour arriver à nos fins il nous faut prendre connaissance de :

· L'analyse et la définition des besoins d'un commun accord entre les spécialistes et les utilisateurs.

· L'étude de l'existant : Le domaine d'application, l'état actuel de l'environnement du futur système, les ressources disponibles, les performances attendues, etc.

· Proposition des nouvelles solutions.

Le présent chapitre va nous donner un aperçu global de l'application.

I. Définition du champ d'étude et Analyse des besoins

A. Définition du champ d'étude

Le champ d'étude appelé aussi domaine ou univers de discours ou réel perçu, correspond à la présentation du domaine de l'étude et du travail que nous allons effectuer.

Dans le but d'améliorer la Gestion de la Bibliothèque de l'Institut Supérieur d'Informatique et du Multimédia de Sfax (ISIMS), nous proposons d'analyser, de concevoir et d'implémenter une application Web pour la gestion de la bibliothèque.

B. Présentation du domaine d'étude

Vue la diversité des tâches administratives de la bibliothèque de l'Institut Supérieur d'Informatique et du Multimédia de Sfax (ISIMS), telles que :

· L'édition des cartes bibliothécaires,

· La mise à jour des adhérents,

· La mise à jour des documents,

· La passation des commandes pour l'acquisition des documents,

· Le contrôle des retards de retour de ces documents,

· Etc....

La gestion de la bibliothèque devient une tâche de plus en plus complexe, sans oublier les opérations relatives aux utilisateurs comme par exemple la recherche des documents.

En effet notre mission consiste à passer d'une gestion manuelle à une gestion automatique utilisable par divers membres en particulier le bibliothécaire et l'adhérant.

C. Objectifs à atteindre

L'objectif principal consiste à concevoir et réaliser une application Web permettant la gestion de la bibliothèque universitaire de l'ISIMS. Une telle application devrait offrir l'intégrité, la sécurité et la confidentialité des données ainsi que de garantir l'accès à l'information au moment opportun. Pour atteindre cet objectif, nous allons décomposer notre projet en deux parties.

La première partie concerne l'aspect administratif, celle qui traite la gestion des documents pour la bibliothèque, et la seconde partie représente l'aspect utilisateur.

La réalisation d'une telle application nous permet d'atteindre les objectifs secondaires suivants

· Avoir une vision globale de la situation des documents : le bibliothécaire doit avoir un produit lui permettant de connaître à tous moment la liste des documents prêtés, la liste des documents réservés ainsi que la liste des documents disponibles.

· Suivre la situation des adhérents sur le respect ou le non respect de la réglementation : le bibliothécaire devrait avoir quotidiennement la liste des adhérents retardataires n'ayant pas respecté les règles imposées par l'ISIMS.

· Définir des mesures spécifiques permettant d'interdire aux adhérents retardataires de bénéficier des prêts pour un certain délai dans le système en question.

· Alléger les traitements manuels du bibliothécaire au niveau de l'organisation physique des documents et au niveau du temps de traitement de prêt et la gestion administrative.

· Mettre en place un système permettant une analyse détaillée de la fréquence des documents empruntés afin de faciliter l'acquisition des nouveaux documents.

· Décharger le personnel des tâches lourdes et répétitives tout en offrant le meilleur service aux utilisateurs.

· Proposer une application assez dynamique et adaptable au niveau de la gestion
des adhérents pour pouvoir satisfaire aux besoins futurs de la bibliothèque.

· Faciliter la tâche des insertions à la bibliothèque pour remplir les données nécessaires, comme par exemple, des informations complémentaires nécessaires relatives au document ou à l'adhérant.

· Doter le nouveau système de plusieurs critères de recherche afin que l'utilisateur puisse choisir celle qui convient au mieux à ses besoins.

· Prévoir une certaine sécurité au logiciel en offrant la possibilité de sauvegarder régulièrement les informations pertinentes afin de pouvoir les restaurer en cas d'une panne irréversible.

· Avoir la possibilité de consulter les ressources disponibles en temps réel en termes de livres et d'autres supports d'informations dans la bibliothèque en vue de les acquérir ou de les réserver par défaut.

· Connaître à tout moment dans l'ordre chronologique les étudiants ayant réservé des documents non disponibles dans la bibliothèque.

· Disposer d'une vue généralisée sur les livres traitant le mrme thème en consultant la base de données afin de choisir le document ou le support le plus pertinent qui répond au mieux aux besoins des utilisateurs.

D. Travail à réaliser

Dans le cadre de ce mémoire de fin d'étude, nous avons tenté d'aborder le problème à un niveau plus fin de granularité, étant donné la complexité de la tâche.

Notre projet « Application Web pour la gestion de la bibliothèque » englobe les fonctions décrites par la gestion des adhérents, la gestion des prêts, la gestion des documents et le contrôle des retards telles que schématisées dans le tableau 1.

		Gestion des Adhérents	·
Consultation des adhérents.		·
Ajout d'un nouveau adhérant.		·
Modification d'un adhérant.		·
Suppression d'un adhérant.
Gestion des Prêts		·
Affectation d'un document à un adhérant.		·
Statistiques de prt de document (nombre d'exemplaires).
Gestion des Documents		·
Gestion des besoins.		·
Recherche d'un document.		·
Ajout d'un nouveau document.		·
Modification d'un document.		·
Suppression d'un document.		·
Consultation des documents.		·
Réservation d'un document.
Gestion des Retards		·
Recensement de la liste des retardataires.		·
Envoi des messages d'avertissement.

Tableau 1 : Gestion de la bibliothèque.

E. Analyse et définition des besoins

La décision de la conception et le développement de ce système ont été pris sans définir explicitement les services attendus par l'utilisateur. Il a fallu discuter avec le bibliothécaire et faire la collecte des différentes informations nécessaires afin de concevoir un système qui répond aux besoins du bibliothécaire.

L'étude présentée dans ce chapitre est donc le fruit de ces discussions et de l'analyse

de besoins.

L'interface Homme-Machine présente un aspect important dans notre application étant

donné que le but primordial à atteindre est de développer une application Web pour la gestion

de la bibliothèque.

La conception d'une interface utilisateur doit prendre en compte les besoins, l'expérience et les capacités de l'utilisateur. De ce fait deux contraintes doivent etre prises en compte :

· La convivialité et la simplicité de l'interface vis-à-vis de l'utilisateur auquel elle est destinée.

· La conformité des fonctionnalités offertes au traitement exigé.

F. Besoins fonctionnels

Cette section présente les services attendus par l'utilisateur de l'interface. Nous décrivons ce que l'interface doit offrir comme fonctions sans pour autant spécifier les détails de leurs fonctionnements :

· La gestion des adhérents.

· La gestion des prêts.

· La gestion des documents.

· Le contrôle des retards.

G. , QaIIIDbDIerDliFrEADuafHrDSSGFDaRQs

Lorsque notre application devient automatisée, elle peut communiquer des données à

munique les informations sur

Si un étudiant n'a pas encore remis un livre, il n'aura pas son diplôme.

Par ailleurs, notre application ne communique pas avec d'autres applications externes. Il n'existe pas de communication entre la bibliothèque de l'ISIMS et les autres bibliothèques des institutions.

La figure 1 illustre les différents flux d'informations échangées entre la bibliothèque et

docum



Figure 1 : Interfaces avec d'autres applications.

H. La plateforme physique L'application peut tourner sur une machine indépendante et elle s'exécute sous Internet.

I. Planning de déroulement du projet Le planning de déroulement du projet est illustré par le diagramme de Gantt dans le

ent sont les

suivantes :

· La spécification dans laquelle nous allons définir les besoins, les objets et les contraintes.

· La conception dans laquelle nous allons définir les principes de base de la solution
retenue.

· Le développement ou implémentation dans lequel nous allons détailler davantage l'étape précédente, choisir le langage de programmation qui nous semble approprié, écrire l'ensemble des programmes de l'application et choisir le processus de l'implémentation.

	Février	Mars	Avril	Mai		Juin	Spécification
						Conception
						Rédaction

Tableau 2: Planning du déroulement du projet.

II. Etude de l'existant

L'étude de l'existant nécessite une analyse détaillée de son domaine de l'étude, de son environnement, de ses perspectives, suivie d'une critique qui permet de dégager le dysfonctionnement de la gestion de la bibliothèque et ce dans le but de remédier aux problèmes détectés et apporter des solutions requises ainsi que des suggestions d'améliorations.

A. L'analyse de l'existant

La bibliothèque est gérée par une seule personne appelée bibliothécaire. Cette personne est chargée de toutes les opérations manuelles à savoir :

· Registre d'inventaire : à chaque fois qu'il y a acquisition d'un nouveau document, le bibliothécaire procède à l'enregistrement de ce nouveau document au registre d'inventaire dans lequel il mentionne les informations nécessaires, telles que : côte, numéro d'inventaire, titre et complément du titre, mention de responsabilité, éditeur, date, ISBN, 2^ème ISBN et mots clés.

· Les codifications : le bibliothécaire attribue un code pour chaque nouveau document. Ce code est composé de deux parties. La première qui est constituée de deux lettres, elle désigne respectivement le thème et le sous-thème correspondant. La deuxième représente un numéro séquentiel. Il est à noter également que les mêmes documents ayant plus d'un exemplaire possèdent le mrme code. A titre d'exemple, la codification suivante permettra l'identification et le classement physique des documents.

I : Informatique (thème).

M : Mathématique (thème). E : Economie.

G : Généralité.

IB : Multimédia (sous-thème). MA : Mathématique Généralité. MC : Mathématique Algèbre. IH : Base de données.

· La gestion des rayons : les documents ayant le même thème et sous-thème sont classés par numéro séquentiel dans le même rayon.

· La gestion des prêts : tous les documents de la bibliothèque peuvent être consultés sur place ou faire l'objet d'un prfft à domicile.

o Consultation sur place : les revues, périodiques et usuelles sont réservées seulement pour la consultation sur place.

o Prêt à domicile : les étudiants du premier cycle de l'ISIMS peuvent emprunter un seul document, tandis que ceux du deuxième cycle peuvent emprunter jusqu'à deux documents à la fois. De plus, la durée maximale d'un prt peut atteindre une semaine pour chaque document emprunté.

Les enseignants ont le droit d'emprunter au maximum trois documents à la fois
sans carte d'adhésion, et par conséquent, le bibliothécaire maintient pour
chaque enseignant une fiche de prit. Dans ce cas, la durée maximale d'un prêt

varie de 7 jours jusqu'à 20 jours.

n Pour emprunter des documents, un adhérant doit se présenter, accompagné de sa carte d'adhésion, au guichet en indiquant le thème ou le sous-thème en question.

n Le bibliothécaire procède à la recherche des documents correspondants à ces thèmes.

· Si disponible, l'adhérant remplit la demande de consultation (en mentionnant l'usage (usuel ou à domicile), nom et prénom, niveau, auteur, titre, signature) et lui remet avec sa carte d'adhésion. Ainsi, le bibliothécaire termine la procédure de prêt (en mentionnant sur la demande l'inventaire, la cote, la date de sortie et la date de retour), et finalement il lui remet le document.

· Sinon, l'adhérant peut faire une réservation. Le bibliothécaire lui réserve.

De même, pour remettre les documents, l'adhérant doit se présenter au guichet. Le bibliothécaire reçoit les documents et lui remet sa carte d'adhésion.

· Travaux d'inventaire : pendant les vacances universitaires, le bibliothécaire procède
à l'inventaire physique des documents. Durant cette opération, le bibliothécaire procède à la vérification de la présence physique des documents afin de mettre à jour les fichiers et le registre d'inventaire.

· La gestion des retards : à la fin de chaque journée, le bibliothécaire détient les cartes
des adhérents qui n'ont pas remis à temps les documents empruntés. Le tableau 3 énum ère les sanctions en fonction du nombre de jours de retard. Mais celles-ci ne sont
pas réellement appliquées.

Sanction
Premier retard		Deuxième retard	Troisième retard	Moins de 7 jours
Retrait de deux mois		Retrait d'un mois	Retrait définitif	Entre 7 jours et un mois
Retrait d'un mois		Retrait définitif	3 aY TITC P RIY
Retrait définitif

Tableau 3: Catégories des sanctions.

B. &rLtLqWI-IASI-Al'I-xLItant

· Problème de dédoublement de poste car il n'y a pas assez d'effectifs : si le responsable de la bibliothèque s'absente, la tache devient difficile et compliquée.

· La tache de recherche est inexistante pour l'étudiant car il y a absence totale de répertoire manuel ou automatique de la liste des documents disponibles et qui devraient être mis à la disposition des étudiants.

· Un volume d'information assez important : complexité de la réalisation des tâches

· La codification n'est pas significative : il y a manque de cohérence entre

· Problème de local : il n'y a pas suffisamment d'espace pour la bibliothèque.

· Une lourdeur dans les tâches au sein de la bibliothèque telles que par

o La sélection des titres pour faire l'acquisition des documents.

o L'enregistrement des titres dans le registre d'inventaire.

o La classification des documents

o L

III. Solutions proposées

L

les objectifs du futur système. P

A. Volet fonctionnel

D

d'atteindre les objectifs désirés

· A ccès immédiat pour les étudiants

· Mise en place d'une base de données complètes qui regroupe toutes les données nécessaires et qui sera utilisée par toutes les fonctions de la « Gestion de la
bibliothèque ».

· Minimisation des travaux manuels

· Facilitation de la réponse aux interrogations diverses concernant les documents

· Assurance d'une gestion efficace et parfaite de recherche afin de fournir le maximum d'informations

· G estion automatique des retards (journalière ou périodique).

B. Volet technique

A travers le Web, l'adhérant peut accéder instantanément et meme à distance pour rechercher les documents disponibles à l'ISIMS. Pour cela, il est nécessaire de :

· Mettre en place et intégrer une base de données dans le système d'information de la bibliothèque.

· Créer des terminaux.

· Mettre à la disposition des adhérents une connexion Internet.

· Etablir des réseaux locaux.

C. Volet organisationnel

La communication entre les acteurs internes se fait d'une manière formelle (ce sont toutes les informations qui circulent sur des supports officiels).

A ce niveau, il est nécessaire de réserver un local dans lequel il y aura la possibilité de communiquer directement avec la bibliothèque. Donc il faut créer :

· Un moyen pour simplifier les circuits de circulation de l'information.

· Un moyen pour répartir la responsabilité du bibliothécaire.

· Un ensemble de procédures permettant le partage des données.

· Une base de données afin de permettre un meilleur suivi.

· Des procédures automatiques et en temps réel.

Conclusion

Après avoir identifié les besoins des utilisateurs, nous avons précisé l'objectif à atteindre, puis nous avons élaboré un planning de déroulement du projet pour préciser et organiser les différentes étapes nécessaires pour la réalisation de notre projet. Finalement, nous avons proposé quelques solutions pour nous guider dans notre projet.

Le chapitre suivant aborde la partie théorique de notre application.



Étude Théorique

Chapitre 2 :

Introduction

Les applications Web sont très diverses et c'est précisément la variété des applications offertes aussi bien en matière d'information que de communication qui font la force d'Internet.

Nous allons présenter dans ce chapitre la plate forme, les Framework et l'architecture

I. Présentation du Web

L'Internet est aujourd'hui le premier réseau mondial accessible à toutes les entreprises. World Wide Web est la partie de l'application de l'Internet dont on parle le plus. C'est une technologie qui permet à partir d'un logiciel client appelé navigateur (ou browser) d'accéder facilement à des documents stockés sur un serveur connecté à l'Internet. Avec le Web, l'Internet s'ouvre au grand public et ne nécessite plus de connaissances spécifiques en informatique. Le modèle Internet est celui du client serveur, où un programme client permet à

un utilisateur de soumettre des requêtes à un serveur Web et de visualiser le résultat, le

serveur Web étant un programme qui tourne sur un ordinateur dans le but de répondre à des requêtes de logiciel client qui tournent sur d'autres ordinateurs. Un document est la plus petite unité fournie par le serveur en réponse à une requête du client. Les documents Web, qui utilisent l'hypertexte, pointent vers d'autres documents et permettent ainsi, par un clic de souris, de passer en toute transparence d'un document hébergé sur un serveur quelconque, à un document stocké sur un serveur distant.

Le langage utilisé pour créer des pages est HTML. La communication entre navigateur

et serveur Web se fait grâce à un protocole spécialisé dans le transport de ce type de pages

HTTP. Un programme serveur dédié à la gestion de ce protocole est au coeur de tout serveur Web. Il se charge de répondre aux demandes des navigateurs, va chercher la page désirée et renvoie à l'utilisateur qui la consulte depuis son navigateur. Le Web permet non seulement d'accéder à des documents statiques et prédéfinis, mais aussi d'accéder dynamiquement à des informations stockées sur des systèmes de bases de données. Ainsi, le Web peut être vu comme un nouvel environnement de développement d'applications Web. Créer des pages HTML dynamiquement sur le serveur permet de personnaliser les informations en fonction des interactions de l'utilisateur. Souvent, cette interactivité se traduit concrètement par un

échange client-serveur avec une base de données. Dans ce cas, on ne crée donc plus un document statique, mais un document personnalisé. Ceci pose les bases du concept d'application réelle au travers du Web.

En fait, il relie la plupart des serveurs multimédias, repose sur un système d'adressage en utilisant des adresses IP (Internet Protocol) et des adresses URL. Chaque ordinateur branché à Internet possède une adresse unique, appelée adresse IP, qui lui permet d'rtre repéré et contacté par les autres ordinateurs du réseau.

Sa popularité s'explique par la diversité de ses contenus, la facilité d'utilisation, la création de ses propres contenus, la capacité à accommoder une grande variété de formats ainsi que l'interactivité avec l'utilisateur.

Il s'agit d'un grand réseau interconnecté par des liens hypertexte fonctionnant comme des mots-clés, qui emmènent l'internaute d'une page à une autre, dont le seul lien est ce mot souligné sur lequel l'utilisateur aura cliqué.

II. 3 liAHRaRIWILdI141r114iRIcRuIIKANn A ARP 11&01nRAMIINHa dans le Web

De nombreuses applications fonctionnent selon un environnement client / serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en terme de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion, etc.

Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client de messagerie, etc. Le programme, tournant sur une machine cliente, est capable de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier électronique).

Dans un environnement purement Client / serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur, c'est un des principaux atouts de ce modèle.

A.



Fonctionnement d'un systVme Client / Serveur Un système Client / Serveur fonctionne selon le schéma illustré par la figure 2.

Figure 2: Système Client / Serveur.

Le client émet une requête vers le serveur grâce à son adresse et le port, et le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port.

B. Présentation de l'architecture à deux niveaux

L'architecture à deux niveaux, appelée aussi architecture 2-tiers (`Tiers' est un mot anglais qui signifie étage) 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. En fait, l'interface graphique se situe sur le poste client et la base de données est localisée sur le serveur. La logique de traitement pouvant se situer sur l'une ou l'autre des parties. Dans une architecture clientserveur à deux niveaux, les PC sont généralement connectés aux serveurs de base de données via un réseau local.

L'utilisateur final contrôle le poste client qui réalise une grande partie des traitements de l'application et sollicite des informations ou des traitements SQL de la part de un ou plusieurs serveurs. Dans le modèle à deux niveaux, une partie de la logique de gestion réside sur le serveur sous la forme de procédures stockées. La caractéristique majeure du serveur est d'itre disponible pour répondre, de préférence de manière simultanée, aux demandes de plusieurs clients. Ce type d'architecture est une bonne solution d'informatique distribuée lorsque le nombre d'utilisateurs ne dépasse pas une centaine d'utilisateurs, cependant il existe



d'une part une limite tenant au fait que la connexion est maintenue en permanence entre le
client et le serveur, meme si aucun travail n'est effectué, d'autre part les procédures d'accès
aux données étant spécifiques aux moteurs de base de données, la flexibilité et le choix d'une

L 'architecture à deux niveaux fonctionne selon le schéma illustré par la figure 3.

Figure 3: Architecture à deux niveaux. C. 3 0 111MIRD STRIRIKIIIRPUlf 1111i 111iDHPq

Dans l'architecture à trois 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 :

· Le client : le demandeur de ressources.

· Le serveur d'application (appelé aussi middleware)

ressource m

· L

service au premier serveur.

La figure 4 montre le fonctionnement de cette architecture.



Figure 4: Architecture à trois niveaux.

Etant donné l'emploi massif du terme d'architecture à 3 niveaux, celui-ci peut parfois désigner aussi les architectures suivantes :

· Partage d'application entre client, serveur intermédiaire et serveur d'entreprise.

· Partage d'application entre client, base de données intermédiaire et base de données d'entreprise.

D. &RPSDIDCIsRQ Ees EIKx NSH d'DIFICIteFEKIe

Dans l'architecture trois tiers ou multi-tiers, un niveau supplémentaire est ajouté entre les deux niveaux précédents, permettant de séparer les traitements de l'interface graphique et du serveur de base de données. Ce niveau intermédiaire peut être implémenté de différentes manières entre moniteur transactionnel, serveur de messages, ou serveur d'application. Le dialogue peut se faire en mode synchrone ou en mode asynchrone, dans ce cas l'utilisateur est informé lors d'une nouvelle connexion du résultat de sa requ~te précédente. L'architecture à trois niveaux supporte de la centaine d'utilisateurs à plusieurs milliers accédant à plusieurs serveurs répartis géographiquement.

La division de l'application en couches distinctes, consacrées à l'interface utilisateur graphique, à la logique de gestion (partitionnée entre plusieurs processeurs) et aux traitements sur la base de données permet de faciliter l'extension et la maintenance des applications tout en offrant un moyen d'intégration des nouvelles applications aux systèmes existants. Ce gain

engendre toutefois des taches plus complexes d'administration des composants de l'architecture (clients, serveurs et équipement réseau) ou du déploiement de l'Inllicltionltilr TrrtiTrs

E. L'architecture Multi-niveaux

LanrlwiiLirre fiv initimLA wnirminur RnitiernLim v) lifurrnuneilme Run iertiinn ILTialinLn _{Lnnminrimimnc} Ttilirim sertiirmuun mTirieuirmiies rinimafiniLl imnirirnlimi nrtiimPmlnimuenwlRILitmminf ^trois nitimLirm Inientiment une iriLiteciri nflN nitimm





Figure 5: Architecture Multi-niveaux.

F. L'acc~s CGI

1n1 1R I,LIn te I,IIntiriace, iningrwdr[miimmLLIne) mrirgi Ltimpirmr unliro,I,LInsitumilim mitieus I riteif une rLT _r inncéilrimclient (Browser). Pour cela un programme externe au serveur Web s'exécute. Celuilli crnrlit L,nv,iqn,enrmimmtrm wuirrriurinimiinmLlifi Tim6 montrrim Tiincipe



Figure 6: Principe des programmes CGI.

IV. La plate-forme J2EE

La plate-forme J2EE (Java 2 Entreprise Edition), est la proposition de SUN pour le développement et la mise en °oeuvre d'applications d'entreprise multi-niveaux. Elle s'appuie entièrement sur le langage JAVA.

J2EE fournit :

· Un modèle de développement de composants Web (Servlets, JSP) et de composants métier (EJB) sous la forme d'APIs JAVA.

· Un ensemble de services (JDBC, JTA, JNDI, JMS, RMI / IIOP, JavaMail, XML), utiles aux composants, sous la forme d'APIs JAVA.

· Un modèle de création de modules Web (.war) de modules EJB (.jar) et de modules d'entreprises (.ear), associés à des descripteurs de déploiement au format XML, utiles pour le déploiement des applications d'entreprise.

· Des conteneurs Web et EJB pour la mise en oeuvre des composants.

A. Les Framework utilisés

Pour réaliser notre application, nous avons utilisé les Framework suivants :

· Spring,

· Struts,

· Hibernate.

1. Le Framework Spring

Le Framework Spring est un conteneur dit « léger a», c'est-à-dire une infrastructure similaire à un serveur d'application J2EE. Il prend donc en charge la création d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets (IoC :Inversion of Control). Le principal avantage par rapport aux serveurs d'application est qu'avec Spring, les classes n'ont pas besoin d'implémenter une quelconque interface pour être prises en charge par le Framework. C'est en se sens que Spring est qualifié de conteneur « léger a». L'idée du pattern IoC est très simple, elle consiste, lorsqu'un objet A a besoin d'un objet B, à déléguer à un objet C la mise en relation de A avec B.

2. Le Framework Struts

Apache Struts est un Framework libre pour développer des applications web J2EE. Il utilise et étend l'API Servlet Java afin d'encourager les développeurs à adopter l'architecture Modèle-Vue-Contrôleur. Struts permet la structuration d'une application Java sous forme d'un ensemble d'actions représentant des événements déclenchés par les utilisateurs de l'application. Ces actions sont décrites dans un fichier de configuration de type XML décrivant les cheminements possibles entre les différentes actions. En plus, Struts permet d'automatiser la gestion de certains aspects comme par exemple la validation des données entrées par les utilisateurs via l'interface de l'application. Ainsi, il n'est plus besoin de venir coder le contrôle de chaque donnée fournie par un utilisateur, il suffit de décrire les vérifications à effectuer dans un fichier XML dédié à cette tâche. La figure 7 illustre l'architecture du Modèle Vue et Contrôleur.



Figure 7: Architecture du Modèle Vue Contrôleur.

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. 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 javaBean héritant de la classe ActionForm. Dans le fichier de configuration struts-config.xml, à chaque URL devant être traitée par programme on associe certaines informations :

· Le nom de la classe étendant Action chargée de traiter la requête.

· 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 si les données qu'il a stockées et qui proviennent du formulaire, sont valides ou non. Pour cela, une méthode du bean appelée validate est appelée automatiquement (si le développeur le souhaite et la définie) par le contrôleur et renvoie éventuellement une liste des erreurs. Dans ce cas là, le contrôleur n'ira pas plus loin et passera la main à une vue déterminée dans son fichier de configuration pour informer l'utilisateur des erreurs qu'il a commis lors de la saisie de son formulaire. 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 exécute 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é.

3. Le Framework Hibernate

Hibernate est un Framework open source gérant la persistance des objets en base de données relationnelle. La manipulation de SQL dans le langage de programmation JAVA est rendue possible par l'utilisation du JDBC. Puisque, chaque requite est effectuée sur le modèle logique de la base de données, cette approche présente l'inconvénient de lier très fortement le code de l'application au schéma de la base de données. En conséquence, toute évolution apportée au modèle logique doit ~tre répercutée sur le code de l'application.

L'outil Hibernate propose une solution à ce problème. Celle-ci consiste à définir, dans des fichiers de configurations, le lien entre le diagramme de classes de l'application qui exploite une base de données et le modèle logique de cette base de données. Il permet ensuite de manipuler les données de la base de données sans faire la moindre référence au schéma de la base de données en utilisant l'API fournie par cet outil gr~ce au lien établi dans les fichiers de configuration.

a. Configuration d'Hibernate

Hibernate est conçu pour pouvoir être utilise dans différents types d'architectures d'application. Pour cela, chaque application doit indiquer à Hibernate comment celui-ci peut accéder et manipuler la source de données dans un fichier de configuration nommé hibernate.cfg.xml.

Les principaux éléments à paramétrer sont les suivantes :

· Le SGDB utilisé. Chaque SGBD propose une implémentation du langage SQL qui diffère souvent de la norme SQL. Hibernate doit connaitre le type de SQL qu'il doit générer.

· La Connexion à la base de données. Si la connexion à la base de données se fait en utilisant JDBC, il faut indiquer à Hibernate, le driver JDBC, l'url de connexion ainsi

qu'un nom d'utilisateur et un mot de passe permettant de se connecter `a la base de données. Les connexions peuvent également etre gérées par un serveur d' J I IIIcT IM IiIIfauIIITTITTTrIàIHITTMINT IcomTnIINIIpTutIaIIIdTrIMITInTxITTs I WITIIparIcTIsTNITuII(AIMINITIJNT).I

· xTsISTNIIITsItiTIM ITITTNIMIT IaIITsIIIIdTIMrTIIunITnsTfTITIMMIIdTIMMTxIVIsIàIlaI basT ITTIMIéTsITtIMI11131ITTIIMITI IMrIcTlI IITTMINTIMMITIunT I IlTinTnrirIiuffTniairTIdTIcTsIsTrvicTmITais IpTuiIaumiIutirTiIdTrIsTnicTsItiTisI TirIpTmmIts I

miIrérrmTi, IlTImi[ImiaxTIdTIHibTrnatTIrrTnsitT I: I

· xaIlMIITIIIVITIImITx1TIdTITITITTsITxpITIIMtIlaIMTIdTIMINTsI; I

· xIMIIIIITIMMINcTI(IIIIIIM ITTIITIlTImITx1TIdTIcNTIsTsITtIEIbIsTIITIdoMTsI; I

· Une configuration au niveau système de l'accès. I

b. 8 lkilisalkioK11 1⁴1-F iblialki

L'utilisation de Hibernate se fait principalement au travers de la classe Session qu'il imilt. IUII1jTtIsTrrImT IlT1IfomrrmrirI111rm1T I:I

· Rendre persistant un objet d'une classe. C'est la méthode save 111Io17ITIcTliT I fonctionnalité. Elle prend en paramètre l'objet à rendre persistant. I

· Charger un objet d'une classe à partir de la base de _1717T1 Ix1I111h11T I11adITstI utilisée à cette fin. Elle prend en paramètre la classe de l'objet à charger ainsi que la valeur de l'identifiant (clé primaire) de cet objet. I

· Modification d'un objet persistant. Il suffit pour cela de modifier la valeur des Viopriétés d'un objet puis d'appeler la méthode flush de l'objet session. I

· Suppression d'un objet persistant. L'appel de la méthode delete avec en paramètre un objet persistant se charge d'effectuer la suppression dans la base de données. I

· xTcxTrcxTiIdTrIobjTts IHibTrnmTIiroposTIunIlmx,xTIdTIrTqmxiTIriTntéIob ItsInomé I HQL dont la syntaxe est similaire au SQL et qui permet d'effectuer des requetes sur le 111x1TI11j1t. I

La figure 8 illustre l'architecture de Hibernate. I





Figure 8: Architecture d'Hibernate.

V. Architecture 3-tiers et mise en place du modèle MVC

Une application Web possède souvent une architecture 3-tiers :

· la couche dao s'occupe de l'accès aux données, le plus souvent des données persistantes au sein d'un SGBD.

· La couche métier implémente les algorithmes " métier " de l'application. Cette couche est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être utilisable aussi bien avec une interface console, 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. C'est généralement la couche la plus stable de l'architecture. Elle ne change pas si on change l'interface utilisateur ou la façon d'accéder aux données nécessaires au fonctionnement de l'application.

· La couche interface utilisateur qui est l'interface (graphique souvent) qui permet à l'utilisateur de piloter l'application et d'en recevoir des informations.

Les couches métier et dao sont normalement utilisées via des interfaces Java. Ainsi la couche métier ne connaît de la couche dao que son ou ses interfaces et ne connaît pas les classes les implémentant. C'est ce qui assure l'indépendance des couches entre-elles : changer l'implémentation de la couche dao n'a aucune incidence sur la couche métier tant qu'on ne touche pas à la définition de l'interface de la couche dao. Il en est de même entre les couches interface utilisateur et métier.

L'architecture MVC prend place dans la couche interface utilisateur lorsque celle-ci est une interface web. La figure 9, illustre l'architecture 3-tiers et la mise en place du MVC.



Figure 9: Architecture 3-tiers et mise en place du MVC.

Le traitement d'une demande d'un client se déroule selon les étapes suivantes :

1/ Le client fait une demande au contrôleur. Celui-ci voit passer toutes les demandes des clients. C'est la porte d'entrée de l'application. C'est le C de MVC.

2/ Le contrôleur C traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la couche métier. Une fois la demande du client traitée, celle-ci peut appeler diverses réponses. Un exemple classique est :

· une page d'erreurs si la demande n'a pu être traitée correctement.

· une page de confirmation sinon

3/ Le contrôleur choisit la réponse (une vue) à envoyer au client. Choisir la réponse à envoyer au client nécessite plusieurs étapes:

· choisir l'objet qui va générer la réponse. C'est ce qu'on appelle la vue V, le V de MVC. Ce choix dépend en général du résultat de l'exécution de l'action demandée par l'utilisateur.


· lui fournir les données dont il a besoin pour générer cette réponse. En effet, celle-ci contient le plus souvent des informations calculées par le contrôleur. Ces informations forment ce qu'on appelle le modèle M de la vue, le M de MVC. L'étape 3 consiste donc en le choix d'une vue V et en la construction du modèle M nécessaire à celle-ci.

4/ Le contrôleur C demande à la vue choisie de s'afficher. Il s'agit le plus souvent de faire exécuter une méthode particulière de la vue V chargée de générer la réponse au client.

5/ Le générateur de vue V utilise le modèle M préparé par le contrôleur C pour initialiser les parties dynamiques de la réponse qu'il doit envoyer au client.

6/ La réponse est envoyée au client. La forme exacte de celle-ci dépend du générateur de vue. Ce peut être un flux HTML, PDF, Excel... Dans notre application, et pour plus de simplicité, la couche métier est intégrée au générateur de vue.

Conclusion

Nous avons présenté dans ce chapitre, l'environnement dans lequel notre application a été réalisée. La réalisation est basée sur un modèle conceptuel. C'est ce que nous allons présenter dans le prochain chapitre.



Modélisation Conceptuelle

Chapitre 3 :

Introduction

Ce chapitre a pour but d'analyser les fonctionnalités de l'application, de définir les droits d'accès pour l'acteur et de présenter les différents diagrammes et modèle de

conception en utilisant le langage UML. Nous allons procéder comme suit : En premier lieu,

nous présentons les approches de conception. Dans un second temps, nous présentons le cycle

de développement d'un logiciel. Enfin et dans la dernière partie nous présentons les différents diagrammes relatifs à chaque acteur.

I. Choix de la méthode de conception

D eux approches de conceptions existent : l'approche fonctionnelle qui voit le système
comme un ensemble de fonctions à réaliser et l'approche objet qui voit le système comme un ensemble d'objets.

On choisira dans ce projet l'approche objet. La modélisation objet consiste à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse.

A. Le langage UML

Unified Modeling Language, dont le développement a commencé en 1994, est un outil

de m

décrire des artefacts d'un système logiciel. Pour cela UML se base sur une sémantique précise

conception de

programmes, ainsi que leur description pour des non informaticiens. Ce mode

de conception repose donc sur les principes de la programmation objet. UML modélise les

objets et leurs liens au moyen de vues constituées de diagrammes.

B. Les Vues UML

U ML fournit un moyen astucieux permettant de présenter diverses projections d'une

meme représentation grace aux vues. Une vue est constituée d'un ou plusieurs diagrammes.

O

1. Les vues statiques

E lles permettent de représenter le système physiquement. On trouve alors les

diagrammes suivants :

- Le Diagramme de classes : il représente la structure statique en termes de classes et de relations entre elles, il représente aussi un ensemble d'interface et de paquetages ainsi que leurs relations.

- Le Diagramme d'objets ou le diagramme d'instances : représente une instance possible du diagramme de classes.

- Le Diagramme de composants : représente les morceaux d'applications packagés sous la forme de composants disposants d'interfaces. Il permet de décrire ces composants qui sont : le sous-système, le module, le programme et le sous-programme, le processus et la tâche.

- Le Diagramme de déploiement : complémentaire du diagramme de composants, il décrit la répartition physique des instances de composants, de processus et d'objets d'une application distribuée.

2. Les vues dynamiques

Les cinq diagrammes comportementaux (ou dynamiques) représentent des vues dynamiques du système :

- Le Diagramme de cas d'utilisation : sont des vues qui décrivent les interactions entre les différents acteurs externes (utilisateurs du cas) et les fonctionnalités du système. La description de l'interaction est réalisée suivant le point de vue de l'utilisateur. Leur but est d'identifier les acteurs du domaine, leurs responsabilités respectives et de décrire leurs besoins.

- Le Diagramme de collaboration : il décrit l'interaction modélisée par les échanges de messages entre objets ou entre acteurs et objets.

- Le Diagramme de séquence : il diffère légèrement du diagramme de collaboration par l'ajout d'une dimension temporelle en précisant la chronologie des échanges de messages entre les objets.

- Le Diagramme d'états transitions : il décrit l'ensemble des états des objets du système et les transitions qui déclenchent le passage d'un état donné vers un autre état.

- Le Diagramme d'activités : est une variante des diagrammes d'états-transitions. Il décrit l'ensemble des activités effectuées par les acteurs du système en les décomposant en sous-activités et en spécifiant les contraintes relatives à l'enchaînement de ces dernières.

C. Avantages d'UML

UML est un langage formel et normalisé qui facilite la compréhension de représentations abstraites complexes et le principal avantage d'UML est qu'il est devenu le standard en terme de modélisation objet, son caractère polyvalent et performant et sa souplesse en fait un langage universel.

Ces avantages sont multiples :

· UML est un langage formel et normalisé.

· Gain de précision.

· Gage de stabilité.

· Encourage l'utilisation d'outils.

· UML est un support de communication performant.

· Il cadre l'analyse.

· Il facilite la compréhension de représentations abstraites complexes.

Le principal avantage d'UML est qu'il est devenu le standard en termes de modélisation objet, son caractère polyvalent et performant et sa souplesse en fait un langage universel.

II. $ AFhZIFtuAILIpnpADleLdILl'ISSOFItiK

En respectant la répartition en trois couches, nous avons décomposé notre application en quatre « package » : web, service, dao et model.

$ ISELW 113'PQ1SEIFI113ITAX, TlTMSEtIN lEnFIBMIRINIMIX sera interceptée par le FRQ440e1C ESLI 113eIIieIBp0FliRncHI'EFIRn E113iIuEIM113XESEFNEgI1« web » pour prendre en FIEUI RENFIX^-111 LlEF\IRQINE ESSITHIDn FILIEEQKRP EIFI113eIARYIFINTESSELIMEnt EXSEFNEIe « service ») qui représentent la logique applicatiY11113e11ESSOFEIiRn SRXTrEEMRERFIDOM AEE FRP P XJFEIIRQ1111Enf NEVIIIMPWEFF I« service Interface »). Pour accomplir sa tâche, la couche « service » aura besoin des composants « DAO Implémentation » (du package « dao ^a») 113eIlEWFROFKI113VEFFqVER R113RCIIeKqDEIIFYSqlEX113MIIsuItEts _sRXVIRIP 11113'REjets (appartenant au package « model ^a 1 11XLIeSIIA11241t431113RP EIQ-1113e1l¹ESSOFEtARn. EQIQ UD E contrôleur sélectionne la page de vue adéquate pour visualiser les résultats de traitement.

III. Conception détaillée

Dans notre application, nous allons définir les étapes suivantes : 1- Définir les acteurs et les activités.

2- Définir les diagrammes des cas d'utilisations.

3- Définir les diagrammes de séquences.

4- Définir le diagramme de classes.

La démarche adoptée pour élaborer le projet est la suivante : A partir de la définition des besoins, nous allons identifier les acteurs et les activités, desquels nous déduirons le diagramme de cas d'utilisation.

A. Les diagrammes de cas d'utilisation

On utilise les diagrammes des cas d'utilisation pour représenter et structurer au niveau conceptuel, les besoins des utilisateurs et les objectifs correspondants du système. Le but est d'identifier les acteurs du domaine et leurs interactions avec l'interface. Ce diagramme permet de déterminer le modèle objet sur lequel le système reposera.

> Avantages

· Formalisme simple : Les concepts proposés sont faciles à comprendre et à utiliser.

· Les modélisations résultats : Facile à comprendre, à lire et à interpréter.

· Un bon moyen de communication.

> Identification des acteurs

Un acteur représente un rôle joué par une entité externe qui interagit directement avec le système étudié.

On distingue deux intervenants qui interagissent avec l'interface : l'adhérant et le bibliothécaire.

> Identification des activités

Décrit l'ensemble des activités effectuées par les acteurs du système en les décomposant en sous activités et en spécifiant les contraintes relatives à l'enchaînement de ces activités.

> ,SHAiIIHAiIn SR IEs SNAVAIANOSEBBIJIIANn de la bibliothèque : Le bibliothécaire effectue :

· Recherche des documents,

· Gestion des documents,

· Gestion des prêts,

· Gestion des adhérents,

· Gestion des retours,

· Gestion des retards. L'adhérant effectue :

· Recherche des documents qui peut être selon un ou plusieurs critères (par maison d'édition, par thème, par sous thème, par auteur, par mots clés~).

Ces activités peuvent être résumées par le diagramme suivant :

> Diagramme de cas d'utilisation

Dans notre contexte, le diagramme de cas d'utilisation comporte les acteurs :

· Bibliothécaire.

· Adhérant.





Figure 10 : Diagramme de cas d'utilisation pour la gestion de la bibliothèque.

> Description Textuelle :

Titre : Recherche des documents selon un critère donné

Acteur principal : Adhérant, Bibliothécaire.

Pré-conditions :

- Connexion internet établie

Objectif : faire une recherche sur les documents, selon un critère donnée, existant dans la bibliothèque. Scénarios :

Scénario Nominal		Scénario Alternatif	6F1pc111103^11pFKEFs
Action des Acteurs	Réaction du Système	A1 : Champs obligatoires vides. Le Scénario Alternatif démarre 8) 9) Le système indique à l'utilisateur qu'il y a un champ obligatoire vide. Le Scénario Nominal reprend au 5)	E1 : Refus de recherche. Le Scénario d'Echecs démarre 9) 10) Le système indique à l'utilisateur que la recherche est impossible. 11) Le cas d'utilisation se termine avec Echec.
1) L'utilisateur se connecte au système. 3) L'utilisateur choisit la recherche des documents. 4) L'utilisateur valide son choix. 6) L'utilisateur saisit les informations relatives à la recherche.	2) Le système affiche le menu principal. 5) Le système affiche le formulaire relatif à la recherche des documents.
7) L'utilisateur valide ses	8) Le système vérifie que tous les				informations.
champs obligatoires sont remplis.
9) le système affiche le résultat de la recherche.

Tableau 4: Recherche des documents selon un critère donné.

Titre : Gestion de prêts.

Acteur principal : Bibliothécaire.

Acteur secondaire : Adhérant.

Pré-conditions :

- Connexion internet établie.

- Le document existe et disponible.

- L'adhérant a été reconnu par le système. Post-conditions :

- L'adhérant prend le document preté pendant une durée donnée. Scénarios :

Scénario Nominal		Scénario Alternatif	6IOKDURVOMIs
Action des Acteurs	Réaction du Système	A1 : Echec de l'authentification.	E1 : L'adhérant n'est pas inscrit.
1) L'adhérant se présente au		Le Scénario Alternatif démarre 7)	Le Scénario d'Echecs démarre 12)
guichet et demande un document.		8) Le système informe au	13) Le système indique au
2) Le bibliothécaire se connecte	3) Le système affiche le menu	bibliothécaire que	bibliothécaire que l'adhérant
au système.	principal.	l'authentification est échouée et lui	n'existe pas.
	4) Le système demande au	demande de s'authentifier.	14) Le cas d'utilisation se termine
5) Le bibliothécaire s'authentifie.	bibliothécaire de s'authentifier.	Le Scénario Nominal reprend 4)	avec échec.
6) Le bibliothécaire valide ses	7) Le système vérifie la validité des	A2 : Champs obligatoires vides.
informations.	informations.	Le Scénario Alternatif démarre 12)
8) le bibliothécaire choisit	9) le système affiche le formulaire	13) Le système indique au
Emprunt document. 10) Le bibliothécaire saisit les informations relatives à la demande d'emprunt.	relatif à la demande de prêt.	bibliothécaire qu'il y a des champs obligatoires non remplis. Le Scénario Nominal reprend 9).
11) Le bibliothécaire valide les données.	12) Le système vérifie la validité des données et que tous les champs obligatoires sont remplis.
14) Le bibliothécaire demande d'enregistrer le prt et de mettre à jour l'état du document.	13) Le système affiche à la bibliothécaire toutes les informations relatives à ce prêt.
15) Le bibliothécaire valide.	16) Le système informe au
	bibliothécaire que le prêt a été
	enregistré et l'état du document a été
	mis à jour.

Tableau 5: Gestion de prêts.

Titre : Gestion des adhérents.

Acteur principal : Bibliothécaire.

Pré-conditions :

- Connexion internet établie. Post-conditions :

- Un nouveau adhérant ajouté ou mis à jour ou supprimé.
Objectif : La gestion des adhérents est effectuée par le bibliothécaire.

Scénarios :

Scénario Nominal		Scénario Alternatif	6 IfpatIlpfpFKFIs
Action des Acteurs	Réaction du Système	A1 : Echec de l'authentification. Le Scénario Alternatif démarre 6) 7) Le système indique au bibliothécaire l'échec de	E1 : Refus de faire l'opération. Le Scénario d'Echecs démarre 13) 14) Le système indique au bibliothécaire que l'opération n'a
1) Le bibliothécaire se connecte au système.	2) Le système affiche le menu principal. 3) Le système demande au
4) Le bibliothécaire s'authentifie. 5) Le bibliothécaire valide. 17	bibliothécaire de s'authentifier. 6) Le système vérifie la validité des informations. 7) Le système affiche l'interface	l'authentification et lui demande de s'authentifier. Le Scénario Nominal reprend 3) A2 : Les champs obligatoires sont	pas pu être effectuée. 15) Le cas d'utilisation se termine avec échec.		8) Le bibliothécaire choisit la
personnelle.	vides.		gestion des adhérents.
9) Le système affiche le formulaire	Le Scénario Alternatif démarre 12)		10) Le bibliothécaire remplie tous
relatif.	13) Le système indique au
les champs obligatoires.		bibliothécaire qu'il y a un champ
11) Le bibliothécaire valide.	12) Le système vérifie que les	obligatoire vide.
	champs obligatoires sont remplis.	Le Scénario Nominal reprend 9).
14) Le bibliothécaire se	13) Le système affiche que
déconnecte.	l'opération (ajout, modification,...) a été effectuée.

Tableau 6: Gestion des adhérents.

Titre : Gestion des documents.

Acteur principal : Bibliothécaire. Pré-conditions :

Connexion internet établie.

Post-conditions :

Un nouveau document ajouté ou mis à jour ou supprim

Objectif : La gestion des documents est effectuée par le bibliothécaire. Scénarios :

Scénario Nominal		Scénario Alternatif	Scénario d'échecs
Action des Acteurs	Réaction du Système	A1 : Echec de l'authentification.	E1 : Refus de faire l'opération.
1) Le bibliothécaire se connecte	2) Le système affiche le menu	Le Scénario Alternatif démarre 6)	Le Scénario d'Echecs démarre 13)
au système.	principal.	7) Le système indique au	14) Le système indique au
	3) Le système demande au	bibliothécaire l'échec de	bibliothécaire que l'opération n'a pas
4) Le bibliothécaire	bibliothécaire de s'authentifier.	l'authentification et lui demande de	pu être effectuée.
s'authentifie.		s'authentifier.	15) Le cas d'utilisation se termine
5) Le bibliothécaire valide.	6) Le système vérifie la validité des informations.	Le Scénario Nominal reprend 3) A2 : Les champs obligatoires sont	avec échec.
8) Le bibliothécaire choisit la	7) Le système affiche l'interface	vides.
gestion des documents.	personnelle.	Le Scénario Alternatif démarre 12)
10) Le bibliothécaire remplie les	9) Le système affiche le formulaire	13) Le système indique au
champs obligatoires.	relatif.	bibliothécaire qu'il y a un champ
11) Le bibliothécaire valide.	12) Le système vérifie que tous les champs obligatoires sont remplis.	obligatoire vide. Le Scénario Nominal reprend 9).
14) Le bibliothécaire se déconnecte.	13) Le système affiche que l'opération a été effectuée.

Tableau 7: Gestion des documents.

Titre : Gestion de retours.

Acteur principal : Bibliothécaire. Acteur secondaire : Adhérant. Pré-conditions :

- Connexion internet établie.

- Le document existe et est déjà prêté.

- L'adhérant a été reconnu par le système. Post-conditions :

- L'adhérant rend le document prité. Scénarios :

Scénario Nominal		Scénario Alternatif	Scénario d'échecs
Action des Acteurs	Réaction du Système	A1 : Echec de l'authentification. Le Scénario Alternatif démarre 7) 8) Le système demande au bibliothécaire de s'authentifier en lui informant l'échec de l'authentification. Le Scénario Nominal reprend 4).	E1 : L'adhérant n'est pas inscrit. Le Scénario d'Echecs démarre 12) 13) Le système indique au bibliothécaire que l'adhérant n'existe pas. 14) Le cas d'utilisation se termine avec échec.
1) L'adhérant se présente au guichet et rend le document. 2) Le bibliothécaire se connecte au système.	3) Le système affiche le menu principal. 4) Le système demande au bibliothécaire de s'authentifier.
5) Le bibliothécaire		A2 : Les champs obligatoires sont
s'authentifie.		vides.
6) Le bibliothécaire valide.	7) Le système vérifie la validité des	Le Scénario Alternatif démarre 13)
	données.	14) Le système informe au
	8) le système affiche l'interface	bibliothécaire qu'il y a un champ
9) Le bibliothécaire choisit	personnelle.	obligatoire vide.
retour d'un document.	10) le système affiche le formulaire	Le Scénario Nominal reprend 10).
11) Le bibliothécaire remplie les	relatif.	A3 : Les données sont invalides.
champs obligatoires.		Le Scénario Alternatif démarre 13).
12) Le bibliothécaire valide.	13) Le système vérifie que tous les	14) Le système informe au
	champs obligatoires sont remplis et	bibliothécaire que les données sont
	valides.	invalides.
	14) Le système affiche au bibliothécaire toutes les	Le Scénario Nominal reprend 10).
15) Le bibliothécaire demande	informations relatives à cet emprunt.
au système de supprimer
l'emprunt et d'actualiser l'état	17) Le système informe au
du document.	bibliothécaire que l'emprunt a été
16) Le bibliothécaire valide.	supprimé et l'état du document est
18) Le bibliothécaire se	actualisé.
déconnecte.

Tableau 8: Gestion de retours.

Titre : Gestion des retards.

Acteur principal : Bibliothécaire. Pré-conditions :

- Connexion internet établie.

- Un retard est notifié.

- L'adhérant ne peut pas prêter un document. Post-conditions :

- Un avertissement est envoyé à l'adhérant. Objectif : Vérifier les dépassements de délai des prêts.

Scénarios :

Scénario Nominal		Scénario Alternatif	6c1pc111103^11pHOcs
Action des Acteurs	Réaction du Système	A1 : Echec d'authentification. Le Scénario Alternatif démarre 6) 7) Le système informe au bibliothécaire l'échec de l'authentification et lui demande de s'authentifier. Le Scénario Nominal reprend 3).	E1 : Refus de trie de la liste des retardataires. Le Scénario d'Echecs démarre 11) 12) Le système informe au bibliothécaire que le trie est impossible. 13) Le cas d'utilisation se termine
1) Le bibliothécaire se connecte au système. 4) Le bibliothécaire s'authentifie. 5) Le bibliothécaire valide.	2) Le système affiche le menu principal. 3) Le système demande au bibliothécaire de s'authentifier. 6) Le système vérifie la validité des
8) Le bibliothécaire choisit	données. 7) le système affiche l'interface		avec échec. E2 : Refus d'envoi du message.
gestion des retards.	personnelle.		Le Scénario d'Echecs démarre 16)
10) Le bibliothécaire recense la	9) le système affiche l'interface de		17) Le système informe au
liste des adhérents dans lequel	gestion des retards.		bibliothécaire que l'envoie est
la date de retour prévue			impossible.
correspond à la date système.			18) Le cas d'utilisation se termine
11) Le bibliothécaire demande			avec échec.
au système de classifier les
adhérents selon un ordre
chronologique.
12) Le bibliothécaire valide.	13) Le système trie la liste des
15) Le bibliothécaire rédige un	adhérents en retard.
message d'avertissement pour	14) Le système affiche au
chaque retardataire en	bibliothécaire liste des retardataires.
mentionnant les documents
prêtés.
16) Le bibliothécaire envoie le					message.
17) Le système informe au			18) Le bibliothécaire se
bibliothécaire que le message est
déconnecte.	envoyé.

Tableau 9: Gestion des retards.

B. Les diagrammes de séquence

Le diagramme de séquence permet de représenter les échanges entre les composants et

les objets du système, dans le cadre d'exécution des cas d'utilisation, de point de vue temporel.

Dans ce qui suit, nous présentons toutes les fonctions de l'utilisateur à travers des différents diagrammes de séquences.

1. Authentification de l'administrateur Avant d'aborder l'emprunt, le retour, la gestion des adhérents, la gestion des

documents et la gestion des retards, nous développons le diagramme de séquence de

l'authentification tel que décrit dans la figure 11.



Figure 11: Diagramme de séquence pour l'authentification.

2. Gestion des adhérents
· Ajout d'un nouvel adhérent i

La figure 12 décrit l'ajout d'un nouvel adhérent (en tant qu'étudiant ou enseignant). Nous faisons appel à un scénario de création d'un adhérant. Le système retourne une réponse une fois l'enregistrement est fait, car cette séquence est invoquée lors de l'ajout d'un nouvel adhérent.



Figure 12: Diagramme de séquence pour l'ajout d'un nouveau adhérant.
· SupSIIMIRQ d'MQ IEKplIQA :

/ a IUMrIITE MMsArIME sMSSIIMIRQCO'MQIIdKérIQA IQ AaQA qMI IAM3DQA OMiTEIiQiAIK études ou un enseignant qui a achevé son enseignement.



Figure 13: Diagramme de séquence pour la suppression d'un adhérant.

3. Gestion des documents ? Ajout d'un document :

La figure 14 illustre l'ajout d'un nouveau document. En effet, lorsqu'un document n'existe pas, il est nécessaire d'invoquer son ajout et son enregistrement. Sinon, si le document exiIte, il eIt néceIIaire de l'ajouter et l'enregistrer dans l'exemplaire.



Figure 14: Diagramme de séquence pour l'ajout d'un nouveau document. ? Suppression d'un document

Le scénario de la figure 15 décrit la suppression d'un document. On peut accéder à un tel document à partir de la table exemplaire afin de supprimer l'exemplaire et puis mettre à jour la table document (nombre d'exemplaires acquis) et enregistrer la suppression.



Figure 15: Diagramme de séquence pour la suppression d'un document.

4. Gestion des emprunts

Le diagramme de la figure 16 illustre les séquences de messages induites par

l'emprunt de documents par un adhérant dans la bibliothèque, telle que l'existence de document et la réservation éventuelle du document.



Figure 16: Diagramme de séquence pour l'emprunt d'un document.

5. Gestion des retours

Le scénario de la figure 17 illustre le retour de document. Le retour de document est

déclenché par un adhérant et le bibliothécaire supprime l'emprunt.



Figure 17: Diagramme de séquence pour le retour d'un document.

6. Gestion des retards

La figure 18 illustre le scénario relatif à la gestion des retards.



Figure 18: Diagramme de séquence en cas du retard de retour d'un document.

A. Digramme de classe

Le diagramme de classes exprime la structure statique d'un système en représentant

Le diagramm



Figure 19: Digramme de classes de notre application.

Conclusion

Tout au long de ce chapitre nous avons mené une conception détaillée du système d'information selon une approche objet afin de garantir la fiabilité et l'efficacité de la phase de réalisation de l'application.

Nous avons dressé une liste des acteurs constituants le système en exprimant leurs besoins avec les diagrammes de cas d'utilisation, puis nous l'avons détaillé en précisant comment les objets et les acteurs doivent collaborer ensemble selon une dimension temporelle par l'utilisation des diagrammes de séquence. Finalement, nous avons décrit l'aspect statique avec les diagrammes des classes.

A l'aide de l'étude de notre cas nous avons déterminé l'environnement de développement de notre application qui sera présentée dans le chapitre suivant.



Réalisation

Chapitre 4 :

Introduction

Une fois la partie de conception achevée, tous les éléments nécessaires au développement de l'application deviennent disponibles.

Ce chapitre présente les différents outils et techniques informatiques qui ont été utilisés pour la réalisation de notre application. Le premier paragraphe est consacré à l'étude de l'environnement matériel. L'environnement logiciel sera présenté dans un deuxième paragraphe. En dernier lieu, on présente l'architecture de notre application avec un aperçu sur les maquettes des interfaces, ainsi que les différentes fonctionnalités de l'application illustrées par des images écrans.

I. Environnement de développement

A. Environnement matériel

1. PC

Pour la réalisation de notre travail, nous avons utilisé un seul PC.

Caractéristiques		Valeur	Disque dur
320 Go		Type de processeur
,Intel® CoreTM2 Duo		Fréquence du processeur
2.00 GHz		Mémoire centrale
3 Go		Système d'exploitation
Windows 7

Tableau 10: Environnement matériel utilisé.

B. Environnement logiciel

1. Eclipse Eclipse JEE Galileo est un environnement de développement gratuit pour le langage

JAVA. Son point fort est de permettre l'intégration des fonctionnalités supplémentaires par l'intermédiaire des plugins. Il a été utilisé avec le plugin J2EE qui offre des outils pour accélérer le développement des applications Web basées sur les Frameworks

2. MySQL MySQL est un serveur de base de données relationnelle SQL. Il est multi-thread et

multi-utilisateurs. Il est très souvent utilisé avec le langage de création des pages Web dynamiques JSP.

3. Apache Tomcat 6.0 C'est un conteneur de Servlets J2E

JSP de Sun Microsystems Les projets dé plupart des autres conteneurs (J2EE Serv contrôlé à partir d'Eclipse Europa.

4. Rational Rose Rational Rose est développé par Rational Software Corporation, offrant une aide

considérable pour les concepteurs utilisant l'approche objet notamment ceux qui ont migré vers UML en permettant la représentation graphique et la génération de code. Cet outil offre des possibilités graphiques pour représenter les différents diagrammes d'UML tels que :

· xiagramme de classes,

· xiagramme de collaborations

· xiagramme de séquences,

· Etc...

Rational Rose permet de générer à

développeurs tel que : C++ JAVA Visual Basic, SQ

5. Adobe Photoshop 7.0 dobe

pour l'impression et le Web. Il a été utilisé pour créer l'aspect graphique des interfaces ainsi que les éléments graphiques qu'ils les constituent.

6. Adobe DreamWeaver CS3 Pour la production des pages HTML et JSP, nous avons utilisé Adobe xreamWeaver

CS3 qui est un éditeur HTML professionnel destiné à la conception, au codage et au

développeurs de site, de pages et d'applications Web. Quel que soit l'environnement de travail utilisé (codage manuel HTML ou environnement d'édition visuel), DreamWeaver propose des outils qui aideront à créer des applications Web.

II. Implémentation

Nous allons présenter dans cette section le travail réalisé dans le cadre de ce projet par l'intermédiaire de captures écrans de quelques pages de notre application Web.

A. Page d'accueil

Lors de lancement de notre application, la page d'accueil s'affiche pour choisir une tâche parmi celle indiquée dans le menu comme illustre la figure 20.



Figure 20: Page d'accueil.

B. Recherche des documents Cette page est destinée pour tout adhérant (étudiant ou enseignant) voulant faire une

recherche sur un document donné selon plusieurs critères comme illustré la figure 21.



Figure 21: Recherche des documents.

C. Bibliothèque

Cette page est réservée au bibliothécaire, après son authentification, il choisi une



Figure 22: Page réservée au bibliothécaire.

parmi des tches indiquée dans le menu comme l'indiquent la figure 22 et 23.



Figure 23: Partie réservée au bibliothécaire.

D. Gestion des documents

Pour faire la gestion des documents, le bibliothécaire, après avoir s'authentifier, choisi



Figure 24: Gestion des documents.

la tâche Gestion des Documents comme illustré la figure 24.

Conclusion

Nous avons présenté dans ce chapitre la réalisation de notre application. Différentes fonctionnalités ont été développées afin de faciliter l'accès et l'exploitation des données relatives à la gestion de la bibliothèque.

Conclusion et perspectives

Les applications Web (application de gestion utilisant une interface Web) tendent à supplanter les applications de gestion classique gr~ce aux nombreux avantages qu'elles apportent :

· Aucune installation de logiciel n'est nécessaire sur le poste client, un navigateur Web suffit.

· Evolutivité aisée des applications, vu qu'il n'est pas nécessaire de les déployer sur les postes clients.

· Possibilité d'accès à distance.

· Compatibilité avec différents systèmes d'exploitation : Windows, Mac OS, Linux, Pocket PC ou téléphone mobile.

Pour saisir ces avantages, notre projet de fin d'études a été abordé dans le but de réaliser une application Web en J2EE pour la gestion de la bibliothèque permettant la gestion, la recherche et l'emprunt des documents, la gestion des adhérents et des retards.

Ce projet de fin d'études nous a été bénéfique car il nous a permis de bien nous familiariser à programmer en J2EE et les Frameworks open source Struts, Spring et Hibernate.

Nous envisageons d'améliorer notre application en lui ajoutant d'autres modules comme la gestion des documents en utilisant les codes à barres et la gestion des prêts. Nous envisageons également de réaliser un site Web consacré à l'application à fin de pouvoir la commercialiser.

Bibliographie

[DUB, RET, 08] : Julien DUBOIS, << Spring par la pratique », EYROLLES, 2008. [PAT, 07] : Anthony PATRICIO, << Java Persistance et Hibernate », EYROLLES, 2007.

Webographie

[site1] : http://projets-gmi.iup.univ-avignon.fr/projets/proj0708/M2/p09/rapport.pdf [site2] : http://www.java2s.com

[site3] : www.developpez.com

[site4] : http://www.vaannila.com