Rappel du contexte

Vous venez de perdre vos clés dans le bus et avez l’idée de développer un service d’objet trouvé sur Internet : fffound. Le service fournit des portes clés et des autocollants avec un identifiant et un QRcode unique à ses utilisateurs. Les utilisateurs peuvent coller les autocollants sur leurs objets (par exemple un téléphone) ou attacher leurs clés au porte clés.

Ils doivent ensuite lier ces identifiants à leurs comptes, pour que des personnes qui trouveraient les objets perdus puissent rentrer en contact avec eux, en rentrant l’identifiant de l’objet.

Pour ce TP, on considèrera que fffound offre une page de discussion/chat permettant aux propriétaires et découvreurs d’échanger des messages/photos au sein de l’application.

TP Diagramme de classe

Décrire au travers d’un diagramme de classe comment sont organisées les données du service fffound.

Commencer par vous demander quels sont les classes en présence.

Puis modéliser leurs relations les unes aux autres.

Penser à abstraire/généraliser les classes qui ont des parties communes au besoin.

On utilisera creately.com ou draw.io (se créer un compte sur la plateforme)

Corrigé

Plusieurs modélisations sont possibles suivant la façon de fonctionner de l’application. L’exemple ci-dessous est une proposition, le niveau de détail aurait pu être plus grand.

Correction

Rendu

Les TPs compterons pour 50% de la note.

Le TP peut se faire seul ou en binôme.

Le rendu se fait en deux fois :

  1. v1 en fin de TP à 18h il est possible d’avoir terminé à ce moment là questionnaire spirale.
  2. v2 avant dimanche 4 décembre 23h59 questionnaire spirale.

L’évaluation se fera principalement sur la v1, la v2 permettra de finaliser/nettoyer le TP.

L’architecture peut prendre des formes assez diverses, des rendus trop similaire entre groupes seront sanctionnés.