Informatique de Gestion

UNIVERSITE DE KINSHASA
FACULTE DES SCIENCES

Département de Mathématiques et Informatique
Informatique de Gestion :
Travaux Pratiques
Destiné aux étudiants de Troisième Graduat en Sciences Informatiques
Assistant MANZAMBI NDONGALA Nathan
Titulaire du Cours:
Prof. Dr. Saint-Jean DJUNGU
Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

2011-2012
© UNIKIN 2012 Page 1
Objectifs
Les principaux objectifs de ces Travaux Pratiques sont les suivants :
 Initier les étudiants à la conception des systèmes d’informations en utilisant la

technique de dépendance fonctionnelle
 Pouvoir implémenter les bases de données en SQL Server, Access, MYSQL, Java
DB, etc.
 Etre familier au développement des applications clientes orientées objets (avec

Java : netbeans) qui attaquent de manière transparente les bases de données
 Etre capable de mettre en place des applications d’entreprise avec la technologie

JEE
 Apprendre le reporting en Java, et .net
Pré requis
Pour bien assimiler ces travaux pratiques, l’étudiant doit avoir une bonne
connaissance sur :
 La programmation Orientée Objet

 L’analyse informatique
 MERISE
 Algorithmique et Structure des données
 Les bases de données relationnelles et le langage SQL

Sommaire
Partie I : Conception des applications de gestion
Chapitre I : Les bases de données

 Merise : Dépendance fonctionnelle
 Le langage SQL
Chapitre II : Architecture des applications de gestion
Partie II : Mise en œuvre des applications de gestion avec la technologie J2EE
Chapitre III : Persistance et Accès aux bases de données

 JDBC
 JPA
Chapitre IV : La logique Métier
 EJB
Chapitre V : La Couche présentation
 Swing
 Reporting
 Les technologies du web : HTML, CSS, Servelet, JSP, JSF, XML, etc.
Partie III : Etude de cas et Exercices
Chapitre VI : Etudes des Cas

Chapitre VII : Exercices

Partie I : Conception des applications de gestion
Chapitre I : Les bases de données
I.1. Conception d’une base de données avec Merise
Quand nous construisons directement les tables d’une base de données dans un logiciel de
gestion des bases de données (SQL Server, MYSQL,…), nous sommes exposés à deux types de
problèmes :
 Nous ne savons pas toujours dans quelle table placer certaines colonnes (par
exemple, l’adresse de livraison se met dans la table des clients ou dans la table de
commande) ;
 Nous avons du mal à prévoir les tables de jonction intermédiaires (par exemple, la
table des interprétations qui est indispensable entre les tables des films et des
acteurs).
Il est donc nécessaire de recourir à une étape préliminaire de conception. Les

techniques présentées ici font partie de la méthodologie Merise (Méthode d’Etude et de
Réalisation Informatique pour les Systèmes d’Entreprise) qui permet notamment de
concevoir un système d’information d’une façon méthodique er standardisée.
Le but de ce chapitre est d’introduire le schéma entités-associations, le

schéma relationnel, et d’expliquer la traduction entre les deux. La construction du schéma
entités-associations se fera en étudiant les dépendances fonctionnelles. Le chapitre est
clôturé par une série d’exercices liés à la conception des bases de données.
I.1. Le Modèle Conceptuel de données (MCD)

I.1.1. Méthodologie de Base
Face à un problème bien défini (soit à travers un énoncé précis, soit à travers
une collection de formulaires ou d’états que le nouveau système d’information est censé
de remplacer), nous pouvons procéder comme suit pour concevoir un MCD :
1. Identifier les entités

2. Constituer le dictionnaire des données (l’ensemble de tous les attributs de toutes
les entités identifiées)
3. Etudier les dépendances fonctionnelles entre les attributs
4. Construire le graphe de couverture minimale

5. Déduire le MCD Normalisé à partir du graphe de couverture minimale
I.1.2. Dépendances fonctionnelles

Pour établir efficacement un modèle entités-associations bien normalisé, on
peut étudier au préalable les dépendances fonctionnelles entre les attributs puis, les
organiser en graphe de couverture minimale. Cette technique est traditionnellement
employée pour normaliser des schémas relationnels, mais elle s’applique très bien en
amont, au niveau des modèles conceptuels.
I.1.2.1. Définitions
Un attribut Y dépend fonctionnellement d’un attribut X si et seulement si une

valeur de X induit une unique valeur de Y. On note une dépendance fonctionnelle par une
flèche simple : X Y
Par exemple, si X est le numéro de client et Y le nom de client, alors on a bien : X Y.

Par contre, on n’a pas Y X, car plusieurs clients de numéros différents peuvent
porter le même nom.
I.1.2.2. Propriétés
Transitivité : si X Y et Y Z alors X Z
Par exemple, on a : numéros de commande numéros de client,

numéro de client nom client,
Donc on a aussi : numéros de commande nom client
Mais cette dernière dépendance fonctionnelle est transitive, car il faut passer
par le numéro de client pour l’obtenir. Au contraire, la deuxième dépendance de notre
exemple est directe. Seules les dépendances directes vont nous intéresser.
Un attribut Y peut avoir une dépendance fonctionnelle qui repose sur la

conjonction de plusieurs attributs, auquel cas la dépendance est dite non élémentaire.
Les dépendances fonctionnelles non élémentaires sont notées par une flèche unique mais
comportant plusieurs points d’entrée (regroupés autour d’un cercle).
Par exemple, la quantité de commande (d’un article dans une commande) dépend de
deux attributs : le numéro de commande et le numéro de l’article. Notons que cette
dépendance est à la fois non élémentaire et directe.
Numéro de commande + numéro de l’article quantité commandée

Numéro de commande
Numéro de l’article quantité commandée
I.1.3. Graphe de Couverture Minimale
En représentant tous les attributs et toutes les dépendances fonctionnelles

directes entre eux, nous obtenons un réseau appelé graphe de couverture minimale.
Numéro de commande numéro article
Numéro de client date de commande désignation
Nom du client adresse quantité commandée
I.1.4. Traduction vers un schéma entités-associations
A partir du graphe de couverture minimale, le schéma entités-associations

normalisé correspondant apparait naturellement, en suivant quelques étapes simples.
Etape 1 : Il faut repérer et souligner les identifiants

Etape 2 : puis tous les attributs non identifiants qui dépendent directement d’un
identifiant et d’un seul, forment une entité (avec l’identifiant, bien sur).
Etape 3 : ensuite, les dépendances élémentaires entre les identifiants forment des
associations binaires dont les cardinalités maximales sont 1 au départ de la dépendance
fonctionnelle et n à l’arrivée.
Etape 4 : enfin, les attributs (non identifiants) qui dépendent de plusieurs identifiants
sont les attributs d’une association supplémentaire dont les cardinalités maximales sont
toutes n.

Commandes Articles
Clients
PK num commande PK numero article
PK numero client
date designation
nom client FK1 numero client
prenom
adresse
Concerner
PK,FK2 numero article

PK,FK1 numero client
quantite
A ce stade, les trois formes normales de CODD devraient être vérifiées, si ce

n’est pas le cas, il y a donc une erreur au niveau de la traduction ou au niveau du graphe
de couverture minimale.
I.1.5. Les Formes Normales de BOYCE CODD
Première forme normale : à un instant donné dans une entité, pour un individu, un
attribut ne peut prendre qu’une valeur et non pas, un ensemble ou une liste des valeurs.
Livres
livres Auteurs
1,n
PK numero livre 1,n
PK numero livre PK numero auteur
titre
auteurs
titre Ecrire nom
editeur
editeur
nbre de page
nbre de page
année
année
Deuxième forme normale : l’identifiant peut être composé de plusieurs attributs mais les
autres attributs de l’entité doivent dépendre de l’identifiant en entier et non pas une
partie de cet identifiant.
Troisième forme normale : tous les attributs d’une entité doivent dépendre directement
de son identifiant et d’aucun d’autre attribut.
I.2. Le Modèle Logique de données (MLD)
Pour traduire un MCD en un MLD Relationnel, il suffit d’appliquer cinq règles.
Notations : on dit qu’une association binaire est de type :

 1 :1 (un à un) si aucune de des deux cardinalités maximales n’est n.

 1 :n (un à plusieurs) si une des deux cardinalités maximales est n
 N :m (plusieurs à plusieurs) si les deux cardinalités maximales sont n.
Règle 1 : Toute entité devient une table dans laquelle les attributs deviennent les
colonnes. L’identifiant de l’entité constitue alors la clé primaire de la table.
Règle 2 : une association de type 1 :n disparait, au profit d’une clé étrangère dans la table
côté 0,1 ou 1,1, qui référence la clé primaire de l’autre table. Cette d’une clé étrangère ne
peut recevoir la valeur vide si cardinalité est 1,1.
Règle3 : une association binaire de type n : m devient une table supplémentaire (parfois
appelé Table de jonction, Table de jointure, table d’association) dont la clé primaire est
composée de deux clés étrangères.
Règle 4 : une association binaire de type 1 : 1est traduite comme une association de type
1 : n sauf que la clé étrangère se voit imposer une contrainte d’unicité en plus d’une
éventuelle contrainte de non vacuité.
Si les associations fantômes ont été éliminées, il devrait y avoir au moins un coté de
cardinalité 0,1. C’est alors dans la table du côté opposé que doit aller la clé étrangère. Si
les deux côtés sont de cardinalités 0,1 alors la clé étrangère peut être placée
indifféremment dans l’une de deux tables.
Règle 5 : une association non binaire est traduite par une table supplémentaire dont la clé
primaire est composée d’autant de clés étrangères que d’entités en association.
I.3. Le Modèle Physique de données (MPD)
La traduction d’un MLDR en un modèle physique est la création (par des

requêtes SQL) d’une base de données hébergée par un SGBD relationnel particulier. Dans
le cadre de ce TP, nous utiliserons MYSQL, ou SQL Server. Le MPD précise notamment le
stockage de chaque donnée à travers son type et sa taille.
I.2. Le langage SQL
I.2.1. Définitions des données
I.2.2. Manipulation des données
I.2.3. Interrogation des données

Chapitre II : Architecture des applications de gestion
Architecture 3 tiers
L'architecture 3-tiers ou architecture à trois niveaux est l'application du modèle plus
général qu'est le multi-tiers.
L'architecture logique du système est divisée en trois niveaux ou couches :
• couche présentation
• couche métier
• couche accès aux données
C'est une extension du modèle client/serveur.
III.1. Définition et concepts
L'architecture 3-tiers (de l'anglais tiers signifiant étage ou niveau) est un modèle logique
d'architecture applicative qui vise à séparer très nettement trois couches logicielles au
sein d'une même application ou système, à modéliser et présenter cette application
comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est
clairement défini :
• la présentation des données : correspondant à l'affichage, la restitution sur le
poste de travail, le dialogue avec l'utilisateur ;
• le traitement métier des données : correspondant à la mise en œuvre de
l'ensemble des règles de gestion et de la logique applicative ;
• et enfin l'accès aux données persistantes: correspondant aux données qui sont
destinées à être conservées sur la durée, voire de manière définitive.
Dans cette approche, les couches communiquent entre elles au travers d'un « modèle
d'échange », et chacune d'entre elles propose un ensemble de services rendus. Les
services d'une couche sont mis à disposition de la couche supérieure. On s'interdit par
conséquent qu'une couche invoque les services d'une couche plus basse que la couche
immédiatement inférieure ou plus haute que la couche immédiatement supérieure
(chaque niveau ne communique qu'avec ses voisins immédiats).
Le rôle de chacune des couches et leur interface de communication étant bien définis, les
fonctionnalités de chacune d'entre elles peuvent évoluer sans induire de changement
dans les autres couches. Cependant, une nouvelle fonctionnalité de l'application peut
avoir des répercussions dans plusieurs d'entre elles. Il est donc essentiel de définir un
modèle d'échange assez souple, pour permettre une maintenance aisée de l'application.

Ce modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations
suivantes :
• allègement du poste de travail client (notamment vis-à-vis des architectures
classiques client-serveur de données typiques des applications dans un contexte
Oracle/Unix) ;
• prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages,
etc.) ;
• introduction de clients dits « légers » (plus liée aux technologies Intranet/HTML
qu'au 3-tiers proprement dit) ;
• amélioration de la sécurité des données, en supprimant le lien entre le client et les
données. Le serveur a pour tâche, en plus des traitements purement métiers, de
vérifier l'intégrité et la validité des données avant de les envoyer dans la couche
de données.
• rupture du lien de propriété exclusive entre application et données. Dans ce
modèle, la base de données peut être plus facilement normalisée et intégrée à un
Entrepôt de données.
• et enfin, meilleure répartition de la charge entre différents serveurs d'application.
Précédemment, dans les architectures client-serveur classiques, les couches présentation et

traitement étaient trop souvent imbriquées. Ce qui posait des problèmes à chaque fois que
l'on voulait modifier l'interface homme-machine du système.
L'activation à distance (entre la station et le serveur d'application) des objets et de leurs
méthodes (on parle d'invocation) peut se faire au travers d'un ORB (avec le protocole IIOP ou
au moyen des technologies COM/DCOM de Microsoft ou encore avec RMI en technologie
J2EE). Cette architecture ouverte permet également de répartir les objets sur différents
serveurs d'application (soit pour prendre en compte un existant hétérogène, soit pour
optimiser la charge).
Il s'agit d'une architecture logique qui se répartit ensuite selon une architecture technique
sur différentes machines physiques, bien souvent au nombre de 3, 4 ou plus. Une répartition
de la charge doit dans ce cas être mise en place.
III.2. Les trois couches
III.2.1. Couche Présentation (premier niveau)
Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle
d'Interface Homme Machine. En informatique, elle peut être réalisée par une application
graphique ou textuelle. Elle peut aussi être représentée en HTML pour être exploitée par un
navigateur web ou en WML pour être utilisée par un téléphone portable.
On conçoit facilement que cette interface peut prendre de multiples facettes sans changer la
finalité de l'application.

Dans le cas d'un système de distributeurs de billets, l'automate peut être différent d'une
banque à l'autre, mais les fonctionnalités offertes sont similaires et les services identiques
(fournir des billets, donner un extrait de compte, etc.).
Toujours dans le secteur bancaire, une même fonctionnalité métier (par exemple, la
commande d'un nouveau chéquier) pourra prendre différentes formes de présentation
selon qu'elle se déroule sur Internet, sur un distributeur automatique de billets ou sur
l'écran d'un chargé de clientèle en agence.
La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier,

et en retour lui présente les informations renvoyées par les traitements de cette couche. Il
s'agit donc ici d'un assemblage de services métiers et applicatifs offerts par la couche
inférieure.
III.2.2. Couche Métier / Business (second niveau)
Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique »,

et qui décrit les opérations que l'application opère sur les données en fonction des requêtes
des utilisateurs, effectuées au travers de la couche présentation.
Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette
couche.
La couche métier offre des services applicatifs et métier [1] à la couche présentation. Pour
fournir ces services, elle s'appuie, le cas échéant, sur les données du système, accessibles au
travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation
les résultats qu'elle a calculés.
III.2.3. Couche Accès aux données (troisième niveau)
Elle consiste en la partie gérant l'accès aux gisements de données du système. Ces données
peuvent être propres au système, ou gérées par un autre système. La couche métier n'a pas
à s'adapter à ces deux cas, ils sont transparents pour elle, et elle accède aux données de
manière uniforme (couplage faible).
Données propres au système
Ces données sont pérennes, car destinées à durer dans le temps, de manière plus ou moins
longue, voire définitive.
Les données peuvent être stockées indifféremment dans de simples fichiers texte, ou
eXtensible Markup Language (XML), ou encore dans une base de données. Quel que soit le
support de stockage choisi, l'accès aux données doit être le même. Cette abstraction
améliore la maintenance du système.
Les services sont mis à disposition de la couche métier. Les données renvoyées sont issues
du/des gisements de données du système.

Pour une implémentation « native », le motif de conception (en anglais design pattern) à
implémenter dans cette couche est le Data Access Object (DAO). Ce dernier consiste à
représenter les données du système sous la forme d'un modèle objet. Par exemple un objet
pourrait représenter un contact ou un rendez-vous.
La représentation du modèle de données objet en base de données (appelée persistance)
peut s'effectuer à l'aide d'outils tels que Hibernate.
Données gérées par un autre système
Les données peuvent aussi être gérées de manière externe. Elles ne sont pas stockées par le
système considéré, il s'appuie sur la capacité d'un autre système à fournir ces informations.
Par exemple, une application de pilotage de l'entreprise peut ne pas sauvegarder des
données comptables de haut niveau dont elle a besoin, mais les demander à une application
de comptabilité. Celle-ci est indépendante et préexistante, et on ne se préoccupe pas de
savoir comment elle les obtient ou si elle les sauvegarde, on utilise simplement sa capacité à
fournir des données à jour.

Partie II : Mise en œuvre des applications de gestion avec la technologie J2EE
Chapitre III : Persistance et Accès aux bases de données
III.1. JDBC
II.1. Les Outils nécessaires pour utiliser JDBC
Les classes de JDBC sont regroupées dans le package java.sql et sont incluses
dans le JDK à partir de sa version 1.1. La version 2.0 de cette API est incluse dans la version
1.2 du JDK.
Pour pouvoir utiliser JDBC, il faut un pilote qui est spécifique à la base de
données à laquelle on veut accéder. Avec le JDK, Sun fournit un pilote qui permet l'accès aux
bases de données via ODBC.
Ce pilote permet de réaliser l'indépendance de JDBC vis à vis des bases de
données.
Pour utiliser le pont JDBC−ODBC sous Window 9x ou version supérieure, il faut
utiliser ODBC en version 32 bits.
II.2. Les type de pilotes JDBC
Il existe quatre types de pilote JDBC :

Type 1 : (JDBC−ODBC bridge) : le pont JDBC−ODBC qui s'utilise avec ODBC et un pilote ODBC
spécifique pour la base à accéder. Cette solution fonctionne très bien sous Windows. C'est la
solution idéale pour des développements avec exécution sous Windows d'une application
locale. Cette solution « simple » pour le développement possède plusieurs inconvénients :
 La multiplication du nombre de couches rend complexe l'architecture (bien que

transparent pour le développeur) et détériore un peu les performances
 La partie native (ODBC et son pilote) rend l'application moins portable et dépendante
d'une plateforme.
Type 2 : un driver écrit en java qui appelle l'API native de la base de données
Ce type de driver convertit les ordres JDBC pour appeler directement les API de la base de
données via un pilote natif sur le client. Ce type de driver nécessite aussi l'utilisation de code
natif sur le client.
Type 3 : un driver écrit en Java utilisant le protocole natif de la base de données

Ce type de driver utilise un protocole réseau propriétaire spécifique à une base de données.
Un serveur dédié reçoit les messages par ce protocole et dialogue directement avec la base
de données. Ce type de driver peut être facilement utilisé par une applet mais dans ce cas le

serveur intermédiaire doit obligatoirement être installé sur la machine contenant le serveur
web.
Type 4 : un driver Java natif
Ce type de driver, écrit en java, appelle directement le SGBD par le réseau. Ils sont fournis
par l'éditeur de la base de données.
Les drivers se présentent souvent sous forme de fichiers jar dont le chemin doit être ajouté
au classpath pour permettre au programme de l'utiliser.
II.3. Enregistrer une base de données dans ODBC
Pour utiliser un pilote de type 1 (pont ODBC−JDBC) sous Windows 9x, il est
nécessaire d'enregistrer la base de données dans ODBC avant de pouvoir l'utiliser.
Pour enregistrer une nouvelle base de données, il faut utiliser l'administrateur

de source de données ODBC.
Pour lancer cette application sous Windows 9x, il faut doubler cliquer sur
l'icône "ODBC 32bits" dans le panneau de configuration.
Sous Windows XP, il faut double cliquer sur l'icône "Source de données
(ODBC)" dans le répertoire "Outils d'administration" du panneau de configuration.
Sous Windows 7, il faut doubler cliquer l’icône « Source de données(ODBC) »

dans le répertoire « Outils d’administration » du Système et Sécurité du panneau de
configuration.
L'outil se compose de plusieurs onglets. L'onglet "Pilote ODBC" liste

l'ensemble des pilotes qui sont installés sur la machine. L'onglet "Source de données
utilisateur" liste l'ensemble des sources de données pour l'utilisateur couramment connecté
sous Windows.
L'onglet "Source de données système" liste l'ensemble des sources de

données accessibles par tous les utilisateurs.

Le plus simple est de créer une telle source de données en cliquant sur le bouton "Ajouter".
Une boite de dialogue permet de sélectionner le pilote qui sera utilisé par la source de
données.
Il suffit de sélectionner le pilote et de cliquer sur "Terminer". Dans l'exemple ci dessous, le

pilote sélectionné concerne une base Microsoft Access.

Il suffit de saisir les informations nécessaires notamment le nom de la source de données et
de sélectionner la base. Un clic sur le bouton "Ok" crée la source de données qui pourra
alors être utilisée.
II.4. La Connexion à une base de données
En Java, la connexion à une base de données se fait en deux temps :

premièrement on charge le pilote qui fait le lien entre la source de données et l’application
et après, on établit la connexion.
II.4.1. Chargement du pilote (ou Driver)
Pour se connecter à une base de données via ODBC, il faut tout d'abord
charger le pilote JDBC−ODBC qui fait le lien entre les deux.
Exemple d’un code Java :
try{
Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");
}
catch (ClassNotFoundException e){}
Pour se connecter à une base en utilisant un driver spécifique, la documentation du driver

fournit le nom de la classe à utiliser.
Exemple d’un code java utilisant le driver de MySQL Server
try{
Class.forName ("com.mysql.jdbc.Driver");
}

Catch (ClassNotFoundException e){}
Exemple d’un code java utilisant le driver de JAVA DB
try{
Class.forName("org.apache.derby.jdbc.ClientDriver");
}
catch(Exception e){
jTextField2.setText("Exception");
}
II.4.2. Etablissement de la Connexion
Pour se connecter à une base de données, il faut instancier un objet de la

classe Connection en lui précisant sous forme d'URL la base à accéder.
Syntaxe de base :
Connection con = DriverManager.getConnection(url, "myLogin", "myPassword");
Exemples :
1. ODBC
DBurl = "jdbc:odbc:info";
try{
con = DriverManager.getConnection(DBurl,"root","");
}
catch(SQLException e){}
2. MySQL Server
DBurl = "jdbc:mysql://localhost:3307/info";
try{
Connection con = DriverManager.getConnection(DBurl,"root","");
}
catch(SQLException e){}
3. Java DB
String DBurl = "jdbc:derby://localhost:1527/Essai";

try{
Connection con = DriverManager.getConnection(DBurl, "Nathan", "Nathan");
}
catch(Exception ej){jTextField2.setText("Exception");}

II.5. Présentation des classes de l'API JDBC
Toutes les classes de JDBC sont dans le package java.sql. Il faut donc
l'importer dans tous les programmes devant utiliser JDBC. L’instruction java d’import est le
suivant : « import java.sql.* ; »
Il y a 4 classes importantes : DriverManager, Connection, Statement (et
PreparedStatement), et ResultSet, chacune correspondant à une étape de l'accès aux
données :
Une fois la connexion établie, il est possible d'exécuter des ordres SQL. Les
objets qui peuvent être utilisés pour obtenir des informations sur la base de données sont :
II.6. Exécution des requêtes SQL
II.6.1. Opérations de Sélection et de Mise à jour
Les requêtes d'interrogation SQL sont exécutées avec les méthodes d'un objet
Statement que l'on obtient à partir d'un objet Connection.
Exemple :
ResultSet résultats = null;

String requete = "SELECT * FROM client";
try {
Statement stmt = con.createStatement();
résultats = stmt.executeQuery(requete);
} catch (SQLException e) {
//traitement de l'exception
}
Pour une requête de type interrogation (SELECT), la méthode à utiliser de la
classe Statement est executeQuery. Pour des traitements de mise à jour, il faut utiliser la
méthode executeUpdate(). Lors de l'appel à la méthode d'exécution, il est nécessaire de lui
fournir en paramètre la requête SQL sous forme de chaine.

Le résultat d'une requête d'intérrogation est renvoyé dans un objet de la
classe ResultSet par la méthode executeQuery().
La méthode executeUpdate() retourne le nombre d'enregistrements qui ont

été mis à jour
Exemple :
...
//insertion d'un enregistrement dans la table client
requete = "INSERT INTO client VALUES (3,'client 3','prenom
3')";
try {
int nbMaj = stmt.executeUpdate(requete);
affiche("nb mise a jour = "+nbMaj);
e.printStackTrace();
}
...
Lorsque la méthode executeUpdate() est utilisée pour exécuter un traitement
de type DDL ( Data Defiition Langage : définition de données ) comme la création d'un table,
elle retourne 0. Si la méthode retourne 0, cela peut signifier deux choses : le traitement de
mise à jour n'a affecté aucun enregistrement ou le traitement concernait un traitement de
type DDL.
Si l'on utilise executeQuery() pour exécuter une requête SQL ne contenant pas
d'ordre SELECT, alors une exception de type SQLException est levée.
II.6.2. La Classe ResultSet
C'est une classe qui représente une abstraction d'une table qui se compose de
plusieurs enregistrements constitués de colonnes qui contiennent les données.
Les principales méthodes pour obtenir des données sont :

La méthode getMetaData() retourne un objet de la classe ResultSetMetaData
qui permet d'obtenir des informations sur le résultat de la requête. Ainsi, le nombre de
colonne peut être obtenu grâce à la méthode getColumnCount de cet objet.
Exemple :
ResultSetMetaData rsmd;
rsmd = results.getMetaData();
nbCols = rsmd.getColumnCount();
La méthode next() déplace le curseur sur le prochain enregistrement. Le

curseur pointe initialement juste avant le premier
enregistrement : il est nécessaire de faire un premier appel à la méthode next() pour se
placer sur le premier enregistrement.
Des appels successifs à next permettent de parcourir l'ensemble des

enregistrements. Elle retourne false lorsqu'il n'y a plus d'enregistrement. Il faut toujours
protéger le parcours d'une table dans un bloc de capture d'exception
Exemple :
//parcours des données retournées

try {
ResultSetMetaData rsmd = résultats.getMetaData();
int nbCols = rsmd.getColumnCount();
boolean encore = résultats.next();
while (encore) {
for (int i = 1; i <= nbCols; i++)
System.out.print(résultats.getString(i) + " ");
System.out.println();

encore = résultats.next();
}
résultats.close();
//traitement de l'exception
}
Exemple complet de mise à jour et sélection d’une table:
import java.sql.*;
public class TestJDBC1 {
private static void affiche(String message) {
System.out.println(message);
}
private static void arret(String message) {
System.err.println(message);
System.exit(99);
}
public static void main(java.lang.String[] args) {
Connection con = null;
ResultSet résultats = null;
String requete = "";
// chargement du pilote
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
} catch (ClassNotFoundException e) {
arret("Impossible de charger le pilote jdbc:odbc");
}
//connection a la base de données
affiche("connection a la base de données");
try {
String DBurl = "jdbc:odbc:testDB";
con = DriverManager.getConnection(DBurl);
arret("Connection à la base de données impossible");
}
//insertion d'un enregistrement dans la table client
affiche("creation enregistrement");
requete = "INSERT INTO client VALUES (3,'client 3','client
4')";
try {
int nbMaj = stmt.executeUpdate(requete);
affiche("nb mise a jour = "+nbMaj);
}
//creation et execution de la requete
affiche("creation et execution de la requête");
requete = "SELECT * FROM client";

try {
résultats = stmt.executeQuery(requete);
arret("Anomalie lors de l'execution de la requête");
}
//parcours des données retournées
affiche("parcours des données retournées");
try {
ResultSetMetaData rsmd = résultats.getMetaData();
int nbCols = rsmd.getColumnCount();
boolean encore = résultats.next();
while (encore) {
for (int i = 1; i <= nbCols; i++)
System.out.print(résultats.getString(i) + " ");
encore = résultats.next();
}
résultats.close();
arret(e.getMessage());
}
affiche("fin du programme");
System.exit(0);
}
}
Résultat:
connection a la base de données

creation enregistrement
nb mise a jour = 1
creation et execution de la requête
parcours des données retournées
1.0 client 1 prenom 1
2.0 client 2 prenom 2
3.0 client 3 client 4
fin du programme
II.6.3. Obtention des informations sur la base de données
II.6.3.1. La classe ResultSetMetaData
La méthode getMetaData() d'un objet ResultSet retourne un objet de

typeResultSetMetaData. Cet objet permet de connaître le nombre, le nom et le type des
colonnes.
II.6.3.2. La classe DatabaseMetaData

Un objet de la classe DatabaseMetaData permet d'obtenir des informations sur la base de
données dans son ensemble : nom des tables, nom des colonnes dans une table, méthodes
SQL supportées
La méthode getTables() de l'objet DataBaseMetaData demande quatre arguments :

getTables(catalog, schema, tablemask, types[]);
 catalog : le nom du catalogue dans lequel les tables doivent être recherchées. Pour
une base de données
 JDBC−ODBC, il peut être mis à null.
 schema : le schéma de la base dedonnées à inclure pour les bases les supportant. Il
est en principe mis à null
 tablemask : un masque décrivant les noms des tables à retrouver. Pour les retrouver
toutes, il faut l'initialiser avec le caractère '%'
 types[] : tableau de chaines décrivant le type de tables à retrouver. La valeur null
permet de retrouver toutes les tables.

Exemple :
con = DriverManager.getConnection(url);
dma =con.getMetaData();
String[] types = new String[1];
types[0] = "TABLES"; //set table type mask
results = dma.getTables(null, null, "%", types);
boolean more = results.next();
while (more) {
for (i = 1; i <= numCols; i++)
System.out.print(results.getString(i)+" ");
more = results.next();
}
II.6.4. L'utilisation d'un objet PreparedStatement
L'interface PreparedStatement définit les méthodes pour un objet qui va

encapsuler une requête pré−compilée. Ce type de requête est particulièrement adapté pour
une exécution répétée d'une même requête avec des paramètres différents.
Cette interface hérite de l'interface Statement. Lors de l'utilisation d'un objet

de type PreparedStatement, la requête est envoyée au moteur de la base de données pour
que celui ci prépare son exécution.
Un objet qui implémente l'interface PreparedStatement est obtenu en
utilisant la méthode preparedStatement() d'un objet de type Connection. Cette méthode
attend en paramètre une chaîne de caractères contenant la requête SQL. Dans cette chaine,
chaque paramètre est représenté par un caractère ?. Un ensemble de méthode setXXX() (ou
XXX représente un type primitif ou certains objets tel que String, Date, Object, ...) permet de
fournir les valeurs de chaque paramètre défini dans la requête. Le premier paramètre de

cette méthode précise le numéro du paramètre dont la méthode va fournir la valeur. Le
second paramètre précise cette valeur.
Exemple :
package com.jmd.test.dej;
import java.sql.*;
public class TestJDBC2 {
private static void affiche(String message) {
System.out.println(message);
}
private static void arret(String message) {
System.err.println(message);
System.exit(99);
}
public static void main(java.lang.String[] args) {
Connection con = null;
ResultSet resultats = null;
String requete = "";
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
} catch (ClassNotFoundException e) {
arret("Impossible de charger le pilote jdbc:odbc");
}
affiche("connection a la base de données");
try {
String DBurl = "jdbc:odbc:testDB";
con = DriverManager.getConnection(DBurl);
PreparedStatement recherchePersonne =
con.prepareStatement("SELECT * FROM personnes WHERE
nom_personne = ?");
recherchePersonne.setString(1, "nom3");
resultats = recherchePersonne.executeQuery();
affiche("parcours des données retournées");
boolean encore = resultats.next();
while (encore) {
System.out.print(resultats.getInt(1) + " :
"+resultats.getString(2)+" "+
resultats.getString(3)+"("+resultats.getDate(4)+")");
encore = resultats.next();
}
resultats.close();
arret(e.getMessage());
}
affiche("fin du programme");
System.exit(0);
}

}
Pour exécuter la requête, l'interface PreparedStatement propose deux méthodes :
 executeQuery() : cette méthode permet d'exécuter une requête de type

interrogation et renvoie un objet de type ResultSet qui contient les données issues
de l'exécution de la requête
 executeUpdate() : cette méthode permet d'exécuter une requête de type mise à jour
et renvoie un entier qui contient le nombre d'occurrences impactées par la mise à
jour.

III.2. JPA
(Version future)
Chapitre IV : La logique Métier
IV.1. La couche Métier
Le chapitre précédent a montré comment implémenter des objets persistants avec

JDBC et comment les interroger avec SQL. La couche de persistance utilise des objets
qui encapsulent et associent leurs attributs à une base de données relationnelle grâce
à des annotations. Le principe consiste à garder les entités aussi transparentes que
possible et à ne pas les mélanger avec la logique métier. Les entités peuvent bien sûr
posséder des méthodes pour valider leurs attributs, mais elles ne sont pas conçues
pour représenter des tâches complexes, qui nécessitent souvent une interaction avec
d’autres composants (autres objets persistants, services externes, etc.).
La couche de persistance pas plus que l’interface utilisateur ne sont faites pour traiter
du code métier, surtout quand il y a plusieurs interfaces (web, Swing, terminaux
mobiles, etc.). Pour séparer la couche de persistance de la couche présentation, pour
implémenter la logique métier, pour ajouter la gestion des transactions et la sécurité,
les applications ont besoin d’une couche métier : avec Java EE, cette couche est
implémentée par les EJB (Enterprise Java Beans).
La décomposition en couches est importante pour la plupart des applications. En

suivant une approche descendante, les chapitres précédents sur JDBC et JPA ont
modélisé les classes de domaine en définissant généralement des noms (Artist, CD,
Book, Customer, etc.). Au-dessus de cette couche, la couche métier modélise les
actions (ou verbes) de l’application (créer un livre, acheter un livre, afficher une
commande, livrer un livre…). Souvent, cette couche interagit avec des services web
externes (SOAP ou REST), envoie des messages asynchrones à d’autres systèmes (à
l’aide de JMS) ou poste des e-mails ; elle orchestre différents composants allant des
bases de données aux systèmes externes, sert de plaque tournante aux transactions
et à la sécurité et constitue un point d’entrée pour toutes sortes de clients comme les
interfaces web (servlets ou beans gérés par JSF), le traitement par lot ou les systèmes
externes.
IV.2. EJB : Entreprise Java Beans

(Version future)

Chapitre V : La Couche présentation
V.1. API Swing
Swing fait partie de la bibliothèque Java Foundation Classes (JFC). C'est une API dont le but
est similaire à celui de l'API AWT mais dont le mode de fonctionnement et d'utilisation est
complètement différent. Swing a été intégré au JDK depuis sa version 1.2. Cette bibliothèque
existe séparément pour le JDK 1.1.
La bibliothèque JFC contient :

 l'API Swing : de nouvelles classes et interfaces pour construire des interfaces
graphiques
 Accessibility API :
 2D API: support du graphisme en 2D
 API pour l'impression et le cliquer/glisser
Ce chapitre contient plusieurs sections :
 Présentation de Swing
 Les packages Swing
 Un exemple de fenêtre autonome
 Les composants Swing
 Les boutons
 Les composants de saisie de texte
 Les onglets
V.1.1. Présentation de Swing

Swing propose de nombreux composants dont certains possèdent des
fonctions étendues, une utilisation des mécanismes de gestion d'événements performants
(ceux introduits par le JDK 1.1) et une apparence modifiable à la volée (une interface
graphique qui emploie le style du système d'exploitation Windows ou Motif ou un nouveau
style spécifique à Java nommé Metal).
Tous les éléments de Swing font partie d'un package qui a changé plusieurs
fois de nom : le nom du package dépend de la version du J.D.K. utilisée :
 com.sun.java.swing : jusqu'à la version 1.1 beta 2 de Swing, de la version 1.1 des JFC
et de la version 1.2 beta 4 du J.D.K.
 java.awt.swing : utilisé par le J.D.K. 1.2 beta 2 et 3
 javax.swing : à partir des versions de Swing 1.1 beta 3 et J.D.K. 1.2 RC1
Les composants Swing forment un nouvelle hériarchie parallèle à celle de

l'AWT. L'ancêtre de cette hiérarchie est le composant JComponent. Presque tous ces

composants sont écrits en pur Java : ils ne possèdent aucune partie native sauf ceux qui
assurent l'interface avec le système d'exploitation : JApplet, JDialog, JFrame, et JWindow.
Cela permet aux composants de toujours avoir la même apparence quelque soit le système
sur lequel l'application s'exécute.
Tous les composants Swing possèdent les caractéristiques suivantes :
 Ce sont des beans

 Ce sont des composants légers (pas de partie native) hormis quelques exceptions.
 Leurs bords peuvent être changés
La procédure à suivre pour utiliser un composant Swing est identique à celle des composants
de la bibliothèque AWT :
 Créer le composant en appelant son constructeur, appeler les méthodes du

composant si nécessaire pour le personnaliser et l'ajouter dans un conteneur.
 Swing utilise la même infrastructure de classes que AWT, ce qui permet de mélanger
des composants Swing et AWT dans la même interface. Sun recommande toutefois
d'éviter de les mélanger car certains peuvent ne pas être restitués correctement.
 Les composants Swing utilisent des modèles pour contenir leurs états ou leurs
données. Ces modèles sont des classes particulières qui possèdent toutes un
comportement par défaut.
V.1.2. Les packages Swing

Swing contient plusieurs packages :

V.1.3. Un exemple de fenêtre autonome
La classe de base d'une application est la classe JFrame. Son rôle est
équivalent à la classe Frame de l'AWT et elle s'utilise de la même façon.
Exemple :
import javax.swing.*;
import java.awt.event.*;
public class swing1 extends JFrame {
public swing1() {
super("titre de l'application");
WindowListener l = new WindowAdapter() {
public void windowClosing(WindowEvent e){
System.exit(0);
}
};
addWindowListener(l);
setSize(200,100);
setVisible(true);
}
public static void main(String [] args){
JFrame frame = new swing1();
}
}
V.1.4. Les composants Swing

Il existe des composants Swing équivalents pour chacun des composants AWT
avec des constructeurs semblables. De nombreux constructeurs acceptent comme argument
un objet de type Icon, qui représente une petite image généralement stockée au format Gif.
Le constructeur d'un objet Icon admet comme seul paramètre le nom ou l'URL
d'un fichier graphique
Exemple:
public swing3() {
System.exit(0);
}
};
ImageIcon img = new ImageIcon("tips.gif");
JButton bouton = new JButton("Mon bouton",img);
JPanel panneau = new JPanel();
panneau.add(bouton);
setContentPane(panneau);
setSize(200,100);
setVisible(true);
}
}
}
V.1.4.1. La classe JFrame
JFrame est l'équivalent de la classe Frame de l'AWT : les principales

différences sont l'utilisation du double buffering qui améliore les rafraichissements et
l'utilisation d'un panneau de contenu (contentPane) pour insérer des composants (ils ne sont
plus insérés directement au JFrame mais à l'objet contentPane qui lui est associé). Elle
représente une fenêtre principale qui possède un titre, une taille modifiable et
éventuellement un menu.
La classe possède plusieurs constructeurs :

Par défaut, la fenêtre créée n'est pas visible. La méthode setVisible() permet
de l'afficher.
Exemple:
public class TestJFrame1 {
public static void main(String argv[]) {
JFrame f = new JFrame("ma fenetre");
f.setSize(300,100);
f.setVisible(true);
}
}
La gestion des événements est identique à celle utilisée dans l'AWT depuis le
J.D.K. 1.1.
Exemple:
public swing2() {
System.exit(0);
}
};
JButton bouton = new JButton("Mon bouton");
setSize(200,100);
setVisible(true);
}
}
}
Tous les composants associés à un objet JFrame sont gérés par un objet de la
classe JRootPane. Un objet JRootPane contient plusieurs Panes. Tous les composants ajoutés
au JFame doivent être ajoutés à un des Pane du JRootPane et non au JFrame directement.
C'est aussi à un de ces Panes qu'il faut associer un layout manager si nécessaire.

Le Pane le plus utilisé est le ContentPane. Le Layout manager par défaut du contentPane est
BorderLayout. Il est possible de le changer :
Exemple :
...
f.getContentPane().setLayout(new FlowLayout());
...
Exemple:
f.setSize(300,100);
JButton b =new JButton("Mon bouton");
f.getContentPane().add(b);
f.setVisible(true);
}
}
Le JRootPane se compose de plusieurs éléments :
 glassPane : un JPanel par défaut

 layeredPane qui se compose du contentPane (un JPanel par défaut) et du menuBar
(un objet de type JMenuBar)
Le glassPane est un JPanel transparent qui se situe au dessus du layeredPane. Le glassPane

peut être n'importe quel composant : pour le modifier il faut utiliser la méthode
setGlassPane() en fournissant le composant en paramètre.
Le layeredPane regroupe le contentPane et le menuBar.

Le contentPane est par défaut un JPanel opaque dont le gestionnaire de présentation est un
BorderLayout. Ce panel peut être remplacé par n'importe quel composant grâce à la
méthode setContentPane().
Attention : il ne faut pas utiliser directement la méthode setLayout() d'un objet JFrame
sinon une exception est levée.
Exemple:
import java.awt.*;
f.setLayout(new FlowLayout());
f.setSize(300,100);
f.setVisible(true);
}
}
Le menuBar permet d'attacher un menu à la JFrame. Par défaut, le menuBar
est vide. La méthode setJMenuBar() permet d'affecter un menu à la JFrame.
Exemple: Création d'un menu très simple
import java.awt.*;
f.setSize(300,100);
JMenuBar menuBar = new JMenuBar();
f.setJMenuBar(menuBar);
JMenu menu = new JMenu("Fichier");
menu.add(menuItem);
menuBar.add(menu);
f.setVisible(true);
}
}
V.1.4.1.1. Le comportement par défaut à la fermeture

Il est possible de préciser comment un objet JFrame, JInternalFrame, ou
JDialog réagit à sa fermeture grâce à la méthode setDefaultCloseOperation(). Cette méthode
attend en paramètre une valeur qui peut être :

Cette méthode ne permet pas d'associer d'autres traitements. Dans ce cas, il
faut intercepter l'événement et lui associer les traitements.
Exemple: la fenêtre disparaît lors de sa fermeture mais l'application ne se termine pas
f.setSize(300,100);
f.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE)
;
f.setVisible(true);
}
}
V.1.4.1.2. La personnalisation de l'icône
La méthode setIconImage() permet de modifier l'icône de la JFrame.
Exemple :
f.setSize(300,100);
;
ImageIcon image = new ImageIcon("book.gif");
f.setIconImage(image.getImage());
f.setVisible(true);
}
}
Si l'image n'est pas trouvée, alors l'icône est vide. Si l'image est trop grande,
elle est redimensionnée.
V.1.4.1.3. Centrer une JFrame à l'écran

Par défaut, une JFrame est affichée dans le coin supérieur gauche de l'écran.
Pour la centrer dans l'écran, il faut procéder comme pour une Frame : déterminer la position
de la Frame en fonction de sa dimension et de celle de l'écran et utiliser la méthode
setLocation() pour affecter cette position.
Exemple:
import java.awt.*;
f.setSize(300,100);
;
Dimension dim = Toolkit.getDefaultToolkit().getScreenSize();
f.setLocation(dim.width/2 − f.getWidth()/2, dim.height/2 −
f.getHeight()/2);
f.setVisible(true);
}
}
V.1.4.1.4. Les évenements associées à un JFrame
La gestion des évenements associés à un objet JFrame est identique à celle

utilisée pour un objet de type Frame de AWT.
Exemple:
f.setSize(300,100);
f.setVisible(true);
f.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
);
}
}
V.1.4.2. Les étiquettes : la classe JLabel
Le composant JLabel propose les mêmes fonctionnalités que les intitulés AWT
mais ils peuvent en plus contenir des icônes.
Cette classe possède plusieurs constructeurs :

Le composant JLabel permet d'afficher un texte et/ou une icône en précisant leur alignement.
L'icône doit être au format
GIF et peut être une animation dans ce format.
Exemple:
import java.awt.*;
public class TestJLabel1 {
f.setSize(100,200);
JPanel pannel = new JPanel();
JLabel jLabel1 =new JLabel("Mon texte dans JLabel");
pannel.add(jLabel1);
ImageIcon icone = new ImageIcon("book.gif");
JLabel jLabel2 =new JLabel(icone);
JLabel jLabel3 =new
JLabel("Montexte",icone,SwingConstants.LEFT);
f.getContentPane().add(pannel);
f.setVisible(true);
}
}
La classe JLabel définit plusieurs méthodes pour modifier l'apparence du
composant :

L'alignement vertical par défaut d'un JLabel est centré. L'alignement
horizontal par défaut est soit à droite si il ne contient que du texte, soit centré si il contient
une image avec ou sans texte. Pour modifier cet alignement, il suffit d'utiliser les méthodes
ci dessus en utilisant des constantes en paramètres : SwingConstants.LEFT,
SwingConstants.CENTER, SwingConstants.RIGHT, SwingConstants.TOP,
SwingConstants.BOTTOM
Par défaut, un JLabel est transparent : son fond n'est pas dessiné. Pour le
dessiner, il faut utiliser la méthode setOpaque() :
Exemple:
import java.awt.*;
f.setSize(100,200);
JLabel jLabel1 =new JLabel("Mon texte dans JLabel 1");
jLabel1.setBackground(Color.red);
JLabel jLabel2 =new JLabel("Mon texte dans JLabel 2");
jLabel2.setOpaque(true);
f.setVisible(true);
}
}
Dans l'exemple, les 2 JLabel ont le fond rouge demandé par la méthode
setBackground(). Seul le deuxième affiche un fond rouge car il est rendu opaque avec la
méthode setOpaque().
Il est possible d'associer un raccourci clavier au JLabel qui permet de donner le
focus à un autre composant. La méthode setDisplayedMnemonic() permet de définir le
raccourci clavier. Celui ci sera activé en utilisant la touche Alt avec le caractère fourni en
paramètre. La méthode setLabelFor() permet d'associer le composant fourni en paramètre
au raccourci.
Exemple:
import java.awt.*;

f.setSize(300,100);
JButton bouton = new JButton("saisir");
pannel.add(bouton);
JTextField jEdit = new JTextField("votre nom");
JLabel jLabel1 =new JLabel("Nom : ");
jLabel1.setDisplayedMnemonic('n');
jLabel1.setLabelFor(jEdit);
pannel.add(jEdit);
f.setVisible(true);
}
}
Dans l'exemple, à l'ouverture de la fenêtre, le focus est sur le bouton. Un
appui sur Alt+'n' donne le focus au champ de saisie.
V.1.4.3. Les panneaux : la classe Jpanel
La classe JPanel est un conteneur utilisé pour regrouper et organiser des

composants grâce à un gestionnaire de présentation (layout manager). Le gestionnaire par
défaut d'un JPanel est un objet de la classe FlowLayout.
V.1.5. Les boutons
Il existe plusieurs boutons définis par Swing.

V.1.5.1. La classe AbstractButton
C'est une classe abstraite dont hérite les boutons Swing JButton, JMenuItem
et JToggleButton.
Cette classe définit de nombreuses méthodes dont les principales sont :
Tous les boutons peuvent afficher du texte et/ou une image. Il est possible de
préciser une image différente lors du passage de la souris sur le composant et lors de
l'enfoncement du bouton : dans ce cas, il faut créer trois images pour chacun des états
(normal, enfoncé et survolé). L'image normale est associée au bouton grâce au constructeur,
l'image enfoncée grâce à la méthode setPressedIcon() et l'image lors d'un survole grâce à la
méthode setRolloverIcon(). Il suffit enfin d'appeler la méthode setRolloverEnable() avec en
paramètre la valeur true.
Exemple:
public swing4() {

System.exit(0);
}
};
ImageIcon imageNormale = new ImageIcon("arrow.gif");
ImageIcon imagePassage = new ImageIcon("arrowr.gif");
ImageIcon imageEnfoncee = new ImageIcon("arrowy.gif");
JButton bouton = new JButton("Mon bouton",imageNormale);
bouton.setPressedIcon(imageEnfoncee);
bouton.setRolloverIcon(imagePassage);
bouton.setRolloverEnabled(true);
getContentPane().add(bouton, "Center");
setSize(200,100);
setVisible(true);
}
}
}
Un bouton peut recevoir des évenements de type ActionEvents (le
bouton a été activé), ChangeEvents, et ItemEvents.
Exemple: fermeture de l'application lors de l'activation du bouton
public class TestJButton3 {
f.setSize(300,100);
JButton bouton1 = new JButton("Bouton1");
bouton1.addActionListener( new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
}
);
pannel.add(bouton1);
f.setVisible(true);
}
}

Pour de plus amplements informations sur la gestion des événements, voir le
chapitre correspondant.
V.1.5.2. La classe JButton
JButton est un composant qui représente un bouton : il peut contenir un texte

et/ou une icône.
Les constructeurs sont :
Il ne gère pas d'état. Toutes les indications concernant le contenu du composant JLabel sont
valables pour le composant JButton.
Exemple: un bouton avec une image

public swing3() {
System.exit(0);
}
};
ImageIcon img = new ImageIcon("tips.gif");
JButton bouton = new JButton("Mon bouton",img);
setSize(200,100);
setVisible(true);
}
}
}
L'image gif peut être une animation. Dans un conteneur de type JRootPane, il
est possible de définir un bouton par défaut grace à sa méthode setDefaultButton().

Exemple: définition d'un bouton par défaut dans un JFrame
import java.awt.*;
public class TestJButton2 {
f.setSize(300,100);
JButton bouton1 = new JButton("Bouton 1");
f.getRootPane().setDefaultButton(bouton3);
f.setVisible(true);
}
}
Le bouton par défaut est activé par un appui sur la touche Entrée alors que le
bouton actif est activé par un appui sur la barre d'espace.
La méthode isDefaultButton() de JButton permet de savoir si le composant est
le bouton par défaut.
V.1.5.3. La classe JToggleButton
Cette classe définit un bouton à deux états : c'est la classe mère des
composants JCheckBox et JRadioButton.
La méthode setSelected() héritée de AbstractButton permet de mettre à jour
l'état du bouton. La méthode isSelected() permet de connaître cet état.
V.1.5.4. La classe ButtonGroup
La classe ButtonGroup permet de gérer un ensemble de boutons en garantissant qu'un seul

bouton du groupe sera sélectionné.
Pour utiliser la classe ButtonGroup, il suffit d'instancier un objet et d'ajouter des boutons
(objets héritant de la classe AbstractButton) grâce à la méthode add(). Il est préférable
d'utiliser des objets de la classe JToggleButton ou d'une de ces classes filles car elles sont
capables de gérer leurs états.
Exemple:

public class TestGroupButton1 {
f.setSize(300,100);
ButtonGroup groupe = new ButtonGroup();
JRadioButton bouton1 = new JRadioButton("Bouton 1");
groupe.add(bouton1);
f.setVisible(true);
}
}
V.1.5.5. Les cases à cocher : la classe JCheckBox
Les constructeurs sont les suivants :
Un groupe de cases à cocher peut être défini avec la classe ButtonGroup. Dans
ce cas, un seul composant du groupe peut être sélectionné. Pour l'utiliser, il faut créer un
objet de la classe ButtonGroup et utiliser la méthode add() pour ajouter un composant au
groupe.
Exemple:
public class TestJCheckBox1 {
f.setSize(300,100);

JCheckBox bouton1 = new JCheckBox("Bouton 1");
f.setVisible(true);
}
}
V.1.5.6. Les boutons radio : la classe JRadioButton
Les constructeurs sont les mêmes que ceux de la classe JCheckBox.
Exemple :
public class TestJRadioButton1 {
f.setSize(300,100);
f.setVisible(true);
}
}
Pour regrouper plusieurs boutons radio, il faut utiliser la classe
CheckboxGroup
V.1.6. Les composants de saisie de texte
Swing possède plusieurs composants pour permettre la saisie de texte.

V.1.6.1. La classe JTextComponent
La classe abstraite JTextComponent est la classe mère de tous les composants

permettant la saisie de texte.
Les données du composant (le modèle dans le motif de conception MVC) sont
encapsulées dans un objet qui implémente l'interface Document. Deux classes implémentant
cette interface sont fournies en standard : PlainDocument pour du texte simple et
StyledDocument pour du texte riche pouvant contenir entre autre plusieurs polices de
caractères, des couleurs, des images, ...
Les methodes principales de JTextComponent sont :

Toutes ces méthodes sont donc accessibles grâce à l'héritage pour tous les
composants de saisie de texte proposés par Swing.
V.1.6.2. La classe JTextField
La classe javax.Swing.JTextField est un composant qui permet la saisie d'une

seule ligne de texte simple. Son modèle utilise un objet de type PlainDocument.
Exemple:
public class JTextField1 {

f.setSize(300, 100);
JTextField testField1 = new JTextField ("mon texte");
pannel.add(testField1);
f.setVisible(true);
}
}
La propriété horizontalAligment permet de préciser l'alignement du texte dans le composant

en utilisant les valeurs JTextField.LEFT , JTextField.CENTER ou JTextField.RIGHT.
V.1.6.3. La classe JPasswordField
La classe JPasswordField permet la saisie d'un texte dont tous les caractères saisis seront
affichés sous la forme d'un caractère particulier ('*' par défaut). Cette classe hérite de la
classe JTextField.
Exemple :
import java.awt.Dimension;
public class JPasswordField1 {
JPasswordField passwordField1 = new JPasswordField ("");
passwordField1.setPreferredSize(new Dimension(100,20 ));
pannel.add(passwordField1);
f.setVisible(true);
}
}

La méthode setEchoChar(char) permet de préciser le caractère qui sera utilisé pour afficher
la saisie d'un caractère.
Il ne faut pas utiliser la méthode getText() qui est déclarée deprecated mais la méthode
getPassword() pour obtenir la valeur du texte saisi.
Exemple:
public class JPasswordField2 implements ActionListener {
JPasswordField passwordField1 = null;
JPasswordField2 jpf2 = new JPasswordField2();
jpf2.init();
}
public void init() {
passwordField1 = new JPasswordField("");
passwordField1.setPreferredSize(new Dimension(100, 20));
pannel.add(passwordField1);
JButton bouton1 = new JButton("Afficher");
bouton1.addActionListener(this);
f.setVisible(true);
}
public void actionPerformed(ActionEvent e) {
System.out.println("texte saisie = " +
String.copyValueOf(passwordField1.getPassword()));
}
}
Les méthodes copy() et cut() sont redéfinies pour empêcher l'envoi du
contenu dans le composant et émettre simplement un beep.
V.1.6.4. La classe JFormattedTextField
Le JDK 1.4 propose la classe JFormattedTextField pour faciliter la création d'un

composant de saisie personnalisé. Cette classe hérite de la classe JTextField.
V.1.6.5. La classe JEditorPane

Ce composant permet de saise de texte riche multi−lignes. Ce type de texte
peut contenir des informations de mise en pages et de formatage. En standard, Swing
propose le support des formats RTF et HTML.
Exemple : affichage de la page de Google avec gestion des hyperliens
import java.net.URL;
import javax.swing.event.*;
public class JEditorPane1 {
public static void main(String[] args) {
final JEditorPane editeur;
try {
editeur = new JEditorPane(new URL("http://google.fr"));
editeur.setEditable(false);
editeur.addHyperlinkListener(new HyperlinkListener() {
public void hyperlinkUpdate(HyperlinkEvent e) {
if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED)
{
URL url = e.getURL();
if (url == null)
return;
try {
editeur.setPage(e.getURL());
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
});
pannel.add(editeur);
} catch (Exception e1) {
e1.printStackTrace();
}
f.setVisible(true);
}
}

V.1.6.6. La classe JTextPane
V.1.6.7. La classe JTextArea
La classe JTextArea est un composant qui permet la saisie de texte simple en

mode multi−lignes. Le modèle utilisé par ce composant est le PlainDocument : il ne peut
donc contenir que du texte brut sans éléments multiples de formatage.
JTexteArea propose plusieurs méthodes pour ajouter du texte dans son modèle :
 Soit fournir le texte en pramètre du constructeur utilisé

 Soit utiliser la méthode setText() qui permet d'initialiser le texte du composant soit
utiliser la méthode append() qui permet d'ajouter du texte à la fin de celui contenu
dans le texte du composant
 Soit utiliser la méthode insert() permet d'insérer un texte à une position données en
caractères dans dans le texte du composant
La méthode replaceRange() permet de remplacer une partie du texte

désignée par la position du caractère de début et la position de son caractère de fin par le
texte fourni en paramètre.

La propriété rows permet de définir le nombre de ligne affichée par le
composant : cette propriété peut donc être modifiée lors d'un redimensionnement du
composant. La propriété lineCount en lecture seule permet de savoir le nombre de lignes
dont le texte est composé. Il ne faut pas confondre ces deux propriétés.
Exemple:
public class JTextArea1 {
JTextArea textArea1 = new JTextArea ("mon texte");
pannel.add(textArea1);
f.setVisible(true);
}
}
Par défaut, la taille du composant augmente au fur et à mesure de

l'augmentation de la taille du texte qu'il contient. Pour éviter cet effet, il faut encapsuler le
JTextArea dans un JScrollPane.
Exemple :
public class JTextArea1 {
JTextArea textArea1 = new JTextArea ("mon texte");
JScrollPane scrollPane = new JScrollPane(textArea1);
scrollPane.setPreferredSize(new Dimension(200,70));
pannel.add(scrollPane);
f.setVisible(true);

}
V.1.7. Les onglets
La classe javax.swing.JTabbedPane encapsule un ensemble d'onglets. Chaque onglet est

constitué d'un titre, d'un composant et éventuellement d'une image.
Pour utiliser ce composant, il faut :
 Instancier un objet de type JTabbedPane

 Créer le composant de chaque onglet
 Ajouter chaque onglet à l'objet JTabbedPane en utilisant la méthode addTab()
Exemple:
import java.awt.event.KeyEvent;
public class TestJTabbedPane1 {
JFrame f = new JFrame("Test JTabbedPane");
JTabbedPane onglets = new JTabbedPane(SwingConstants.TOP);
JPanel onglet1 = new JPanel();
JLabel titreOnglet1 = new JLabel("Onglet 1");
onglet1.add(titreOnglet1);
onglet1.setPreferredSize(new Dimension(300, 80));
onglets.addTab("onglet1", onglet1);
JPanel onglet2 = new JPanel();
JLabel titreOnglet2 = new JLabel("Onglet 2");
onglet2.add(titreOnglet2);
onglets.addTab("onglet2", onglet2);
onglets.setOpaque(true);
pannel.add(onglets);
f.setVisible(true);
}

}
A partir du JDK 1.4, il est possible d'ajouter un raccourci clavier sur chacun des
onglets en utilisant la méthode setMnemonicAt(). Cette méthode attend deux paramètres :
l'index de l'onglet concerné (le premier commence à 0) et la touche du clavier associée sous
la forme d'une constance KeyEvent.VK_xxx. Pour utiliser ce raccourci, il suffit d'utiliser la
touche désignée en paramètre de la méthode avec la touche Alt.
La classe JTabbedPane possède plusieurs méthodes qui permettent de définir

le contenu de l'onglet :
La méthode getSelectedIndex() permet d'obtenir l'index de l'onglet courant.

La méthode setSelectedIndex() permet de définir l'onglet courant.
V.2. Reporting
V.2.1. Introduction

Les applications d'entreprises nécessitent souvent des éditions écran, mais
aussi papier, provenant de sources diverses (base de données, fichiers XML, etc…)
Les solutions d'implémentation sont diverses :
 Framework d'entreprise propriétaire

 Outils payants (Actuate, Business Objects, etc.)
Cependant des outils issus du libre existent et sont très puissants en terme de
fonctionnalités :
 XSL et XSL-FO pour la mise en forme de données XML

 Le framework Jasper Report
Nous étudierons dans ce document l'utilisation de la librairie Jasper Report au

travers de la construction d'un rapport simple via le iReport et de sa génération au format
PDF avec du code JAVA. La source de données choisie est le SGBD MySQL.
V.2.2. Utilisation de iReport
Lors du lancement de iReport (version 3.5.2), une fenêtre « Welcome

Windows apparait avec le message suivant : «Follow these three steps to create your first
report »
V.2.2.1. Création d’une connexion

En cliquant sur la 1ère Etape, on lance le wizard pour créer une connexion à
une base de données ; la fenêtre ci-dessous apparait :
On choisit une source de données puis, on clique sur Next>. Pour notre cas la
source de données est DataBase JDBC Connection.
La nouvelle boite de dialogue qui apparait permet de faire la connexion à la

base de données ; il faut donc préciser le nom de la Base de données, le pilote, et l’URL de la
base de données.

Et après, on teste la connexion avant de la sauver. Une fois la connexion est
sauvée, on clique sur la 2è étape la création du rapport.
V.2.2.2.Création d’un rapport
On lance le Report Wizard en précisant le nom du rapport et son

emplacement. Puis on clique sur le « Suivant ».

« Suivant »
Cliquer Next en spécifiant la requête SQL

Cliquer Next et sélectionner tous les champs en cliquant >>
Suivant>

Suivant>
Un clique sur « Terminer » génère le rapport.

V.2.2.3. Compilation du rapport
La compilation du rapport se fait après son enregistrement. Le format du

rapport est « jrxml ». La compilation génère un fichier de format « jasper ».
Compiler
V.2.3. Génération du rapport PDF via Java
Pour utiliser notre rapport compilé sur iReport, nous devons au préalable
configurer l’environnement de travail en ajoutant les librairies dans la CLASSPATH de
l’application.
Exemple :

public class GeneratePDF {
// - Paramètres de connexion à la base de données
String url = "jdbc:mysql://localhost/jasper_database";
String login = "root";
String password = "root";
try {
// - Connexion à la base
Driver monDriver = new com.mysql.jdbc.Driver();
DriverManager.registerDriver(monDriver);
Connection connection = DriverManager.getConnection(url,
login, password);
// - Chargement et compilation du rapport
JasperDesign jasperDesign = JRXmlLoader.load("D:\\iReport-

1.2.1\\report1.jrxml");
JasperReport jasperReport =
JasperCompileManager.compileReport(jasperDesign);
// - Paramètres à envoyer au rapport

Map parameters = new HashMap();
parameters.put("Titre", "Titre");
// - Execution du rapport
JasperPrint jasperPrint =
JasperFillManager.fillReport(jasperReport, parameters,
connection);
// - Création du rapport au format PDF

JasperExportManager.exportReportToPdfFile(jasperPrint,
"c:\\iReport-1.2.1\\classic.pdf");
}
catch (JRException e) {
}
catch (SQLException e) {
}
finally {
connection.close();
}
}
}
Après exécution de cette classe, on a :

V.3. Les pages web dynamiques: JSP
(Version future)
V.4. JSF : Java Server Face
(Version future)

Partie III : Etude de cas et Exercices
Chapitre VI : Etudes des Cas
Le processus de développement que nous allons suivre est le suivant :
I. Spécification initiale et constitution du cahier de charge

II. Analyse de l’existant
III. Critique de l’existant
IV. Modélisation
1. Modélisation Conceptuelle
 MCC
 MCT
 MCD
2. Modélisation Organisationnelle
 MOT
 MOD
3. Modélisation logique et physique
 Architecture globale du Système
 MLT
 MLD
 MPD
V. Implémentation
1. Implémentation de la base de données
2. Implémentation de la couche métier en Java
3. Implémentation de la couche de présentation

Projet : Gestion d’une bibliothèque Universitaire : Automatisation
des emprunts des Ouvrages
1. Spécification Initiale et Constitution du cahier de charge
L’Université de Kinshasa souhaite automatiser la gestion de sa bibliothèque centrale.

Les deux catégories de tâches à automatiser sont les suivantes :
 Les tâches sur la gestion des abonnés

 Les tâches sur la gestion des Ouvrages
Le gestionnaire des abonnés désire que le nouveau système lui fournisse :
 Les abonnés dont l’abonnement est encours

 Les abonnés dont l’abonnement a expiré
 Les abonnés par rapport à leurs promotions
 L’historique des emprunts de l’abonné
 L’édition d’une carte d’abonnement après l’enregistrement d’un nouvel
abonné
La gestion des ouvrages concerne la production des rapports automatisés de:
 Tous les Ouvrages

 Tous les Ouvrages disponibles en stock
 Tous les Ouvrages encours d’emprunts
 Ouvrages par rapport à leurs auteurs
 Ouvrages par rapport à leurs maisons d’éditions
 Ouvrages par rapport à leurs maisons de publications
2. Analyse de l’existent
2.1. Présentation de la Bibliothèque Centrale de l’Université de Kinshasa
L’histoire de la Bibliothèque Centrale de l’Université de Kinshasa est

liée à celle de la création de l’Université de Kinshasa, anciennement Université de
Lovanium.
L’Université de Kinshasa, institution publique d’enseignement

supérieur et universitaire de la République Démocratique du Congo, a été créée par

l’ordonnance n°081-142 du 03 octobre 1981 du Président de la République MOBUTU
SESE SEKO. Ce texte loi n’a été que pour régulariser le dossier car cette institution
fonctionnait déjà depuis 1954, date de sa fondation, sous l’appellation ≪ Université
Lovanium ≫ (1954-1971) avant de devenir tour à tour Université Nationale du Zaire,
Campus de Kinshasa (1971-1981) et Université de Kinshasa (1981 à nos jours).
De sa création à ce jour, l’Université de Kinshasa a connu plusieurs recteurs et vice

recteurs dont le premier fut le Révérend Père M.SCHURMANS, qui a dirigé du 13 avril
au 12 octobre 1954. Il fut nommé par le bâtisseur Mgr LUC GILLON lui-même avant
de reprendre le bâton de commandement de 1954 à 1967 puis le cède au tout
premier noir, Mgr Tharcisse TSHIBANGU de 1967 à 1971.
A la date d’aujourd’hui (2008), le dernier des recteurs est le Professeur KIKA, nommé
par l’actuel Président de la République Démocratique du Congo Joseph KABILA
Kabange, par un décret portant nomination des recteurs des établissements publics
d’enseignement supérieur et universitaire.
Il faut signaler que de ces différents recteurs qui ont défilé à la tête de l’Université de
Kinshasa, le Professeur Nestor MPEYE NYANGO est revenu deux fois au pouvoir : de
1983 à 1986, et de 2000 à 2001.
A la création de l’Université de Kinshasa, Université Lovanium à l’époque, en 1954, la

bibliothèque était déjà implantée. Et cela au début des années 1953 avec
l’appellation de « Bibliothèque de l’université Lovanium » sous la direction du
Professeur Jacques PACQUET, son bibliothécaire en chef.
Déjà en date du 25 février 1953, le bibliothécaire en chef effectua la première

commande des livres dont le fonds, essentiellement philosophique, était loge dans
deux chambres d’étudiants au home 1 du plateau des étudiants en 1954.
Une année après, soit en 1955, trois autres chambres furent ajoutées et le sous-sol
de la faculté des Sciences a servi, en 1956, de cache ou magasin. Tandis que le
bâtiment Administratif, érige en 1957, réservera une partie du rez-de-chaussée a la
bibliothèque dont l’occupation effective interviendra trois ans après, soit en 1960
pendant les grandes vacances.
 Situation géographique
La Bibliothèque Centrale de l’Université de Kinshasa est logée dans le grand

bâtiment administratif de l’Université de Kinshasa.
Elle est séparée de part et d’autre :
 Au nord par la Faculté des Sciences ;

 Au sud par la Faculté des Sciences Sociales, Administratives et Politiques ;

 A l’ouest par l’Etat-major de la police universitaire de l’Université de Kinshasa
et la librairie universitaire ;
 A l’est par l’amphithéâtre Léon de Saint Moulin.
Les locaux repartis en trois grandes parties ou niveaux, sont successivement occupes
par le magasin avec une dimension de 1.851.651 m2 et une capacité de stockage de
10.000.000 (dix millions) de volumes, représentant le sous-sol ou 1er niveau, suivi du
rez-de-chaussée occupe par la salle de reliure, l’intendance, le département des
acquisitions et celui de catalogage, l’administration (bureau du bibliothécaire en chef,
du bibliothécaire en chef adjoint et le secrétaire de direction) et la salle de machine ;
cela constitue le 2eme niveau et enfin le troisième niveau qui abrite les
départements de conservation et prêts, celui de référence et circulation, avec une
grande salle de lecture de •}200 places. Ces deux derniers niveaux ont la même
superficie, soit 917.499 cm2 chacun.
 Objectif global
L’Université de Kinshasa, comme tout établissement universitaire au monde, a pour

objectif la formation des étudiants, qui dirigeront plus tard la société et la recherche
scientifique, qui contribuera au progrès social.
Dans son aspect de la recherche, elle utilise deux principaux moyens, celui des
expériences et la documentation. C’est bien à ce niveau que nous trouvons la raison
fondée d’une bibliothèque à l’Université.
En résume, la bibliothèque centrale de l’Université de Kinshasa a pour objectif global

d’aider les étudiants, le corps scientifique et professoral a la recherche, en leur
fournissant la documentation adéquate.
 Principales activités
La bibliothèque centrale de l’Université de Kinshasa a comme principales activités :
 La gestion des ouvrages ;

 La mise en disposition des ouvrages ;
 La conservation de ces ouvrages.
2.2. Analyse de la structure et activités système existent
La bibliothèque centrale de l’Université de Kinshasa est composée de 6

départements, elle est dirigée par un bibliothécaire en chef qui supervise toutes les
opérations.
Elle utilise 3 moyens pour l’obtention de ses ouvrages : l’achat, les dons et les
échanges avec d’autres bibliothèques.

Ces ouvrages sont réceptionnés par le département des acquisitions, qui les
estampille et les enregistre. L’estampillage consiste à apposer des insignes sur les
ouvrages pour ainsi permettre de prouver leur appartenance à la bibliothèque.
Ensuite, on procède à l’enregistrement des ouvrages. A ce stade, les ouvrages se
distinguent en 2 grands groupes : les livres et les périodiques. Ils sont tous enregistres
dans un registre d’après son groupement, ainsi pour les livres, on indique les
informations suivantes dans le dit registre : un numéro (unique attribue à ce niveau),
la date de réception du livre, son (ou ses) auteur(s), son titre, son éditeur, son lieu
d’Edition, sa maison d’édition, son année de publication, le tome (ou volume), au cas
où il en existerait plusieurs , le nombre de copie, la collection.
Et pour les périodiques, on indique un numéro unique, attribue par ce département,

comme dans le cas des livres, la date de réception de la périodique, son (ses) titre(s),
l’entreprise l ayant sous sa responsabilité, sa périodicité, la numérotation de son
volume, son lieu de publication, sa maison de publication, l’année de sa publication,
les observations.
Depuis peu, on procède par l’enregistrement sur ordinateur à l’aide du logiciel

MSEXCEL.
Les ouvrages quittent, après ces opérations, le département d’acquisition pour celui
de catalogage pour subir un certain nombre de traitement en plus.
A l’arrivée des ouvrages au département de catalogage, on procède par l’indexation,

qui est un travail destine à représenter par les éléments d’un langage documentaire,
les résultats de l’analyse d’un ouvrage en vue de faciliter la recherche ; en d’autres
termes, c’est un travail destine à exprimer le contenu d’un ouvrage par le langage
documentaire qui, lui- même, est constitué de vedettes matières (contenu exacte de
l’ouvrage en quelques mots), ou descripteurs, ou mots-clés et d’une indice tire d’une
classification.
Pour y arriver, il faut parcourir rapidement la table de matière, ou la préface, ou

l’avant-propos, ou l’introduction, ou les mots en bas de pages, ou lire la conclusion,
ou encore le résume sur le dos de la couverture de l’ouvrage, au cas où l’on ne
retrouvait toujours pas, on lit l’ouvrage dans son entièreté, sinon chercher les
spécialistes qui peuvent apporter de l’aide sur la matière de cet ouvrage.
Certains ouvrages peuvent développer un ou plusieurs contenus. Apres avoir été fixe
sur le contenu, on fait appel à la table de classification de DEWEY, qui permettra
d’attribuer un indice a l’ouvrage.
Au bout de cette étape, on établit la cote constituée de l’indice, des 3 premières

lettres du nom de l’auteur, et de l’année de publication. Cette cote représente
l’adresse permettant de retrouver un ouvrage.
A la suite de l’indexation, les cotes sont transmises au service de la description

bibliographique ou l’on établit la fiche de catalogue pour chaque ouvrage.

Lors de cette opération, on rencontre un grand nombre de difficultés compte tenu de
la diversité des ouvrages à traiter, il peut s’agir d’un rapport de séminaire, d’une
publication scientifique, d’une encyclopédie, d’un dictionnaire ou des ouvrages
ordinaires.
Pour tous ces ouvrages, l’établissement de la fiche de catalogue ne s’effectue pas de

la même façon.
Nous prendrons le cas des ouvrages ordinaires, qui est le plus fréquent, on note sur la
première ligne la clé d’entrée (généralement le nom de l’auteur) en Majuscule, suivi
d’un point-virgule, son prénom dont la première lettre est inscrit en majuscule et le
reste en minuscule.
Sur la seconde ligne, on indique : le titre, le sous-titre, le complément du titre, toutes

les annotations de l’auteur tel que sur l’ouvrage. Tous séparés par des points virgules.
A la fin, on marque un tiret précède d’un point, puis on indique tout ce qui concerne
l’édition (le lieu, la maison, l’année d’édition), on le fait suivre d’un point suivit d’un
tiret, puis la pagination, suivi d’un point-virgule, puis la dimension de l’ouvrage, on
marque par la suite la collection et le numéro ISBN sépare par le point suivi d’un tiret.
Sur une ligne supplémentaire, on indique les différentes autres vedettes en suivant
leur hiérarchie
La fiche de base ainsi établit, elle est expédiée au service de duplication ou on la

reproduit en changeant la première ligne ; soit en la remplaçant par la vedette
matière soit par les indications de la cote.
Pour les ouvrages co-écrits, ou en dupliquera pour chacun des auteurs.

Ensuite, les ouvrages peuvent être mis à la disposition des lecteurs ; c’est-à-dire qu’ils
sont envoyés vers le département de référencement et circulation. Une partie est
redirigée vers le magasin.
Ceux au niveau du département de référencement et circulation vont être expose

pendant un certain temps et les passe, ensuite, au département de conservation et
prêt ou l’on classe les ouvrages selon leurs côtes.
Dans cette bibliothèque, suite aux abus très courant des abonnes, on a opté pour la
politique des prêts internes c’est-à-dire que les abonnes n’ont droit d’utiliser les
ouvrages que dans la salle de lecture de la bibliothèque et nulle part ailleurs.
Il existe un registre dans ce département ou l’on note les informations sur tous les
abonnes qui empruntent les ouvrages. On y signale : son nom, sa promotion, la cote
du livre, le titre et le nom de l’auteur.
Les abonnes de la bibliothèque fournissent les informations suivantes pour être

admis : le nom, le prénom, le post nom, la qualité, la faculté, le numéro matricule,
l’année d’étude et la promotion pour les étudiants, l’adresse, et enfin la photo.

2.3. Analyse de postes de travail
2.4. Analyse de flux d’information
Recensement des acteurs
 Acquisition
 Catalogage
 Référencement et circulation
 Conservation et prêt
 Magasinage
Légende
 Ouvr : Ouvrages
 T1 : Estampillage et enregistrement dans la registre
 Ouvr1 : Ouvrages estampilles et enregistres
 T2 : Indexation
 Ouvr2 : Ouvrages ayant subi l’indexation
 Cote
 T3 : Etablissement de la fiche de catalogage de base
 FCB : Fiche de catalogage de base
 T4 : Duplication des fiches de catalogage de base
 FCC : Fiche de catalogage cote
 FCM : Fiche de catalogage matières
 FCA : Fiche de catalogage Auteurs

 Ouvr3 : Ouvrages exposes
 T6 : Classement des ouvrages d’après leurs côtes (conservation)
 Ouvr4 : Ouvrages en conservation
 T7 : Prêt ouvrages et enregistrement de l’abonne
 Ouvr5 : Ouvrages empruntes
2.5. Analyse des moyens de traitements

3. Critique de l’existent
3.1. Recensement des problèmes et Analyse des problèmes
Nous devons retenir de cette analyse que la bibliothèque universitaire de l’UNIKIN

arrive a bien remplir sa tache ainsi permettant aux scientifiques d’obtenir les
informations recherchées.
Au niveau de la gestion de la bibliothèque également, on s’active de telle manière à

donner le meilleur de soi, pour sa bonne marche.
Néanmoins, ils font face à des nombreuses difficultés tels que :
 L’exécution de plusieurs taches manuellement alors qu’ils possèdent déjà

l’outil informatique ;
 L’utilisation des logiciels non appropries, ne leur servant, a priori qu’a
l’enregistrement ;
 Le temps de réponse très long dans le cas d’une augmentation des
fréquentations de la bibliothèque ;
 L’insuffisance d’ouvrages ;
 Abus de confiance du cote des abonnes ;
 Et tant d’autres problèmes découlant de ceux cités ci-dessus.
3.2. Construction de la solution
Pour pallier à ces problèmes, nous pensons qu’il est fort nécessaire d’informatiser
quelques servies de la bibliothèque ; ainsi elle gagnera en temps, en qualité de
travail, en communication en son sein, en sécurité et au-delà de tout ceci en
rentabilité financière, car nous savons tous qu’une bibliothèque plus moderne attire
un grand nombre de client.

Concernant notre travail, nous proposerons une solution à court terme qu’est la
gestion des livres et abonnes de la bibliothèque, dans le futur nous verrons si nous
pourront proposer une solution à long terme ; celle qui consistera à interconnecter
différents services n’utilisant qu’une seule base de donnée.
Et pour certains département tels que celui de conservation et prêt et celui des
périodiques nous proposons d’y installer des ordinateurs important à leur
rendement.
3.3. Evaluation de la solution : Aspect Technique
Le nouveau système que nous implémenterons constitue notre solution à court terme, et on
aura besoin des spécifités techniques suivantes :
 Un serveur de Base de données avec MySQL Server 5.0

 Un serveur d’application GlassFish
 La plateforme 6 ou 7 de Java doit être installée
 Le système d’exploitation : Microsoft Windows Server 2003
3.4. Evaluation de la solution : Aspect Economique
Du point de vue économique, les outils utilisés sont tous issus du monde libre sauf le
Microsoft Windows Server 20003. La bibliothèque payera donc :
 Une licence pour ce système d’exploitation de Microsoft

 Et aussi une main d’œuvre de 4.500 $ aux développeurs
4. Modélisation
4.1. La modélisation Conceptuelle
4.1.1. Elaboration du MCC
Le modèle de communication comprend le domaine "prêter les livres". Les partenaires

ou intervenants externes à la bibliothèque sont : "lecteur" (de livre), "éditeur" (de
livre) et "relieur" (de livre) qui pourraient être des types (appelés sous-types) de
fournisseur. D'autres partenaires tels que "mécène" ou "banque" ne sont pas
représentés.
Les domaines sont : "prêter les livres aux lecteurs" (assurer la rotation des livres
prêtés, récupérer les livres prêtés), "enrichir la bibliothèque" (conseiller le choix de
lecture, commander les nouveautés) et "maintenir les livres en état" (faire relier les

livres, les mettre au pilon). On ne considérera par la suite que le domaine (restreint)
"prêter les livres".
Les messages entre domaines ne sont pas représentés. Ils pourraient être la
demande d'état de livre entre "prêter" et "maintenir", la demande de livre non
connu...
Les messages sont :
 Demande d'abonnement : nom personne, prénom personne, adresse

personne.
 Demande de prêt : titre de l'ouvrage, auteur, thème.
 Retour de prêt : n° de livre, date de retour réelle du livre. Prêt accordé : n° de

livre, date de retour maximum du livre, date du prêt, n° de prêt.
 Abonnement accordé : n° d'abonné.
 Demande de restitution : date de la relance, nom abonné, adresse abonné, n°

de livre, date de retour maximum du livre, date du prêt, n° de prêt.
Les règles de calcul sont :
 Calcul de la date de retour théorique à partir de la date du prêt et de la durée


 maximale du prêt (qui dépend du titre emprunté).
 Calcul du nombre de livres empruntables calculé à partir du n° abonné en
 recherchant tous les exemplaires non rendus.
4.1.2. Elaboration des MCT
Les opérations conceptuelles sont :
 Prise en compte de la demande de prêt : si la personne n'est pas

abonnée, elle l'est sans condition. Elle peut avoir des livres à restituer
ou son quota est dépassé. Une demande de restitution de livre est faite.
Dans le cas contraire, et si un exemplaire est disponible, le prêt est
accordé.
 Abonner lecteur : systématique après une demande d'abonnement.

Cette opération pourrait ne pas exister. Le message de demande
d'abonnement n'est pas très conceptuel.
 Récupérer livre : cette opération est décidée et ne comporte pas de

message événement. Elle consiste à examiner le cas des livres non
rendus dont le prêt est échu. Le message résultat est la demande de
restitution.
 Prise en compte du retour du prêt : opération enclenchée à réception

du message retour du prêt (et du livre physique). Elle consiste à
récupérer le livre et à demander à "entretenir" son avis sur l'état du
livre rendu.
Le modèle général d’un MCT :

4.1.3. Elaboration du MCD
a. Dictionnaire des données
Attribut Nom de l’attribut Description

IDAuteur Identifiant de l’auteur
nom auteur nom auteur

prénom auteur prénom auteur
ID Collection Identifiant de la
collection
code collection Code de la collection
libellé collection Libellé de la collection
code éditeur
code exemplaire
date de destruction
date d'achat
n° abonné
adresse lecteur
prénom lecteur
nom lecteur
code ouvrage
titre ouvrage
durée autorisée
code prêt
date de retour réelle
du livre
date prêt
code thème
nom éditeur

prénom éditeur
libellé thème
b. Etude des dépendances fonctionnelles
Cette notation : X Y,Z veut dire Y et Z dépendent

fonctionnellement de X
IDAuteur nom auteur, prénom auteur
ID Collection code collection, libellé collection
code éditeur nom éditeur, prénom éditeur

code exemplaire date d'achat, date de destruction
n° abonné nom lecteur, prénom lecteur,
adresse lecteur.
code ouvrage titre ouvrage, durée autorisée
code prêt date prêt, date de retour réelle du

livre
code thème libellé thème
c. Graphe de couverture minimale
Déduction du MCD

4.2. La modélisation Organisationnelle
4.2.1. Elaboration des MOT
Les postes de travail sont :

 le bibliothécaire : aide au choix de l'ouvrage, remplit les commandes,
réceptionne les livres des éditeurs ;
 l'accueil : administratif, responsable des abonnements, de la relance aux
abonnés ;
 le magasinier : responsable du stock, déballe et range les livres, met à disposition
les livres demandés, réceptionne les livres reliés.
Les opérations organisées sont :
 Conseiller lecteur : opération rajoutée pour montrer qu'une procédure peut être
multi-domaines.
 Prise en compte de la demande d'abonnement : ici la procédure est détaillée
dans le cas où le lecteur n'a pas son adresse ou une justification de son identité
et de son adresse (utile pour la relance des livres non restitués).
 Abonner lecteur : identique au conceptuel.
 Prise en compte de la demande de prêt : la différence est que le magasinier va
chercher le livre en magasin.
 Chercher livre : opération typiquement organisée. Le magasinier peut ne pas
trouver le livre s'il est tombé de l'armoire ou s'il est mal rangé. Pour éviter que

cela ne se reproduise, il devra mémoriser sa présence et effectuer un inventaire
tous les mois.
 Prise en charge du prêt : c'est à ce moment que le prêt sera enregistré.
 Annoncer indisponibilité
 Inventorier : opération nouvelle "temporisée" mensuellement.
La procédure de prêt de livre est :
4.2.2. Elaboration du MOD
Les individus sont les mêmes que le MCD. Au lieu de créer un individu
supplémentaire tel que "inventaire", une information supplémentaire est dans l'individu

"livre" : présence du livre. Elle permet de savoir qu'un exemplaire théoriquement en stock
n'est pas à sa place. Elle est mise à jour quand le magasinier ne trouve pas l'exemplaire ou
quand il le retrouve suite à un inventaire.
4.3. La modélisation Logique et Physique
4.3.1. Architecture Globale du Système
L'architecture 3-tiers ou architecture à trois niveaux est l'application du modèle plus

général qu'est le multi-tiers.
L'architecture logique de notre système sera divisée en trois niveaux ou couches :
• couche présentation
• couche métier
• couche des données
4.3.2. Elaboration du MLT
Au niveau de MLT, on présente les différents états que l’application est censée
de produire.
4.3.3. Elaboration du MLD
4.3.4. Elaboration du MPD

5. Implémentation
5.1. Implémentation de la couche de bases de données
5.2. Implémentation de la couche métier en Java

5.3. Implémentation de la couche de Présentation en Java

Chapitre VII : Exercices
VII.1. Passage au relationnel
Exercice 1
Figure 1: Modélisation E/A de la base de données d'une l'auto-école.

Une auto-école souhaite construire une base de données pour gérer les examens
théoriques du code de la route de ses élèves. Chaque élève est identifié par un
numéro unique et est caractérisé par un nom, un prénom, une adresse et une date
de naissance. Chaque élève assiste à plusieurs séances de code (autant qu'il le
souhaite). Chaque séance est caractérisée par une date et une heure. A chaque
séance de code, le directeur de l'auto-école choisit une série de questions sur un CD-
ROM.
Chaque CD-ROM est identifié par un numéro et est caractérisé par un nom d'éditeur.
Chaque CD-ROM est composé de 6 séries, numérotées de 1 à 6. Chaque série est
composée de 40 questions.
Chaque question est identifiée par un intitulé et est caractérisée par une réponse, un
niveau de difficulté et un thème. Une même question peut apparaître dans plusieurs
séries avec un numéro d'ordre pour chaque série ; par exemple une même question
peut apparaître comme question N±2 dans la série 5 du CD-ROM 15 et comme
question N±12 dans la série 3 du CD-ROM 4. Une même série peut être projetée
plusieurs fois à des séances différentes. Lorsqu'un élève assiste à une séance, il
obtient le nombre de fautes (une note sur 40) qu'il a fait pour la série passée pendant
la séance.
Lorsqu'un élève a obtenu, au cours des quatre dernières séances auxquelles il a

assistées, un nombre de fautes inférieur ou égal à 5, le directeur de l'auto-école
l'autorise à passer l'examen théorique du code de la route à une date donnée (un
seul examen pour une date donnée). L'auto-école ne peut présenter que 8 élèves
maximum à chaque date d'examen. Les élèves ayant obtenu plus de 5 fautes à
l'examen sont recalés et doivent assister de nouveau à des séances de code avant de
pouvoir se représenter à l'examen.
La base de données doit permettre de répondre à des requêtes telles que "Quel est le
nombre moyen de fautes pour la série 5 du CD-ROM 14?", "Quels élèves peuvent se
présenter au prochain examen du code de la route ?", "Quels élèves ont échoué au
moins une fois à l'examen ?" etc.
La figure 1 présente la modélisation Entité/Association (format Merise). Les schémas

de modélisation ci-avant sont sémantiquement clairs. Néanmoins, quels points
nécessitent d'être précisés.
• L'ensemble d'entités Serie est un ensemble d'entités faibles de CD-ROM, au format

Merise (ou une association qualifiée en UML). En effet, ce choix de modélisation a été
fait pour représenter le fait que le numéro d'une série est relatif au CD-ROM auquel
la série appartient.

• Les cardinalités de l'association entre les ensembles d'entités Serie et CD-ROM sont
1:1-6:6, car une série appartient à un unique CD-ROM et un CR-ROM contient
exactement 6 séries de questions. Le principe est le même pour les cardinalités de
l'association entre Serie et Question : une série contient exactement 40 questions
(cardinalité 40 : 40). En revanche, une même question peut apparaître dans plusieurs
séries avec un numéro d'ordre différent à chaque fois, d'où la cardinalité 1 : N et
l'attribut Numéro qui caractérise l'association contient.
• L'attribut NombreFautes est un attribut de l'association entre les ensembles
d'entités Client et Examen_Code et de l'association entre les ensembles d'entités
Client et Seance_Code. En effet, cet attribut caractérise l'association et non pas un
client, une séance de code ou encore un examen de code. Il caractérise le lien entre
deux entités de ces ensembles.
Déduisez le schéma relationnel de la base de données correspondante.
Vous préciserez les clés primaires des relations en les soulignant ainsi que les clés
étrangères en les signalant par un # et en précisant à quoi elles font référence.
Dans votre schéma relationnel, chaque relation doit être spécifiée de la manière
suivante :
Nom(att1,...,attn) où Nom est le nom de la relation et att1, ..., attn sont des noms
d'attributs.
Le nom de la relation doit obligatoirement avoir un lien avec les noms des ensembles
d'entités (classes) ou des associations du schéma de modélisation de la question 1.
Vous donnerez des explications claires et concises du passage au relationnel. Vous
préciserez notamment pourquoi et comment vous créez ou modifiez certaines
relations (1 ligne maximum par relation).
Exercice 2
On souhaite construire une base de données gérant des revues et les articles de ces revues. Une
revue est caractérisée par un nom et une périodicité. Chaque revue parait sous la forme de numéros,
chaque numéro étant identifié par un nombre relatif à la revue et à l'année en cours (ex. le numéro
N°12 de Linux Magazine en 2003 est différent du numéro N°12 de Linux Magazine en 2004). Un
numéro est également caractérisé par un nombre de pages. Chaque numéro contient des articles
écrits par un ou plusieurs auteurs. Un auteur est caractérisé par un nom, un prénom, ainsi qu'un
email. Chaque article possède un titre et un contenu. Un même article peut apparaître dans plusieurs
numéros d'une même revue ou de différentes revues. Lorsqu'un article apparaît dans un numéro
d'une revue, il a une page de début et une page de n. Un article peut faire référence à d'autres
articles, en précisant le numéro et la revue dans lesquels l'article référencé a été publié.

La base de données doit permettre de répondre à des requêtes telles que "Combien de numéros de
Linux Magazine sont parus en 2004 ?", "Quels sont les titres des articles parus dans au moins deux
revues différentes ?", "Quels sont les auteurs ayant publiés dans le numéro 3 de la revue L'Histoire
en 2004 ?" etc.
La figure ci dessus présente la modélisation Entité/Association Les schémas de modélisation
ci-avant sont sémantiquement clairs. Néanmoins, quels points nécessitent d'être précisés.
• L'ensemble d'entités Numéro est un ensemble d'entités faibles de Revue au format Merise. En
effet, ce choix de modélisation a été fait pour représenter le fait que l'identificateur d'un numéro est
relatif à la revue à laquelle le numéro appartient. Un numéro d'une revue donnée étant identifié par
un nombre et une année, ces deux attributs (ID et Année) sont soulignés.
• Les cardinalités de l'association entre les ensembles d'entités Numéro et Article sont 1:N-1:M, car
un article peut apparaître dans plusieurs numéros et un numéro contient plusieurs articles. Le
principe est le même pour les cardinalités de l'association entre Auteur et Article.
• Les attributs PageDébut et PageFin caractérisent l'association entre Article et Numéro (un numéro
étant relatif à une revue, il est inutile de faire une association avec Revue). En effet, la page de début
et la page de n peuvent varier, pour un même article, lorsqu'il paraît dans plusieurs numéros
différents.
• Un article peut faire référence à un autre article. Le numéro et la revue dans lesquels l'article
référencé apparaît doivent être précisés dans l'article référençant. Par exemple, l'article intitulé
"Correction d'exercices en bases de données" peut faire référence à l'article "Concepts généraux en
BD relationnelle" du numéro 12 de l'année 2004 de la revue "Informatique magazine".
A cet effet, les ensembles d'entités Numéro et Article ont été regroupés au sein d'un agrégat au
format Merise. Cet agrégat (ou cette classe association) représente l'article référencé, c'est-à-dire

l'article et le numéro de la revue où il a été publié (il est inutile d'ajouter la revue à l'agrégat puisque
Numéro est un ensemble d'entités faibles de Revue). Les cardinalités ont pour borne inférieure 0 car
un article peut ne référencer aucun autre article et un article peut ne jamais être référencé. Pour
plus de détails sur l'agrégation.
Déduisez le schéma relationnel de la base de données correspondante.
Vous préciserez les clés primaires des relations en les soulignant ainsi que les clés étrangères en les
signalant par un # et en précisant à quoi elles font référence.
Dans votre schéma relationnel, chaque relation doit être spécifiée de la manière suivante :
RNom(att1,...,attn) où RNom est le nom de la relation et att1, ..., attn sont des noms d'attributs.
Le nom de la relation doit obligatoirement avoir un lien avec les noms des ensembles d'entités ou
des associations du schéma de modélisation de la question 1.
Vous donnerez des explications claires et concises du passage au relationnel. Vous préciserez
notamment pourquoi et comment vous créez ou modifiez certaines relations (1 ligne maximum par
relation).
VII.2. Langage d'interrogation
Exercice 3
On suppose qu'une bibliothèque gère une base de données dont le schéma est le
suivant (les clés primaires des relations sont soulignées) :
Emprunt(Personne, Livre, DateEmprunt, DateRetourPrevue, DateRetourE_ective)

Retard(Personne, Livre, DateEmprunt, PenalitéRetard)
Exprimer, lorsque cela est possible, les requêtes suivantes en algèbre relationnelle,
en calcul à variable nuplet et en SQL.
1. Quelles sont les personnes ayant emprunté le livre "Recueil Examens BD" ?
2. Quelles sont les personnes n'ayant jamais rendu de livre en retard ?
3. Quelles sont les personnes ayant emprunté tous les livres (empruntés au moins
une fois) ?
4. Quels sont les livres ayant été empruntés par tout le monde (i.e. tous les
emprunteurs) ?
5. Quelles sont les personnes ayant toujours rendu en retard les livres qu'elles ont
empruntés ?
Exercice 4

Un organisme de gestion de spectacles, de salles de concert et de vente de billets de spectacles gère
une base de données dont le schéma relationnel est le suivant :
Spectacle (Spectacle_ID, Titre, DateDéb, Durée, Salle_ID, Chanteur)
Concert (Concert_ID, Date, Heure, Spectacle_ID)
Salle (Salle_ID, Nom, Adresse, Capacité)
Billet (Billet_ID, Concert_ID, Num_Place, Catégorie, Prix)
Vente (Vente_ID, Date_Vente, Billet_ID, MoyenPaiement)
Les attributs soulignés sont les attributs appartenant à la clé primaire. Ils sont de type entier.
L'attribut Salle_ID de la relation Spectacle est une clé étrangère qui fait référence à l'attribut de
même nom de la relation Salle. L'attribut Spectacle_ID de la relation Concert est une clé étrangère
qui fait référence à l'attribut de même nom de la relation Spectacle. L'attribut Concert_ID de la
relation Billet est une clé étrangère qui fait référence à l'attribut de même nom de la relation
Concert.
L'attribut Billet_ID de la relation Vente est une clé étrangère qui fait référence à l'attribut de même
nom de la relation Billet.
Exprimez, lorsque cela est possible, en SQL.
2.1. Quelles sont les dates du concert de Corneille au Zenith ?
2.2. Quels sont les noms des salles ayant la plus grande capacité ?
2.3. Quels sont les chanteurs n'ayant jamais réalisé de concert à la Cygale ?
2.4. Quels sont les chanteurs ayant réalisé au moins un concert dans toutes les salles ?
2.5. Quels sont les dates et les identificateurs des concerts pour lesquels il ne reste aucun billet
invendu ?
VII.3. Dépendances fonctionnelles et normalisation
Exercice 5
Soit un schéma de bases de données contenant les relations suivantes :

Bureau(NumBureau, NumTelephone, Taille) avec
FBureau = { NumBureau ! NumTelephone, Taille; NumTelephone ! NumBureau; }
Occupant(NumBureau, PersonneID) avec FOccupant = { NumBureau ! PersonneID }
Materiel(NumBureau, NumPC) avec FMateriel = { NumPC ! NumBureau }

1. Les contraintes ci-dessous sont-elles vérifiées par ce schéma de bases de données?
Si la réponse est positive, expliquez pourquoi. Si la réponse est négative, indiquez
quelle(s) dépendance(s)fonctionnelle(s) il faut ajouter/supprimer ou modifier pour
que la contrainte soit vérifiée.
(a) "Un bureau peut contenir plusieurs postes téléphoniques."
(b) "Il y a une et une seule personne par bureau."
(c) "Un bureau contient un seul ordinateur."
2. A partir des familles de dépendances fonctionnelles initiales données dans

l'énoncé, indiquez quelles sont les clés minimales possibles de chaque relation.
Exercice 6
Soit R une relation dont le schéma est le suivant :
R (UtilisateurID, Nom, Prénom, AdresseEmail, Login, Passwd, ServeurMail).
3.1. Exprimer, à l'aide de dépendances fonctionnelles, les contraintes suivantes que doivent
vérifier les instances de la relation R :
(a) "On peut déduire le nom et le prénom d'un utilisateur à partir de son identificateur."
(b) "Un utilisateur (identifié par son identificateur) possède un seul login et un seul password par
serveur de mails."
(c) "Une adresse email est associée à un et un seul identificateur d'utilisateur."
Attention : un utilisateur peut avoir plusieurs adresses de mails.
(d) "Une adresse email est associée à un et un seul serveur de mails."
3.2. Indiquer, à partir de la famille de dépendances fonctionnelles, issue de la question 1, quelles

sont les clés minimales de R.
3.3. Indiquer, à partir de la famille de dépendances fonctionnelles, issue de la question 1, en quelle

forme normale est la relation R.

Bibliographie
[1] C. GRUAU, Conception d’une base de données, 2005.
[2] E. Reboisson, Génération de rapport avec Jasper Report, Date 05/11/2005
[3] F. Chabli, Exemple d'utilisation de l'API JFreeChart avec JasperReports, 26 mai 2009
[4] M. DOUDOUX, Développons en JAVA.

Informatique de Gestion

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Informatique de Gestion

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE KINSHASA

FACULTE DES SCIENCES

Destiné aux étudiants de Troisième Graduat en Sciences Informatiques

Assistant MANZAMBI NDONGALA Nathan

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

Les principaux objectifs de ces Travaux Pratiques sont les suivants :

 Initier les étudiants à la conception des systèmes d’informations en utilisant la

 Etre familier au développement des applications clientes orientées objets (avec

 Etre capable de mettre en place des applications d’entreprise avec la technologie

 Apprendre le reporting en Java, et .net

 La programmation Orientée Objet

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 2

Partie I : Conception des applications de gestion

Chapitre I : Les bases de données

Partie II : Mise en œuvre des applications de gestion avec la technologie J2EE

Chapitre III : Persistance et Accès aux bases de données

Partie III : Etude de cas et Exercices

Chapitre VI : Etudes des Cas

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 3

Chapitre I : Les bases de données

I.1. Conception d’une base de données avec Merise

Il est donc nécessaire de recourir à une étape préliminaire de conception. Les

Le but de ce chapitre est d’introduire le schéma entités-associations, le

I.1. Le Modèle Conceptuel de données (MCD)

1. Identifier les entités

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 4

I.1.2. Dépendances fonctionnelles

Un attribut Y dépend fonctionnellement d’un attribut X si et seulement si une

Par exemple, si X est le numéro de client et Y le nom de client, alors on a bien : X Y.

Par exemple, on a : numéros de commande numéros de client,

Un attribut Y peut avoir une dépendance fonctionnelle qui repose sur la

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 5

Numéro de l’article quantité commandée

I.1.3. Graphe de Couverture Minimale

En représentant tous les attributs et toutes les dépendances fonctionnelles

Numéro de commande numéro article

Numéro de client date de commande désignation

Nom du client adresse quantité commandée

I.1.4. Traduction vers un schéma entités-associations

A partir du graphe de couverture minimale, le schéma entités-associations

Etape 1 : Il faut repérer et souligner les identifiants

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 6

PK,FK2 numero article

A ce stade, les trois formes normales de CODD devraient être vérifiées, si ce

I.1.5. Les Formes Normales de BOYCE CODD

I.2. Le Modèle Logique de données (MLD)

Pour traduire un MCD en un MLD Relationnel, il suffit d’appliquer cinq règles.

Notations : on dit qu’une association binaire est de type :

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 7

I.3. Le Modèle Physique de données (MPD)

La traduction d’un MLDR en un modèle physique est la création (par des

I.2. Le langage SQL

I.2.1. Définitions des données

I.2.2. Manipulation des données

I.2.3. Interrogation des données

Prof. Dr. Saint Jean DJUNGU Ass. MANZAMBI NDONGALA Nathan

© UNIKIN 2012 Page 8

III.1. Définition et concepts