Implémentation d'une application de gestion des courriers.

Section 2. Système d'information informatisé

Dans cette section nous allons parler du système d'information informatisé qui est une composante du cycle d'abstraction de MERISE. Ce système comprend le niveau logique et le niveau physique.

Le système déjà décrit au niveau conceptuel et organisationnel doit l'être ensuite au plan informatique. Cette description est elle-même décomposée en deux niveaux :

? Niveau logique ? Niveau physique

A. Choix du hardware

Ici nous définirons les contraintes du matériel qui pourra faire tourner notre logiciel :

Nombre	Processeur	Ram	Capacité mémoire		Lecteur	5
AMD E-300 APU with Radeon(tm) HD Graphics 1.30	4.00Go	#177;600Go(+ un disque externe)	DVD RW et CD

B. Choix du software

Afin de pouvoir mieux utilisé notre programme nous suggérons les logiciel suivants :

? Windows (XP, SEVEN ou EIGHT) comme système d'exploitation ou LUNIX.

? Mozilla ou Internet Explorer, au moins la version 10, comme navigateur.

2.1. Niveau logique

C'est une vue en terme de données favorable à un traitement ou à une sélection. Ce modèle implante les données de la base dans un SGBD approprié.

2.1.1. Modèle logique de donnée (MLD)

Deux modèles sont à présenter à ce niveau, à savoir :

- Le modèle logique de données brut

- Le modèle logique de données valide

69

Il est obtenu en partant du MCD et du MOD. Ici on voie comment organisé les données sur un support informatique.

Ainsi, pour passer du MCD au MLD, les règles sont les suivantes :

a. Changement des vocabulaires

? Les objets du MOD deviennent des tables dans le ML ;

? Les propriétés des objets deviennent des attributs des tables ; ? L'identifiant devient la clé primaire.

b. Traitement des relations

Plusieurs cas sont à épingler en ce qui concerne le traitement des relations à savoir :

1er Cas : Relation du type père-fils :

Nous sommes en présence des couples suivants : (0,1) ou(1,1) d'une part, et (0,n) ou (1 ,n) d'autre part. Il s'agit d'une contrainte d'intégrité fonctionnelle.

La relation qui les lient disparait mais sa sémantique demeure, car l'objet qui a la cardinalité (0,n) ou (1,n) est considéré comme père et cède sa clé primaire à l'objet qui a la cardinalité (0,1) ou (1,1) qui à son tour est considéré comme fils.

Etant donné qu'il possède une clé primaire, celle qu'elle vient d'hériter du père est une clé étrangère parce qu'elle est clé primaire dans sa table respective. Si la relation était porteuse des propriétés, elles migrent vers la table fils.

2è Cas : La cardinalité multiple : Relation du type père-père

(contrainte d'intégrité multiple). Ce cas intervient lorsqu'on a d'une part le couple d'une part (0,n)ou(1,n), d'autre part (0,n)ou(1,n), cas que nous n'avons pas rencontré. Par contre c'est le premier cas que nous avons rencontré ; c'est donc à partir du respect des règles que fixent ce cas que nous avons obtenu le MLD Brut ci-après :

70

Présentation du MLD Brut

Destinataire

#Num_dest Nom_dest Adr_dest Tel_dest Mail_dest

Partenaire

#Num_part Cat_part Nom_part Adr_part Tel_part Mail_part

Bordereau

#Num_bor #code_cour #num_dest Mtnt_du

Adr_dest H_dep_agnt Date_dep_agnt Nom_pers_recep Date_ac_rec Nom_ac_rec

Courrier

#Code_cour #num_part #mat_agent #num_dest Adr_dest Tel_dest Montant_du Type_cour Date_ret H_ret date_dep h_dep

statut

Service
courrier

#code_serv Nom_respo

Agent

#Mat_agent #code_serv Nom_agent Postn_agent Login_agent Mail_agent Pw_agent droit_agent

71

C. Processus de normalisation

La normalisation est un processus qui consiste à éliminer les dernières redondances et les valeurs nulles c'est-à-dire limiter les risques d'incohérences potentielles (Mvibudulu & Konkfie , 2012)

Les formes normales (FN) à respecter pour qu'un MLD soit valide :

1e FN : Tous les attributs doivent être élémentaire c'est-à-dire non

subdivisible, non répétitive et possède au moins une clé ;

Dans ce cas nous pouvons sortir les attributs non atomiques dans

les tables destinataire et partenaire, qui sont :

- Adresse du destinataire

- Catégorie de partenaire

? Décomposition des attributs non atomiques

CATEGORIE (code_cat, lib_cat)

ADRESSE (Province,district,territoire,quartier)

Décomposons à présent les attributs de la nouvelle table

ADRESSE :

PROVINCE (code_prov,lib_prov,lib_ville) ;

DISTRICT (code_dist,lib_dist ) ;

TERRITOIRE (code_ter,lib_ter) ;

QUARTIER (code_quart,lib_quart,lib_avenue).

NB : Bien que certains attributs des tables qui découlent de la table

d'origine ADRESSE sont décomposable, nous allons le laisser pour ne pas alourdir la base de données lors des éventuels consultations, recherche,... et cette décomposition concerne seulement l'attribut adresse de la classe destinataire.

Ainsi, ADRESSE va générer quatre tables :

72

Destinataire

#Num_dest Nom_dest Adr_dest Tel_dest Mail_dest #code_ter #code_dist #code_prov #code_quart

District

#code_dist Lib_dist

Province

#code_prov Lib_prov

Territoire

#code_ter Lib_ter

Quartier

#code_quart Lib_quart Lib_avenue

L'attribut CATEGORIE va aussi générer une table :

Partenaire	Catégorie
#Num_part #code_cat Nom_part Adr_part Tel_part Mail_part
	#code_cat Lib_cat

NB : la table destinataire reçoit les clés primaires de nouvelles tables crées, qui deviennent par conséquent des clés étrangère dans celle-ci.

2e FN : Etre déjà à la 1FN, chacun de ses attributs non membre de la clé dépendent totalement de la clé primaire. Cette FN s'applique aux tables à clé primaire composée ;

Cette forme est vérifiée.

3e FN : Etre déjà à la 2FN, les attributs non clé de la table ne dépendent pas transitivement de la clé primaire c'est-à-dire ne passe pas par un autre attribut non clé.

Cette forme est aussi vérifiée.

Après avoir illustré la normalisation par les différents schémas ci-haut, nous allons à présent tracer le modèle logique de données valide issu du MLD Brut ci-haut.

73

Présentation du MLD Valide (MLDV)

Partenaire

#Num_part #code_cat Nom_part Adr_part Tel_part Mail_part

Quartier

#code_quart Lib_quart Lib_avenue

Catégorie

#code_cat Lib_cat

Courrier

#Code_cour #num_part #mat_agent #Num_dest Tel_dest Montant_du Type_cour Date_ret H_ret date_dep h_dep

statut

Agent

#Mat_agent #code_serv Nom_agent Postn_agent Login_agent Mail_agent Pw_agent droit_agent

Service
courrier

#code_serv Nom_respo

Province

#code_prov Lib_prov

Bordereau

#Num_bor #code_cour #num_dest Mtnt_du

Adr_dest H_dep_agnt Date_dep_agnt Nom_pers_recep Date_ac_rec Nom_ac_rec

Destinataire

#Num_dest Nom_dest Tel_dest Mail_dest #code_prov #code_dist #code_ter #code_quart

Territoire

#code_ter Lib_ter

District

#code_dist Lib_dist

74

D. Schéma relationnel associé

Il nous permet de définir les fenêtres de menu et nombre d'élément

à placer dans le programme à concevoir.

courrier : [# code_cour :car[10] ; #num_part: car[10];#mat_agent :

car[15] ;#num_dest :car[10] ;tel_dest :car[20] ;montant_du :car[10] ;type_cour :car[20] ;

date_ret :date[8] ;h_ret :Time[6] ;date_dep :Date[8] ;h_dep :Time[6] ;statut :car[10]]

partenaire : [#num_part:car[10] ; #code_cat : car[10] ; nom_part: car[50] ; adr_part : car[60] ;

tel_part: car[20] ;mail_part :car[40] ]

agent: [#mat_agent : car[15] ;#code_serv, nom_agent: car[25] ; postn_agent :car[25] ;

login_agent :car[20] ;mail_agent :car[50] ;pw_agent :car[32] ;droit_agent :car[30]]

service courrier : [#code_serv : car[10] ; nom_respo: car[40] ;]

province : [#code_prov : car[10] ; lib_prov : car[40]]

district :[#code_dist :car[10] ;lib_dist[40]]

territoire: [#code_ter : car[10] ; lib_ter: car[40] ]

quartier :[#code_quart :car[10] ;lib_quart :car[40] ;lib_avenue :car[50]]

categorie :[#code_cat :car[10] ;lib_cat :car[40]]

destinataire :[ #Num_dest :car[10,]Nom_dest :car[60],Tel_dest :car[15],Mail_dest :car[50],#code_pro

v :car[10],#code_dist :car[10],#code_ter :car[10],#code_quart :car[10]]

bordereau :[#num_bor :car[10],mtnt_du :car[10],adr_dest :car[60] ,h_dep_agnt :time[6],date_

dep _agnt:date[8],nom_pers_recep :car[60],date_ac_recep :date[8],nom_ac_rec :car[60],#co

de_cour :car[10],#num_dest :car[10]]

E. Quantification de la Base de données (BDD)

L'intérêt majeur de ce calcul est de nous permettre de savoir si le matériel que nous allons utiliser répondra au volume de la base.

1. Volume théorique de la BDD

Vthéo = ?ni x occurrences

Où

ni = taille

Occurrence = ma = n^bre d'enregistrement de la table

Table	?ni	Ma	Vthéo
Courrier	223	1000	223000
partenaire	190	2	380
Agent	197	50	9850
Service courrier	25	1	25
Province	50	11	550
District	50	100	5000
Territoire	50	500	25000
Quartier	100	1000	100000
Catégorie	50	5	250
Bordereau	222	1000	222000
destinataire	195	1000	195000
Total Vthéo			781055

75

2. Volume des index

Vi = taille index x occurrences

Index	?ni	Occurrence	Vi
Code_cour	10	1000	10000
Num_part	10	2	20
Mat_agent	15	50	750
Code_serv	10	1	10
Code_prov	10	11	110
Code_dist	10	100	1000
Code_ter	10	500	5000
Code_quart	10	1000	10000
Code_cat	10	5	50
Num_dest	10	1000	10000
Num_bor	10	1000	10000
Totale Vi			46940

3. Volume de la BDD

Vbdd = Vthéo + Vi

Vbdd = 781055 + 46940

= 827995

4. Volume réel de la BDD

Vrbdd = Vtot x coef

Coef est une valeur quelconque. Vrbdd = 827995 x 3

= 2483985 octets

76

2.1.2. Modèle logique de traitement (MLT)

Il concerne la description en unité de traitement des phases

automatisables définis dans le MOT.

Règles de passage du MOT au MLT

? On identifie d'abord les ULT à partir du MOT ;

? Ont construit des procédures pour chaque domaine ;

? Les procédures fonctionnelles deviennent des procédures

logiques ou ULT au MLT.

: Lecture

: imprimer

: Écriture

: Disque dure

Procédure logique : enregistrement des courriers

i. ULT1

ULT2

77

Chaque ULT repose sur des boites d'écran ou boites de dialogue.

ULT1

Logique de dialogue

HOMME			MACHINE		RESULTAT
			Affichage page d'accueil
Clic sur le lien
					Affichage de la
					page d'authentification

Enchainement des boutons

Lien	Action	Résultat
Admin(logo)	Cliquer	Chargement ULT2

ii. ULT2

ULT3

ULT2

agent

ULT1

78

ULT2

Logique de dialogue

HOMME				MACHINE			RESULTAT
				Affichage page d'authentification
Saisi identifiant et mot de passe
				Si identifiant
							Affichage page espace
				et mot de passe existent			administrateur

Enchainement des boutons

Boutons	Action	Résultat
Valider	Cliquer	Vérifier la validité de l'id et mot de passe et chargement de ULT3

iii. ULT3

ULT1

ULT4

79

ULT3

Logique de dialogue

HOMME			MACHINE		RESULTAT
			Affichage page espace administrateur
Clic sur le lien
					Affichage de la page de gestion

Enchainement des boutons

Boutons	Action	Résultat
Courriers	Cliquer	Sélection les courriers

iv. ULT4

ULT5

ULT3

80

ULT4

Logique de dialogue

HOMME			MACHINE			RESULTAT
			Affiche la page de gestion
Clic le lien sur
						Affiche le formulaire de de saisi
						courriers

Enchainement des boutons

Boutons	Action	Résultat
Gestion des courriers Retour au menu administrateur	Cliquer Cliquer	Selectionne gestion des courriers Déconnection de la session et chargement d?ULT3

v. ULT5

ULT4

ULT5

ULT5

courriers

81

ULT4

Logique de dialogue

HOMME			MACHINE			RESULTAT
			Affiche le formulaire de saisi de courriers
Clic le lien sur
						Insert les données

Enchainement des boutons

Procédure logique : création compte agent

i. ULT1

ULT2

82

Boutons

	Action	Résultat
Valider Retour au menu administrateur	Cliquer Cliquer	Insert les détails du courrier Déconnection de la session et chargement d?ULT4

ULT1

Logique de dialogue

HOMME			MACHINE			RESULTAT
			Affichage du site
Clic sur le lien
						Affichage de la
						page de d?authentification

Enchainement des boutons

Lien	Action	Résultat
Admin(logo)	Cliquer	Chargement ULT2

ii. ULT2

ULT2

ULT3

agent

ULT1

83

ULT2

Logique de dialogue

HOMME				MACHINE			RESULTAT
				Affichage page d'authentification
Saisi identifiant et mot de passe
				Si identifiant
							Affichage page espace
				et mot de passe existent			administrateur

Enchainement des boutons

Boutons	Action	Résultat
Valider	Cliquer	Vérifier la validité de l'id et mot de passe

iii. ULT3

ULT1

ULT4

ULT1

84

ULT3

Logique de dialogue

HOMME			MACHINE		RESULTAT
			Affichage page espace administrateur
Clic sur le lien
					Affichage de la page de gestion

Enchainement des boutons

Boutons	Action	Résultat
Création compte	Cliquer	Sélection création compte

iv. ULT4

ULT4

ULT3

ULT4

85

ULT4

Logique de dialogue

HOMME			MACHINE		RESULTAT
			Affiche la page de gestion
Clic sur le lien
					Affiche le formulaire de saisi du compte client

Enchainement des boutons

Boutons	Action	Résultat
Valider Retour au menu administrateur	Cliquer Cliquer	Insert les informations sur l'agent Déconnection de la session et chargement d'ULT3

i. ULT1

Processus logique : connaitre le statut du

ULT2

courriers

ULT1

86

Logique de dialogue ULT1

HOMME		MACHINE			RESULTAT
		Affiche masque de saisi
Saisir le track number
		Insert le track number
					Affiche la boite de
					dialogue

Enchainement des boutons

Boutons	Action	Résultat
Valider Annuler	Cliquer Cliquer	Affiche le message et charge ULT2 Vider le champ de saisi et chargement du ULT1

ii. ULT2

ULT1

87

2.2. Niveau physique

Ce niveau est lié aux choix techniques informatiques en rapport avec le système de gestion des bases de données. Il permet de résoudre le problème d'implantation de la BDD recourant au SGBD.

Il est subdivisé en deux :

· Modèle physique de donnée ;

· Modèle physique de traitement.

2.2.1. Modèle physique de donnée (MPD)

Le MPD est un modèle de la base de données. Merise n'a pas tenu compte de développement de cette étape, cependant elle laisse le soin au SGBD choisi de le faire, toute en respectant les contraintes établies.

Règles de passage du MLD valide au MPD :

· Les tables deviennent des fichiers. MySQL les nomme aussi

tables ;

· Les attributs deviennent des champs ;

· Les clés demeurent clé.

a. Création de la base de données

· Structure de la Base de données

88

? Structure de la table agent

? Structure de la table courrier

89

? Structure de la table partenaire

? Structure de la table province

? Structure de la table catégorie

90

? Structure de la table quartier

? Structure de la table district

? Structure de la table territoire

91

? Structure de la table service courrier

? Structure de la table destinataire

? Structure de la table bordereau

2.2.2. Modèle physique de traitement (MPT)

Il donne une vision globale de l?ensemble du programme qui constitue notre projet.

92

? Page d?accueil

93

? Page d'authentification

94

? Page de gestion courries

95

96