| Nom | Rôle | GitHub |
|---|---|---|
| Abdellah EL BOUANANI | Database & Security Lead | abdellahelbouanani0/Theab01 |
| Ali AHLAOU | Product Owner & UI Logic | ahlaouali |
| Abdelghafour AIT-MELLOUK | Software Architect | hmontaca645 |
| Elhassane ENASSIRI | DevOps & QA Engineer | hassannassiri181-cmyk |
- Introduction et Description du Projet
- Exigences du Système
- Conception du Système
- Instructions d'Installation et d'Utilisation
- Description de l'Architecture et Choix de Conception
- Sécurité
- Tests et Maintenance
- Difficultés Rencontrées et Solutions
- Conclusion
BATAL-FIT est une application conçue pour résoudre les "points de friction" majeurs rencontrés par les pratiquants de musculation (Gymrats) : les ballonnements dus à une mauvaise hydratation, la fatigue décisionnelle concernant les repas, et les stagnations à l'entraînement.
- Hydratation Intelligente : Calcule les besoins en eau en fonction des suppléments consommés (ex: Créatine, Whey) et distribue les rappels (Anti-Bloat) pour éviter l'inconfort à l'entraînement.
- Architecte de Repas Contextuel : Propose des recettes en fonction des ingrédients disponibles dans le frigo et des macros restants pour la journée.
- Coach IA Adaptatif : Analyse la fatigue (Ratio de charge, Fréquence cardiaque) et adapte l'intensité des séances suivantes pour prévenir les blessures (Règle des 10%).
- Écosystème Social : Ligues et tableaux de bord pour maintenir la motivation.
| ID | Fonctionnalité |
|---|---|
| F1 | L'utilisateur peut enregistrer sa consommation de suppléments (Créatine, Whey, etc.) |
| F2 | Le système calcule et ajuste l'objectif d'hydratation quotidien en fonction des suppléments |
| F3 | Le système génère un planning d'hydratation anti-ballonnement avant l'entraînement |
| F4 | L'utilisateur peut saisir les ingrédients disponibles dans son frigo |
| F5 | Le système propose des recettes adaptées aux macros restants de la journée |
| F6 | L'utilisateur peut enregistrer ses performances d'entraînement (poids, répétitions, FCR) |
| F7 | Le système analyse la fatigue et ajuste automatiquement la séance du lendemain |
| F8 | L'utilisateur peut consulter son tableau de bord de progression (3 piliers) |
| F9 | L'utilisateur peut participer à des ligues sociales et classements |
| F10 | L'utilisateur peut s'authentifier de manière sécurisée (email + mot de passe) |
- Performance : Réponse de l'API < 500ms pour les opérations courantes ; connexion DB via Singleton pour éviter la surcharge.
- Sécurité : Mots de passe hachés (BCrypt), sessions via JWT, requêtes SQL via
PreparedStatement. - Scalabilité : Architecture en couches (Model / DAO / Service / Controller) facilitant l'ajout de nouvelles fonctionnalités.
- Maintenabilité : Code respectant SOLID, DRY, KISS ; nommage significatif ; méthodes courtes.
- Portabilité : Java 8+, Maven, compatible Windows/Linux/macOS.
| Acteur | Rôle |
|---|---|
| Gymrat (Utilisateur) | Enregistre ses données, consulte ses plans, interagit avec l'application |
| Système IA (Coach/Architecte) | Analyse les données, génère des recommandations, déclenche les rappels |
- Un utilisateur peut se connecter et recevoir un token JWT valide.
- Après l'enregistrement de suppléments, l'objectif d'eau est recalculé et un planning est généré.
- Après la saisie d'ingrédients, au moins une recette compatible avec les macros restants est proposée.
- Après l'enregistrement d'une séance, le système détecte la fatigue et ajuste la séance planifiée si le ratio de charge dépasse 1.3.
| Priorité | Fonctionnalité |
|---|---|
| Must Have | Authentification (F10), Hydratation intelligente (F1, F2, F3), Enregistrement des séances (F6) |
| Should Have | Architecte de repas (F4, F5), Coach IA adaptatif (F7), Tableau de bord (F8) |
| Could Have | Écosystème social / Ligues (F9), Rappels vocaux |
| Won't Have | Intégration wearables (hors scope v1), Paiement en ligne |
- En tant que Gymrat, je veux enregistrer mes suppléments du matin, afin de recevoir un planning d'hydratation adapté qui évite les ballonnements pendant l'entraînement.
- En tant que Gymrat, je veux saisir les ingrédients de mon frigo, afin de recevoir des suggestions de repas qui complètent mes macros restants de la journée.
- En tant que Gymrat, je veux enregistrer ma séance de musculation, afin que le système détecte ma fatigue et ajuste automatiquement l'intensité de ma prochaine séance.
- En tant que Gymrat, je veux consulter mon tableau de bord, afin de suivre ma progression sur les 3 piliers (hydratation, nutrition, entraînement).
- En tant que Gymrat, je veux me connecter de manière sécurisée, afin que mes données personnelles et de santé soient protégées.
Tous les fichiers sources .puml sont disponibles dans le répertoire docs/uml/.
Fichier :
docs/uml/use_case.puml
@startuml
left to right direction
actor "Gymrat (User)" as user
actor "AI System" as system
package "BATAL-FIT" {
usecase "Manage hydration and supplements" as UC1
usecase "Receive vocal hydration reminders" as UC2
usecase "Input fridge inventory" as UC3
usecase "Generate macro-adapted recipes" as UC4
usecase "Log workout performances" as UC5
usecase "Adapt intensity (Injury Prevention)" as UC6
usecase "View progress dashboard" as UC7
usecase "Participate in social leagues" as UC8
}
user --> UC1 ; user --> UC3 ; user --> UC5 ; user --> UC7 ; user --> UC8
system --> UC2 : Triggers
system --> UC4 : Filters and calculates
system --> UC6 : Analyzes fatigue
@enduml
Fichier :
docs/uml/class_diagram.puml
Le diagramme de classes couvre les couches suivantes :
- Modèles :
User,WorkoutSession,PlannedSession,SupplementLog,Recipe,Meal,HydrationLog,HydrationSchedule - Interfaces DAO :
UserDAO,WorkoutDAO,RecipeDAO,HydrationDAO - Services :
AuthService,SecurityUtil,MacroService,HydrationEngine,AntiBloatScheduler,FatigueAnalyzer,VocalCoach - Contrôleurs :
MealController
| Fichier | Scénario |
|---|---|
docs/uml/seq_auth.puml |
Authentification (Login → BCrypt → JWT) |
docs/uml/seq_smart_hydration.puml |
Hydratation intelligente (Suppléments → Planning Anti-Bloat) |
docs/uml/seq_fridge_to_plate.puml |
Architecte de repas (Frigo → Macros → Recettes) |
docs/uml/seq_ai_coach_fatigue.puml |
Coach IA (Séance → Analyse fatigue → Ajustement) |
Bonus :
| Fichier | Type |
|---|---|
docs/uml/activity_hydration.puml |
Diagramme d'activité — Hydratation intelligente |
docs/uml/state_workout_session.puml |
Diagramme d'états — Session d'entraînement |
docs/uml/deployment.puml |
Diagramme de déploiement |
- Java JDK 8 ou supérieur
- MySQL Server 8.x
- Maven 3.x
- Eclipse IDE (ou tout IDE compatible Maven)
1. Cloner le dépôt :
git clone https://github.com/ENSIAS-MEH/appoo-team-1.git
cd appoo-team-12. Configurer la base de données :
mysql -u root -p < src/main/resources/schema.sql
mysql -u root -p < src/main/resources/data.sql3. Configurer la connexion :
Éditer src/main/resources/config.properties :
db.url=jdbc:mysql://localhost:3306/batal_fit
db.user=<votre_utilisateur>
db.password=<votre_mot_de_passe>4. Compiler et lancer :
mvn clean package
mvn exec:java -Dexec.mainClass="com.fitnessapp.BatalFitApp"Au démarrage, l'application présente un menu interactif en console permettant de :
- Créer un compte / Se connecter
- Enregistrer des suppléments et consulter le planning d'hydratation
- Saisir les ingrédients du frigo et obtenir des suggestions de repas
- Enregistrer une séance d'entraînement et consulter l'analyse de fatigue
- Consulter le tableau de bord de progression
┌─────────────────────────────────┐
│ Controller Layer │ MealController
├─────────────────────────────────┤
│ Service Layer │ AuthService, HydrationEngine,
│ │ FatigueAnalyzer, MacroService,
│ │ AntiBloatScheduler, VocalCoach
├─────────────────────────────────┤
│ DAO Layer │ UserDAO, WorkoutDAO,
│ │ RecipeDAO, HydrationDAO
├─────────────────────────────────┤
│ Model Layer │ User, WorkoutSession, Recipe,
│ │ Meal, HydrationLog, ...
├─────────────────────────────────┤
│ Database Layer │ MySQL via DatabaseConnection
└─────────────────────────────────┘
| Pattern | Classe(s) | Justification |
|---|---|---|
| Singleton | DatabaseConnection |
Une seule instance de connexion DB, optimise les ressources |
| DAO | UserDAO, WorkoutDAO, RecipeDAO, HydrationDAO |
Isole la logique d'accès aux données de la logique métier |
| Strategy | FatigueAnalyzer |
Encapsule l'algorithme d'analyse de fatigue (workload ratio + FCR) |
| Observer | AntiBloatScheduler → VocalCoach |
Le scheduler notifie le VocalCoach lors de la création d'un planning |
| Facade | BatalFitApp |
Point d'entrée unique qui orchestre tous les sous-systèmes |
- S — Responsabilité Unique : Chaque classe a une responsabilité précise (
HydrationEnginecalcule uniquement les offsets d'eau,AntiBloatSchedulergère uniquement le planning). - O — Ouvert/Fermé : Les interfaces DAO (
UserDAO,WorkoutDAO) permettent d'ajouter de nouvelles implémentations sans modifier le code existant. - L — Substitution de Liskov :
UserDAOImpletWorkoutDAOImplsont substituables à leurs interfaces respectives. - I — Ségrégation des Interfaces : Interfaces DAO séparées par entité métier (pas d'interface monolithique).
- D — Inversion des Dépendances : Les services dépendent des interfaces DAO, pas des implémentations concrètes.
- Nommage significatif :
calculateWorkloadRatio(),frontLoadAlgorithm(),checkInjuryGuard() - Pas de nombres magiques : les seuils (ratio 1.3, règle des 10%) sont des constantes nommées
- Méthodes courtes avec une seule responsabilité
PreparedStatementsystématique pour toutes les requêtes SQL
Le schéma SQL est disponible dans src/main/resources/schema.sql.
Tables principales : users, workout_sessions, planned_sessions, supplement_logs, recipes, meals, hydration_logs, hydration_schedule.
- Git avec branches par fonctionnalité (
feature/hydration,feature/fatigue-analyzer, etc.) - Messages de commit significatifs référençant les fonctionnalités ou numéros de bugs
- Pull Requests avec revue de code avant fusion dans
main - Suivi des bugs via GitHub Issues avec référence au commit de correction
Maven est utilisé pour :
- Gestion des dépendances (
mysql-connector-j,jbcrypt,jjwt,junit-jupiter) - Compilation (
mvn compile) - Tests (
mvn test) - Packaging (
mvn package)
- Toutes les requêtes SQL utilisent des
PreparedStatement— aucune concaténation de chaînes pour les requêtes. - Principe du moindre privilège : l'utilisateur DB applicatif n'a que les droits
SELECT,INSERT,UPDATEnécessaires.
- Les mots de passe ne sont jamais stockés en clair.
- Hachage avec BCrypt (via
jbcrypt 0.4) — résistant aux attaques par force brute. - Sessions sécurisées via JWT (via
jjwt 0.12.5) — tokens signés, sans état côté serveur.
- Les messages d'erreur exposés à l'utilisateur sont génériques (pas de stack trace, pas de détails SQL).
- Aucune donnée sensible (mots de passe, tokens) n'est loggée.
- Vérification du token JWT avant chaque opération sensible.
- Framework : JUnit 5 (
junit-jupiter-api 5.10.2) - Couverture cible : chaque classe de service et DAO dispose de tests unitaires.
- Lancement :
mvn test
- Le bug est signalé via une GitHub Issue avec description, étapes de reproduction et comportement attendu.
- Une branche
fix/<numéro-issue>est créée. - Le correctif est implémenté et testé (ajout de test de non-régression si applicable).
- Un commit est créé avec le message :
fix: <description> (closes #<numéro>). - Une Pull Request est ouverte, revue, puis fusionnée dans
main.
- Javadoc sur toutes les méthodes publiques des services et DAOs.
- README maintenu à jour à chaque évolution majeure.
| Difficulté | Solution Apportée |
|---|---|
| Algorithme Anti-Bloat : Distribuer l'hydratation de façon à éviter les ballonnements pendant l'entraînement nécessitait une logique de "front-loading" non triviale. | Implémentation d'un frontLoadAlgorithm() dans AntiBloatScheduler qui concentre 60% de l'hydratation dans les heures précédant l'entraînement, avec des intervalles calculés dynamiquement. |
| Détection de fatigue multi-critères : Combiner le ratio de charge (Acute:Chronic Workload Ratio), la fréquence cardiaque au repos et la règle des 10% en un seul score cohérent. | Création d'un FatigueAnalyzer avec des méthodes dédiées (calculateWorkloadRatio, checkRestHeartRate, checkInjuryGuard) dont les résultats sont agrégés dans determineFatigueLevel(). |
| Gestion de la connexion DB : Éviter les connexions multiples et les fuites de ressources. | Pattern Singleton sur DatabaseConnection avec gestion explicite des ressources (try-with-resources pour les PreparedStatement). |
| Sécurité des sessions : Maintenir l'état de l'utilisateur sans session serveur. | Adoption de JWT : le token signé contient l'identité de l'utilisateur et est vérifié à chaque requête sans accès à la base de données. |
BATAL-FIT répond aux trois problèmes principaux des pratiquants de musculation — hydratation mal gérée, fatigue décisionnelle nutritionnelle, et stagnation à l'entraînement — à travers une architecture logicielle solide et sécurisée.
Le projet applique rigoureusement les principes SOLID, DRY et KISS, utilise les patterns DAO, Singleton, Strategy et Observer, et garantit la sécurité des données via BCrypt et JWT. La base de code est structurée pour être facilement extensible (ajout de nouveaux types de suppléments, nouvelles règles de fatigue, intégration wearables en v2).
Les prochaines évolutions envisagées incluent une interface graphique (JavaFX ou application mobile), l'intégration de capteurs wearables pour la fréquence cardiaque en temps réel, et un module de chiffrement AES pour les données de santé sensibles en base.
lien de Screen Record : https://drive.google.com/drive/folders/1LOvVkMkkSUjyv7w6un4f-NbGPG8RRBSN?usp=sharing