WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et développement d'une application web pour la gestion des urgences: cas de l'application SOS communautaire


par Mackly Loick Tchicaya
ESCIC - Bachelor en full stack and data  2025
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

Chapitre 3 : Modélisation UML

4.1. Diagramme de cas d'utilisation

4.1.1. Acteurs principaux

Le système SOS Communautaire interagit avec trois acteurs principaux :

1. Citoyen : Utilisateur lambda qui signale des incidents et reçoit des alertes.

2. Autorité : Entité officielle (police, pompiers, ambulances) chargée de l'intervention.

3. Administrateur (Admin) : Gère le système, modère les contenus, supervise les données.

4.1.2. Relations entre acteurs et cas d'utilisation

Le diagramme ci-dessous illustre les interactions entre les acteurs et les fonctionnalités clés du système :

Explication des relations :

· Le citoyen peut signaler un incident, recevoir des alertes, confirmer la véracité d'un incident et consulter son historique.

· L'autorité visualise les incidents en temps réel, prend des mesures et clôture les dossiers.

· L'administrateur supervise l'ensemble du système, y compris la modération des signalements abusifs.

4.2. Diagramme de classes

4.2.1. Classes principales

Les classes métiers du système incluent :

· Utilisateur : Représente un citoyen, une autorité ou un administrateur.

· Incident : Stocke les détails d'un incident (type, localisation, statut).

· Notification : Gère les alertes envoyées aux utilisateurs.

· Autorité : Spécialisation de Utilisateur pour les services d'urgence.

4.2.2. Associations et héritage

Le diagramme suivant montre les relations entre les classes, y compris l'héritage pour les rôles utilisateurs :

Explication des relations :

· La classe Utilisateur est la base pour Citoyen, Autorité, et Administrateur via l'héritage.

· Un Citoyen peut signaler plusieurs Incidents.

· Un Incident peut générer plusieurs Notifications envoyées aux utilisateurs proches.

4.3. Diagramme de séquence

4.3.1. Scénario de signalement d'un incident

Voici le flux d'interaction lorsqu'un citoyen signale un incident :

4.3.2. Scénario de validation communautaire

Processus de confirmation d'un incident par les utilisateurs proches :

4.4. Diagramme d'activités

4.4.1. Flux de traitement d'un incident

Le diagramme suivant illustre le cycle de vie d'un incident, de sa création à sa résolution :

Signalement par un citoyen

1

Stockage dans la base de données

Envoi de notifications aux
citoyens proches

Envoi de notifications aux autorités

Oui

4,

Incident confirmé

Non

4,

Incident douteux

1

Rapport d'intervention

1

Autorité prend en charge

Autorité vérifie la validité

Incident clôturé et archivé

Explication :

· Un incident commence par un signalement, puis est stocké et notifié.

· Les confirmations communautaires déterminent si l'incident est priorisé.

· L'autorité intervient, résout l'incident, et le système archive les données.

précédent sommaire suivant






La Quadrature du Net

Ligue des droits de l'homme