Dossier de conception_v1.00

DDCGPA

Auteur : AAB Réf : DDC_GPA_001.V1.00

Objet Version Auteur DateRédaction initiale 0.20 A.A.B 11/11/12Modifications 0.80 A.A.B 22/12/12Modifications 0.90 A.A.B 08/01/13Validation 1.00 A.A.B 18/01/13

26DDCGPA


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

|

26DDCGPA


4.3 Diagramme de séquence concessionnaire.................................................................................25

4.4 Diagramme de séquence utilisateur...........................................................................................26

|

26DDCGPA


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.

|

26DDCGPA


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.

|

26DDCGPA


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.

|

26DDCGPA


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.

|

http://www.commentcamarche.net/contents/bdd/bddintro.php3

26DDCGPA


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

|

26DDCGPA


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".

|

26DDCGPA


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.

|

26DDCGPA


3.4 Base de données détaillée

Relation entre les tables:

|

26DDCGPA


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 , PRIMARY KEY (ìd`) )

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 ,

|

26DDCGPA


`ville` VARCHAR(45) NULL , `tel` VARCHAR(45) NULL ,PRIMARY KEY (ìd`) , UNIQUE INDEX `numeroparc_UNIQUE` (`numeroparc` ASC) )

ENGINE = InnoDB;

-- ------------------------------------------------------- Table `mydb`.`clients`-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`clients` (

ìd` INT NOT NULL , `numeroclient` VARCHAR(45) NULL ,`nom` VARCHAR(45) NULL , `prenom` VARCHAR(45) NULL , `raisonsociale` VARCHAR(45) NULL , `ville` VARCHAR(45) NULL , `tel` VARCHAR(45) NULL ,PRIMARY KEY (ìd`) ,

UNIQUE INDEX `numeroclient_UNIQUE` (`numeroclient` ASC) )

ENGINE = InnoDB;

-- ------------------------------------------------------- Table `mydb`.`nvehicules`-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`nvehicules` (

ì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 , PRIMARY KEY (ìd`) ,

UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) )

ENGINE = InnoDBCOMMENT = 'véhicules neuf' ;

|

26DDCGPA


-- ------------------------------------------------------- Table `mydb`.`formulairecontacts`-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `mydb`.`formulairecontacts` (

ìd` INT NOT NULL , `departemnt` VARCHAR(45) NULL ,`titre` VARCHAR(45) NULL , `prenom` VARCHAR(45) NULL , `nom` VARCHAR(45) NULL , àdresse` VARCHAR(45) NULL , `ville` VARCHAR(45) NULL ,`mail` VARCHAR(45) NULL , `message` MEDIUMTEXT NULL ,

PRIMARY KEY (ìd`) )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 ,PRIMARY KEY (ìd`) ,

UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) )

ENGINE = InnoDB,

COMMENT = 'véhicules occasion' ;

|

26DDCGPA


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:

|

26DDCGPA


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.

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

|

26DDCGPA


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

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.

|

26DDCGPA


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.

3.6.2 Conception du module groupe

3.6.3 Conception du module userinfos (information des utilisateurs)

|

26DDCGPA


3.6.4 Conception du module parc

3.6.5 Conception du module client

|

26DDCGPA


3.6.6 Conception du module nouveau véhicule

3.6.7 Conception du module véhicule occasion

|

26DDCGPA


3.6.8 Conception du module formulaire de contact

|

26DDCGPA


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.

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.

|

26DDCGPA


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.

4. Diagrammes

4.1 Diagramme de classes

|

26DDCGPA


4.2 Diagramme de séquence admin

|

26DDCGPA


4.3 Diagramme de séquence concessionnaire

|

26DDCGPA


4.4 Diagramme de séquence utilisateur

|

26DDCGPA


|

Documents

Dossier de conception_v1.00