DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
2012/2013
Dossier de conception
Gestion d'un parc automobile
Andrea, Arnold, ...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
2
Sommaire
1. Introduction...........
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
3
4.4 Diagramme de séquence utilis...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
4
1. Introduction
1.1 Objectifs du...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
5
2. Domaine d'application
2.1 Obj...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
6
2.2 Les interfaces
2.2.3 Interfa...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
7
2.4 Normes, standards et outils
...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
8
3.2 Architecture MVC
L’applicati...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
9
Chaque fichier serait située dan...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
10
En utilisant les conventions Ca...
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
R...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
12
Les tables:
-- ----------------...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
13
PRIMARY KEY (`id`) ,
UNIQUE IND...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
14
-- ----------------------------...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
15
3.5 Dictionnaire de données
La ...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
16
La table PARCS permet de créer ...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
17
La table FORMULAIRECONTACTS per...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
18
3.6.2 Conception du module grou...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
19
3.6.4 Conception du module parc...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
20
3.6.6 Conception du module nouv...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
21
3.6.8 Conception du module form...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
22
Si la connexion échoue, mysql_c...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
23
4. Diagrammes
4.1 Diagramme de ...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
24
4.2 Diagramme de séquence admin
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
25
4.3 Diagramme de séquence conce...
DDC
GPA
Auteur : AAB
Réf : DDC_GPA_001.V1.00
Institut Limayrac | Andrea, Arnold, Bellon
26
4.4 Diagramme de séquence utili...
Upcoming SlideShare
Loading in...5
×

Dossier de conception_v1.00

1,248

Published on

Projet : Création d'un logiciel de gestion de parc automobile.
CPI. Institut Limayrac, Toulouse

1 Comment
1 Like
Statistics
Notes
  • Avec plus de 700 véhicules en gestion externalisée, Buy Made Easy adopte une approche résolument NEUTRE et INDÉPENDANTE vis-à-vis des financeurs et constructeurs.

    Gestion de parc automobile dans sa globalité, Buy Made Easy prend en charge votre flotte à 100% avec un tarif unique mensuel par véhicule afin d'adapter le budget aux variations de votre activité.

    http://www.buymadeeasy.com/nos-metiers-solutions/consulting-en-achats/flotte-automobile.html#gestions-de-parc
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,248
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Dossier de conception_v1.00"

  1. 1. 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
  2. 2. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 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
  3. 3. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 3 4.4 Diagramme de séquence utilisateur ........................................................................................... 26
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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 ,
  13. 13. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 13 PRIMARY KEY (`id`) , 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 , `nom` VARCHAR(45) NULL , `prenom` VARCHAR(45) NULL , `raisonsociale` VARCHAR(45) NULL , `ville` VARCHAR(45) NULL , `tel` VARCHAR(45) NULL , PRIMARY KEY (`id`) , 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 , PRIMARY KEY (`id`) , UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) ) ENGINE = InnoDB COMMENT = 'véhicules neuf' ;
  14. 14. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 14 -- ----------------------------------------------------- -- Table `mydb`.`formulairecontacts` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `mydb`.`formulairecontacts` ( `id` INT NOT NULL , `departemnt` VARCHAR(45) NULL , `titre` VARCHAR(45) NULL , `prenom` VARCHAR(45) NULL , `nom` VARCHAR(45) NULL , `adresse` VARCHAR(45) NULL , `ville` VARCHAR(45) NULL , `mail` VARCHAR(45) NULL , `message` MEDIUMTEXT NULL , PRIMARY KEY (`id`) ) ENGINE = InnoDB; -- ----------------------------------------------------- -- Table `mydb`.`ovehicules` -- ----------------------------------------------------- CREATE TABLE IF NOT EXISTS `mydb`.`ovehicules` ( `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 , `kilometrage` VARCHAR(100) NULL , `circulation` YEAR NULL , PRIMARY KEY (`id`) , UNIQUE INDEX `numero_UNIQUE` (`numero` ASC) ) ENGINE = InnoDB, COMMENT = 'véhicules occasion' ;
  15. 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  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.
  16. 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. 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. 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)
  19. 19. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 19 3.6.4 Conception du module parc 3.6.5 Conception du module client
  20. 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. 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. 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.
  23. 23. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 23 4. Diagrammes 4.1 Diagramme de classes
  24. 24. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 24 4.2 Diagramme de séquence admin
  25. 25. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 25 4.3 Diagramme de séquence concessionnaire
  26. 26. DDC GPA Auteur : AAB Réf : DDC_GPA_001.V1.00 Institut Limayrac | Andrea, Arnold, Bellon 26 4.4 Diagramme de séquence utilisateur

×