4. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
4
1. Introduction
1.1 Objectifs du document
Ce document présente la conception détaillée du projet.Cette phase de conception
intervient immédiatement après la phase de spécifications, qui consiste en la réalisation d’une
application de gestion d’un parc automobile.
1.2 Portée du document
Ce document participe à la construction de l'application, et servira de support dans la phase
de programmation.
5. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
5
2. Domaine d'application
2.1 Objectifs du système
L’objectif de ce projet est de fournir un système destiné à gérer les stocks de véhicules des
différents points de ventes de notre client.
Ce système contient deux versions de l'application: une versioncomplète installée au siège de la
société et disponible sur tous les postes de travail des différentes agences (destinée aux
commerciaux), et une version légère mobile accessible depuis des tablettes ou des Smartphones
(destinée aux clients).
La versioncomplète permet aux commerciaux de gérer leur stock de véhicules ainsi que les
réservations et transfert de véhicules. Cette application sera utilisableà l’aide d’un navigateur WEB et
le commercial devra être muni d'un identifiant et d'un mot de passe.
La version légère sera destinée aux clients, leur permettant seulement de consulter la base de
données des véhicules.
6. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
6
2.2 Les interfaces
2.2.3 Interfaces utilisateurs
Le système contient deux versions de l'application, une complète et une dite légère. Les
interfaces des deux versions seront des interfaces WEB (via un navigateur WEB). Ces interfaces
communiqueront avec une base de données. Ces interfaces permettront l'affichage et la saisie de
données. Pour ce qui est de la version légère destinée aux clients, si ceux-ci accèdent au logiciel par
Smartphones ou tablettes, des contraintes de taille d'écran et de résolution devront peut être
envisagée selon la technologie du PDA.
La version complète comporte à son point d'entrée une authentification par mot de passe et
identifiant pour le commercial qui va utiliser les services proposés.
2.2.4 Interfaces logicielles
Interface avec la base de données centrale: les deux versions de l'application doivent
interagir avec la base de données centrale de manière synchronisée. Cette base de données
unique rassemble toutes les données manipulées par les différents points de ventes de
l'entreprise.
Interface de synchronisation: la synchronisation doit s'effectuer entre tous les postes de
travail des différents centres utilisant la version complète pour éviter les conflits dans la base
de données. La base de données doit aussi être mise à jour et synchronisée immédiatement
après modification de celle-ci. La base de données doit être à jour pour une consultation
efficace de celle-ci par un client ou un collègue.
2.2.5 Interfaces de communication
Interface entre le périphérique du client (tablette ou Smartphone) et la base de données: le
périphérique du client communique avec la base de données grâce à une liaison WIFI.
Interface entre le poste de travail du commercial et la base de données: pour accéder aux
données et aux services présentés, une connexion TCP/IP est nécessaire.
7. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
7
2.4 Normes, standards et outils
Utilisation de CakePHP pour créer l'interface WEB, couplée à un serveur Apache2 contenant
la base de données. La configuration et la gestion des paramètres de la base de données se feront
avec PHPmyAdmin.
3. Conception générale
3.1 Langages utilisés
Le langage de programmation choisi est PHP, il permet un interfaçage simple avec de
nombreux systèmes de gestion de bases de données(SGBD).
PHP fournit un grand choix de fonctions permettant de manipuler les bases de données en un seul
outil, il offre toutes les fonctionnalités dont nous avons besoin pour réaliser notre projet de la
conception jusqu’au déploiement.
Plus qu’un simple éditeur, il réunit toutes les fonctionnalités nécessaires pour bien développer. Parmi
ces fonctionnalités, on peut citer la coloration syntaxique, la complétion de code, le pilage de code, la
vérification de la syntaxe et autre encore.
A part les fonctionnalités de débogage de base telles que les points d’arrêt, les observateurs, les piles
d’appels ou le traçage des erreurs, il propose aussi des fonctionnalités avancées comme le débogage
en temps réel, les installations de profilage, et propose une solution de débogage de scripts complète
pour nous aider à écrire le bon code.
Pour une organisation facile, cet outil suggère de regrouper nos fichiers dans des projets. On peut
travailler sur plusieurs fichiers à la fois et obtenir à tout moment un résumé de l’état de notre projet.
Pour gagner du temps dans la réalisation d’une tâche, PHPEditsupporte l’utilisation des Framework.
En effet, cet outil est compatible avec les Frameworks de développement avec une configuration
minimale tels qu’eZPublish, Prado, Symfony, etc. Dans notre cas, nous utiliserons cakephp.
- Enfin, PHPEdit supporte aussi l’ajout des plugins pour étendre ses fonctionnalités. Certains plugins
sont déjà inclus dans l’éditeur et d’autres qui nécessitent une licence d’utilisation.
8. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
8
3.2 Architecture MVC
L’application fonctionnera selon la méthodologie « Modèle Vue Contrôleur ». Nous
utiliserons le Framework Cakephp afin de profiter de toutes ses fonctionnalités qui nous permettrons
d’optimiser l’application.
Le « modèle » reçoit les informations, il envoie au « contrôleur » qui les traites et envoi à « la vue »
qui renvoi à son tour au « contrôleur » les informations que « le model » doit afficher. La figure ci-
dessous donne un exemple de traitement.
Le Modèle représente les données de l'application
La Vue affiche une présentation des données du modèle
Le Contrôleur intercepte et route les requêtes faites par le client
3.3 Convention de nommage
Pour les règles de codage, nous allons respecter celles de Cakephp, qui sont bien définies et
permettent d’optimiser les fonctionnalités de Cakephp.
Conventions pour le nom des fichiers et des classes
Pour une classe VehiculeClasse, le fichier devrait être nommé vehicule_classe.php.
La classe Contrôleur vehicule_controller.php (notez l'ajout de _controller )
La classe Vue vue_vehicules devrait se trouver dans un fichier nommé view.ctp
9. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
9
Chaque fichier serait située dans ou sous les répertoires appropriés (qui peuvent être dans un sous-
répertoire) du répertoire principal App de cakephp.
Conventions pour les modèles
Les noms de classe de modèle sont au singulier et commencent par une majuscule : Vehicule,
VehiculePetit.
Les noms de tables en base de données correspondant aux modèles CakePHP sont au pluriel et
utilisent le caractère souligné (underscore). Les tables correspondantes aux modèles mentionnés ci-
dessus seront donc vehicules, vehicule_petits.
Les clés étrangères des relations hasMany, belongsTo ou hasOne sont reconnues par défaut grâce au
nom (singulier) de la table associée, suivi de _id.
Les tables de jointure utilisées dans les relations hasAndBelongsToMany (HABTM) entre modèles
devraient être nommées d'après le nom des tables des modèles qu'elles unissent, dans l'ordre.
Toutes les tables avec lesquelles les modèles de CakePHP interagissent (à l'exception des tables de
jointure), nécessitent une clé primaire simple pour identifier chaque ligne de manière unique.
CakePHP n'accepte pas les clés primaires composées.
Conventions pour les Contrôleurs
Les noms des classes de contrôleur sont au pluriel par 'Controller'. Exemple : VehiculesController,
VehiculePetitsController.
Convention pour les Vues
Les fichiers de gabarits de vue (Template) sont nommés d'après les fonctions du contrôleur qu'elles
affichent, sous une forme "soulignée" (underscored). La méthode soyezPret() de la classe
VehiculesController cherchera un gabarit de vue dans : /app/views/personnes/soyez_pret.ctp
Le schéma classique est "/app/views/contrôleur/nom_de_fonction_avec_underscore.ctp".
10. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
10
En utilisant les conventions CakePHP dans le nommage des différentes parties de l’application, nous
gagnons en fonctionnalité et facilité de codage.
Voici un exemple récapitulant les conventions abordées :
Nom de la table dans la base de données : vehicules
Classe du Modèle : Vehicule, trouvée dans /app/models/vehicule.php
Classe du Contrôleur : VehiculesController, trouvée dans le répertoire
/app/controllers/vehicules_controller.php
Gabarit de la Vue : trouvé dans /app/views/vehicules/index.ctp
En utilisant ces conventions, CakePHP sait qu'une requête à http://exemple.com/vehicules/ sera liée
à un appel à la fonction index() du Contrôleur VehiculesController, dans lequel le modèle Vehicule
est automatiquement disponible (et automatiquement lié à la table vehicules dans la base) et rendue
dans un fichier.
Aucune de ces relations n'a été configurée par rien d'autre que la création des classes et des fichiers
dont on aura besoin.
Convention pour les tables
Les tables doivent être au pluriel afin de respecter les conventions de cakephp, exemple : users,
groups.
11. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
11
3.4 Base de données détaillée
Relation entre les tables:
12. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
12
Les tables:
-- -----------------------------------------------------
-- Table `mydb`.`users`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`users` (
`id` VARCHAR(20) NOT NULL ,
`username` VARCHAR(45) NULL ,
`password` VARCHAR(45) NULL ,
`created` DATE NULL ,
`modified` DATE NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`groups`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`groups` (
`id` INT NOT NULL ,
`created` DATE NULL ,
`modified` DATE NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`userinfos`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`userinfos` (
`id` INT NOT NULL ,
`numero` VARCHAR(45) NULL ,
`nom` VARCHAR(45) NULL ,
`prenom` VARCHAR(45) NULL ,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`parcs`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`parcs` (
`id` INT NOT NULL ,
`numeroparc` MEDIUMINT(9) NULL ,
`ville` VARCHAR(45) NULL ,
`tel` VARCHAR(45) NULL ,
15. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
15
3.5 Dictionnaire de données
La table GROUPS permet de créer un groupe (admin ou concessionnaire) :
id identifiant du groupe
created date de création du groupe
modified modifier la date de création du groupe
La table GROUPS_HAS_USERS permet de faire le lien entre la table GROUPS et la table USERS. Cette
table contient donc deux clés primaires :
groups_id clé primaire pour identifier un groupe provenant de la table
GROUPS.
users_id clé primaire pour identifier un utilisateur provenant de la table
USERS.
La table USERS permet de créer un utilisateur :
id identifiant de l’utilisateur
username pseudonyme de l’utilisateur
password mot de passe de l’utilisateur
created date de création de l’utilisateur
modified modifier la date de création de l’utilisateur
La table USERINFOS permet de compléter la table USERS avec des informations sur l’utilisateur :
id identifiant de l’utilisateur
numero matricule de l’utilisateur
nom nom de famille de l’utilisateur
prenomprenom de l’utilisateur
La table USERS_HAS_PARCS permet de faire le lien entre la table USERS et la table PARCS. Cette table
contient donc deux clés primaires:
users_id clé primaire pour identifier un utilisateur provenant de la table
USERS.
parcs_id clé primaire pour identifier un parc provenant de la table PARCS.
16. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
16
La table PARCS permet de créer un parc:
id identifiant d'un parc
numeroparc le numéro d'un parc
ville la ville où se situe le parc
tel le numéro de téléphone d'un parc
ovehicule_id l'identifiant d'un véhicule d'occasion contenu dans le parc
nvehicule_id l'identifiant d'un véhicule neuf contenu dans le parc
La table OVEHICULES permet de créer un véhicule d'occasion. Cette table est aussi utilisée par la
table PARCS:
id l'identifiant d'un véhicule d'occasion
numero le numéro d'un véhicule d'occasion
marque la marque du véhicule d'occasion
model le modèle du véhicule d'occasion
...
La table NVEHICULES permet de créer un véhicule neuf. Cette table est aussi utilisée par la table
PARCS:
id l'identifiant d'un véhicule neuf
numero le numéro d'un véhicule neuf
marque la marque du véhicule neuf
model le modèle du véhicule neuf
...
La table CLIENTS permet de créer un client. Les tables OVEHICULES et NVEHICULES se servent de
cette table:
id l'identifiant d'un client
numeroclient le numéro du client, à ne pas confondre avec le numéro de
téléphone
nom le nom d'un client
prenom le prénom d'un client
17. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
17
La table FORMULAIRECONTACTS permet de créer un formulaire de contact:
id l'identifiant du formulaire
departement le département où ce formulaire a été écrit
titre le titre du formulaire
prenom le prénom de la personne ayant écrite ce formulaire
nom le nom de la personne ayant écrite ce formulaire
adresse l'adresse de la personne ayant écrite ce formulaire
3.6 Structure de données globale, des fichiers et de base de données
3.6.1 Conception du module utilisateur
Le fichier users_controller.php possède une classe UsersController, ainsi que des fonctions : index,
view, add, edit, delete. Ce fichier interroge la base de donné via le fichier user.php, qui répondra à
son tour au fichier users_Controller.php qui va traiter les informations reçues, les enverra au fichier
index.ctp qui se chargera de l’affichage de la vue sur le navigateur.
Index.ctp récupère les méthodes se trouvant dans les fichiers du répertoire /app/views/users ; il
s’agit de : add.ctp(fonction ajoujetr), edit.ctp(fonction editer), view.ctp(fonction afficher).
Toutes les captures ci-dessous suivent la même logique.
18. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
18
3.6.2 Conception du module groupe
3.6.3 Conception du module userinfos (information des utilisateurs)
20. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
20
3.6.6 Conception du module nouveau véhicule
3.6.7 Conception du module véhicule occasion
21. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
21
3.6.8 Conception du module formulaire de contact
3.7 Stratégie de traitement d'erreurs et des exceptions
au niveau de la base de donnée
De façon générale, les erreurs de base de données potentielles se divisent en trois catégories :
les erreurs de connexion.
les erreurs de syntaxe SQL.
les erreurs de contrainte.
nous allons utilisé la fonction die() pour mettre fin à l'exécution du script dans le cas ou uneerreur se
produit. En ajoutant les fonctions mysql_errno() et mysql_error, nous avons la possibilité de
connaitre le numéro de l'erreur générée lors de la dernière action sur la base de données et
récupérer la description texte de l'erreur générée.
Si la connexion réussit, mysql_connect retourne un identifiant de connexion. Cet identifiant n'étant
pas considéré comme "faux", il est converti en booléen "true" qui valide le résultat, die n'est donc
pas exécutée.
22. DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
22
Si la connexion échoue, mysql_connect retourne "false", die est donc exécutée pour déterminer le
résultat. Il en résulte donc l'affichage du message d'erreur et l'arrêt brutal du script.
Au niveau de CakePHP
L'utilisation de Cakephp permet d'utiliser des méthodes d’erreur afin d’arrêter le processus
d'interaction et d’afficher une page d’erreur à l’utilisateur. cette méthode affichera une page
d’erreur à l’utilisateur(page d’erreur 404) et arrêtera tout processus ultérieur de votre application.
notamment définir un callback pour être effectué chaque fois que votre application attrape une
erreur PHP
La configuration des Error est faite à l’intérieur du fichier app/Config/core.php de Cakephp.
Lors du développement d’un site, nous voyons toutes les erreurs et les avertissements grâce à un
niveau de debug réglé sur 2 dans app/config/core.php. Lors de la mise en ligne du site, nous mettons
ce niveau à 0, les erreurs deviennent donc invisibles à l’utilisateur. Mais si une erreur SQL survient,
une méthode de callback, « onError », appelée automatiquement lorsqu’une opération sur la base
de données produit une erreur.
Nous allons se servir de cette fonction pour le site est en ligne avec le débug à 0, pour afficher une
page d’erreur, et prendre toute mesure utile pour prévenir l’administrateur par email ou protéger
l’accès au site le temps que le bug soit corrigé, gérer efficacement.
les exceptions sont gérées séparément; nous allons créer un gestionnaire d’erreur à partir d'une
classe appelée AppError pour gérer nos erreurs.