Vous allez modélisez un site de réservation de babysitting. L’application permet de mettre en relation un babysitter et des parents d’enfants.
Le babysitter s’inscrit sur le site, il donne :
Le parent s’inscrit sur le site, il donne :
Le parent et le babysitter doivent s’identifier pour accéder au site.
Le calendrier est composé :
Le parent recherche un babysitter disponible, pour une date donnée, sur une plage horaire de son choix, et peut choisir des compétences. La recherche affiche la liste des babysitters disponibles.
Dans un 1er temps, il faut définir les entités sans les relier entre elles. La 1ère erreur que fait un débutant lorsqu’il demarre un diagramme, c’est de partir dans le détail. Par exemple, on commence à penser comment un parent va interagir avec un babysitter, ou on définit comment un babysitter enregistre ses disponibilités. On finit par concevoir un schéma complexe. En fait, il faut commencer par définir les acteurs et le référentiel.
Les acteurs sont les entités qui interagissent sur le système. Il y a 2 acteurs :
Ces 2 acteurs doivent s’identifier. Ils héritent donc de User qui est une entité classique de connexion à un site.
Puis on complète, et on relie les acteurs.
Le référentiel est composé d’éléments qui évoluent très peu. C’est les fondations du modèle. Ici, nous avons des compétences :
un calendrier:
un calendrier avec des relations :
Un babysitter posséde des compétences et mets ces disponibilités dans le calendrier.
Et voilà :
note : Il existe une relation entre le parent les compétences car les compétences recherchées par les parents sont des données persistentes (le parent ne resaisit pas à chaque requête les compétences qu’il désire.)