Chapitre PV.Conception
IV.1. Introduction
Le recours à la conception est depuis longtemps une
pratique indispensable au développement web, car un modèle
conceptuel est prévu pour arriver à anticiper les
résultats du codage. Un modèle conceptuel est en effet une
représentation abstraite d'un système destiné à en
faciliter l'étude et à le documenter.
C'est un outil majeur de communication entre les
différents intervenants au sein d'un projet. En outre, les
systèmes devenant de plus en plus complexes, leur compréhension
et leur maItrise globale dépassent les capacités d'un seul
individu. La construction d'un modèle conceptuel abstrait aide à
y remédier. Le modèle présente notamment l'atout de
faciliter la traçabilité du système, à savoir la
possibilité de partir d'un de ses éléments et de suivre
ses interactions et ses liens avec d'autres parties du modèle.
Une bonne conception réside en un bon choix de la
méthode de modélisation puisqu'un modèle est
établit pour traduire les besoins du concepteur et il prend sa
véritable dimension lorsqu'il permet de communiquer sans
ambiguIté.
IV.2. Architecture du système
L'objectif de cette étape consiste à
définir la finalité du projet et son inscription dans une
stratégie globale. C'est-à-dire l'expression, le recueil et la
formalisation des besoins du demandeur (le client) et de l'ensemble des
contraintes, puis l'estimation de la faisabilité de ces besoins. [5]
· Spécifications ou conception
générale
Il s'agit de l'élaboration des spécifications de
l'architecture générale du logiciel.
· Conception
détaillée
Cette étape consiste à définir
précisément chaque sous-ensemble du logiciel.
· Codage (Implémentation ou
programmation)
C'est la traduction dans un langage de programmation des
fonctionnalités définies lors de phases de conception.
· Tests unitaires
Ils permettent de vérifier individuellement que chaque
sous-ensemble du logiciel est implémenté conformément aux
spécifications.
· Integration
L'objectif est de s'assurer de l'interfacage des
différents éléments (modules) du logiciel. Elle fait
l'objet de tests d'intégration consignés dans un document.
· Qualification (ou recette)
C'est-à-dire la vérification de la
conformité du logiciel aux spécifications initiales.
· Documentation
Elle vise à produire les informations nécessaires
pour l'utilisation du logiciel et pour des développements
ultérieurs.
· Mise en production
C'est le déploiement sur site du logiciel.
· Maintenance
Elle comprend toutes les actions correctives (maintenance
corrective) et évolutives (maintenance évolutive) sur le
logiciel.
Figure 1:Modèle du cycle de vie en cascade
Dans ce modèle le principe est très simple:
chaque phase se termine a une date précise par la production de certains
documents ou logiciels. Les résultats sont définis sur la base
des interactions entre étapes, ils sont soumis a une revue approfondie
et on ne passe a la phase suivante que s'ils sont jugés
satisfaisants.
Le modèle original ne comportait pas de
possibilité de retour en arrière. Celle-ci a été
rajoutée ultérieurement sur la base qu'une étape ne remet
en cause que l'étape précédente, ce qui, dans la pratique,
s'avère insuffisant.
L'inconvénient majeur du modèle de cycle de vie
en cascade est que la vérification du bon fonctionnement du
système est réalisée trop tardivement: lors de la phase
d'intégration, ou pire, lors de la mise en production.
administrateur
Gérer le système
Demande de
prospect
Satisfait-le besoin
Accéder au site
Commercialisation
client
Déposer annonce
Fournir des informations
vis iteur
Figure 2: Diagrammes de contexte dynamique de l'application
IV.3. Conception
A ce stade, nous allons effectuer une analyse complète
de notre système afin déterminer un dimensionnement correct des
caractéristiques de notre produit. Il s'agit donc de faire une analyse
fonctionnelle du système qui consiste a distinguer les besoins
fonctionnelles.
Il s'agit de l'ensemble des fonctionnalités qui
décrivent les services attendus. Dans cette partie, nous allons d'abord
décrire l'ensemble des acteurs qui interagissent avec notre
système, ensuite nous décrirons en détails l'ensemble des
interactions entre ces acteurs et le système a l'aide des diagrammes de
cas d'utilisation. Et enfin, nous décrivons le comportement de ces cas
d'utilisations par les diagrammes d'interactions.
o Les acteurs du système :
Après avoir recensé l'ensemble des besoins, nous
avons distingué les différents acteurs suivants :
|
Administrate
ur
|
C'est le super-utilisateur qui gère le site. Il ajoute des
structures et crée un responsable de site pour chaque structure.
|
|
Client
|
Il s'agit d'un groupe d'utilisateur qui est nommé par
l'administrateur et qui accède a l'interface protégé avec
des tâches réduites. Toutes les mises a jour qu'ils effectuent
sont d'abord validées par l'administrateur avant d'être
publiée.
|
|
Prospect
|
Le prospect est un client ou un fournisseur potentiel. En
amont ou en aval de la production, il est identifié et
démarché par l'entreprise qui cherche la meilleurs source
d'approvisionnement et le moyen le plus sur et le plus rentable
d'écouler sa production.
|
|
Internaute
|
C'est le groupe qui accède uniquement a la zone publique.
Ils ne
s'authentifient pas, et accède directement a cette zone
pour consultation (affichage d'une carte ou un plan, navigation,
recherches...). En d'autres termes ce sont les internautes.
|
o Interactions entre les acteurs et le
système
Ces interactions seront décrites a l'aide de diagrammes de
cas d'utilisation. Si nécessaire certains cas d'utilisation seront
également décrits a l'aide d'un scénario textuelle.
Description de la structure:
Les diagrammes issus des phases de conception ont
été retravaillés en les épurant au maximum pour les
présentés ici. Au final, le modèle présente une
structure "relativement" simple, composée de trois parties : Membre, les
produits et les catégories:
SMS Annonce
Gestion des membres
Gestion des categories
Gestion des
produits
Figure 3: structure générale du système
|
Paquetages
|
Cas d'utilisations
|
|
|
|
S'authentifier
|
|
|
connexion
|
|
|
|
Ajouter annonce
|
|
|
GESTION DES ANNONCES
|
Rechercher annonce
|
|
Modifier annonce
|
|
Supprimer annonce
|
|
|
|
|
S'authentifier
|
|
|
gesticn catégorie
|
|
Ajouter catégorie
|
|
Modifier catégorie
|
|
Supprimer catégorie
|
|
|
|
|
|
S'authentifier
|
|
gestion membre
|
|
Ajouter membre
|
|
Modifier membre
|
|
|
Supprimer membre
|
|
S'authentifier
|
|
|
|
|
Envoyer message
|
|
ges tion de
contact
|
|
|
Consulter message
|
|
|
S'authentifier
|
|
|
|
|
Ajouter actualité
|
|
gestion actualité
|
|
|
Supprimer actualité
|
|
Figure 4: Modèle représentant les paquetages
principaux de l'application
IV.3.1 Diagrammes de cas d'utilisation du
paquetage
? Le cas d'utilisation i' Navigation sur le portail
»
Ici, nous allons nous intéresser au cas
<<navigation>> car celui-ci permet d'effectuer toutes les actions
de la zone publique. Il faut noter que tous les acteurs peuvent effectuer ce
cas d'utilisation.
accès au profil
utilisateur
gestion de navigation sur le portail
visiter le site
rechercher informations
Figure 5: Diagramme de cas d'utilisation <<Navigation sur
le portail >>
- Visiter le site : C'est une action qui permet pour toute
personne a accéder au portail.
- Accès au profil : Permet aux membres de site
d'accéder a la zone privée.
- Rechercher information : consultation de différentes
informations.
· Diagramme de cas d'utilisation i' Gestion
d'annonce » :
|
|
|
|
|
|
gestion annonce
|
|
valider annonce <<include>>
|
|
admin
|
|
<<include>>
|
clients
|
|
|
modifier annonce authentification_admin
<<include>>
<<include>>
|
|
supprimer annonce ajouter annonce
<<include>>
<<include>>
|
|
rechercher annonce authentification_client
<<include>>
demander produit
authentification_prospect
|
|
prospect
|
|
Figure 6:Diagramme de cas d'utilisation << Gestion
d'annonce >>
|
Cas d'utilisation et description
|
Acteur
|
|
Cas d'utilisation : gestion des annonces
|
|
Ajouter annonce
|
Le client a accès a la liste des annonces
récemment
publiée a travers son compte.
|
Client
|
|
Rechercher annonce
|
Tout utilisateur dispose d'un moteur de recherche
portant sur l'ensemble des annonces aux quelles il a accès
sur son espace numérique.
|
administrateur Client
Prospect
|
|
Demander produit
|
Le prospect après sont recherche sur le site il a la
possibilité de réserver le produit.
|
Prospect
|
|
Valider annonce
|
Après que le client a ajouté son propre annonce, la
validité de ce dernier sera effectuée par l'administrateur.
|
Administrateur
|
|
Modifier annonce
|
L'administrateur permet de modifier les détails ou les
informations de chaque annonce.
|
Administrateur
|
|
Supprimer annonce
|
Après que l'annonce a été vendu ou parfois
elle est dépassée l'administrateur a l'accès de la
supprimer.
|
Administrateur
|
|
· Diagramme de cas d'utilisation i'
Authentification .
admin
saisir email
<<extend>>
Authentification
accéder au compte
tapper mot de passe
<<extend>>
prospect
client
Figure 7:Diagramme de cas d'utilisation <<
Authentification >>
|
Cas d'utilisation et description
|
Acteur
|
|
Cas d'utilisation : identification unique et
gestion des profiles
|
|
S'authentifier
|
Tout utilisateur possède un seul chemin
d'identification
(exemple : e-mail & mot de passe), qui lui permet
d'accéder a l'ensemble des annonces. Tout utilisateur ne
s'authentifier qu'une seule fois au début de session.
|
Administrateur Client
Prospect
|
|
· Diagramme de cas d'utilisation i' Gestion
membres »
visiteur
admin
créer compte
supprimer membre
<<include>>
gestion membre
authentification
<<include>>
modifier profil
client
prospect
Figure 8:Diagramme de cas d'utilisation << Gestion membres
>>
|
Cas d'utilisation et description
|
Acteur
|
|
Cas d'utilisation : Gestion membres
|
|
Créer compte
|
Tout utilisateur qui va accéder au site a le droit de
créer son propre compte, chaque compte possède
un et un seul adresse mail mais chaque acteur peut créer plus qu'un seul
compte.
|
Visiteur
|
|
Modifier profil
|
Chaque acteur peut modifier son profil,
|
Client Prospect
|
Supprimer membre
Seulement l'administrateur peut supprimer un membre dans la base
après une demande de ce dernier.
administrateur
· Diagramme de cas d'utilisation 'Gestion
des catégories .
|
|
|
n
|
|
|
gestion catégorie
|
|
ajouter catégorie <<include>>
|
|
admin
|
|
|
<<include>>
|
|
|
modifier catégorie <<include>>
authentification_admi
|
|
|
supprimer catégorie
|
|
Figure 9:Diagramme de cas d'utilisation <<Gestion des
catégories >>
Cas d'utilisation et description Acteur
Cas d'utilisation : Gestion des
catégories
|
Mise a jour des
catégories
|
Seulement l'administrateur du site peut d'ajouter,
modifier et supprimer une catégorie ou
sous-catégorie.
|
Administrateur
|
|
· Diagramme de cas d'utilisation i' Gestion
de contact))
admin
Gestion de contact
envoyer message
s'authentifier
<<include>>
prospect
clients
Figure 10:Diagramme de cas d'utilisation << Gestion de
contact >>
as d'utilisation et description Acteur
Cas d'utilisation : Gestion des
catégories
|
Envoyer message
|
Tout acteur du système peut se contacter
cetteAdministrateur
procédure se contrôler par l'administrateur.
|
Clients Prospect
|
|
IV.3.2 Scénario textuel des cas
d'utilisation
|
Cas d'utilisation
|
Valider annonce
|
|
But
|
La commercialisation du produit sur le site.
|
|
Acteurs
|
Administrateur
|
|
Pré condition
|
S'authentification
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : le
client ouvre son
|
:
session.
d'ajout d'annonce.
:
champs.
|
|
EnchaInement (b) : remplir le formulaire
|
|
EnchaInement (c) : vérification par l'administrateur.
|
|
ENCHAINEMENTS ALTERNATIFS EnchaInement (d) :
modifié certains
|
|
|
Exceptions
|
|
[Exception : 1 ] : refusé l'annonce dans
le cas de manque des informations
obligatoires.
|
|
Cas d'utilisation
|
Navigation sur le portail
|
|
But
|
S'informer
|
|
Acteurs
|
Tous les utilisateurs
|
|
Pré condition
|
Accès a internet
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : Le
système le portail
|
:
du site avec tous les outils de
navigation. la recherche sur un
objet.
ALTERNATIFS :
tout le résultat de la recherche.
|
|
EnchaInement (b) : L'utilisateur effectue
|
|
EnchaInement (c) : ENCHAINEMENTS
|
|
EnchaInement (d) : Le système affiche
|
|
|
Exceptions
|
|
[Exception : 1 ] : L'utilisateur n'entre pas les
bons critères de recherche.
[Exception : 2 ] : Le système ne retourne
aucun résultat.
|
|
Cas d'utilisation
|
Consulter contact
|
|
But
|
Répondre aux messages des contacts
|
|
Acteurs
|
Administrateur
|
|
Pré condition
|
Ouvrir la session administrateur
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : le
contact s'authentifier
|
:
et l'envoyer
reçoit les messages dans la boite de réception
:
lit les messages et répondre ces contacts.
|
|
EnchaInement (b) : écrire son message
|
|
EnchaInement (c) : l'administrateur
|
|
ENCHAINEMENTS ALTERNATIFS EnchaInement (d) :
l'administrateur
|
|
|
Exceptions
|
|
[Exception : 1 ] : suppression des messages qui
sont répètes.
|
|
Cas d'utilisation
|
Ajouter annonce
|
|
But
|
Permet a un client de SMS Annonce d'ajouter des annonces.
|
|
Acteurs
|
Client
|
|
Pré condition
|
Une annonce est créée pour un prospect qui
achète ces annonces. Ce prospect et ces annonces doivent exister dans le
système.
|
|
ENCHAINEMENTS NOMINAUX
EnchaInement (a) :
le client accéder a
|
:
son espace avec son e-mail et mot de passe.
le formulaire d'ajout annonce.
champs d'ajout.
:
stockée dans la base de données a fin que
|
|
EnchaInement (b) : le client demande
|
|
EnchaInement (c) : le client remplir les
|
|
ENCHAINEMENTS ALTERNATIFS EnchaInement (d) :
l'annonce sera
|
|
l'administrateur se valider.
|
|
Exceptions
|
|
[Exception : 1 ] : Si l'identifiant du client
n'est pas présent dans le système une
exception `'identifiant non valide» est levée.
[Exception : 2 ] : Si l'identifiant de l'annonce
n'est pas présent dans le système une
exception `'annonce n'est pas disponible» est
levée.
|
|
Cas d'utilisation
|
supprimer annonce
|
|
But
|
Permet a un client ou administrateur de
supprimer une annonce du système.
|
|
Acteurs
|
Client / Administrateur
|
|
Pré condition
|
L'annonce doit être existante dans le système
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : A
partir d'un numéro
|
:
annonce(Id_annonce) le système en affiche les
l'administrateur de la supprimer. Si l'administrateur l'annonce est
supprimée du système.
|
|
détails et propose a accepte alors
|
|
Exceptions
|
|
[Exception : 1 ] : Si l'identifiant n'est pas
présent dans le système une exception
`'Annonce n'existe pas» est levée.
|
|
Cas d'utilisation
|
S'inscrire
|
|
But
|
l'accès aux services de site.
|
|
Acteurs
|
Client et prospect
|
|
Pré condition
|
Visiter le site
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) :
visiter le portail
|
:
d'inscription
:
pour activer son compte.
|
|
EnchaInement (b) : remplir le formulaire
|
|
ENCHAINEMENTS ALTERNATIFS EnchaInement (c) :
réception d'un mail
|
|
|
Exceptions
|
|
[Exception : 1 ] : dans le cas oü l'un des
membres oublier son mot de passe il est
possible de modifier son compte.
|
|
Cas d'utilisation
|
Rechercher annonce
|
|
But
|
Permet a un prospect de retrouver une annonce.
|
|
Acteurs
|
Prospect
|
|
Pré condition
|
L'annonce doit être existante dans le système
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : lancer
la recherche
|
:
:
|
|
EnchaInement (b) : sélection l'annonce
|
|
ENCHAINEMENTS ALTERNATIFS EnchaInement (c) :
vérifié les détails
|
|
|
Exceptions
|
|
[Exception : 1 ] : Si l'identifiant n'est pas
présent dans le système une exception
`'l'annonce n'existe pas» est levée.
|
|
Cas d'utilisation
|
Authentification
|
|
But
|
Accès a la zone privée
|
|
Acteurs
|
Les Utilisateurs sauf les visiteurs simples
|
|
Pré condition
|
Utilisateur créé.
Utilisateur appartient a la structure concernée.
|
|
ENCHAINEMENTS NOMINAUX EnchaInement (a) : Le
système présente
|
:
le portail d'accueil
le menu paramétrage
le formulaire d'authentification
son login et son mot de passe
et accepte l'identité de l'utilisateur
crée une session et enregistre les paramètres de
la page administrateur correspondante au profil de
:
ainsi a toutes les fonctionnalités dont il a droit
|
|
EnchaInement (b) : L'utilisateur sélectionne
|
|
EnchaInement (c) : Le système présente
|
|
EnchaInement (d) : L'utilisateur saisie
|
|
EnchaInement (e) : Le système vérifie
|
|
EnchaInement (f) : Ensuite le système
|
|
l'utilisateur dans celle-ci EnchaInement (g) : Le système
affiche
|
|
l'utilisateur
ENCHAINEMENTS ALTERNATIFS EnchaInement (h) :
L'utilisateur accède
|
|
|
Exceptions
|
|
[Exception : 1 ] : L'utilisateur a oublier son
compte
[Exception : 2 ] : Le système lui
redemande son login et mot de passe
|
IV.3.3 Diagramme de sequence
1: authentification()
: annonce
: administrateur
: clients
: prospect
2: valider authentification()
3: demande de reservation de produit()
4: vérification disponibilité()
5: affiché une formulaire de contact client()
6: remplir le message()
7: envoyer le message()
9: repondre le message()
11: confirmer leur réservation()
Figure 11:diagramme de séquence de réservation du
produit
1: Authentification
: admin
2: valider authentification
3: demander le page d'ajout annonce
4: afficher la formulaire
6: saisir les données
: vérification
7: enregistrement de nouvelle annonce
: clients
Figure 12:diagramme de séquence d'ajout annonce
Ce diagramme montre le scénario du cas d'utilisation
<<Ajouter annonce>> en effet c'est un
scénario générale qui représente l'ensemble de tous
les annonces.
|
|
|
|
|
: admin
|
: annonce
|
|
|
|
1: authentification()
|
|
|
2: vérification authentification()
|
|
|
3: demande la page des annonces()
|
|
4: affiché la list d'annonces()
|
|
5: saisir et valider les options des annonces()
|
6: renvoyer la résultat de recherche()
|
|
6:
|
6:
|
|
Figure 13:diagramme de séquence de suppression
d'annonce
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: admin
|
|
: personne
|
|
|
|
|
|
|
1: authentification()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2: valider authentification()
|
|
|
|
|
|
|
|
|
|
|
3: demande la page des contacts()
|
|
|
|
|
|
|
|
|
|
|
4: affiché la list des messages non lis()
|
|
|
|
|
|
|
|
|
|
|
5: choisir de consulter un message()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6: vérification()
|
|
|
|
|
7: affiché les détails de messages()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 14:Diagramme de séquence de consultation des
messages
: actualité
: admin
1: authentification()
2: vérifier authentification()
3: demande la page d'ajout actualité()
4: affiché la formulaire d'ajout()
5: saisir les options d'ajout()
6: vérification()
7: valider l'ajout d'actualité()
Figure 15:diagramme de séquence d'ajout
actualité
IV.3.4 Diagramme d'activité
Il donne une vision des enchaInements des activités propre
a une opération ou a un cas d'utilisation.
Le diagramme d'activité est attaché a une
catégorie de classes et décrit le déroulement des
activités de cette catégorie. Le déroulement s'appelle
"flot de contrôle". Il indique la part prise par chaque objet dans
l'exécution d'un travail. Il sera enrichi par les conditions de
séquence.
demander
l'authentification
vérifier le validation
enregistrer
profil utilisateur
profiu
[ profil_prospect ] [ profil_client ]
[profil_admin]
ouvrir espace
prospect
ouvrir espace
client
ouvrir espace administration
Figure 16:Diagramme d'activité "authentification"
Le diagramme d'activité d'authentification nous permet de
voir les comportements internes du système, lors du démarrage de
l'application par l'utilisateur, le système lui affiche le
formulaire d'authentification, après que le mot de passe
soit saisit le système vérifie sa validité et affiche la
page d'accueil sinon il affiche un message d'erreur.
saisir l'identifiant
client
identifiant non trouvO
identifiant trouvO
stockage du
nouvelle annonce
affichage du form ulaire d'ajout
dem ande du form ulaire
d'ajout
saisir les nouvelles
donnOes
afficher un
message d'erreur
verifier l'existance de nouvelle annonce
confirm ation
d'ajout
Figure 17:Diagramme d'activité " ajout annonce"
|
|
|
|
demande de modification
|
|
|
|
affichage de formulaire de
modification
|
|
|
|
saisir les données recherche de
|
|
a modifier l'annonce
|
|
|
|
|
affichage
|
|
d'erreur
|
|
|
saisir les nouvelles
données
|
|
|
sausgarder les
données
|
|
|
Figure 18:Diagramme d'activité de modification annonce
Après une demande d'ajout d'une donnée par
l'utilisateur (patient, garde- patient, naissance), le système lui
affiche le formulaire d'ajout pour qu'il puisse saisir ces données et
confirmer leur enregistrement au niveau de la base de données.
demande de suppression
affichage de formulaire de
suppression
saisir les matricules de
l'annonce
suppression
recherche de
l'annonce
confirmation de
suppression
Figure 19:Diagramme d'activité de suppression d'annonce
affichage de formulaire de
recherche
saisir le donnée a
chercher
recherche de
l'annonce
affichage de l'annonce
demande d'une
recherche
Figure 20:Diagramme d'activité de recherche
affichage message
d'erreur
affichage message d'envoi avec succès
affichage de formulaire de
contact
demande formulaire
d'envoi message
saisir les données
obligatoires
envoyer le message
Figure 21:Diagramme d'activité d'envoi de message
6: 6: vérification
1: 1: Authentification
3: 3: demander le page d'ajout
annonce
5: 5: saisir les données
: clients
2: 2: valider authentification
4: 4: afficher la
formulaire
7: 7: enregistrement de nouvelle annonce
: admin
IV.3.5 Diagramme de collaboration
: annonce
1: 1: authentification()
: administrateur
: prospect
5: 5: affiché une formulaire de contact client()
2: 2: valider authentification()
9: 9: confirmer leur réservation()8: 8: repondre le
message()
6: 6: remplir le message()
3: 3: demande de reservation de produit()
7: 7: envoyer le message()
4: 4: vérification disponibilité()
: clients
Figure 22:diagramme de collaboration de réservation
produit
Figure 23: diagramme d'ajout annonce
6: 6: vérification()
|
: admin
|
4: 4: affiché la formulaire d'ajout()
7: 7: valider
l'ajout d'actualité()
|
|
1: 1: authentification()
3: 3: demande la page d'ajout
actualité()
5: 5: saisir les options d'ajout()
: actualité
2: 2: vérifier authentification()
|
|
|
1: 1: authentification()
3: 3: demande la page des
annonces()
5: 5: saisir et valider les options des annonces()
7: 7:
choisir de supprimer l'annonce()
|
|
|
: annonce
|
|
: admin
|
|
|
|
2: 2: vérification authentification()
4: 4: affiché la list d'annonces()
6: 6: renvoyer la
résultat de recherche()
8: 8: valider la suppression()
|
|
Figure 24: diagramme de suppression annonce
6: 6: vérification()
|
|
|
|
1: 1: authentification()
3: 3: demande la page des
contacts()
5: 5: choisir de consulter un message()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: personne
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2: 2: valider authentification()
|
|
|
|
|
: admin
|
4: 4: affiché la list des messages non lis()
7: 7:
affiché les détails de messages()
|
|
Figure 25: diagramme de consultation message
Figure 26: diagramme d'ajout actualité
IV.4. Structure de la base de donnée
IV.4.1 Diagramme de classe
Le diagramme de classes est généralement
considéré comme le plus important dans un développement
orienté objet. Il représente l'architecture conceptuelle du
système : il décrit les classes que le système utilise,
ainsi que leurs liens, que ceux-ci représentent un emboItage conceptuel
(héritage) ou une relation organique (agrégation).
d_article lom_actualité description
3jouter() modifier() 3upprimer()
actualité
0..*
1
catégorie annonce
3ctiver compte() Jesactiver compte()
d_catégorie
nom catégorie 3ous_catégorie1
3ous_catégorie2 3ous_catégorie3 3ous_catégorie4
3ous_catégorie5
3jouter() modifier() 3upprimer() )pname()
administrateur
1
0..*
1 1..'
1
;identifier() connexion() 3et_login()
3et_mot de passe() 3et_e-mail() 3et_nom() 3et_prénom()
)et_logino
pt_mot de passe() get_e-mail()
ogin
mot de passe nom
pronom
e-mail
personne
consulter annonce() modifier annonce() 3upprimer annonce()
3jouter annonce() 3et_titre annonce() 3et_description() ptid()
)et_date ajoutO pt_proprietaire()
d_annonce Jate_ajout .latégorie
ü ille
titre annonce description prix ttc
mage1 rrage2 rrage3 rrage4
d_prospect
nom prospect pronom prospect
ü ille 3dresse
mail el
tat
connexion()
·echercher annonce() 3c:did()
3et_nom() 3et_prénom() 3et_mail() 3et_tel()
annonce
prospects
0..*
0..*
1..*
0..* 1..*
1..*
0..*
clients
d_client
nom client pronom client
ü ills 3dresse
el
mail tat
connexion() 3etid()
3et_nom() 3et_prénom() 3et_mail() 3et_tel()
3jouter annonce()
1
1
1..*
d_ville 'om_villa
3jouter() 3upprimer()
ville
1
Figure 27: Diagramme de classe
IV.4.2 la base de données du projet
Le passage du modèle objet vers le modèle
relationnel peut se faire automatiquement avec l'outil Rational Rose. Le
résultat obtenu doit être finalisé ensuite selon
l'application. Ce passage peut se faire avec plus de détails et
précision manuellement.
Les règles de passage sont :
o Les classes sont transformées en model conceptuel
(entités associations).
· chaque classe donne lieu a un type d'entité ou un
type d'association, les attributs de la classe sont les
propriétés des entités.
· les méthodes de la classe sont enlevées, il
ya un traitement des identifiants. Si a une clé candidate, elle devient
l'identifiant de l'entité.
· Si non un identifiant arbitraire est ajouté aux
propriétés de l'
entité.ni l'héritage se
concrétise par la création d'une table par classe. Dans une
relation d'héritage, l'objet père est représenté en
table.
· L'objet fils hérite de la clé primaire et
des attributs de l'objet père y rajoutant ses propres attributs.
o Le modèle conceptuel est traduit en modèle
logique (modèle relationnel).
· Traduire chaque entité en association en table
selon les cardinalités.
· Définir la série de contraintes
d'intégrité référentielles.
o Le modèle relationnel est implémenté
physiquement.
· Implémenter la base.
Vérifier les contraintes d'intégrité
référentielles.
IV.4.3 Schéma relationnel de la base de
données
- Personne (login, mot de passe, nom, prénom,
e-mail);
- Annonce (id annonce, date_ajout, catégorie,
ville, titre_annonce, prix ttc, image);
- Catégorie (id catégorie,
nom_catégorie, sous_catégorie) ; - Actualité (id
actualité, nom_actualité, description);
- Ville (id ville, nom_ville) ;
Projet : Développement Web License Fondamentale
Informatique de Gestion
Figure 28 : Structure de la base de données
IV.5. Conclusion
Après que nous finissons la partie de conception a l'aide
des outils des modélisations compatibles et simple, nous allons passer
maintenant a la phase de réalisation de projet ce que nous allons vue
dans le chapitre suivant.
Année universitaire : 2009 - 2010 Page : 61 /65
| 
