Projet Java(Suivi GSM : Gestion Scolaire)

Ralis par : - Ennahdi El Idrissi Mohamed Encadr par : - Dr. Mohammed Lahmer1

I. Analyse a. Entrei. Cahier des Charges ClientOn veut raliser la gestion scolaire (suivi GSM). Cette gestion consiste en les tches suivantes : Lcole met les tudiants au courant des nouveauts de dernires minutes. (absence de professeurs, changement de lemploi du temps, lapparition des bulletins de notes, etc.). 2. Lcole Informe les tudiants propos de la date de dbut et la date de fin dun projet, avec un rappel entre ces deux dates. 3. Le service financier lance un rappel aux tudiants propos du payement trimestriel. 4. Le service de scolarit met la disposition des tudiants la consultation des dates de vacances. 5. Le service de scolarit reoit les demandes ddition des attestations de scolarit et les demandes de stages.1.

Un tudiant qui souhaite consulter le tableau daffichage lectronique est oblig de fournir son numro de tlphone. Lidentification de chaque tudiant se fera grce son numro de tlphone extraite depuis sa carte puce, accompagnant sa requte, pour permettre de dterminer les informations par lesquelles il est strictement concern (Niveau, Classe, Branche).

Lexistant

ii.

Au sujet des notes et informations de dernires minutes, ils sont annoncs sur le tableau daffichage. Les dates des projets sont communiques de la mme faon en plus des emails.

Interview

2

b.1.

Sortie

i. Les FonctionnalitsIdentification des acteurs Il existe thoriquement au moins deux types dacteurs pour cette application, mais notre tche ne demande que de raliser une seule partie. Lacteur principal est ltudiant. On suppose que la Base de Donnes de lcole existe depuis toujours.

-

Les diffrents services proposs actuellement (et dans un futur proche) Jusqu prsent, nous nous sommes penchs sur les grandes catgories de services proposer : Envoyer des demandes ddition dattestations Recevoir des rappels ou informations2.

3

ii. Modle1.

Use Cases

4

2. Diagramme de Squences

fig. 1 : Scnario de la Connexion

fig. 2 : Scnario de la Demande5

fig. 3 : Scnario de la Consultation

6

3. Diagramme de Classes

7

iii. Contraintes Lidentification de chaque tudiant se fait grce au numro de tlphone qui se trouve dans la carte SIM en cours dutilisation.

II. Conceptiona.i.

Dploiement

b.

Architecture

Architecture Globale de lApplication

NTel @IP+NPort

Serveur (Socket)

Client (Socket )

NTel

JDBC:ODBC

SGBD

System dExploitation

Architecture Globale du Portail

8

Notre produit tant orient Mobile , il nous a fallu dans un premier temps choisir la plate-forme sur laquelle nous allions nous appuyer. Notre choix tait J2ME . LIDE utilis est EclpiseME pour le code, et le J2ME Wireless ToolKit qui met disposition linterface graphique de lapplication. J2ME (Java 2 Micro Edition) est le framework Java spcialis dans les applications mobiles.

ii.

Architecture de la Base de Donnes En ce qui concerne la base de donnes principale qui existe dans le serveur, elle est dcrite comme suit : Le systme de gestion de base de donnes (SGBDR) relationnelle qui soccupe de sa gestion est Oracle 9i; Le serveur stocke les informations complmentaires, les messages envoyer, les demandes reues et les rappels potentiels. Les interactions entre GSM et le SGBD se fait par lintermdiaire dun serveur (Socket). Un Socket est une interface logicielle avec les services du systme d'exploitation, grce laquelle un dveloppeur exploitera facilement et de manire uniforme les services d'un protocole rseau (session TCP pour recevoir et d'expdier des donnes)

9

Scripte de la Base de DonnesCREATE TABLE Etudiants ( NumTel VARCHAR2(20) NOT NULL, Nom VARCHAR2(30) NOT NULL, Prenom VARCHAR2(20) NOT NULL, idClasse INTEGER NOT NULL, CONSTRAINT PK_Etudiant PRIMARY KEY (NumTel) ) / CREATE TABLE RecepDateVac ( IdGSM INTEGER NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_RecepDateVac PRIMARY KEY (Message_ID, IdGSM) ) / CREATE TABLE Notes ( contenu VARCHAR2(50) NOT NULL, dateApparition INTEGER NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_Notes PRIMARY KEY (Message_ID) ) / CREATE TABLE Demandes ( IdDmd INTEGER NOT NULL, Titre VARCHAR2(50) NOT NULL, Type VARCHAR2(50) NOT NULL, IdGSM INTEGER NOT NULL, CONSTRAINT PK_Demandes PRIMARY KEY (IdDmd) ) / CREATE TABLE DatesVacances ( DateVac INTEGER NOT NULL, Duree INTEGER NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_DatesVacances44 PRIMARY KEY (Message_ID) ) /

10

CREATE TABLE RappelsPrj ( dateDeb INTEGER NOT NULL, dateFin INTEGER NOT NULL, sujet VARCHAR2(50) NOT NULL, prof VARCHAR2(50) NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_RappelPrj47 PRIMARY KEY (Message_ID) ) / CREATE TABLE GSMs ( IdGSM INTEGER NOT NULL, NumTel VARCHAR2(50) NOT NULL, CONSTRAINT PK_GSM PRIMARY KEY (IdGSM), CONSTRAINT TC_GSM UNIQUE (NumTel) ) /

CREATE TABLE Classes ( idClasse INTEGER NOT NULL, annee INTEGER NOT NULL, niveau INTEGER NOT NULL, branche VARCHAR2(50) NOT NULL, nomoption VARCHAR2(50) NOT NULL, CONSTRAINT PK_Classes PRIMARY KEY (idClasse) ) / CREATE TABLE RappelsPayement ( dateDebRetard INTEGER NOT NULL, Message_ID INTEGER NOT NULL, IdGSM INTEGER NOT NULL, CONSTRAINT PK_RappelPayement46 PRIMARY KEY (Message_ID) ) /

11

E TABLE RecepNotes ( IdGSM INTEGER NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_RecepNotes49 PRIMARY KEY (IdGSM, Message_ID) ) / CREATE TABLE RecepRapPrj ( IdGSM INTEGER NOT NULL, Message_ID INTEGER NOT NULL, CONSTRAINT PK_RecepRapPrj48 PRIMARY KEY (IdGSM, Message_ID) ) / CREATE TABLE NOTECLASSE ( IdNOTECLASSE INTEGER NOT NULL, IdNOTE INTEGER NOT NULL, IdCLASSE INTEGER NOT NULL, CONSTRAINT PK_NOTECLASSE PRIMARY KEY (IdNOTECLASSE) ) /

12

CREATE INDEX TC_Etudiant ON Etudiants (idClasse) / CREATE INDEX TC_RecepDateVac ON RecepDateVac (IdGSM) / CREATE INDEX TC_Demandes ON Demandes (IdGSM) / CREATE INDEX TC_GSM ON GSMs (NumTel) / CREATE INDEX TC_RappelPayement ON RappelPayement (IdGSM) / CREATE INDEX TC_Etudiant ON Etudiants (idClasse) / CREATE INDEX TC_RecepDateVac ON RecepDateVac (IdGSM) / CREATE INDEX TC_Demandes ON Demandes (IdGSM) / CREATE INDEX TC_GSM ON GSMs (NumTel) / CREATE INDEX TC_RappelPayement ON RappelPayement (IdGSM) /

13

ALTER TABLE Etudiants ADD ( CONSTRAINT FK_Etudiant FOREIGN KEY (idClasse) REFERENCES Classes (idClasse)) / ALTER TABLE RecepDateVac ADD ( CONSTRAINT FK_RecepDateVac29 FOREIGN KEY (IdGSM) REFERENCES GSMs (IdGSM)) / ALTER TABLE RecepDateVac ADD ( CONSTRAINT FK_RecepDateVac30 FOREIGN KEY (Message_ID) REFERENCES DatesVacances (Message_ID)) / ALTER TABLE Demandes ADD ( CONSTRAINT FK_Demandes27 FOREIGN KEY (IdGSM) REFERENCES GSMs (IdGSM)) / ALTER TABLE GSMs ADD ( CONSTRAINT FK_GSM35 FOREIGN KEY (NumTel) REFERENCES Etudiants (NumTel)) / ALTER TABLE RappelsPayement ADD ( CONSTRAINT FK_RappelPayement36 FOREIGN KEY (IdGSM) REFERENCES GSMs (IdGSM)) / ALTER TABLE RecepNotes ADD ( CONSTRAINT FK_RecepNotes39 FOREIGN KEY (IdGSM) REFERENCES GSMs (IdGSM)) / ALTER TABLE RecepNotes ADD ( CONSTRAINT FK_RecepNotes40 FOREIGN KEY (Message_ID) REFERENCES Notes (Message_ID)) / ALTER TABLE RecepRapPrj ADD ( CONSTRAINT FK_RecepRapPrj37 FOREIGN KEY (IdGSM) REFERENCES GSMs (IdGSM)) / ALTER TABLE RecepRapPrj ADD ( CONSTRAINT FK_RecepRapPrj38 FOREIGN KEY (Message_ID) REFERENCES RappelsPrj (Message_ID)) / ALTER TABLE NOTECLASSE ADD ( CONSTRAINT FK_NOTECLASSE1 FOREIGN KEY (IdNote) REFERENCES Notes (message_Id)) / ALTER TABLE NOTECLASSE ADD ( CONSTRAINT FK_NOTECLASSE2FOREIGN KEY (IdClasse) REFERENCES Classes (IDclasse)) /

14

III.

Conclusion

Cette application nous a ouvert les portes du monde de dveloppement dans un environnement diffrent des autres. De plus, nous avons appris mieux manier lenvoi et la rception de donnes respectivement depuis et vers un tlphone. (Communication entre tlphone et SGBD). Ajoute le 10/07/2011 : Ce projet a t ralis en deux applications diffrentes : 1Application Java qui reprsente le cot serveur (coute) 2Application J2ME qui reprsente le cot client. La communication entre ces deux applications spares se faisant par le biais des socket (@IP, N port). Projet de 4ime anne, semestre 1.

15