Modélisation de la partie statique du système d’information de la bibliothèque

Télécharger le fichier pdf d’un mémoire de fin d’études

Modèle générale d’architecture système

Toutes les architectures informatiques client/serveur présentent des caractéristiques communes :
· Elles intègrent une interface utilisateur souvent graphique (GUI) ;
· Elles fonctionnent grâce à des applications ;
· Les applications qui les animent manipulent des données.
C’est la répartition de ces trois composantes entre le client et le ou les serveurs qui caractérise les différentes architectures.

Espace serveur

Quelques exemples de serveurs :
· Le serveur objet
Le serveur objet exécute la logique applicative auquel le client se connecte par l’intermédiaire d’un protocole d’objets distribués. Les objets qu’héberge ce serveur, peuvent éventuellement être conditionnés sous la forme de composant.
· Le moniteur transactionnel
Son but est de coordonner l’exécution des transactions distribuées sur plusieurs machines. Par exemple : si l’utilisateur veut à la fois réserver un avion et un hôtel, à l’aide d’une même application, alors l’application devra s’assurer qu e la transaction a lieu intégralement ou pas du tout. Le moniteur transactionnel sera alors très utile pour coordonner ces deux réservations simultanées et s’assurer de l’atomicité (ACID) de ’opérationl composée.
· Le serveur web
Le serveur web, selon le cas, à pour rôle de serveu rs de fichiers ou celui de middleware
· Le serveur de sécurité
Le serveur de sécurité gère l’authentification desutilisateurs et le chiffrement des flux de communication. La norme LDAP (Lightweight Directory Access Protocol) mise en œuvre par Netscape à la fin des années 90, s’impose aujourd’hui comme le standard d’un serveur d’annuaire distribué. LDAP est ainsi au centre de tous les systèmes de sécurité à base de cryptage à clé publique.

Espace client

Le logiciel client n’est pas lié à la machine qui le fait tourner, il doit être portable et mobile. Dece fait, l’espace client est souvent unique pour un utilisateur donné et sa localisation physique est en principe indéterminée.

Les briques de l’architecture système

Interface utilisateur

Aujourd’hui, les interfaces utilisateurs sont interactives, multimédia, et de préférence portables, c’est à dire des interfaces graphiques pouvant fonctionner sur tous les systèmes d’exploitation et conservant toujours le même aspect.

Les applications

Le choix en matière de langage de développement estconsidérable, il faut savoir qu’ils sont le plus souvent de haut niveau, c’est à dire qu’ils re stent éloigner des préoccupations bassement matériels, ces détails sont réglés automatiquementLe. développement peut donc se concentrer sur la logique de l’application. Langages de scripts (Perl, PHP, TCL, JavaScript, VBScript) et langages objet (Java, C++, VB.Net, C#) prédominent largement. Les premiers sont très simple et permettent de développer rapidement des petites applications.
Pour des projets de plus grandes envergures, il est nécessaire d’avoir recours au langage objet de troisième génération. Dans la pratique, les applications d’entreprises mettent souvent en jeu de combinaisons de ces deux types de langage.
Cependant, le problème du développement informatique ne se limite pas au choix d’un langage.
La qualité d’une application informatique s’exprime selon quatre axes :
· Facilité de développement (FAIRE) ;
· Facilité de déploiement (INSTALLER) ;
· Facilité à être maintenu ou maintenabilité (METTREA JOUR) ;
· Facilité de réutilisation (RECYCLER).
Dans les architectures client/serveur, l’optimum de qualité est atteint par le recours à la programmation objet ou à base de composant (ActiveX , DLL,…) Ces briques logicielles qui servent à construire l’édifice applicatif, sont généralement développées dans des langages compilés de troisième génération comme C++ ou JavaLa. gestion des interfaces graphiques de type HTML est par contre, simplifiée par l’utilisation de langage de script côté serveur. On assiste actuellement à la multiplication des solutions offr ant des combinaisons de script et de composants : les langages de scripts jouent le rôle d’intermédiaire entre le serveur d’application et les composants qu’il héberge (ASP/ActiveX, JSP/EJB, JavaScript/EJB).

Les données

La très grande majorité des données de gestion estencore à l’heure actuelle stockée dans des bases de données non relationnelles, dans des « Mainframes » jusqu’à une époque très récente. La plupart des éditeurs de solution intranet avait purement et simplement oublié ce fait.
Les accès se limitaient aux données relationnelles (Sybase, Oracle à travers SQL) souvent exclusivement au travers de l’interface ODBC (Open DataBase Connectivity) de Microsoft.
Les Systèmes de Gestion de Base de Données Objet nepercent toujours pas. Leurs qualités sont pourtant indéniables lorsque l’homme mène un projetobjet :
· La persistance des données objets est gérée presqueautomatiquement ;
· Il n’est pas nécessaire de constituer une correspondance entre la représentation des données et leur représentation sous forme relationnelle ;
· Les performances sont aussi bonnes voire meilleures qu’avec le SGBDR ;
· L’administration de base de données est souvent plus aisée qu’avec le SGBDR.

Le Middleware

Pour lier efficacement les différentes composants d’une application client/serveur, il est parfois nécessaire d’avoir recours à des logiciels spécifiques : « les middlewares »
Comme leur nom l’indique, ce sont des intermédiaires. Ils servent à simplifier le travail du développeur en se chargeant d’un point particulier. Ils sont de plusieurs types, les principaux étant :
· Les middlewares d’accès aux données :
Ils mettent en communication les applications avec les différentes sources de données de l’entreprise.
· Les ORB (Object Request Broker) :
Leur premier but est de rendre plus transparente la communication avec les applications situées sur des machines distantes, grâce à ce qu’o n appelle objets distribués (interopérabilités).
· Les moniteurs transactionnels :
Leur fonction est de coordonner les transactions distribuées sur plusieurs machines
· Les Messages Oriented Middleware (MOM) :
Il s’agit de serveurs intermédiaires dans la communication entre application.

Influence de la sécurité

Avant l’ouverture des réseaux sur le monde extérieur, la sécurité est devenue une caractéristique obligatoire des architectures clients/serveurs.
Elle a en réalité des composants distincts.
· La protection des réseaux contre les intrusions, c’est à dire l’interdiction de l’accès à des services autres que ceux qui sont officiellement permis ;
· L’authentification des utilisateurs.
Les contraintes très fortes de sécurité sur Interneimposent des limitations aux architectures clients/serveurs dans l’entreprise. En particulier la présence de firewall peut empêcher ou limiter l’utilisation de certains protocoles de haut niveau .

Le problème de bande passante

Sur Internet, il n’est pas rare pour un utilisateur connecté par modem de rencontrer des débits réseaux inférieur à 10 ko/s. Difficile dans ces conditions de proposer sur Internet les mêmes services, les même applications que celles qui sontexploitées à l’intérieur de l’entreprise. En réseau local, la bande passante par utilisateur estgénéralement supérieure.
Les contraintes de bande passante sont dans certain cas insurmontable. Certes, des solutions comme Internet par câble ou l’ADSL permet d’envisag er des débits par utilisateurs proche de ceux des réseaux locaux.

Les architectures clients/serveurs basés sur Internet

Il existe en fait que deux types fondamentaux d’architecture basée sur Internet :
Architectures clients/serveurs HTML/WEB ; Architectures à code mobile.

Les architectures C/S HTML/WEB

L’architecture HTML/WEB est historiquement la première à avoir été mise en œuvre. Elle repose sur l’utilisation du serveur web en tant que middleware. En d’autre terme, toutes les requêtes de l’utilisateur passent par le serveur web, et celui- ci les dirige vers les codes applicatifs adéquats.

Les architectures à codes mobiles

Les architectures à code mobile se déclinent en deux catégories distinctes :
Architecture à code mobile de type client/serveur d e données Architecture à code mobile de type client/serveur d istribués
Le point commun à ces deux modèles est le téléchargement de la partie cliente de l’application afin d’établir le dialogue client/serveur.

Les applications multitiers distribuées de J2EE 

Les composants J2EE

Les applications J2EE sont composées de composants . Un composant J2EE contient des unités logicielles fonctionnelles qui sont assemblées dansune application J2EE avec ses propres classes et fichiers et qui communiquent avec d’autres composants. La spécification J2EE défini les composants J2EE suivants :
· Les applications clientes et les applets sont des composants qui tournent sur le client ;
· Les composants servlets et Java Server Pages (JSP) sont les composants web qui tournent sur un serveur ;
· Les composants Enterprise Java Beans (EJB) sont les composants métiers qui tournent sur un
serveur.
Les composants J2EE sont écrits en Java et sont compilés de la même manière que tous les autres langages de programmation. La différence entre une classe Java standard et un composant J2EE est que les composants J2EE sont assemblés dans uneapplication J2EE, sont vérifiés pour qu’ils soient conforme au spécification de J2EE, sont déployés sur un serveur J2EE où ils tournent et sont gérés par ce même serveur.

Les clients J2EE

Un client J2EE peut être un client web ou une application cliente.

Client web

Un client web est divisé en deux :
· Des pages web dynamiques contenant différents types de langages à balise tel que HTML, XML qui sont générées par les composants web tournat sur le niveau Web de l’architecture multitiers ;
· Les navigateurs web qui affichent les pages reçues des serveurs.
Un client web est généralement appelé « client léger » du fait qu’il ne traite pas des règles métiers complexes, n’effectue pas des requêtes à la base de données, ou ne se connecte pas aux applications héritées.

Applet

Un applet est une petite application écrite en Javaet qui s’exécute sur un « Java Virtual Machine » (JVM) installé sur un navigateur web. Cependant, les systèmes clients peuvent avoir besoin des plug-ins Java et des politiques de sécurité de fichier pour que les applets puissent fonctionner correctement.
Les composants web sont les APIs, les plus utilisés pour la création des clients web, parce qu’aucun plug-in Java et aucune politique de sécurité de fichier n’est nécessaire sur le système client. Mais aussi les composants web séparent la programmation des applications de la mise en page des applications web.

Les applications clientes

Une application cliente tourne sur une machine cliente et permet de traiter des tâches qui requièrent des interfaces utilisateurs plus riches que celle proposé par les langages à balises. Typiquement, il a une interface graphique (GUI) créé par les APIs « Swing » et « Abstract Window Toolkit (AWT) ».
Les applications clientes peuvent directement avoir accès au niveau métier de l’architecture multitiers de J2EE. Aussi, une application cliente peut avoir accès à un servlet situé sur le niveau web par l’intermédiaire du protocole HTTP.

Les composants web

Les composants web sont soit des servlets, soit des Java Server Page (JSP). Les Servlets sont des classes Java qui, dynamiquement, traitent les requêtes et construisent les réponses. Les JSP s’exécutent de la même manière qu’une servlet, maispermettent une approche beaucoup plus naturelle pour la création du contenu statique.
Les pages HTML et les applets sont liés au composant web durant l’assemblage de l’application mais ne sont pas considérés comme des composants web selon la spécification J2EE. Les autres scripts côtés serveur sont aussi liés aux composant web, mais comme les pages HTML, ils ne sont pas considérés comme des composants web.
Comme illustrés sur la figure ci-dessous, le niveauweb, comme le niveau client, peut inclure des composants JavaBeans, qui sont des classes java spéciales, pour gérer les entrées utilisateurs et envoyer ces entrées vers l’ « enterprise bean », qui tournent sur le niveau métier.

L’architecture du composant JavaBean

Les serveurs et le niveau client peuvent aussi inclure des composants basés sur les composants JavaBeans pour gérer le flux de données entre les pplications clientes et les applets et les composants tournant sur le serveur J2EE ou entre les composants serveurs et la base de données. Les composants JavaBeans ne sont pas considérés comme un composant J2EE par la spécification J2EE.
Les JavaBeans possèdent des propriétés et ont des méthodes « getproperty » et « setproperty » pour avoir accès à ces propriétés. Les composants avaBeansJ utilisés à cet effet sont simples en conception et en implémentation mais devraient se conformer à la convention d’identification et de conception décrite dans l’architecture du composant JavaBean.

Les composants métiers

Les codes métiers, qui résolvent ou répondent au besoin d’un domaine d’activité particulier comme les banques, la finance ou la vente, sont traités par l’ « enterprise bean » qui tourne sur le niveau métier.
La figure ci-dessous illustre comment un enterprise bean reçoit les données des programmes clients, les traites si nécessaires, et les envoie au système d’information de l’entreprise (EIS) pour la sauvegarde. Un enterprise bean effectue aussi l’opération inverse, il rend les données sauvegardées, les traites si nécessaires, et les nvoie au client qui les a demandées.
Il existe trois types d’enterprise bean :
· beans entity : un bean entity représente les données persistants sauvegardées dans une table de la base de données. Si le client a terminé ou leserveur s’est arrêté, les sous-couches services assurent que les données de l’entité beansoient sauvegardées ;
· beans session : un bean session représente une conversation transitoire avec un client. Lorsqu’un client fini l’exécution, le bean session et les données sont perdus ;
· beans message-driven : un bean message-driven combine les caractéristiques d’un bean session et d’un « message listener » de Java Message Service (JMS), permettant ainsi de recevoir des messages JMS de façon asynchrone.

Le niveau EIS

Le niveau EIS traite les programmes EIS et renferme les infrastructures systèmes de l’entreprise comme les processus de transaction des mainframes, les systèmes de base de données et d’autres systèmes d’information hérités. Comme par exemple,une application J2EE peut avoir besoin d’accéder au système d’information de l’entreprise pour une connexion à la base de données.

Les conteneurs J2EE

Normalement le développement d’application multitiers est difficile à réaliser parce qu’il implique beaucoup de code complexe à traiter comme la transa ction et le multithreading. L’architecture de la plate-forme J2EE produit des applications J2EE facile à programmer parce que la logique applicative est organisée de façon à ce que les com posants soient réutilisables. De plus, le serveur J2EE produit une sous-couche service sous forme de conteneur pour chaque type de composant. Parce qu’on ne peut pas développer soit même ces services, on devrait se concentrer à résoudre les problèmes métiers qui se présentent sous les yeux.

Les services conteneurs

Les conteneurs sont les interfaces entre un composant et les fonctionnalités spécifiques de bas niveau de la plate-forme que supporte le composant. Avant qu’un composant web, qu’un composant enterprise bean, ou qu’un composant d’app lication cliente s’exécute, ils doivent être assemblés dans un module J2EE et déployés dans leurpropre conteneur. Le processus d’assemblage implique des paramètres spécifiques des conteneurs dans l’application J2EE et pour l’application J2EE lui même. Les paramètres du conteneur personnalisent les supports sous-jacents fournis par le serveur J2EE incluant les services comme :
· la gestion des transactions : le modèle de transaction J2EE permet de spécifier les relations entre les méthodes qui composent une simple transaction afin que toutes les méthodes dans une transaction soient traitées comme une seule unité ;
· la sécurité : le modèle de sécurité J2EE permet deconfigurer un composant web ou un enterprise bean de ce fait les utilisateurs autorisés sont les seuls à avoir accès aux ressources systèmes ;
· le Java Naming Directory Interface (JNDI) lookup : le service JNDI lookup fournit un service de nommage multiple et de répertoires dans l’entreprise afin que le composant d’application puisse avoir accès au service de nommage et de répertoire ;
· la connexion à distance : le modèle de connexion à distance de J2EE gère la connexion de base entre le client et l’enterprise bean. Quand un enterprise bean a été créé, le client appelle une de ces méthodes comme s’il était dans la même achinem virtuelle.
L’architecture J2EE fournit des services configurables. Les composants d’application à l’intérieur d’une même application J2EE peuvent se comporter différemment selon le cas où elle a été déployée. Par exemple un enterprise bean, qui se connecte à une base de données, a un niveau de sécurité spécifique pour un environnement de production et un autre niveau de sécurité pour un autre environnement de production.

Les types de conteneurs

Le processus de déploiement installe les composantsd’application J2EE dans les conteneurs J2EE illustrés par la figure ci-dessous.

Le serveur J2EE

Un serveur J2EE fournit un conteneur EJB et un conteneur web

Le conteneur EJB

Le conteneur EJB gère l’exécution des enterprises beans pour les applications J2EE. L’enterprise bean et son conteneur s’exécutent sur le serveur J2EE.

Conteneur web

Le conteneur web gère l’exécution des composants JSP et servlet pour les applications J2EE. Les composants web et son conteneur s’exécutent sur le serveur J2EE.

Le conteneur d’application cliente

Le conteneur d’application cliente gère les composants d’application cliente. L’application cliente et son conteneur s’exécutent sur le client.

Le conteneur d’applet

Le conteneur d’applet gère l’exécution des applets .Cela concerne en l’exécution des navigateurs web et des plug-ins Java sur le client en même temps.

Les APIs de J2EE 

La figure ci-dessous illustre les APIs de la plate-forme J2EE 1.4 dans chaque conteneur J2EE.

La technologie Enterprise JavaBean

Un composant enterprise JavaBean ou enterprise bean, est un ensemble de code possédant des champs et des méthodes pour implémenter le module ed la logique métier. Un enterprise bean est comme un bloc qui peut être utilisé seul ou avec d’autre enterprise bean qui exécutent la logique métier dans le serveur J2EE.

La technologie Java Servlet

La technologie Java servlet permet de définir les classes servlet spécifique à HTTP. Une classe servlet étend les capacités des serveurs qui hébergent les applications et qui sont accédées par le modèle de programmation requête-réponse. Quoique sleservlets puissent répondre à n’importe quel type de requête, elles sont communément employées pour étendre les hébergeurs d’applications par les serveurs web.

La technologie JavaServer Page

La technologie JavaServer Page permet d’inclure des snippets de code servlet directement dans un document basé texte. Une page JSP est un document basé texte qui contient deux types de texte :
· Les données statiques qui peuvent être exprimées rpan’importe quel format de document basé texte tel que l’HTML, le WML, le XML ;
· Les éléments JSP qui détermineront le contenu dynamique de la page.

L’API Java Message Service

L’API Java Message Service est un service de messagerie standard qui permet au composant d’application J2EE de créer, d’envoyer, de recevoir et de lire des messages. Cela permet la communication distribuée qui est sûre, et asynchrone.

L’API Java Transaction

L’API Java Transaction permet de mettre en place une gestion des transactions dans des applications distribuées en partageant une même transaction entre plusieurs composants EJB, et/ou en partageant une même transaction entre différentes connexions de base de données.

L’API JavaMail

L’API JavaMail fournit des fonctionnalités de gestion de courrier électronique aux applications Java. L’API JavaMail a deux parties :
· L’interface niveau application utilisée par le composant d’application pour envoyer le mail ;
· L’interface fournisseur de service.
La plate-forme J2EE inclut au JavaMail un fournisseur de service qui permet au composant d’application d’envoyer un mail par Internet.

JNDI

Cet API permet l’accès à des services de nommage ou d’annuaire (LDAP) fournissant une implémentation de l’interface SPI.

L’API JDBC

L’API JDBC permet d’invoquer des commandes SQL à l ’intérieur des programmes Java. On utilise l’API JDBC par les servlets et les JSP pour avoir un accès direct à la base de données sans passer par l’enterprise bean.

Table des matières

INTRODUCTION
CHAPITRE I. GENERALITES
I.1. Contexte
I.1.1. Applications multitiers distribuées
I.2. Architecture système
I.2.1. Introduction sur le client/serveur
I.2.2. Modèle générale d’architecture système
I.2.2.1. Espace serveur
I.2.2.2. Espace client
I.2.3. Les briques de l’architecture système
I.2.3.1. Interface utilisateur
I.2.3.2. Les applications
I.2.3.3. Les données
I.2.3.4. Le Middleware
I.2.4. Typologie technique
I.2.4.1. Type de données véhiculées
I.2.4.2. Type de dialogue client/serveur
I.2.4.3. Structure et localisation des applicatifs
I.2.5. Les architectures client/serveur
I.2.5.1. Client/serveur à client passif (1/3)
I.2.5.2. Client/serveur de données (2/3)
I.2.5.3. Client/serveur distribués (3/3)
I.2.5.4. Client/serveur à objets distribués (système réparti)
Cette architecture se compose des différentes couches suivantes:
I.2.6. Evolution du client/serveur avec Internet
I.2.6.1. Standardisation des protocoles
I.2.6.2. Influence de la sécurité
I.2.6.3. Le problème de bande passante
I.2.7. Les architectures clients/serveurs basés sur Internet
I.2.7.1. Les architectures C/S HTML/WEB
I.2.7.2. Les architectures à codes mobiles
CHAPITRE II. LA PLATE-FORME J2EE
II.1. Introduction
II.2. Les applications multitiers distribuées de J2EE
II.2.1. Les composants J2EE
II.2.2. Les clients J2EE
II.2.2.1. Client web
II.2.2.2. Applet
II.2.2.3. Les applications clientes
II.2.3. Les composants web
II.2.3.1. L’architecture du composant JavaBean
II.2.4. Les composants métiers
II.2.5. Le niveau EIS
II.3. Les conteneurs J2EE
II.3.1. Les services conteneurs
II.3.2. Les types de conteneurs
II.3.2.1. Le serveur J2EE
II.3.2.2. Le conteneur EJB
II.3.2.3. Conteneur web
II.3.2.4. Le conteneur d’application cliente
II.3.2.5. Le conteneur d’applet
II.4. Les APIs de J2EE
II.4.1. La technologie Enterprise JavaBean
II.4.2. La technologie Java Servlet
II.4.3. La technologie JavaServer Page
II.4.4. L’API Java Message Service
II.4.5. L’API Java Transaction
II.4.6. L’API JavaMail
II.4.7. JNDI
II.4.8. L’API JDBC
CHAPITRE III. LES BASES DE DONNEES
III.1. Présentation générale
III.1.1. Introduction aux bases de données
III.1.2. Objectifs et avantages
III.1.2.1. Indépendance physique.
III.1.2.2. Indépendance logique.
III.1.2.3. anipulable par des non-informaticiens.
III.1.2.4. Accès aux données efficace.
III.1.2.5. Administration centralisée des données.
III.1.2.6. Non redondance des données.
III.1.2.7. Cohérence des données.
III.1.2.8. Partageabilité des données.
III.1.2.9. Sécurité des données.
III.1.3. Différents types de bases de données
III.1.4. Quelques systèmes existants
III.1.5. Modéliser les données
III.2. L’algèbre relationnelle
III.2.1. Définition
III.2.2. Quelques remarques sur l’algèbre relationnelle
III.3. Le langage SQL
III.3.1. L’obtention des données
III.3.2. La mise à jour d’informations
III.3.2.1. Insertion.
III.3.2.2. Mise à jour
III.3.2.3. Suppression.
III.3.3. La définition des données : Le DDL
III.3.3.1. Les types de données
III.3.3.2. La création de tables
III.3.3.3. Expression des contraintes d’intégrité
CHAPITRE IV. DEVELOPPEMENT D’APPLICATION WEB
IV.1. Application web
IV.1.1. Cycle de vie des applications web
IV.1.2. Modules web
IV.2. La technologie Java Servlet
IV.2.1. Introduction aux servlets HTTP
IV.2.1.1. Les bases de HTTP
IV.2.1.2. L’API servlet
IV.2.2. Cycle de vie d’une servlet
IV.2.2.1. Construction et initialisation du servlet
IV.2.2.2. Gestion des demandes client
IV.2.2.3. Servlets et multithread
IV.2.2.4. Destruction d’un servlet
IV.2.3. Retrouver l’information
IV.2.3.1. Paramètres d’initialisation
IV.2.3.2. Le serveur
IV.2.3.3. Le client
IV.2.3.4. La requête
IV.2.4. Réponse à une requête
IV.2.4.1. Structure d’une réponse
IV.2.4.2. Réponse normale
IV.2.5. Session
IV.2.6. Connexion aux bases de données
IV.2.6.1. L’API JDBC
IV.2.6.2. Obtenir une connexion
IV.2.6.3. Exécuter des requêtes SQL
IV.3. La technologie JavaServer Page
IV.3.1. Introduction
IV.3.2. Comparaison entre JSP et servlet
IV.3.3. Architecture
IV.3.4. Les tags JSP
IV.3.4.1. Declaration tag (<%! %>)
IV.3.4.2. Expression tag (<%= %>)
IV.3.4.3. Directive tag (<%@ directive … %>)
IV.3.4.4. Scriptlet tag (<% … %>)
IV.3.4.5. Action tag
IV.3.4.6. Commentaire
CHAPITRE V. REALISATION : MISE EN PLACE DU SYSTÈME D’INFORMATION POUR LA GESTION DE LA BIBLIOTHÈQUE DE L’ESPA
V.1. Démarche méthodologique de construction d’une applicatio
V.1.1. Les différentes étapes
V.1.1.1. Expression des besoins
V.1.1.2. Analyse
V.1.1.3. Conception
V.1.1.4. Implémentation
V.1.1.5. Les tests de vérification :
V.1.1.6. Validation
V.1.1.7. Maintenance et évolution
V.1.2. Les différents cycles de vie
V.1.2.1. Le cycle de vie en cascade
V.1.3. Merise
V.1.4. Récapitulations
V.2. Modélisation de la partie statique du système d’information de la bibliothèque
V.2.1. Architecture matérielle
V.2.2. Description du fonctionnement de la bibliothèque
V.2.2.1. Organisation des livres
V.2.2.2. Lecture sur place
V.2.2.3. Emprunt de livre à domicile
V.2.2.4. Adhésion
V.2.2.5. Inventaire
V.2.3. Diagramme de flux
V.2.3.1. Modèle de contexte
V.2.3.2. Modèle de flux conceptuel
V.2.4. Règles de gestion
V.2.5. Dictionnaire de données
V.2.6. Les entités
V.2.6.1. Définition
V.2.7. Le modèle conceptuel de données
V.2.7.1. Définition
V.2.7.2. Le modèle conceptuel de données de la bibliothèque
V.3. Modélisation de la partie dynamique du système d’information de la bibliothèque
V.3.1. Description du fonctionnement de l’application de la gestion de la bibliothèque
V.3.1.1. Description du fonctionnement de l’application
V.3.1.2. Organigramme
V.4. Exemples de pages de l’application
V.4.1. La page d’identification
V.4.2. La page inscription membre
V.4.3. La page liste des livres
CONCLUSION
ANNEXE
ANNEXE 1 : Les fondements du reseau
ANNEXE 2 : HTML
BIBLIOGRAPHIE

Télécharger le rapport complet