Dossier de conception_v1.00

DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
2012/2013
Dossier de conception
Gestion d'un parc automobile
Andrea, Arnold, Bellon
Objet Version Auteur Date
Rédaction initiale 0.20 A.A.B 11/11/12
Modifications 0.80 A.A.B 22/12/12
Modifications 0.90 A.A.B 08/01/13
Validation 1.00 A.A.B 18/01/13

DDC
GPA
Auteur : AAB
Institut Limayrac | Andrea, Arnold, Bellon
2
Sommaire
1. Introduction......................................................................................................................................... 4
1.1 Objectifs du document.................................................................................................................. 4
1.2 Portée du document...................................................................................................................... 4
2. Domaine d'application ........................................................................................................................ 5
2.1 Objectifs du système..................................................................................................................... 5
2.2 Les interfaces................................................................................................................................. 6
2.2.3 Interfaces utilisateurs............................................................................................................. 6
2.2.4 Interfaces logicielles............................................................................................................... 6
2.2.5 Interfaces de communication................................................................................................. 6
2.4 Normes, standards et outils .......................................................................................................... 7
3. Conception générale ........................................................................................................................... 7
3.1 Langages utilisés............................................................................................................................ 7
3.2 Architecture MVC.......................................................................................................................... 8
3.3 Convention de nommage.............................................................................................................. 8
3.4 Base de données détaillée........................................................................................................... 11
3.5 Dictionnaire de données ............................................................................................................. 15
3.6 Structure de données globale, des fichiers et de base de données............................................ 17
3.6.1 Conception du module utilisateur........................................................................................ 17
3.6.2 Conception du module groupe............................................................................................. 18
3.6.3 Conception du module userinfos (information des utilisateurs) ......................................... 18
3.6.4 Conception du module parc................................................................................................. 19
3.6.5 Conception du module client ............................................................................................... 19
3.6.6 Conception du module nouveau véhicule............................................................................ 20
3.6.7 Conception du module véhicule occasion............................................................................ 20
3.6.8 Conception du module formulaire de contact..................................................................... 21
3.7 Stratégie de traitement d'erreurs et des exceptions .................................................................. 21
4. Diagrammes....................................................................................................................................... 23
4.1 Diagramme de classes................................................................................................................. 23
4.2 Diagramme de séquence admin.................................................................................................. 24
4.3 Diagramme de séquence concessionnaire.................................................................................. 25

DDC
GPA
Auteur : AAB
3
4.4 Diagramme de séquence utilisateur ........................................................................................... 26

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
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

DDC
GPA
Auteur : AAB
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".

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
11
3.4 Base de données détaillée
Relation entre les tables:

DDC
GPA
Auteur : AAB
12
Les tables:
-- -----------------------------------------------------
-- Table `mydb`.ùsers`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.ùsers` (
ìd` VARCHAR(20) NOT NULL ,
ùsername` VARCHAR(45) NULL ,
`password` VARCHAR(45) NULL ,
`created` DATE NULL ,
`modified` DATE NULL ,
PRIMARY KEY (ìd`) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`groups`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`groups` (
ìd` INT NOT NULL ,
`created` DATE NULL ,
`modified` DATE NULL ,
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.ùserinfos`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.ùserinfos` (
ìd` INT NOT NULL ,
`numero` VARCHAR(45) NULL ,
`nom` VARCHAR(45) NULL ,
`prenom` VARCHAR(45) NULL ,
PRIMARY KEY (ìd`) ,
UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`parcs`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`parcs` (
ìd` INT NOT NULL ,
`numeroparc` MEDIUMINT(9) NULL ,
`ville` VARCHAR(45) NULL ,
`tel` VARCHAR(45) NULL ,

DDC
GPA
Auteur : AAB
13
UNIQUE INDEX `numeroparc_UNIQUE` (`numeroparc` ASC) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`clients`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`clients` (
`id` INT NOT NULL ,
`numeroclient` VARCHAR(45) NULL ,
`raisonsociale` VARCHAR(45) NULL ,
`tel` VARCHAR(45) NULL ,
UNIQUE INDEX `numeroclient_UNIQUE` (`numeroclient` ASC) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`nvehicules`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`nvehicules` (
`id` INT NOT NULL ,
`numero` MEDIUMINT(9) NULL ,
`marque` VARCHAR(45) NULL ,
`model` VARCHAR(45) NULL ,
`carrosserie` VARCHAR(45) NULL ,
`puissance` VARCHAR(45) NULL ,
`couleur` VARCHAR(45) NULL ,
`finission` VARCHAR(45) NULL ,
`commentaire` TEXT NULL ,
`photo` TINYBLOB NULL ,
`prix` VARCHAR(45) NULL ,
`boite` VARCHAR(45) NULL ,
`motorisation` VARCHAR(45) NULL ,
ENGINE = InnoDB
COMMENT = 'véhicules neuf' ;

DDC
GPA
Auteur : AAB
14
-- -----------------------------------------------------
-- Table `mydb`.`formulairecontacts`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`formulairecontacts` (
ìd` INT NOT NULL ,
`departemnt` VARCHAR(45) NULL ,
`titre` VARCHAR(45) NULL ,
àdresse` VARCHAR(45) NULL ,
`mail` VARCHAR(45) NULL ,
`message` MEDIUMTEXT NULL ,
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.òvehicules`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.òvehicules` (
ìd` INT NOT NULL ,
`numero` MEDIUMINT(9) NULL ,
`marque` VARCHAR(45) NULL ,
`model` VARCHAR(45) NULL ,
`carrosserie` VARCHAR(45) NULL ,
`puissance` VARCHAR(45) NULL ,
`couleur` VARCHAR(45) NULL ,
`finission` VARCHAR(45) NULL ,
`commentaire` TEXT NULL ,
`photo` TINYBLOB NULL ,
`prix` VARCHAR(45) NULL ,
`boite` VARCHAR(45) NULL ,
`motorisation` VARCHAR(45) NULL ,
`kilometrage` VARCHAR(100) NULL ,
`circulation` YEAR NULL ,
ENGINE = InnoDB,
COMMENT = 'véhicules occasion' ;

DDC
GPA
Auteur : AAB
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
 prenomprenom 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.

DDC
GPA
Auteur : AAB
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

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
18
3.6.2 Conception du module groupe
3.6.3 Conception du module userinfos (information des utilisateurs)

DDC
GPA
Auteur : AAB
19
3.6.4 Conception du module parc
3.6.5 Conception du module client

DDC
GPA
Auteur : AAB
20
3.6.6 Conception du module nouveau véhicule
3.6.7 Conception du module véhicule occasion

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
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.

DDC
GPA
Auteur : AAB
23
4. Diagrammes
4.1 Diagramme de classes

DDC
GPA
Auteur : AAB
24
4.2 Diagramme de séquence admin

DDC
GPA
Auteur : AAB
25
4.3 Diagramme de séquence concessionnaire

DDC
GPA
Auteur : AAB
26
4.4 Diagramme de séquence utilisateur

Dossier de conception_v1.00

Contenu connexe

En vedette

Similaire à Dossier de conception_v1.00

Plus de Arnold Stellio

Dossier de conception_v1.00