## Prompt pour Génération de Diagrammes de Séquence (Projet OCP Gestion
des Arrêts)
**Objectif :** Générer des diagrammes de séquence UML illustrant les
principaux cas d'utilisation de l'application web de gestion des arrêts
d'équipement pour le service OIJ/I de l'OCP Jorf Lasfar.
**Format Souhaité :** Code PlantUML pour chaque diagramme.
**Contexte du Système :**
* Application Web composée d'un Frontend (Vue.js), d'un Backend
(Laravel API) et d'une Base de Données (BDD).
* Un système de notification (interne ou externe) peut être impliqué.
* Acteurs principaux : Opérateur, Technicien de Maintenance,
Superviseur.
**Diagrammes de Séquence à Générer :**
**1. Déclaration d'un Nouvel Arrêt par un Opérateur**
* **Acteurs :** Opérateur, Frontend, Backend, BDD, Service de
Notification.
* **Scénario :**
1. L'Opérateur se connecte à l'application (interaction non
détaillée ici, supposée réussie).
2. L'Opérateur accède au formulaire de déclaration d'arrêt via le
Frontend.
3. L'Opérateur remplit les informations (équipement, description,
criticité initiale, éventuellement photos) et soumet le formulaire.
4. Le Frontend envoie une requête API (POST /api/arrets) au Backend
avec les données.
5. Le Backend valide les données.
6. Le Backend enregistre le nouvel arrêt dans la BDD (état initial :
"Déclaré").
7. Le Backend récupère l'ID de l'arrêt créé.
8. Le Backend demande au Service de Notification d'envoyer une
alerte aux Superviseurs concernés.
9. Le Backend retourne une réponse de succès (avec l'ID de l'arrêt)
au Frontend.
10. Le Frontend affiche un message de confirmation à l'Opérateur.
**2. Assignation d'un Arrêt par un Superviseur**
* **Acteurs :** Superviseur, Frontend, Backend, BDD, Service de
Notification.
* **Scénario :**
1. Le Superviseur se connecte.
2. Le Superviseur consulte la liste des arrêts non assignés via le
Frontend (requête GET /api/arrets?status=nouveau).
3. Le Backend récupère les arrêts depuis la BDD et les renvoie au
Frontend.
4. Le Frontend affiche la liste.
5. Le Superviseur sélectionne un arrêt et choisit une
équipe/technicien à assigner.
6. Le Frontend envoie une requête API (PUT /api/arrets/{id}/assign)
au Backend avec l'ID du technicien/équipe.
7. Le Backend met à jour le statut de l'arrêt ("Assigné") et l'ID de
l'assigné dans la BDD.
8. Le Backend demande au Service de Notification d'informer le
Technicien/équipe assigné.
9. Le Backend retourne une réponse de succès au Frontend.
10. Le Frontend met à jour l'affichage et confirme l'assignation au
Superviseur.
**3. Enregistrement d'une Intervention par un Technicien**
* **Acteurs :** Technicien, Frontend, Backend, BDD.
* **Scénario :**
1. Le Technicien se connecte.
2. Le Technicien consulte ses arrêts assignés (GET
/api/arrets?assigne=moi).
3. Le Backend récupère les arrêts depuis la BDD.
4. Le Frontend affiche la liste.
5. Le Technicien sélectionne un arrêt pour enregistrer une
intervention.
6. Le Technicien accède au formulaire d'intervention via le
Frontend.
7. Le Technicien remplit les détails (description intervention,
temps passé, pièces, notes) et soumet.
8. Le Frontend envoie une requête API (POST
/api/arrets/{id}/interventions) au Backend.
9. Le Backend valide les données.
10. Le Backend enregistre l'intervention dans la BDD, liée à l'arrêt.
11. Le Backend met éventuellement à jour le statut de l'arrêt si
nécessaire (ex: "En cours").
12. Le Backend retourne une réponse de succès au Frontend.
13. Le Frontend affiche un message de confirmation au Technicien.
**4. Clôture d'un Arrêt par un Technicien (ou Superviseur)**
* **Acteurs :** Technicien (ou Superviseur), Frontend, Backend, BDD,
Service de Notification.
* **Scénario :**
1. L'utilisateur (Technicien/Superviseur) se connecte.
2. L'utilisateur accède à l'arrêt concerné (supposons qu'il est déjà
affiché).
3. L'utilisateur clique sur "Clôturer l'arrêt".
4. Le Frontend demande confirmation et potentiellement un
commentaire final.
5. L'utilisateur confirme.
6. Le Frontend envoie une requête API (PUT
/api/arrets/{id}/cloturer) au Backend.
7. Le Backend met à jour le statut de l'arrêt ("Clôturé") et
enregistre la date/heure de fin dans la BDD.
8. Le Backend calcule potentiellement la durée totale de l'arrêt.
9. Le Backend demande au Service de Notification d'informer les
parties concernées (ex: Opérateur initial, Superviseur).
10. Le Backend retourne une réponse de succès au Frontend.
11. Le Frontend met à jour l'affichage et confirme la clôture.
**Instructions Supplémentaires pour l'IA :**
* Utiliser la notation standard UML pour les messages (flèches pleines
pour synchrones, flèches ouvertes pour asynchrones si pertinent pour les
notifications).
* Représenter clairement les acteurs et les composants système
(lifelines).
* Inclure des messages de retour lorsque c'est pertinent.
* Générer un bloc de code PlantUML distinct pour chaque diagramme
demandé.
* Assurer la lisibilité et la clarté des diagrammes.
1
/
2
100%