HBnB UML - Documentation Guide

Introduction

Cet article explique l’utilité de chaque diagramme UML demandé dans HBnB v2 – Part 1. On couvre le Package Diagram, le Class Diagram, les Sequence Diagrams, puis un UML Glossary minimal pour les symboles clés.

Package Diagram

But : donner une vue d’ensemble de l’architecture en 3 couches et leurs communications.

• Presentation (API/Services) : reçoit les requêtes, ne contient pas de règles métier.
• Business Logic (Façade + Services) : orchestre les cas d’usage, applique les règles.
• Persistence (Repositories/DAO) : accès aux données et au SGBD.

À montrer : API → Façade → Services → Repositories → DB. La Façade sert d’interface unique entre Présentation et Métier, elle simplifie et isole la complexité.

Class Diagram

But : décrire la structure du domaine (classes, attributs, méthodes, relations).

• BaseEntity : id (UUID4), created_at, updated_at.
• User (hérite de BaseEntity) : nom, email, is_admin.
• Place (hérite) : title, description, price, latitude, longitude.
• Amenity (hérite) : name, description.
• Review (hérite) : rating (1..5), comment.

Relations clés : User 1..* Place (owner), Place *..* Amenity, Place 1..* Review, User 1..* Review. Indique les multiplicités (1..*, 0..1…), et l’héritage clair vers BaseEntity.

Sequence Diagrams

But : montrer l’ordre des appels entre couches pour un scénario précis (API → Métier → Données).

1. User Registration : POST /users → Façade → UserService (validation + hash) → UserRepository.save → 201.
2. Place Creation : POST /places → Façade → PlaceService (vérifs) → PlaceRepository.save → 201.
3. Review Submission : POST /places/{id}/reviews → ReviewService (charge Place+User, valide note) → ReviewRepository.save → 201.
4. List Places : GET /places?filters → PlaceService.list → PlaceRepository.query → 200 + liste.

Astuce : nomme les lifelines comme tes composants réels pour que le reviewer fasse le lien avec ton code.

UML Glossary

• Association — lien entre deux classes (ex. Place—Review). Ajouter la multiplicité (1..*, 0..1…).
• Agrégation — losange blanc : “A a des B”, les parties peuvent vivre sans le tout.
• Composition — losange plein : les parties dépendent du tout (cycle de vie partagé).
• Héritage/Généralisation — flèche triangle vide vers la super-classe (User → BaseEntity).
• Dépendance — ligne pointillée : “utilise” (faible couplage) ; ex. Service → Repository.
• Réalisation — ligne pointillée + triangle : implémentation d’interface / contrat abstrait.
• Multiplicités — 1..*, 0..1, 1..1 : combien d’instances sont reliées.
• Package — regroupe classes/composants (idéal pour montrer les couches).
• Façade — point d’entrée unique vers le métier (simplifie, sécurise, centralise).