Conception et réalisation d'un composant d'affichage des horaires des vols d'avions sous Joomla

III.0 Introduction

La section sur la modélisation par la méthode MERISE nous permet de présenter les différents niveaux et modèles de MERISE qui ont été utilisés dans le cadre de cette étude.

III.1 La méthode MERISE

III.1.1 Présentation de la méthode MERISE

MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques [1].

La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment.

La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE (Centre d'Études Techniques de l'Équipement) implanté à Aix-en-Provence France.

[1] https://www.commentcamarche.net/contents/655-merise-initiation-a-la-conception-de-systemes-d-information

12

III.1.2 Cycle d'abstraction de conception des systèmes d'information

La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.

Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information :

Figure 2 : cycle d'abstraction pour la conception des systèmes d'information

L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela :

· Faire l'inventaire des éléments nécessaires au système d'information

· Délimiter le système en s'informant auprès des futurs utilisateurs

13

III.2 Les niveaux de MERISE

La méthode Merise propose quatre niveaux de représentation d'un système d'information [2] :

· Le niveau conceptuele;

· Le niveau logique;

· Le niveau physique;

· Le niveau organisationnel.

Ces différents niveaux répondent aux questions suivantes :

o Niveau Conceptuel : Quoi Faire ? Avec Quelles Données ?

o Niveau logique : Qui ? Où ? Quand ?

o Niveau physique: Comment?

III.2.1 Le niveau conceptuel

Le niveau conceptuel représente les informations et leurs relations d'une part, les utilisations qui en sont faites et les contraintes d'autre part. Ces définitions sont établies en faisant abstraction de toute contrainte liée à l'organisation.

V' En termes de données, cette description fait appel au formalisme Entité-Association et se traduit par des entités de base et par des relations avec ces entités.

V' En termes de traitements, ces mêmes entités vont être décrites par leurs sollicitations ou par les réactions qu'elles déclenchent de la part du système d'information, donc par les traitements dont elles sont les causes et les conséquences. Ceci se fait à l'aide d'événements, de synchronisation et d'opérations.

III.2.2 Le niveau organisationnel ou logique

Alors qu'au niveau conceptuel est exprimé la réalité perçue par l'entreprise dans son ensemble, le niveau organisationnel exprime cette même réalité telle qu'elle est vécue par les acteurs quels qu'ils soient. A ce niveau, aucune différence n'est faite entre les hommes et les machines. On intègre à l'analyse les critères liés à l'organisation.

V' En termes de données, les entités et relations suscitent la création de tableaux. La vue logique est nécessairement orientée vers une classe de solutions.

V' En termes de traitements, les événements décrits ne sont pas des événements temporels mais des événements à dominante spatiale.

[2] https://www.cours-gratuit.com/cours-merise/la-methode-merise-niveau-logique-physique

14

III.2.3 Le niveau opérationnel ou physique

C'est une représentation des moyens qui vont effectivement être mis en oeuvre pour gérer les données ou activer les traitements. Le niveau physique apporte des solutions techniques.

ü En ce qui concerne les données, il y a passage d'une classe de solutions à un produit de cette classe. Concrètement, cela se traduira par l'utilisation d'un SGBD. On effectue des choix sur les méthodes de stockage et d'accès.

ü En termes de traitements, le modèle opérationnel décrira l'architecture des programmes qui vont activer les différentes tâches de l'ordinateur. En aucun cas à ce niveau, il n'y a de programmation effective.

III.3 Modèles de MERISE

La combinaison des quatre niveaux et trois approches de MERISE donne lieu à la création de douze modèles de référence.

La figure ci-dessous nous montre la structure des modèles de MERISE

APPROCHES NIVEAUX	Traitement	Données	Communication
Organisationnel	MOT	MOD	MOC
Conceptuel	MCT	MCD	MCC
Logique	MLT	MLD	MLC
Physique	MPT	MPD	MPC

Tableau 1 : les modèles de MERISE

III.3.1 Modèle conceptuel de données

Le modèle conceptuel des données est une représentation statique du système d'information de l'entreprise qui met en évidence sa sémantique. Il a pour but d'écrire de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensible (Seba, 2003).

Cet aspect recouvre les mots qui décrivent le système ainsi que les liens existants entre ces mots. Le formalisme adopté par la méthode Merise pour réaliser cette description est basé sur les concepts « entité association ».

15

Les concepts de base pour concevoir le modèle conceptuel sont :

a. La propriété (ou attribut ou rubrique)

Ø La propriété est une information élémentaire, c'est-à-dire non déductible d'autres informations, qui présente un intérêt pour le domaine étudié ;

Ø Chaque valeur prise par une propriété est appelée occurrence.

b. L'entité ou individu-type

Une entité est la représentation d'un élément matériel ou immatériel ayant un rôle dans le système que l'on désire décrire. On appelle classe d'entité un ensemble composé d'entités de même type, c'est-à-dire dont la définition est la même. Le classement des entités au sein d'une classe s'appelle classification (ou abstraction). Une entité est une instanciation de la classe. Chaque entité est composée de propriétés, données élémentaires permettant de la décrire.

Un identifiant : est un ensemble de propriétés (une ou plusieurs) permettant de désigner une et une seule entité. La définition originale est la suivante : L'identifiant est une propriété particulière d'un objet telle qu'il n'existe pas deux occurrences de cet objet pour lesquelles cette propriété pourrait prendre une même valeur.

c. L'association (ou relation-type)

Une association (appelée aussi parfois relation) est un lien sémantique entre plusieurs entités. Une classe de relation contient donc toutes les relations de même type (qui relient donc des entités appartenant à des mêmes classes d'entité). Une classe de relation peut lier plus de deux classes d'entité.

Voici les dénominations des classes de relation selon le nombre d'intervenants :

· Une classe de relation récursive (ou réflexive) relie la même classe d'entité ;

· Une classe de relation binaire relie deux classes d'entité ;

· Une classe de relation ternaire relie trois classes d'entité.

d. Cardinalité

Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée. La cardinalité d'une relation est composée d'un

16

couple comportant une borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa valeur :

· La borne minimal (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité peut participer à une relation ;

· La borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité peut participer à une relation Un couple de cardinalités placé entre une entité E et une association A représenté le nombre minimal et maximal d'occurrences de l'association A qui peuvent être « ancrées » à une occurrence d'association E.

Le tableau ci-après récapitule les valeurs que peut prendre ces bornes

Tableau 2 : Tableau récapitulatif des valeurs que peut prendre ces bornes

17

Pour notre cas, le modèle conceptuel est représenté ci-dessous :

Figure 3 : Modèle conceptuel de données

18

III.3.2 Modèle Logique de données

Le modèle logique des données consiste à décrire la structure de données utilisée sans faire référence à un langage de programmation. Il s'agit donc de préciser le type de données utilisées lors des traitements (Baptiste, 2009).

Le but du MLD est de préparer l'implantation de la Base de Données. Généralement, le MLD s'obtient à partir du MCD.

Le MLD peut être relationnel, hiérarchique ou réseau selon le SGBD à utiliser.

Les règles de passage du MCD vers le MLDR utilisées ici concernent le SGBDR du fait qu'il est le plus répandu et celui que nous allons utiliser [3].

Règle1:

§ Une entité devient une table ;

§ L'identifiant devient une clé primaire ;

§ Les propriétés deviennent les colonnes.

Règle2:

§ Relation binaire de cardinalité (n,1) (n, m) tel que n=0 ou n=1 ;

§ La clé primaire de la table à la cardinalité (n,1) devient une clé étrangère à la table de cardinalité (n, m).

Règle3:

§ Relation binaire aux cardinalité (n, m) (n, m) tel que n=0 ou n=1 ;

§ Il y a naissance d'une nouvelle table ayant la comme clé la concaténation des deux autres tables ;

§ Si la relation est porteuse de propriété celle-ci devient attribut pour la nouvelle table.

Règle4:

§ Relation n-aires (quel que soit les cardinalités) ;

§ Il y a création des tables supplémentaires ayant comme clé primaire la
concaténation des identifiants des entités participants à la relation ;

[ 3 ] Cours d'Analyse et Conception des systèmes d'information en ITR2 Campus NGAGARA donnée par NIYONKURU Méthode

[4] https://www.africmemoire.com/part.5-troisieme-chapitre-modelisation-et-conception-du-nouveau-systeme-663.html

19

· Si la relation est porteuse de donnée celle-ci devient la relation pour nouvelle table.

En effet, le MLD de notre composant se présente comme suit :

· Arrivee (id_arr, numero_vol, provenance, icon, heure_d_arr, #id_comp, #id_statut_arr);

· Depart (id_dep, numero_vol, destination, icon, heure_depart, #id_comp, #id_statut_dep);

· Compagnie (id_comp, pays_comp, nom_comp, icon) ;

· Statut_dep (id_statut_dep, statut_dep);

· Statut_arr (id_statut_arr, statut_arr).

III.3.3 Le Dictionnaire des données

Le dictionnaire de données est l'ensemble des informations sur les attributs, le comportement, les tailles et la description pour chaque entité. Pour établir le dictionnaire de données [4], il faudrait répondre à la question :

Le schéma ci-dessous présente le dictionnaire des données de la gestion des données pour l'affichage des horaires des vols d'avions à l'AACB.

Table	MNEMONIQUE	LIBELLE	TYPE DE DONNEES	LONGUEUR
Arrivee	Id_arr	Identifiant du vol d'arrivée	Entier	11
	Numero_vol	Le numéro du vol d'avion	Chaine de caractère	20
	provinance	Provinance d'avion	Chaine de caractère	20
	Heure_d_arr	Heure d'arrivée	Date
	icon	Icon	Chaine de caractère	20

20

	Id_comp	Identifiant de la table compagnie	Entier	11
	Id_statut_arr	Identifiant de la table statut arrivée	Entier	11
Depart	Id_dep	Identifiant du vol de départ	Entier	11
	Numero_vol	Le numéro du vol d'avion	Chaine de caractère	20
	destination	Destination d'avion	Chaine de caractère	20
	Heure_dep	Heure de départ	Date
	icon	Icon	Chaine de caractère	20
	Id_comp	Identifiant de la table compagnie	Entier	11
	Id_statut_dep	Identifiant de la table statut départ	Entier	11
Compagnie	Id_comp	Identifiant de la table compagnie	Entier	11
	nom_comp	Nom du compagnie	Chaine de caractère	20
	icon	Icon	Chaine de caractère	20

21

	Pays_comp	Pays du compagnie	Chaine de caractère	20
Statut_dep	Id_Statut_dep	Identifiant de la table statut départ	Entier	11
	Statut_dep	Statut du vol de départ	Chaine de caractère	15
Statut_arr	Id_statut_arr	Identifiant de la table statut arrivée	Entier	11
	Statut_arr	Statut du vol d'arrivée	Chaine de caractère	15

Tableau 3 : Dictionnaire des données

III.3.4. Modèle physique de données

Le modèle physique de données est une représentation particulière du modèle logique de donnée pour un matériel, un environnement et un logiciel donnée. Le but du MPD est d'adapter la Base de données aux spécifications du SGBD et de l'aspect matériel sur lequel doit tourner l'application. Ainsi, pour concevoir le MPD, on doit se référer au type de SGBD et du logiciel d'implantation utilisé.

Dans le cadre de notre travail, le choix est porté sur le système de gestion de base des données relationnel MySQL qui est un SGBD centralisé, embarqué, distribué, pour entreprises, groupes de travail et particuliers qui utilise le langage de requêtes SQL.

22

Figure 4 : Modèle physique de données

23

CHAP IV. PRESENTATION DES INTERFACES UTILISATEURS

IV.0 Introduction

Ce chapitre constitue la dernière étape de notre étude qui se focalise sur la présentation de l'interface utilisateur. Dans ce chapitre, nous présentons les outils utilisés, ensuite, nous présentons quelques formulaires de notre composant, les fonctionnalités qui ont étés développées et comment ses utilisateurs les accèderont.

IV.1 Les outils utilisés

IV.1.1 SublimeText

SublimeText est un éditeur de texte générique codé en C++ et Python, disponible sur Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension pour Vim, riche en fonctionnalités [5].

IV.1.2 Xampp

XAMPP est un ensemble de logiciels permettant de mettre en place un serveur Web local, un serveur FTP et un serveur de messagerie électronique. Il s'agit d'une distribution de logiciels libres offrant une bonne souplesse d'utilisation, réputée pour son installation simple et rapide [6].

IV.1.3 MySQL

MYSQL est un système de gestion de base de données relationnel (SGBDR) Rapide, robuste et facile d'utilisation. Il est adapté à la gestion de donnée dans un environnement réseau, notamment en architecture client/serveur. Il est fourni avec de nombreux outils et est compatible avec de nombreux langages de programmation. Il est le plus célèbre SGBDR du monde Open Source particulièrement grâce à son interopérabilité avec le serveur des pages web apache et le langage de pages web dynamiques PHP (Thibaud, 2003).

IV.1.4 PHP

PHP est un langage de programmation qui sert essentiellement à construire des sites web. Un programme PHP ne s'exécute pas sur une machine de bureau pour les besoins d'un seul utilisateur mais s'exécute généralement sur un serveur web, auquel accèdent de nombreuses personnes via leurs navigateurs web depuis leurs machines personnelles. Cette section explique PHP s'intègre dans l'interaction entre un navigateur et un serveur. Lorsque vous utilisez votre ordinateur pour visualiser une page web avec un navigateur comme internet Explorer ou Mozilla,

[5] https://fr.wikipedia.org/wiki/Sublime_Text

[6] https://fr.wikipedia.org/wiki/XAMPP

24

vous établissez, via l'internet, une petite conversation entre votre machine et une autre (Sklar, 2004).

IV.1.4 Joomla

IV.1.4.1 définition

Joomla est un CMS (Content Management System) qui permet à des utilisateurs non expérimentés de gérer eux-mêmes leurs sites. Pour rendre ce système utilisable pour tout le monde et pour toutes les problématiques, Joomla permet aux développeurs de créer des composants, des thèmes, des modules etc.

Le but du composant est de créer une application au sein du système.

Il permet d'aller très vite dans la réalisation d'un site web. En effet, pour tout ce qui est gestion des actualités, des utilisateurs etc., on peut se reposer sur l'architecture Joomla qui est très solide, pour mieux se concentrer sur la logique applicative à mettre en place.

De plus ! De nombreux développeurs partagent leurs ouvrages avec la communauté, ce qui permet à n'importe qui de profiter d'une application développée pour Joomla, et de l'intégrer à son site (Simonet, 2016).

IV.1.4.2 Les Modèles View Controller

Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le motif est composé de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.

Ø Un modèle (Model) contient les données à afficher ;

Ø Une vue (View) contient la présentation de l'interface graphique ;

Ø Un contrôleur (Controller) contient la logique concernant les actions effectuées par l'utilisateur [7].

IV.1.4.3 Le fichier d'installation XML

Le fichier d'installation XML c'est un fichier principal du composant Joomla, Lorsque le composant est installé, ou plutôt, pour installer le composant, Joomla va parser ce fichier XML et lire les informations qui lui importe. Il va créer un dossier du nom du composant dans le dossier components, et y importer les fichiers. Il va ensuite exécuter les requêtes, et une fois toutes les informations lues et exécutées, le composant sera près à l'emploi !

[7] https://php-html.net/tutorials/model-view-controller-in-php/

25

On peut dire aussi que pour réaliser un composant Joomla on devrait être suivre les quatre parties principales à savoir :

· Le model;

· Le view;

· Le controller;

· Le fichier d'installation xml.

Nous créons les fichiers qui vont nous permettre de fonctionner. Nous développons le composant en suivant le modèle MVC. Nous créons le contrôleur qui va gérer les entrées et les sorties, Nous créons également les vues qui seront les interfaces auxquelles sera confronté l'utilisateur, et enfin, Nous créons les modèles qui lient l'applicatif à la base de données via un système de mapping relationnel.

Figure 5 : Interactions entre le modèle, la vue et le contrôleur [8].

[8] https://fr.wikipedia.org/wiki/wikipedia:Acceuil_principal

26

IV.2 Présentation du fonctionnement de l'application

IV.2.1 Environnement matériel

Pour arriver à implanter notre composant, nous avons utilisé un environnement matériel avec les caractéristiques suivantes :

V' Un ordinateur Portable de la marque HP ;

V' Processeur Intel(R) Core (TM) 2 Duo CPU T9600 @ 2.80GHz 2.80

GHz ;

V' Une mémoire à accès aléatoire (RAM) d'une capacité de 4 Go ;

V' Un disque dur de capacité de 225 Go.

IV.2.2 Environnement de l'interface

La présentation de l'interface de l'utilisateur c'est là où on va expliquer la fonctionnalité graphique de notre composant. Notre composant présente deux interfaces principales à savoir :

o Interface administrative (backend) c'est l'interface de l'administrateur qui a toutes les fonctions pour la gestion du composant. Ces fonctions pour l'administrateur sont :

§ La suppression ;

§ La mise à jour ;

§ La création et la recherche.

o Interface pour les internautes (visiteurs) c'est là où les visiteurs se connecte pour voir l'affichage des vols d'avion et d'autre.

IV.2.2.1 Côté té administrations (backend)

L'interface administrative pour notre composant a quatre menus principaux :

§ Menu départ ;

§ Menu arrivée ;

§ Menu compagnies ;

§ Menu pour le statut de départs et d'arrivées.

27

Figure 6 : Interface graphique pour l'administration du composant

28

IV.2.2.2 Côté visiteurs (frontend)

Figure 7 : Interface pour la partie des visiteurs

29