Diagramme de Classes et conception Base de Donnees

Citation:

---

Envoyé par escartefigue

Pour créer une nouvelle annonce, il n'est pas nécessaire de supprimer l'ancienne, on en crée simplement une nouvelle avec un nouvel identifiant et une date de création plus récente.
L'application recherchera la date de l'annonce la plus récente pour le parking et c'est celle là qui sera valide.
J'explique dans mon blog comment le faire ;)

L'intérêt est de conserver l'historique des annonces pour un même parking :)

---

Oui bien sur , je me suis embrouillé tout seul ^^ je voulais à la fois avoir un historique des annonces et utiliser une règle de gestion qui autorise une annonce par parkings . désolé pour cette erreur d'inattention je comprend mieux cette partie pour la gestion des annonces

Citation:

---

Envoyé par escartefigue

:aie: MB_ident c'est une boulette, j'ai modifié trop vite en oubliant que MB_membre était un sous-type de PE_personne... désolé.
Concernant MB_matricule, je l'ai déjà expliqué plus haut, c'est un exemple d'attribut du sous-type, vous pouvez le supprimer bien sûr ;)




J'ai compris qu'un responsable (staff) pouvait modérer plusieurs annonces et qu'une annonce pouvait être modérée par plusieurs responsables, d'où cette modélisation.
à modifier si ce n'est pas le cas




oui c'est possible mais il vous faut télécharger looping, sans quoi vous ne pourrez rien en faire et il faut que je zipe le fichier pour pouvoir le déposer, voici le fichier zipé





N'hésitez pas à voter pour les réponses qui vous ont aidées en cliquant sur le pouce vert prévu à cet effet ;)

---

Bonjour,

J'ai ajoute des champs pour la partie Personne.
J'ai aussi ajoute un matricule au Staff pour identifier les membres du staff. je ne sais pas si c'est necessaire.
Je ne sais pas si le type et la longueur des variables que j'ai choisi sont pertinent.

J'ai indique l'adresse mail des utilisateurs. je l'ai indique comme unique. on peut l'utiliser comme cle primaire de la table ?
a quoi correspond PE_ddn , RS_dtfin ?


J'ai renomme en Anglais pour garder une coherence pour l'ensemble du projet.
Si vous pouvez verifier que tout est coherent. le fichier se trouvent en piece jointe dans une archive zip merci.


A quel endroit avez-vous pu definir les contraintes publier et posseder

ALTER TABLE AN_annonce
ADD CONSTRAINT FK_publier_posseder
FOREIGN KEY (PE_ident, PA_ident)
REFERENCES PA_parking(PE_ident, PA_ident)
;




Les classes Member et Staff vont bien heriter des champs (Email, Password, FirstName, LastName, ddn, PhoneNumber) de la classe User ? car j'ai regarde le code sql et on dirait que les classes Member et Staff heritent uniquement du champ US_ID .

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90

CREATE TABLE US_User( US_ID INT IDENTITY, US_Email VARCHAR(50) NOT NULL, US_Password VARCHAR(50), US_LastName VARCHAR(50) NOT NULL, US_FirstName VARCHAR(50) NOT NULL, US_ddn DATE NOT NULL, US_PhoneNumber INT, PRIMARY KEY(US_ID), UNIQUE(US_Email) );   CREATE TABLE ME_Member( US_ID INT, ME_SerialNumber CHAR(6) NOT NULL, PRIMARY KEY(US_ID), UNIQUE(ME_SerialNumber), FOREIGN KEY(US_ID) REFERENCES US_User(US_ID) );   CREATE TABLE ST_Staff( US_ID INT, ST_SerialNumber CHAR(6) NOT NULL, PRIMARY KEY(US_ID), UNIQUE(ST_SerialNumber), FOREIGN KEY(US_ID) REFERENCES US_User(US_ID) );   CREATE TABLE CI_City( CI_ID INT IDENTITY, CI_Insee CHAR(5) NOT NULL, CI_Name VARCHAR(50) NOT NULL, PRIMARY KEY(CI_ID), UNIQUE(CI_Insee) );   CREATE TABLE PA_Parking( PA_ID INT IDENTITY, PA_Length DECIMAL(5,2) NOT NULL, PA_Width DECIMAL(5,2) NOT NULL, PA_Height DECIMAL(5,2) NOT NULL, PA_GeoGPS GEOGRAPHY NOT NULL, PA_Address1 VARCHAR(38) NOT NULL, PA_Address2 VARCHAR(38), PA_Access VARCHAR(50), CI_ID INT NOT NULL, US_ID INT NOT NULL, PRIMARY KEY(PA_ID), FOREIGN KEY(CI_ID) REFERENCES CI_City(CI_ID), FOREIGN KEY(US_ID) REFERENCES ME_Member(US_ID) );   CREATE TABLE AD_Advertisement( PA_ID INT, AD_ID SMALLINT, AD_Date DATE NOT NULL, AD_tarif DECIMAL(7,2) NOT NULL, US_ID INT NOT NULL, PRIMARY KEY(PA_ID, AD_ID), FOREIGN KEY(PA_ID) REFERENCES PA_Parking(PA_ID), FOREIGN KEY(US_ID) REFERENCES ME_Member(US_ID) );   CREATE TABLE RE_Reserve( PA_ID INT, CA_Date DATE, RE_Dtfin DATE NOT NULL, US_ID INT NOT NULL, PRIMARY KEY(PA_ID, CA_Date), FOREIGN KEY(PA_ID) REFERENCES PA_Parking(PA_ID), FOREIGN KEY(US_ID) REFERENCES ME_Member(US_ID) );   CREATE TABLE MO_Moderate( US_ID INT, PA_ID INT, AD_ID SMALLINT, MO_HourlyDate DATETIME2 NOT NULL, MO_Purpose VARCHAR(128), PRIMARY KEY(US_ID, PA_ID, AD_ID), FOREIGN KEY(US_ID) REFERENCES ST_Staff(US_ID), FOREIGN KEY(PA_ID, AD_ID) REFERENCES AD_Advertisement(PA_ID, AD_ID) );   ALTER TABLE AN_annonce ADD CONSTRAINT FK_publier_posseder FOREIGN KEY (PE_ident, PA_ident) REFERENCES PA_parking(PE_ident, PA_ident) ;

---

Pièce jointe 596442

Bonjour NarumiN,

Citation:

---

Envoyé par NarumiN

J'ai ajoute des champs pour la partie Personne.
J'ai aussi ajoute un matricule au Staff pour identifier les membres du staff. je ne sais pas si c'est necessaire.

---

En l'occurrence on parlera d'ajout d'attributs si on s'intéresse au modèle conceptuel et de colonnes si on s'intéresse au modèle tabulaire.
Les champs sont des zones de saisie d'un formulaire ou d'édition sur un état, sans rapport avec le modèle de données donc ;)
Si le matricule est pertinent pour le staff et aussi pour les membres, alors cet attribut est commun et doit remonter dans l'entité-type parente PERSONNE (ou USER si vous préférez)
Le terme de responsable est plus approprié, car le staff désigne un groupe et non une personne, or, vous souhaitez identifier chaque personne faisant partie du staff et non le groupe vu comme un tout, donc des responsables. La preuve en est est que l'entité-type RESPONSABLE est un sous-type de personne ;)

Citation:

---

Envoyé par NarumiN

Je ne sais pas si le type et la longueur des variables que j'ai choisi sont pertinent.

---

Pas toujours :

• une adresse courriel peut faire jusqu'à 255 caractères, il faut donc prévoir du varchar(255)
• le numéro de téléphone est composé de chiffres, mais n'est pas un nombre, il faut donc le définir en type char ou varchar (on n'est pas à l'abri qu'un jour, la norme de numérotation change et utilise des lettres ou d'autres caractères)
• rappelez-vous que je n'avais créé que deux lignes adresses pour le parking, mais il faut compléter à 6 lignes de 38 pour respecter la norme de la poste

Citation:

---

Envoyé par NarumiN

J'ai indique l'adresse mail des utilisateurs. je l'ai indique comme unique. on peut l'utiliser comme cle primaire de la table ?

---

Non : même si l'adresse courriel est unique, c'est un mauvais candidat comme PK. A tout moment, une personne peut changer d'adresse courriel, or, si une PK change, cela provoque des mises à jour en cascade dans toutes les tables filles où cette PK est propagée, ça peut dans certains cas représenter des millions de mises à jour inutiles. C'est pourquoi il est recommandé de choisir comme PK une colonne dont la valeur est unique, mais surtout immuable dans le temps.
C'est pourquoi un identifiant technique attribué par le SGBD (identity column) est le candidat idéal comme PK.
Argument supplémentaire en défaveur d'une adresse courriel comme PK : comme expliqué plus haut, une adresse courriel peut contenir jusqu'à 255 caractères, c'est extrêmement encombrant, sachant que la PK intervient souvent comme critère de jointure, il vous faudra 2x255 caractères rien que pour joindre deux tables ! :aie:
Un integer ne consomme que 4 caractères pour plus de 4 milliards de valeurs distinctes possibles :)

Citation:

---

Envoyé par NarumiN

à quoi correspond PE_ddn , RS_dtfin ?

---

PE_ddn = date de naissance de la personne
RS_dtfin = date de fin de la réservation, indispensable pour savoir à partir de quand au plus tôt on pourra de nouveau réserver le parking

Citation:

---

Envoyé par NarumiN

Si vous pouvez verifier que tout est coherent. le fichier se trouvent en piece jointe dans une archive zip merci.

---

OK, je le note pour plus tard ;)

Citation:

---

Envoyé par NarumiN

Les classes Member et Staff vont bien heriter des champs (Email, Password, FirstName, LastName, ddn, PhoneNumber) de la classe User ? car j'ai regarde le code sql et on dirait que les classes Member et Staff heritent uniquement du champ US_ID .

---

Il n'y a jamais de redondance dans les tables, sauf pour les clefs étrangères, c'est pourquoi seule la colonne US_id se retrouve dans les tables filles (en tant que PK mais ce sont aussi des FK héritées de la classe mère US_USER)
Ce qui n'est pas un problème, il suffira de faire une jointure entre US_USER et l'une ou l'autre des classes filles pour récupérer tous les attributs dont vous avez besoin. Une vue réalisant cette jointure étant la solution adhoc :).

Merci pour ces explications.
Pour le matricule je voulais un moyen de différencier les membres ( particuliers) et les responsables. par exemple plus tard ça serait pour donner les droits précis ou autre si c'est un membre ou un responsable.


Par exemple pour un utilisateur admettons "Adam" . Comment devrons nous indiquer que c'est un responsable ? Il doit donc être présent dans Personne et Responsable. Mais responsable ne contient aucun attribut dans votre exemple.

J'ai compris pour l'adresse mail.

Faut que je rajoute 6 autres lignes pour l'adresse des parking pas de soucis.

Pour réaliser la jointure donc il faut utiliser une VUE avec un logiciel adhoc . Looping en est un non ?

Bonsoir NarumiN


Merci de ne pas utiliser inutilement "répondre avec citation"

quand la citation est inutile, vous pouvez utiliser le bouton "répondre" en bas à gauche du fil de discussion ;)
Pièce jointe 596452

j'ai expliqué précédemment dans quel cas il était utile d'utiliser la citation, dans tous les autres cas, la citation surcharge le fil de discussion au détriment de la clarté

Citation:

---

Envoyé par NarumiN

Merci pour ces explications.
Pour le matricule je voulais un moyen de différencier les membres ( particuliers) et les responsables. par exemple plus tard ça serait pour donner les droits précis ou autre si c'est un membre ou un responsable.


Par exemple pour un utilisateur admettons "Adam" . Comment devrons nous indiquer que c'est un responsable ? Il doit donc être présent dans Personne et Responsable. Mais responsable ne contient aucun attribut dans votre exemple.

---

La présence dans l'entité-type responsable suffit à reconnaitre un simple utilisateur d'un responsable, inutile d'ajouter des attributs s'ils ne sont pas nécessaires, seuls les attributs spécifiques aux responsables, s'ils existent, doivent être ajoutés

Ensuite, s'il existe plusieurs niveaux de responsabilité, on créera une association entre le sous-type responsable et un autre type d'entité, par exemple "ROLE" pour préciser le rôle du responsable

[RESPONSABLE] 1,1 --- (exercer) --- 0,n [ROLE]

Citation:

---

Envoyé par NarumiN

Faut que je rajoute 6 autres lignes pour l'adresse des parking pas de soucis.

---

Non : 6 en tout, donc 4 de plus

Citation:

---

Envoyé par NarumiN

Pour réaliser la jointure donc il faut utiliser une VUE avec un logiciel adhoc

---

Non : j'ai écrit "Une vue réalisant cette jointure étant la solution adhoc".
Looping est un excellent logiciel, mais fait pour modéliser les données, pas pour créer des vues, c'est une tache différente à réaliser en dehors de tout logiciel de modélisation, mais qui est très simple à faire

Désolé pour l'utilisation excessive de "répondre avec citation ".

Pour le cas d'un responsable, je comprend votre explication mais j'ai dû mal à comprendre ce que contiendra l'entité-type responsable si elle ne contient pas d'attributs.

Avez vous un exemple explicite impliquant un membre et un responsable pour visualiser comment seront les entités personne, membre et responsable ?

Oui je voulais dire 6 en tout Désolé.

Pour la jointure , cela se fait avec quel moment ? Lors de la conception logique donc sql ?

Bonjour,

Pour mieux illustrer le résultat, j'ai ajouté l'attribut "RP_date" (date de nomination comme responsable) dans l'entité-type RP_responsable et laissé le matricule "MB_matricule" dans l'entité-type MB_membre
Ainsi on a les attributs communs dans le sur-type et un attribut spécifique dans chaque sous-type.

Voici le script de création du jeu d'essai dans les tables :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

insert into PE_personne(PE_nom, PE_prenom, PE_ddn) values ('Martin', 'Louise', '1998-05-22') , ('Abbadie', 'Remi', '1984-11-05') , ('Lesage', 'Marthe', '1962-06-14') , ('Da Silva', 'Pedro', '1985-01-28') , ('Bogdanov', 'Sergeï', '1971-05-30') ; insert into MB_membre(PE_ident, MB_matricule) values (1, 'A01555') , (2, 'A01620') , (4, 'B49901') , (5, 'A63500') ; insert into RP_responsable(PE_ident, RP_date) values (1, '2019-04-10') , (3, '2020-12-15') ;

---

Je crée ensuite ma vue qui réalise les jointures requises. Bien entendu, il faut utiliser des jointures externes (OUTER JOIN), puisque la présence de l'un ou l'autre sous-type est facultative :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

create view V1 as select PE.PE_ident as ident , PE.PE_nom as nom , PE.PE_prenom as prenom , PE.PE_ddn as date_nais , MB.MB_matricule as matricule , RP.RP_date as date_nomination from PE_personne PE left join MB_membre MB on MB.PE_ident=PE.PE_ident left join RP_responsable RP on RP.PE_ident=PE.PE_ident ;

---

Enfin, j'utilise ma vue dans mon traitement pour récupérer les informations :

Code:

---

select * from V1;

---

Et j'obtiens :

ident	nom	prenom	date_nais	matricule	date_nomination
1	Martin	Louise	1998-05-22	A01555	2019-04-10
2	Abbadie	Remi	1984-11-05	A01620	null
3	Lesage	Marthe	1962-06-14	null	2020-12-15
4	Da Silva	Pedro	1985-01-28	B49901	null
5	Bogdanov	Sergeï	1971-05-30	A63500	null

Selon le besoin, j'ajoute les restrictions (WHERE), les tris (ORDER BY) et autres clauses requises à mon traitement en utilisant cette vue.
Pour rappel : il est fortement recommandé de ne jamais utiliser directement les tables dans les traitements, mais systématiquement les vues, afin de garantir l'indépendance des traitements vis à vis des données ;)

Bonjour,

Merci pour vos explications toujours precises et claires.
Votre exemple est tres clair.

Je comprend mieux. Dans votre exemple, Martin est a la membre et responsable. cela serait-ce plus pertinent que toutes les personnes fassent partie de l'entite-type PE_Personne et ensuite elles soient reparties soient dans ME_Membre ( donc avec un matricule) OU dans RP_Responsable ( donc avec une date de nomination) ? cela pourrait permettre d'avoir une organisation simplifié avec les attributs commun dans PE_Personne et l'attribut spécifique si c'est un membre ou un responsable .

Si j'ai bien compris votre jointure, elle permet de relier l'entite-types PE_Personne a RP_Responsable et MB_Membre en utilisant l'Identifiant PE_Ident(cle primaire dans l'entite PE_Personne et cle etrangere dans les entites-types RP_Responsable et MB_Membre) ?

Concernant la modelisation , j'ai modifie
- vous m'avez dis que Staff designait un groupe et non une personne. J'ai choisi Manager ca correspond mieux ? si non avez-vous une suggestion en anglais ?
- l'adresse courriel en varchar(255)
- ajouter les 4 champs varchar(38) avec un total de 6 pour l'adresse conforme au systeme de la poste
- j'ai modifie le numero de telephone en varchar(10) pour qu'il soit adapte au futur evolutions
- j'ai ajoute date de nomination dans la table RP_Responsable


Si j'ai bien suivi, il reste a faire les vues pour les autres jointures ?

j'ai essaye de faire la vue Parking permettant d'afficher les parkings avec les informations (incluant la ville et l'ID du Client).
je voulais indiquer uniquement les US_ID des clients donc j'ai indique l'entite client et non Users car elle contient les clients ET les managars alors que je souhaite uniquement les client c'est bon comme ca ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

create view VueParking as select PA.PA_ID as id, PA.PA_Length as length, PA.PA_Width as width, PA.PA_Height as height, PA.PA_GeoGPS as GeoGPS, PA.PA_Address1 as adress1, PA.PA_Address2 as adress2, PA.PA_Address3 as adress3, PA.PA_Address4 as adress4, PA.PA_Address5 as adress5, PA.PA_Address6 as adress6, PA.PA_Access as access, CI.CI_ID as ci_id, CL.US_ID as us_id, from PA_Parking PA   left join CL_Client CL on CL.US_ID=US.US_ID left join CI_City CI on CI.CI_ID;

---

Si je comprend bien pour mon projet je pourrais utiliser la MCD et le Diagramme UML pour illustrer les entites-types , attributs et associations ?
les jointures comme celle que vous avez realiser seront a faire lors de la conception logique ( incluant la création des tables et vues a partir du MCD) ?

Je vais devoir répondre a un besoin (que j'ai oublie de préciser) qui est d'inclure une fonctionnalité d'affichage des parkings disponibles a l'échange / location sur une carte Google Map . Puis-je anticiper et prendre en compte cette fonctionnalité en ajoutant une autre entité-type ? l'entité-type Parking peut servir a répondre a ce besoin car elle contient , me semble-t-il, tous les informations nécessaire ?

Pouvez-vous vérifier que tout semble cohérent sur ma MCD par rapport a la demande initiale du projet ( location/échange parkings entre particuliers avec réservation) par aux règles de gestion , s'il vous plait ?
j'ai mis en pièce jointe le MCD et les règles de gestions.

Avec quel outil avez-vous pu simuler le test que vous avez réalisé avec le script de jeu d'essai, vue et résultat sous forme de tableau?


Merci a vous

Pièce jointe 596523Pièce jointe 596524

Bonsoir NarumiN

Citation:

---

Envoyé par NarumiN

Merci pour vos explications toujours precises et claires.

---

Merci à vous, n'hésitez pas à encourager les intervenants qui vous donnent des bons conseils en votant favorablement pour les réponses pertinentes ;)

Citation:

---

Envoyé par NarumiN

Je comprend mieux. Dans votre exemple, Martin est a la fois membre et responsable. cela serait-ce plus pertinent que toutes les personnes fassent partie de l'entite-type PE_Personne et ensuite elles soient reparties soient dans ME_Membre (donc avec un matricule) OU dans RP_Responsable (donc avec une date de nomination) ? cela pourrait permettre d'avoir une organisation simplifié avec les attributs commun dans PE_Personne et l'attribut spécifique si c'est un membre ou un responsable .

---

Ce serait peut-être plus simple, mais ce qui est important, non, fondamental, c'est que la modélisation corresponde aux règles de gestion.
Si, dans la vraie vie de votre organisation, certaines personnes sont membres seulement, d'autres responsables seulement et d'autres encore membres et responsables, alors l'héritage est de type "T" (totalité) tel que je l'ai modélisé. Il ne faut pas faire des entorses aux règles de gestion lors de la modélisation sous prétexte de simplifier. Car si ça ne correspond pas à la réalité, ça vous mènera à une impasse.

Citation:

---

Envoyé par NarumiN

Si j'ai bien compris votre jointure, elle permet de relier l'entite-type PE_Personne a RP_Responsable et MB_Membre en utilisant l'Identifiant PE_Ident(cle primaire dans l'entite PE_Personne et cle etrangere dans les entites-types RP_Responsable et MB_Membre) ?

---

Exactement :)

Citation:

---

Envoyé par NarumiN

Concernant la modelisation , j'ai modifie
- vous m'avez dis que Staff designait un groupe et non une personne. J'ai choisi Manager ca correspond mieux ? si non avez-vous une suggestion en anglais ?
- l'adresse courriel en varchar(255)
- ajouter les 4 champs varchar(38) avec un total de 6 pour l'adresse conforme au systeme de la poste
- j'ai modifie le numero de telephone en varchar(10) pour qu'il soit adapte au futur evolutions
- j'ai ajoute date de nomination dans la table RP_Responsable

---

Va pour "manager" mais le mieux est de demander à la maîtrise d'ouvrage, les responsables métier, quel est le terme utilisé
OK pour les adresses, à la réserve près du terme "champ" inadapté dans ce contexte, il s'agit d'attributs ou de rubriques d'un type d'entité du MCD ou de colonnes d'une table ;)
Pour le téléphone, 10 caractères suffisent si toutes les personnes ont un n° en France, sinon, ça peut se révéler insuffisant.
Pour la date de nomination, ok, mais ce n'est qu'un exemple d'attribut que j'avais ajouté, à ne conserver que s'il est utile à votre gestion

Citation:

---

Envoyé par NarumiN

Si j'ai bien suivi, il reste a faire les vues pour les autres jointures ?

---

Une vue n'est pas forcément une jointure, le plus souvent, une vue est une projection des colonnes d'une seule table et elle permet de rendre les traitements indépendants des données en ne les exposant pas aux aléas liés aux modification des structures. Plus haut, j'ai créé une vue avec jointure parce qu'il y a avait un besoin en ce sens. C'est le recensement des accès les plus fréquents qui permettra de déterminer quelles sont les vues à créer.
Au stade conceptuel, c'est un peu prématuré.

Citation:

---

Envoyé par NarumiN

j'ai essaye de faire la vue Parking permettant d'afficher les parkings avec les informations (incluant la ville et l'ID du Client).
je voulais indiquer uniquement les US_ID des clients donc j'ai indique l'entite client et non Users car elle contient les clients ET les managars alors que je souhaite uniquement les client c'est bon comme ca ?

---

Le type d'entité "Client" n'avait pas été abordé jusqu'ici (à moins que vous l'ayez ajouté dans votre modèle looping que je n'ai pas encore regardé) du coup je ne peux pas me prononcer.
Quoi qu'il en soit, les vues pourront être abordées plus tard, quand le modèle conceptuel sera stabilisé ;)

Citation:

---

Envoyé par NarumiN

Je vais devoir répondre a un besoin (que j'ai oublie de préciser) qui est d'inclure une fonctionnalité d'affichage des parkings disponibles a l’échange / location sur une carte Google Map . Puis-je anticiper et prendre en compte cette fonctionnalite en ajoutant une autre entite-type ? l'entite-type Parking peut servir a répondre a ce besoin car elle contient , me semble-t-il, tous les informations nécessaires ?

---

Le modèle conceptuel des données (MCD) ne doit en aucun cas être modifié en fonction des traitements. L'affichage est du ressort des traitements. Cette préoccupation est donc prématurée à ce stade.

Citation:

---

Envoyé par NarumiN

Avec quel outil avez-vous pu simuler le test que vous avez realise avec le script de jeu d'essai, vue et resultat sous forme de tableau?

---

Il y a des outils gratuits qui permettent de tester les ordres SQL.
J'utilise souvent DB fiddle qui propose de nombreux SGBD et dont l'ergonomie est assez simple.
Voyez ici : https://dbfiddle.uk/

Bonjour,

Citation:

---

Envoyé par escartefigue

Ce serait peut-être plus simple, mais ce qui est important, non, fondamental, c'est que la modélisation corresponde aux règles de gestion.
Si, dans la vraie vie de votre organisation, certaines personnes sont membres seulement, d'autres responsables seulement et d'autres encore membres et responsables, alors l'héritage est de type "T" (totalité) tel que je l'ai modélisé. Il ne faut pas faire des entorses aux règles de gestion lors de la modélisation sous prétexte de simplifier. Car si ça ne correspond pas à la réalité, ça vous mènera à une impasse.

---

Desole je me suis mal exprime. Ce que je souhaite faire c'est que chaque inscrit fasse obligatoirement partie de l'entite-type US_Users (PE_Personne dans votre MCD) et ensuite il fasse partie de l'entite-type CL_Client ( dans votre MCD c'est MB_Membre) OU de l'entite-type MA_Manager (RP_Responsable dans votre MCD).
Ce qui donnera :

- Des Users ( Personne dans votre MCD) :
- des Clients (Membres) qui se serviront de la plateforme pour acceder aux services
- Des Managers ( Responsables) qui seront la moderer la plateforme.

Faut que j'ajoute une nouvelle regle de gestion car pour moi c'etait evident mais je ne l'avais pas mis dans mes regles de gestion :
UCM0001 : Un User (Personne) doit etre obligatoirement un Client (Membre) ou un Manager (Responsable).

la regle est-elle coherente ?

avec l'ajout de cette nouvelle regle de gestion, les regles suivantes sont toujours necessaire :
UM0006 : Chaque User peut etre un Manager
MU0006 : Chaque manager doit être un User de la plateforme
UC0006 : Chaque User peut etre un client
CU0006 : Chaque client doit être un User de la plateforme

L'heritage de Type "T" reste-t-il conforme a ma regle de gestion ?

Citation:

---

Envoyé par escartefigue

Va pour "manager" mais le mieux est de demander à la maîtrise d'ouvrage, les responsables métier, quel est le terme utilisé
OK pour les adresses, à la réserve près du terme "champ" inadapté dans ce contexte, il s'agit d'attributs ou de rubriques d'un type d'entité du MCD ou de colonnes d'une table
Pour le téléphone, 10 caractères suffisent si toutes les personnes ont un n° en France, sinon, ça peut se révéler insuffisant.
Pour la date de nomination, ok, mais ce n'est qu'un exemple d'attribut que j'avais ajouté, à ne conserver que s'il est utile à votre gestion

---

Dans ce projet universitaire, je n'ai pas de maitrise d'ouvrage, responsable metier reel, c'est a moi de simuler cela, faire les choix et les expliquer ^^
oui ce n'est pas champ mais bien attributs dans un type d'entite du MCD ca va finir par rentrer ^^
oui ca sera en France pour le telephone.
Pour la date de nomination, je pense la garder pour connaitre la promotion exacte d'un User( Personne) . Admettons que l'on retire cet attribut Date de nomination de l'entite-type MA_Manager (RP_Responsable), la vue V1 que vous avez cree precedemment elle pourrait par exemple toujours afficher uniquement les responsables (manager) ?

Citation:

---

Envoyé par escartefigue

Le type d'entité "Client" n'avait pas été abordé jusqu'ici (à moins que vous l'ayez ajouté dans votre modèle looping que je n'ai pas encore regardé) du coup je ne peux pas me prononcer.
Quoi qu'il en soit, les vues pourront être abordées plus tard, quand le modèle conceptuel sera stabilisé

---

Client correspond Membre de votre MCD
En faite sur mon modele Looping, j'ai repris le votre et j'ai renomme les entités-types par leur équivalent anglais :

- PE_Personne ---> US_User
- RP_Responsable ---> MA_Manager
- MB_Membre ---> CL_Client
- AN_Annonce ---> AD_Advertisement.

Pour une meilleure compréhension, nous pouvons continuer a travailler sur la version française ca sera plus simple.

Merci a vous, j'ai notifie vos réponses qui m'ont beaucoup aide.

Bonsoir NarumiN

Citation:

---

Envoyé par NarumiN

Desole je me suis mal exprime. Ce que je souhaite faire c'est que chaque inscrit fasse obligatoirement partie de l'entite-type US_Users (PE_Personne dans votre MCD) et ensuite il fasse partie de l'entite-type CL_Client ( dans votre MCD c'est MB_Membre) OU de l'entite-type MA_Manager (RP_Responsable dans votre MCD).
[. . .]
L'heritage de Type "T" reste-t-il conforme a ma règle de gestion ?

---

Il s'agit d'un OU inclusif (l'un l'autre ou les deux), donc oui, l'héritage par totalité (T) est conforme aux règles de gestion.
Si les USERS étaient soit CLIENT soit MANAGER mais jamais les deux, alors il s'agirait d'une partition notée (XT)

Citation:

---

Envoyé par NarumiN

Pour la date de nomination, je pense la garder pour connaitre la promotion exacte d'un User(Personne) . Admettons que l'on retire cet attribut Date de nomination de l'entite-type MA_Manager (RP_Responsable), la vue V1 que vous avez créée precédemment elle pourrait par exemple toujours afficher uniquement les responsables (manager) ?

---

La vue n'affiche rien, elle fait une requête de sélection, autrement dit une projection. L'affichage reste du ressort du traitement ;)
Ce détail sémantique mis à part, la vue que j'ai proposée restitue tous les éléments des USERS quoi qu'il arrive, et d'une part, si présents, les attributs spécifiques aux MANAGERS, et d'autre part, si présents, les attributs spécifiques aux CLIENTS.
Si vous avez besoin d'une vue qui ne restitue que les personnes de type MANAGER, alors il faut créer une autre vue dans laquelle la jointure entre USER et MANAGER sera de type interne (INNER JOIN), ce faisant, seuls les MANAGERS seront restitués (avec les attributs communs à toutes les personnes et ceux spécifiques aux managers, s'il y en a bien sûr ;))

Citation:

---

Envoyé par NarumiN

En faite sur mon modele Looping, j'ai repris le votre et j'ai renomme les entités-types par leur équivalent anglais :
- PE_Personne ---> US_User
- RP_Responsable ---> MA_Manager
- MB_Membre ---> CL_Client
- AN_Annonce ---> AD_Advertisement.
Pour une meilleure compréhension, nous pouvons continuer a travailler sur la version française ca sera plus simple.

---

OK, simple traduction, du coup ça reste facile à comprendre ;)

Citation:

---

Envoyé par NarumiN

Merci a vous, j'ai notifie vos réponses qui m'ont beaucoup aide.

---

:merci:

Bonjour,

Merci pour les explications. Je me suis rendu qu'un Manager pouvait aussi être Client sur la plateforme. Ce qui justifie l'emploi du OU inclusif.

Je voulais savoir si cette règle de gestion "UCM0001 : Un User (Personne) doit être obligatoirement un Client (Membre) ou un Manager (Responsable). " pouvait remplacer les suivantes :
UM0006 : Chaque User peut être un Manager
MU0006 : Chaque manager doit être un User de la plateforme
UC0006 : Chaque User peut être un client
CU0006 : Chaque client doit être un User de la plateforme

Dans le MCD :
- Cela devrait être 1,1 et non 0,N entre Modérer (Moderate) et AN_Annonce (AD_Advertisement)?
- la flèche allant de PA_Parking vers MB_Membre ( CL_Client) ne devrait pas être dans l'autre sens ?
- J'ai pas compris pourquoi l'association "RS_Reserver" (RE_Reserver) est entre MB_Membre (CL_Client) et PA_Parking et non entre MB_Membre (CL_Client) et AN_Annonce (AD_Advertisement) ? On est censé reservé un parking sur annonce et la on reserve sur l'entité type PA_Parking ?


Désolé pour toutes les questions, j'essaye de bien comprendre ^^ merci à vous.

Les règles de gestion sont équivalentes, ce qui n'est pas clair, c'est la possibilité d'être à la fois CLIENT et MANAGER.
C'est pourquoi je propose de reformuler ainsi :

UCM0001 : un User (Personne) doit être obligatoirement un Client (Membre), un Manager (Responsable) ou les deux à la fois.

Citation:

---

Cela devrait être 1,1 et non 0,N entre Modérer (Moderate) et AN_Annonce (AD_Advertisement)?

---

0,n me semble correct : toute annonce n'est pas obligatoirement modérée (d'où le zéro mini) et une même annonce peut être modérée plusieurs fois si un administrateur se rend compte après une première intervention qu'une autre chose qui lui avait échappé ne convient pas (d'où le n maxi).

Citation:

---

la flèche allant de PA_Parking vers MB_Membre ( CL_Client) ne devrait pas être dans l'autre sens ?

---

non : cette flèche matérialise le fait qu'un parking (PA) à une date donnée (CA) ne peut être réservé (RS) que par un seul membre/client (MB).

Citation:

---

J'ai pas compris pourquoi l'association "RS_Reserver" (RE_Reserver) est entre MB_Membre (CL_Client) et PA_Parking et non entre MB_Membre (CL_Client) et AN_Annonce (AD_Advertisement) ? On est censé reservé un parking sur annonce et la on reserve sur l'entité type PA_Parking ?

---

Parcequ'on ne réserve pas une annonce, mais bien un parking.
Seuls les parkings pour lesquels une annonce est publiée seront proposés à la réservation

Merci pour les précisions.
C'est beaucoup plus clair.
Concernant la modélisation de la gestion des parkings, les 3 représentations possibles fournis par Looping se nomment bien :
- la première E/A (Entité / association) porte le nom de "Modélisation Entité/Association" ?
- la représentation UML représente "Le Diagramme des classes " (modélisation des classes) ?
- Le "Modèle logique des données" (MLD) , c'est bien la modélisation de la base de données ?
c'est bien ça ?

Nous avons utilisé le méthode UML si je ne me trompe pas.

Pensez-vous que mes règles de gestion sont bien cohérentes et en adéquation avec ma modélisation ?

CP0001 : Chaque client peut avoir un ou plusieurs parkings
PC0001 : Chaque parking appartient à un seul client
AC0001 : Chaque annonce doit être publiée par le client proprietaire du parking
AC0002 : Chaque annonce peut être publiée par un seul client
CA0002 : Chaque client peut publier plusieurs annonces
PA0003 : Chaque parking peut être présent dans plusieurs annonces
AP0003 : chaque annonce peut contenir une seul parking
CR0003 : Chaque client peut effectuer plusieurs reservations
RC0004 : Chaque reservation est effectuée par un seul client unique
MA0005 : Chaque manager peut modérer une ou plusieurs annonces
AM0005 : Chaque annonce peut être modéré par plusieurs managers
UCM0001 : un User (Personne) doit être obligatoirement un Client (Membre), un Manager (Responsable) ou les deux à la fois.



Cette règle de gestion " AC0002 : Chaque annonce peut être publiée par un seul client" est-elle pertinente ?


A quel endroit avez-vous pu definir les contraintes publier et posseder ?

ALTER TABLE AN_annonce
ADD CONSTRAINT FK_publier_posseder
FOREIGN KEY (PE_ident, PA_ident)
REFERENCES PA_parking(PE_ident, PA_ident)
;



Pensez-vous ma modélisation est stabilisé et que je peut passer à la phase suivante c'est à dire les vues ( si je ne trompe pas ) ?




Merci beaucoup.

P.S : Puis-je utiliser Looping pour refaire mes diagrammes de cas d'utilisations ?

Bonjour,

Citation:

---

Envoyé par NarumiN

P.S : Puis-je utiliser Looping pour refaire mes diagrammes de cas d'utilisations ?

---

Looping est avant tout un outil de modélisation conceptuelle de données et propose donc la réalisation de schémas Entité-Association et de Diagrammes de Classes UML (et génère ensuite les MLD et le SQL pour les schémas relationnels).
Les outils graphiques qu'il propose permettent de réaliser d'autres types de diagrammes (je m'en sers personnellement en cours pour les modèles de flux) en gérant les liens et connexions entre objets, mais hormis pour la modélisation des données, il n'apporte pas grand chose de plus par rapport à bon nombre d'outils graphiques du marché.

Pour ce qui concerne la cohérences des règles et du modèle conceptuel

Citation:

---

Envoyé par NarumiN

CP0001 : Chaque client peut avoir un ou plusieurs parkings

---

Le MCD mentionne 0,n et vous écrivez à la fois "peut" (qui suggère zéro possible) mais aussi "un ou plusieurs", qui a raison ?

Citation:

---

Envoyé par NarumiN

PC0001 : chaque parking appartient à un seul client
AC0001 : chaque annonce doit être publiée par le client propriétaire du parking
CA0002 : chaque client peut publier plusieurs annonces
PA0003 : chaque parking peut être présent dans plusieurs annonces
MA0005 : chaque manager peut modérer une ou plusieurs annonces
AM0005 : chaque annonce peut être modérée par plusieurs managers
UCM0001 : un User (Personne) doit être obligatoirement un Client (Membre), un Manager (Responsable) ou les deux à la fois.

---

Ce paquet de règles est correct (j'ai supprimé les majuscules après les deux points, ce n'est pas l'usage en français, sauf s'il s'agit d'un nom propre ou d'un sigle ;))

Citation:

---

Envoyé par NarumiN

AC0002 : chaque annonce peut être publiée par un seul client

---

Mal formulé : "peut" rend la présence facultative (0,1), or, une annonce doit être publiée par un seul client, ce qui donne
AC0002 : chaque annonce est publiée par un et un seul client

Citation:

---

Envoyé par NarumiN

AP0003 : chaque annonce peut contenir une seul parking

---

Mal formulé : "contenir" est moins approprié que "concerner". De plus, c'est "concerner" qui est utilisé dans le MCD, avoir le même verbe dans le MCD que dans les règles facilite la compréhension. De plus, la aussi, "peut" est inadéquat. Ce qui donne
AP0003 : chaque annonce concerne un et un seul parking

Citation:

---

Envoyé par NarumiN

CR0003 : chaque client peut effectuer plusieurs réservations
RC0004 : chaque réservation est effectuée par un seul client unique

---

C'est plus clair quand les règles de gestion mentionnent tous les objets de gestion de l'association et l'association elle-même .
Ici les objets de gestion sont "client" que vous avez mentionné "parking" que vous avez oublié et "date (calendrier)" que vous avez aussi oublié
l'association est "réserver"
"un seul" et "unique" sont un pléonasme, j'enlève donc "unique" de RC0004
Ce qui donne
CR0003 : chaque client peut réserver plusieurs Parkings
RC0004 : chaque réservation est effectuée par un seul client
xx000n : un parking, à une date donnée, ne peut être réservé que par au plus un client

Citation:

---

Envoyé par NarumiN

cette règle de gestion " AC0002 : chaque annonce peut être publiée par un seul client" est-elle pertinente ?

---

Ici nous sommes dans le cadre d'un exercice non contraint, puisque vous n'avez pas de MOA, mais c'est très vraisemblable, je laisserai donc cette règle en l'état.

Citation:

---

Envoyé par NarumiN

Pensez-vous ma modélisation est stabilisé et que je peut passer à la phase suivante c'est à dire les vues (si je ne trompe pas) ?

---

Oui, ce modèle répond aux règles établies, par contre, la création des vues est un peu prématurée.
En principe, avec ce modèle, on dérive le script SQL de création des tables (après avoir choisi le SGBD). Ce script est généré automatiquement par la plupart des logiciels de modélisation. C'est le cas de looping.
Ensuite, il faut créer les index pour les critères de recherche (exemple : recherche par nom de personne, par nom de ville, par département...)
Quand c'est fait, on se crée un jeu de données avec suffisamment de volume (quelques centaines de milliers de lignes) pour tester les requêtes principales en qualité de résultat et en performances.
Une fois que tout ça est au point, on peut encapsuler les requêtes dans des vues :)

Citation:

---

Envoyé par escartefigue

Pour ce qui concerne la cohérences des règles et du modèle conceptuel


Le MCD mentionne 0,n et vous écrivez à la fois "peut" (qui suggère zéro possible) mais aussi "un ou plusieurs", qui a raison ?

---

Je voulais dire 0,n mais je ne sais pas comment le formuler "un client peut avoir un ou plusieurs parkings ou aucun parking".

Citation:

---

Envoyé par escartefigue

Ce paquet de règles est correct (j'ai supprimé les majuscules après les deux points, ce n'est pas l'usage en français, sauf s'il s'agit d'un nom propre ou d'un sigle ;))

---

Merci pour cette correction.

J'ai mis au propre les règles de gestions en utilisant vos conseils et suggestions.
CODE Règle de gestion
CP0001 chaque client peut avoir un ou plusieurs parkings.
PC0002 chaque parking appartient à un seul client.
AC0003 chaque annonce doit être publiée par le client propriétaire du parking.
AC0004 chaque annonce est publiée par un et un seul client.
CA0005 chaque client peut publier plusieurs annonces.
PA0006 chaque parking peut être présent dans plusieurs annonces.
AP0007 chaque annonce concerne un et un seul parking.
CR0008 chaque client peut réserver plusieurs parkings.
RC0009 chaque réservation est effectuée par un seul client.
PDC0010 un parking, à une date donnée, ne peut être réservé que par au plus un client.
MA0011 chaque manager peut modérer une ou plusieurs annonces.
AM0012 chaque annonce peut être modéré par plusieurs managers.
UCM0013 un utilisateur (User)doit être obligatoirement un Client, un Manager ou les deux à la fois.


A quel endroit avez-vous pu definir les contraintes publier et posseder ?

ALTER TABLE AN_annonce
ADD CONSTRAINT FK_publier_posseder
FOREIGN KEY (PE_ident, PA_ident)
REFERENCES PA_parking(PE_ident, PA_ident)
;

Citation:

---

Envoyé par escartefigue

Oui, ce modèle répond aux règles établies, par contre, la création des vues est un peu prématuré.
En principe, avec ce modèle, on dérive le script SQL de création des tables (après avoir choisi le SGBD). Ce script est généré automatiquement par la plupart des logiciels de modélisation. C'est le cas de looping.
Ensuite, il faut créer les index pour les critères de recherche (exemple : recherche par nom de personne, par nom de ville, par département...)
Quand c'est fait, on se crée un jeu de données avec suffisamment de volume (quelques centaines de milliers de lignes) pour tester les requêtes principales en qualité de résultat et en performances.
Une fois que tout ça est au point, on peut encapsuler les requêtes dans des vues :)

---

Pour le choix du SGBD, il m'est demande de choisir une base de données relationnelles et de justifier mon choix. Sur quels critères, puis-je faire mon choix ? MySQL Server ou MariaDB ? Avez-vous des suggestions ? Le projet doit être fait en Java EE .

Concernant la fonctionnalité "affichage sur une carte Google Map des parkings disponibles" il m'est demande choisir une Base de données Nosql et justifier mon choix.

Merci a vous.

Citation:

---

Envoyé par Paprick

Bonjour,

Looping est avant tout un outil de modélisation conceptuelle de données et propose donc la réalisation de schémas Entité-Association et de Diagrammes de Classes UML (et génère ensuite les MLD et le SQL pour les schémas relationnels).
Les outils graphiques qu'il propose permettent de réaliser d'autres types de diagrammes (je m'en sers personnellement en cours pour les modèles de flux) en gérant les liens et connexions entre objets, mais hormis pour la modélisation des données, il n'apporte pas grand chose de plus par rapport à bon nombre d'outils graphiques du marché.

---

Bonjour,

Merci a vous pour vos explications et votre logiciel.

Bonjour,

Citation:

---

Envoyé par NarumiN

Je voulais dire 0,n mais je ne sais pas comment le formuler "un client peut avoir un ou plusieurs parkings ou aucun parking".

---

Tout simplement "un client peut avoir zéro à plusieurs parkings"

Citation:

---

Envoyé par NarumiN

J'ai mis au propre les règles de gestions en utilisant vos conseils et suggestions.
CODE Règle de gestion
CP0001 chaque client peut avoir un ouzéro à plusieurs parkings.

---

OK pour le reste :)

Citation:

---

Envoyé par NarumiN

A quel endroit avez-vous pu definir les contraintes publier et posseder ?

---

En utilisant l'outil règle de Looping, cet outil permet de saisir du script que l'on choisit de positionner avant ou après le script généré par Looping.
On choisit également d'afficher ou pas le script dans le modèle.

Citation:

---

Envoyé par NarumiN

Pour le choix du SGBD, il m'est demande de choisir une base de données relationnelles et de justifier mon choix. Sur quels critères, puis-je faire mon choix ? MySQL Server ou MariaDB ? Avez-vous des suggestions ? Le projet doit être fait en Java EE.

---

N'importe quel SGBD-R peut faire l'affaire, mais, j'éliminerai les SGBD suivants
- toutes les éditions payantes qui ne vous apporteront rien pour un projet personnel (donc exit Oracle, DB2 et les versions payantes de SQL server)
- MS Access trop rudimentaire
- SQLite dont la vocation mono-utilisateur n'est pas idéale pour apprendre les transactions et la gestion des accès concurrents (si toutefois vous allez jusque là)
- dans une moindre mesure MySQL, qui est une assez mauvaise école car il déroge souvent à la norme SQL et nombreux développeurs qui commencent avec MySQL font ensuite des erreurs liées à cet apprentissage
Du coup je m'orienterai vers SQL-server express edition (gratuite) ou PostGreSQL, ou à la rigueur, MySQL à condition de prendre la V8 (les versions précédentes sont trop limitées fonctionnellement) et à condition de ne pas modéliser les données avec l'interface graphique WorkBench, là aussi, source de modèles bancals (car modélisation directement au niveau MLD).

Citation:

---

Envoyé par NarumiN

Concernant la fonctionnalité "affichage sur une carte Google Map des parkings disponibles" il m'est demande choisir une Base de données Nosql et justifier mon choix.

---

Je ne vois aucun intérêt à choisir une base NoSQL dans ce contexte
cf. cette discussion :
https://www.developpez.net/forums/d2.../#post11716360

Bonjour,

Pour les règles de gestions , j'ai pris en compte votre remarque sur la règle de gestion.

CODE Règle de gestion
CP0001 un client peut avoir zéro à plusieurs parkings.
PC0002 chaque parking appartient à un seul client.
AC0003 chaque annonce doit être publiée par le client propriétaire du parking.
AC0004 chaque annonce est publiée par un et un seul client.
CA0005 chaque client peut publier plusieurs annonces.
PA0006 chaque parking peut être présent dans plusieurs annonces.
AP0007 chaque annonce concerne un et un seul parking.
CR0008 chaque client peut réserver plusieurs parkings.
RC0009 chaque réservation est effectuée par un seul client.
PDC0010 un parking, à une date donnée, ne peut être réservé que par au plus un client.
MA0011 chaque manager peut modérer une ou plusieurs annonces.
AM0012 chaque annonce peut être modéré par plusieurs managers.
UCM0013 un utilisateur (User)doit être obligatoirement un Client, un Manager ou les deux à la fois.


J'ai modifié la contrainte pour qu'elle corresponde aux nouvelles entités-types en anglais:
ALTER TABLE AD_Advertisement
ADD CONSTRAINT FK_publish_own
FOREIGN KEY (US_ID, PA_ID)
REFERENCES PA_parking(US_ID, PA_ID)
;


J'ai oublié de préciser que mon projet (site web / application mobile) doit être réalisé avec Java EE et le tout doit virtualiser ou en docker , je dois aussi utiliser des outils devOPS tels que Jenkins et GitHub
De préférence, je préfère travailler sous linux donc je pense utiliser docker. Dans vos choix, PostgreSQL semble multiplateforme et respectant la norme SQL au mieux. est-ce un bon choix pour un projet web (Java EE) ?


Vous m'avez déconseille sqllite mais pour l'application mobile , une base sqlite est demandé pour "pour gérer la configuration minimum (avatar, langue,rayon*** ...) de l’ihm"

C'est obligatoire :
la fonctionnalité 2 :
- "Un membre de l’application pourra en temps réel voir les parkings disponibles en fonction de sa position GPS et du créneau horaire.
Une demande d’autorisation pourra alors être envoyée par le biais de l’application au propriétaire du parking choisi utilisera un base No SQL/ big data, pour des raisons de rapidité et d’espérance du nombre de parkings importants à gérer dans le futur"

- "Vous réaliserez cette base avec l’outil de votre choix, elle pourra être dans le cloud comme avec la plateforme Firebase, ou non"

- "L’affichage des parkings sur une Google map en fonction de la position GPS courante... en fonction d’un ***rayon défini dans la base sqlite.."

- "Il vous sera possible d’utiliser un ORM et/ou un ODM, mobile first ou database first"

- "Des tests en montée en charge sont demandés: vous proposerez donc une solution open source...et présenterez les résultats."

- "Des tests de sécurité applicative et base de données devront être réalisés... Pour cela de nombreux outils comme monkeys, easyqa,..existent."

- "Vous utiliserez un outil type«javadoc»pour générer automatiquement la documentation."





J'ai repris à zéro mes cas d'utilisations : je viens de faire la description textuelle des différents cas d'utilisations.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212

Documentation des cas d'utilisation : Description textuelle ========================================================= Cas d’utilisation : S’authentifier Acteurs : Managers et Clients. Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe. Précondition : L’acteur doit être présent dans la base de données. Postcondition : - Acteur authentifié. - La page d’accueil s’affiche. Scénario nominal : 1. L’acteur ouvre l’application, 2. Le système affiche la page d’authentification, 3. L’acteur saisit le login et le mot de passe, 4. Le système vérifie l’existence des données, 5. Le système affiche la page d’accueil. Scénario alternatif : 1A. Erreur d’authentification : login ou mot de passe non valide. Cet enchaînement démarre au point 4. 1B. Le système affiche un message d’erreur. Le scénario reprend au point 2. 2. Champs obligatoires vides. Cet enchaînement démarre au point 4. Le scénario reprend au point 2. ========================================================== Cas d’utilisation : Ajouter un parking Acteurs : Client Objectif : Il permet au client de parc d’ajouter un parking dans son profil. Précondition : Succès d’authentification. Postcondition : Parking ajouté. Scénario nominal : 1. Le client choisit d’afficher son profil utilisateur. 2. Le système affiche le profil utilisateur, 3. Le client choisit l’ajout d’un nouveau parking, 4. Le système affiche le formulaire à remplir, 5. Le client saisit les informations à remplir sur le nouveau parking, 6. Le système vérifie les données, 7. Le système enregistre le parking dans la base de données. Scénario alternatif : 1. Champs obligatoires non valides ou vides. Cet enchaînement démarre au point 6. 2. Le système affiche un message d’erreur. Le scénario reprend au point 4.   ============================================================ Cas d’utilisation : Modifier un parking Acteurs : Client Objectif : Il permet au client de modifier les informations de son parking. Précondition : - Succès d’authentification. - Succès de consultation de la liste de ses parkings. Postcondition : Parking modifié. Scénario nominal : 1. Le client choisit d’affiche la « Liste de mes parkings », 2. Le système affiche la liste, 3. Le client choisit la modification des informations d’un parking, 4. Le système affiche le formulaire de modification, 5. Le client modifie les informations du parking, 6. Le système demande la validation des modifications, 7. Le client valide les modifications, 8. Le système vérifie les données, 9. Le système enregistre les modifications dans la base de données. Scénario alternatif : 1. Champs obligatoires non valides ou vides. Cet enchaînement démarre au point 8. 2. Le système affiche un message d’erreur. Le scénario reprend au point 4.   =========================================================== Cas d’utilisation : Supprimer un parking Acteurs : Client Objectif : Il permet au client de supprimer son/ses parkings de son profil utilisateur. Précondition : - Succès d’authentification. - Succès de consultation de la liste de ses parkings. Postcondition : Parking supprimé. Scénario nominal : 1. Le client choisit d’afficher la « Liste de mes parkings », 2. Le système affiche la liste, 3. Le client choisit la suppression d’un parking, 4. Le système demande la validation de la suppression, 5. Le client valide la suppression, 6. Le système procède à la suppression du parking de la base de données. Scénario alternatif : 1. Le client annule la suppression. Cet enchaînement démarre au point 4. 2. Le système affiche une notification. Le scénario reprend au point 2.   ================================================================ Cas d’utilisation : Consulter la liste des annonces parkings Acteurs : Manager et Client Objectif : Il permet aux acteurs de consulter la liste des annonces de parkings. Précondition : Succès d’authentification. Postcondition : Aucune. Scénario nominal : 1. L’utilisateur choisit d’afficher la liste des annonces de parkings, 2. Le système affiche la liste des annonces de parkings, 3. Le système vérifie le type d’utilisateur connecté (si client ou Manager), 4. Si l’utilisateur est : - un client, le système fait appel aux cas d’utilisation interne « Réserver un parking ». - un client et le propriétaire du parking, le système fait appel aux cas d’utilisation interne « Modifier une annonce ». - un Manager, le système fait appel aux cas d’utilisation interne « Modérer une annonce ». Scénario alternatif : Aucun.   ================================================================ Cas d’utilisation : Réserver un parking Acteurs : Client Objectif : Il permet à l’acteur de réserver un parking. Précondition : Succès d’authentification. Postcondition : parking réservé. Scénario nominal : 1. Le client choisit d’afficher la « Liste des annonces ». 2. Le système affiche la liste de ses annonces. 3. le client choisit de visiter une des annonces. 4. Le système affiche l’annonce choisie. 5. Le client choisit de réserver le parking. 6. Si l’acteur n’est pas le propriétaire du parking, le système affiche le formulaire de réservation. 7. Le client remplit le formulaire de réservation. 8. Le système demande la validation des informations saisies. 9. Le client valide les informations. 10. Le système vérifie les données. 11. Le système enregistre la réservation dans la base de données. Scénario alternatif : 1. Champs obligatoires non valides ou vides. Cet enchaînement démarre au point 10. 2. Le système affiche un message d’erreur. Le scénario reprend au point 6.   ================================================================ Cas d’utilisation : Modifier une annonce de parking Acteurs : Client Objectif : Il permet à l’acteur de consulter ses annonces de parkings. Précondition : Succès d’authentification. Postcondition : annonce de parking modifiée. Scénario nominal : 1. Le client choisit d’afficher la « Liste de mes annonces ». 2. Le système affiche la liste de ses annonces. 3. le client choisit de visiter une de ses annonces. 4. Le client choisit la modification des informations de l’annonce. 5. Le système affiche le formulaire de modification. 6. Le client modifie les informations de l’annonce, 7. Le système demande la validation des modifications, 8. Le client valide les modifications, 9. Le système vérifie les données, 10. Le système enregistre les modifications dans la base de données. Scénario alternatif : 1. Champs obligatoires non valides ou vides. Cet enchaînement démarre au point 9. 2. Le système affiche un message d’erreur. Le scénario reprend au point 5. ================================================================ Cas d’utilisation : Modérer une annonce de parking Acteurs : Manager Objectif : Il permet à l’acteur de modérer une annonce. Précondition : Succès d’authentification. Postcondition : annonce de parking modérée. Scénario nominal : 1. Le manager choisit d’afficher la « Liste des annonces ». 2. Le système affiche la liste des annonces. 3. le manager choisit de visiter une des annonces. 4. Le client choisit de modérer l’annonce. 5. Le système affiche le formulaire de modération. 6. Le client modifie les informations de l’annonce, 7. Le système demande la validation des modifications, 8. Le client valide les modifications, 9. Le système vérifie les données, 10. Le système enregistre les modifications dans la base de données. Scénario alternatif : 1. Champs obligatoires non valides ou vides. Cet enchaînement démarre au point 9. 2. Le système affiche un message d’erreur. Le scénario reprend au point 5.

---