Évaluation final - La Caféteria en services

Mise en contexte

La Caféteria du Cégep Belle-Rive sert chaque jour plusieurs centaines de personnes : menu du jour, bols et wraps, burritos le midi, grill, frigos libre-service, viennoiseries, collations. Elle accepte aussi des commandes par téléphone, à ramasser sur place.

Aujourd’hui, le seul système informatique en place est la caisse électronique. Tout le reste repose sur des pratiques manuelles : les écrans du menu sont mis à jour à la main, les commandes téléphoniques sont écrites sur des bons papier, le stock est suivi sur une feuille affichée dans la réserve. La Fondation du cégep offre un rabais de 4 $ sur chaque menu du jour, sur présentation de la carte étudiante, et rembourse ensuite la cafétéria.

La direction souhaite une solution informatique qui permette notamment de consulter le menu, commander pour le ramassage et gérer le stock. Votre mandat est d’en proposer la conception.

Contraintes de la solution

1. La caisse électronique existante est conservée.
2. Seul le ramassage sur place est visé : aucune livraison.
3. La Fondation rembourse la cafétéria selon les rabais enregistrés.
4. Plusieurs applications clientes peuvent utiliser vos services : par exemple une application pour la clientèle, les écrans du menu, un poste en cuisine, la caisse. Vous décidez lesquelles font partie de votre solution.
5. Vous concevez la solution ; vous ne la programmez pas. Aucun code n’est exigé.

Livrables

1. Structure de la solution

Un diagramme qui montre :

• les services de votre solution, entre 4 et 7 ;
• les applications clientes qui les utilisent, ainsi que la caisse électronique ;
• les liens entre ces éléments (qui appelle qui).

Pour chaque service, un court tableau ou paragraphe précise :

• sa responsabilité, en une ou deux phrases ;
• les données dont il est propriétaire ;
• les fonctionnalités qu’il offre, sous forme de liste de points d’accès (méthode et chemin).

La notation est libre (boîtes et flèches, modèle C4 niveau 2, Mermaid…), à condition d’être lisible et accompagnée d’une légende si elle n’est pas standard.

2. Scénarios d’utilisation

Quatre scénarios : les trois scénarios imposés ci-dessous et un scénario de votre choix.

	Scénario	Application cliente
S1	Consulter ce qui est réellement disponible maintenant, avec les prix et le rabais applicable	au choix
S2	Commander pour le ramassage, puis récupérer sa commande	au choix
S3	Appliquer le rabais de la Fondation lors d’un paiement	la caisse électronique
S4	Au choix : un autre problème observé dans votre simulation	au choix

Chaque scénario présente, dans l’ordre :

1. Le problème observé auquel il répond et le besoin concret à satisfaire.

2. L’application cliente qui amorce le scénario.

3. La suite des appels. Pour chaque appel :

   Élément	Exemple de forme attendue
   Service appelé	service-x
   Point d’accès	GET /ressources?filtre=valeur
   Données envoyées	exemple JSON du corps ou des paramètres
   Réponse reçue	code HTTP et exemple JSON

4. La combinaison des réponses : comment l’application (ou un service) assemble les informations reçues de plusieurs appels pour produire le résultat attendu.

3. Justification

1. Expliquez un choix de découpage : pourquoi telle responsabilité forme un service distinct, ou au contraire pourquoi vous avez regroupé deux responsabilités.
2. Choisissez un de vos services et décrivez ce que voit l’utilisateur si ce service ne répond pas pendant un de vos scénarios.

Conditions

• Les diagrammes peuvent être faits sur papier ou avec un outil (draw.io, Mermaid…).
• Remise : fichier PDF contenant les trois livrables.

Critères d’évaluation

Critère	Points
Structure de la solution	30
Scénarios d’utilisation	50
Justification	15
Clarté et qualité de la langue	5
Total	100