Rapport du projet

Gestion Secours
Plateforme pour la sécurité civile

Réalisé par : encadré par :

Raoui Jihane – El aidi Ichraq Mme Saidi Rajaa
EL Moussaoui Hajar _Wessal Hamza

Année Académique : 2020-2021

2
 Table des matières

Introduction........................................................................................................... 4
I. Etude préliminaire ............................................................................................. 5
1. Identifier les modules préliminaires ........................................................... 6
2. Identifier les acteurs.................................................................................... 6
3. Modéliser le contexte.................................................................................. 7
II. Capture des besoins fonctionnels ..................................................................... 8
1. Identifier les cas d’utilisation ..................................................................... 9
2. diagramme des cas d’utilisation ................................................................. 9
3. Identifier les classes candidates ................................................................ 10
III. capture des besoins techniques ..................................................................... 11
1. Spécification technique du point de vue matériel .................................... 12
2. Élaboration du modèle de spécification logicielle .................................... 12
IV. Analyse ......................................................................................................... 14
1. Découpage en catégorie ............................................................................ 15
2. Développement du modèle statique .......................................................... 16
3. Développement du modèle dynamique .................................................... 17
V. Conception générique .................................................................................... 20
VI. Conception préliminaire ............................................................................... 22
1. Enumération des interfaces utilisateur ......................................................... 23
VII. Conception détaillée .................................................................................... 24
1. Conception du stockage des données ......................................................... 25
2. Diagramme de classe détaillé ..................................................................... 26
Conclusion .......................................................................................................... 29

3
 Introduction

Un processus unifié est un processus construit sur UML (Unified Modeling Language).
Plus exactement ce sont les meilleures pratiques du développement objet suivies
pour la réalisation d’un système. Un processus unifié se distingue par les
caractéristiques suivantes :
✓ Itératif : Le logiciel nécessite une compréhension progressive du problème à
travers des raffinements successifs et développer une solution effective de
façon incrémentale par des itérations multiples.
✓ Piloté par les risques : les causes majeures d’échec d’un projet logiciel doivent
être écartées en priorité.
✓ Centré sur l’architecture : le choix de l’architecture logicielle est effectué lors
des premières phases de développement du logiciel. La conception des
composants du système est basée sur ce choix.
✓ Conduit par les cas d’utilisation : le processus est orienté par les besoins
utilisateurs présentés par des cas d’utilisation.
Le processus 2TUP (Two Track Unified Process) est un processus unifié. Il gère la
complexité technologique en donnant part à la technologie dans son processus de
développement.
Le 2TUP propose un cycle de développement qui sépare les aspects techniques des
aspects fonctionnels et propose une étude parallèle des deux branches :
fonctionnelle (étude de l’application) et la technique (étude de l’implémentation).
le processus 2TUP s’articule autour de trois branches :

• Une branche technique

• Une branche fonctionnelle
• Une branche de conception et réalisation.

L’objectif de ce projet est donc, d’une part, de faire le point sur les différentes étapes
de la méthode de processus unifié 2TUP, et d’autre part, de réaliser l’analyse et la
conception d’un Système de Gestion de Secours.

4
 Chapitre 1
ETUDE PRELIMINAIRE

5
L’étude préliminaire est la toute première étape de notreprocessus de développement. Elle
consiste à effectuer un premier repérage desbesoins fonctionnels et opérationnels, en
utilisant principalement le texte, ouUML en actiondes diagrammes très simples.Elle prépare
les activités plus formelles decapture des besoins fonctionnels et de capture des besoins
techniques.

1) Identifier les modules préliminaires :

Notre projet consiste à faire une conception d’un system d’information pour la sécurité
civile. Ce system permet de gérer les fonctionnalités suivantes : Gestion des sinistres,
Gestion du personnel pompier et des engins.

• Gestion des sinistres :

-Un Agent CTA reçoit les appels au secours.

-Les informations des sinistres sont enregistrées dans le système pour le suivi.
-Apres l’enregistrement les informations sont envoyées au centre régional pour
l’intervention

• Gestion des pompiers :

-Conserver la date d’embauche et le dernier indice de traitement.

-Mémoriserles coordonnées pour le suivi administratif.

-Mémoriser les différentes affectations d’un pompier (Caserne et date d’affectation)
- Affecté une équipe à une mission selon le type de la mission et l’engin utilisé

• Gestion des engins :

-Enregistrés les informations des engins : type, numéro d’ordre
-Choisir l’engin selon le type de la mission

2) Identifier les acteurs :

Définition : Un acteur représente l’abstraction d’un rôle joué par des entités
externes(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec
le système étudié.

• Agent CTA :
▪ Recevoir les appels d’urgencesvia le système
▪ Déclencher les alertes

6
 • Agent CODIS :
▪ Recevoir les alertes
▪ Alerter le centre le plus proche
▪ Gestion des engins
▪ Envoyer les renforcements

• Agent CIS :
▪ Recevoir les ordres
▪ Affecter les engins selon la mission
▪ Mobiliser l’équipeselon l’engin
▪ Saisir les informations des missions
▪ Saisir les coordonnées des employeurs
▪ Demander les renforcements

3) Modéliser le contexte :

CTACODIS
Insertion les données Recevoir les alertes
des alertes

Système
Spécification des casernes et des
engins

CIS
Demande
Saisir informations de la mission
d’intervention

7
 Chapitre 2
CAPTURE DES BESOINS
FONCTIONNELS

8
 1- Identification des cas d’utilisation :

Cas d’utilisation Acteur Message émis/reçus

Traiter les alertes Agent CTA Emet : une alerte
Reçoit : compte rendu de
l’intervention
Gérer les engins Agent CODIS Emet : Demande de
consultation
Reçoit : les informations
Gérer les pompiers Agent CIS Emet : Demande de
consultation
Reçoit : les informations
Engager les renforts Agent CODIS Emet : une demande de
renfort
Reçoit : une confirmation
Affecter le sinistre à une Agent CODIS Emet : demande
caserne d’intervention
Reçoit : information de
l’équipe en charge

2- Diagramme des cas d’utilisation :

Définition: un cas d’utilisation représente un ensemble de séquences d’actions réalisées par
le système et produisant un résultat observable intéressant pour un acteur particulier.

9
3- Identifier les classes candidates :
• Employé (Pompier, Cta, Codis, Cis)
• Sinistre
• Engins
• Casernes
• Mission

10
 Chapitre 3
CAPTURE DES BESOINS
TECHNIQUES

11
 1- Spécification technique du point de vue matériel :
Pour les données de notre système, on a préféré détacher notre base de données du serveur
web et la stocké dans un serveur de base de données pour des raisons de sécurité.

Utilisateur Machine utilisateur

Schéma illustrant notre architecture matérielle :

• Machines utilisateurs : sont des ordinateurs de bureau ou toutes sortes de machine

ayant un navigateur web qui permet d’accéder à l'application.
• Serveur web: c’est un ordinateur qui répond aux requêtes des navigateurs en retournant
des pages web. Il peut être aussi sous forme d’ensemble de serveurs permettant le
fonctionnement des applications web.
• Machines serveur (BDD): comporte une importante capacité de stockage, doit être
disponible afin qu’on puisse y accéder à tout moment, et doit avoir une puissante
capacité de traitement dans le cas où plusieurs utilisateurs y accèdent en même temps.
2- Élaboration du modèle de spécification logicielle :
Une fois que les spécifications techniques sont exprimées, onpeut s’intéresser aux fonctionnalités
propres du système technique en procédant à une spécification logicielle.

L'exploitant :

Utilisateur: c’est les personnes qui utilisent d’une manière ou d’une autre les fonctionnalités du
système.

Identification des cas d’utilisation techniques :

12
Gérer la sécurité :

• S’authentifier
• Verification des champs
• Mémoriser le mot de passe

Gérer l’optimisation :

• Opération imbriquées de navigation

Gérer les données :

• Affichage dynamique
• Mise à jour simultanés
• Déploiment en réseau
• Executer sur differents navigateur
• Affichage des différentes opérations effectuées par chaque exploitant

Gérer les erreurs :

• Afficher les types des erreurs

Utiliser l’aide :

• Consulter l’aide d’utilisateur

Synchroniser des objets d’application :

• Synchronisation des accées aux objets

13
 Chapitre 4
ANALYSE

14
 1- Diagramme en catégories

Le découpage en catégories constitue la première activité de l’étape d’analyse.

Le premier principe consiste à regrouper les classes sémantiquement proches. Pour cela, il faut
chercher la cohérence avec les critères suivants :
• Finalité : les classes doivent rendre des services de même nature aux utilisateurs.
• Evolution : isoler les classes réellement stables de celles qui vont vraisemblablement évoluer
au cours du projet.
• Cycle de vie : permet de distinguer les classes dont les objets ont des durées de vie très
différentes.

Dans ce contexte, le découpage en catégories nous donne :

1- Catégorie Mission :
+ Sinistre
+EnCoursTraitement
+SuiVehicule
 Classes de même domaine métier et objectif qui est le suivi du sinistre , en ajoutant qu’ils
évoluent dans le temps
2- Catégorie Gestion :
+ CODIS
+CTA
+CIS
 Classes qui ont la même finalité (Gestion secours), et aussi même évolution et cycle de vie
3- Catégorie Personnel :
+ AgentCIS
+AgentCODIS
+AgentCTA
+Personne
 Il s’agit de classes de même finalité et objectifs. Les administrateurs des locaux font des
services de gestion et technique qui attribue au service métier général ; gestion de
secours.
 Personne la classe qui englobe tous les fonctionnels
4- Catégorie Ressources :
+Engin
+Vehicule
+Pompier
 Classes qui interviennent directement à la mission terrain et font le même rôle en totalité

• Dépendance des catégories :

La catégorie Missions importe la catégorie Ressources, pourtant les classes Engin, Pompier et
Véhicule n’ont toujours pas accès à la classe Mission. De même pour la catégorie Gestion.

Pourtant pour les personnels, ils ont besoin d’accès aux classes de la catégorie Mission et le contraire
peut être fait par transitivité.
Toute relation qui peut être obtenue par transitivité est à éliminér.

15
 2- Développement du modèle statique

Le diagramme de classes est le diagramme le plus important dans toutes les méthodes orientées
objet. C’est également celui qui contient la plus grande gamme de notations et de variantes. Dans
cette étape on va détailler, compléter et optimiser ce diagramme
La démarche utilisée commence par l’affinement des classes qui essaye d’éliminer les classes
redondantes, vagues, qui sont à la place d’un attribut ou d’un rôle ou qui représentent des acteurs
inutiles, par exemple la classe « Agent CTA » va être éliminé car c’est un acteur disant inutile qui
n’attribue pas directement au fonctionnement du système et son rôle est le même que CTA.

De la même façon, on optimise le modèle structurel par l’ajout des classes manquantes, et aussi par
la subdivisiond’une classe existante en plusieurs :
- Dans la catégorie « Mission » nous avons isolé une classe à laquelle la classe
« Sinistre »délègue le suivi réel du temps de déclenchement, de début et fin mission pour
traiter tous les aspects liés au suivi en temps réel des sinistres.
- Au cours d’une mission, le départ du véhicule doit avoir lieu dans les 7 minutes qui suivent la
réception de l’alerte. Il faut donc distinguer une nouvelle classe : « SuiviVehicule » pour le
suivi du temps de son départ et son arrivée.
« SuiviVehicule » et « EnCoursTraitement » ne comportent ni les mêmes responsabilités, ni les
mêmes états que celle de la classe « Sinistre ».

Par la suite, nous essayons à affiner les associations. Les associations représentent des relations
conceptuelles entre les classes et impliquent des responsabilités en termes de navigation. On essaye
donc de supprimer les associations inutiles et d’ajouter leurs propriétés (Frozen/Ordred). Concernant
les attributs, la classe « EnCoursTraitement » va contenir un attribut dérivé « Debut_Mission » qui
égale au temps de déclenchement – Ecart. Ce dernier est un attribut de classe de valeur initiale =20
min considérée fixe.

Et enfin, on ajoute les opérations de classe.

16
 3- Développement du modèle dynamique

Le modèle dynamique est la représentation des scénarios des cas d’utilisation. Un scénario décrit une
exécution particulière d’un cas d’utilisation du début à la fin.

• Diagrammes de séquences

-Authentification

17
-Déclencher alerte

18
-Affecter Caserne

19
 Chapitre 5
CONCEPTION GENERIQUE

20
Framework « Présentation »
Gérer la communication avec l’utilisateur pour la saisie des données et l’affichage.
Définit les classes, interfaces, mécanismes de base pour réaliser la gestion des objets.
Chaque classe et ou interface est représentée par des formulaires, tableaux, menu, boutons.

Framework « Applicatif »
Gérer le déroulement des fonctionnalités du logiciel et la communication avec les autres applications
et services. Cette partie n’est pas visible par l’utilisateur du système. Elle permet de regrouper les
interfaces précédentes qui exécutent certaines actions afin de communiquer avec la couche métier.

Framework « Métier »Définit les éléments permettant d’identifier les objets métier (pompier,
sinistre..) et de les gérer en services métier correspondant aux cas d’utilisation et faisant liaison entre
les commandes de l’utilisateur et la couche de données.

Framework « Accès aux données »

Gérer l’accès aux données persistantes provenant de notre base de données gérée par un
SGBD.Notre application dispose de plusieurs fonctionnalités chose qui devrait causer
l’alourdissement des temps de réponses aux requêtes.
Ceci dit on a pris compte de cette contrainte et nous avons proposé la solution de « Sessions » qui
offrira la possibilité de partage et d’intégrité entre plusieurs utilisateurs.

21
 Chapitre 6
CONCEPTION PRELIMINAIRE

22
1. Énumération des interfaces :

Utilisateurs Interfaces Fonctions

S’authentifier pour le système le
Authentification dirige vers l’espace qui lui est
approprié.
Agent CTA Accueil CTA Interface d’accueil réservée
aux Agents CTA
Ajouter une Alerte Déclencher/Ajouter une
nouvelle alerte.
Traiter les alertes Traitement des alertes
(Suppression, lister,
consultation)
S’authentifier pour le système le
Authentification dirige vers l’espace qui lui est
approprié.

Accueil CODIS Interface d’accueil réservée

aux Agents CODIS
Alerte reçu Affichages les informations
des alertes envoyées par CTA
Agent CODIS Ajouter un Engin Ajouter un nouveauengin.

Traiter les Engins Traitement des

Engins(Supprimer, modifier,
lister, chercher)
Gérer des Missions -Affecter engin à une mission.
-Affecter les casernes à une
mission.
Ajouter renfort Prévenir les pompiers
volontaires.
S’authentifier pour le système le
Authentification dirige vers l’espace qui lui est
approprié.
Accueil CIS Interface d’accueil réservée
aux Agents CIS
Alerte reçu Affichages les informations
des alertes envoyées par
CODIS et CTA
Agent CIS Ajouter un Pompier Ajouter un nouveau pompier.

Gérer les Pompiers Traitement des Pompiers

(Supprimer, modifier, lister,
chercher)
Gestion des missions -Affecter pompier
professionnelle à une mission.
-Affecter pompiers
volontaires à une mission au
cas de besoin de renfort.

23
 Chapitre 7
CONCEPTION DETAILLEE

24
Les concepteurs dans cette phase construisent les classes, les vue d’IHM, les
interfaces, les tables et les méthodes qui vont donner une image « prête à coder » de
la solution.
1.1 Concevoir les classes :
La génération du code à partir des classes est alors particulièrement importante pour
conserver la traçabilité du passage de l’analyse au code.
Il s’agit donc d’introduire de nouvelles classes soit pour prendre en charge des
responsabilités purement techniques, soit pour décharger une classe d’analyse de
certains de ces aspects techniques.
1.2 Concevoir les associations
L’association se transforme en attribut ou en tableau d’attributs suivant sa
multiplicité.
1.3 Concevoir les attributs
Il s’agit de définir le type des attributs identifiés en analyse. Bien que la plupart des
attributs se satisfassent des types de base de Java, certains attributs d’analyse
correspondent à une structure de données qu’il est nécessaire de spécifier
(exemple :engin ,caserne..).
1.4 Concevoir les opérations
Il s’agit de donner une image assez précise du contenu des méthodes du projet.
1.5 Conception du stockage des données :
Le SGBDR permet d’administrer les données et d’y accéder par des requêtes
complexes. C’est la technique la plus répandue, que nous avons retenue pour notre
projet.
On trouve ci-dessous une table qui illustre la conception du stockage des classes :

Classe Attribut Type Description

Id Chaine de Identifiant personne
caractère
Nom Chaine de Nom de la personne
caractère
Personne Prenom Chaine de Prénomde la personne
caractère
CIN Chaine de Le CIN de la personne
caractère
Date_affect Date Date d’affectation

25
 Id Chaine de Identifiant de l’agent CIS
caractère
Nom Chaine de Nom de l’agent CIS
caractère
Agent CIS Prenom Chaine de Prénomde l’agent CIS
caractère
CIN Chaine de Le CIN de l’agent CIS
caractère
Date_affect Date Date d’affectation à une
caserne
Id Chaine de Identifiant de l’agent CODIS
caractère
Nom Chaine de Nom de l’agent CODIS
caractère
Agent CODIS Prenom Chaine de Prénomde l’agent CODIS
caractère
CIN Chaine de Le CIN de l’agent CODIS
caractère
Date_affect Date Date d’affectation à une CODIS
Fonction Chaine de Fonction du pompier
caractère
Pompier Date Date_habil Date d’habilitation du pompier
Type Chaine de Type de pompier
caractère
Id_cis Chaine de Identifiant cis
caractère
CIS Domaine Chaine de Domaine de cis
caractère
Email Chaine de Email de cis
caractère
Id_codis Chaine de Identifiant de CODIS
caractère
CODIS Date_creation Date Date de création de codis
Region Chaine de Région de codis
caractère
Adresse Chaine de Adresse de codis
caractère
CTA Adresse Chaine de adresse de cta
caractère
Email Chaine de Email de cta
caractère
Id_Sinistre Chaine de Identifiant de sinistre
caractère
Sinistre Lieu Chaine de Lieu de sinistre
caractère
Date Date Date d’occurrence de sinistre

26
 Description Chaine de Description détaillée de
caractère sinistre
T_declenche Date Temps de déclenchement
Ecart Date Temps que le véhicule prend
pour arriver au sinistre
EnCoursTraitement T_fin Date Temps de fin
Etat_Mission Chaine de Etat de mission
caractère
Degats Chaine de Les dégâts dans la mission
caractère
/Debut_Mission Date Début de la mission
Matricule Chaine de Identifiant d’engin
caractère
Engin Type Chaine de Type d’engin
caractère
Etat Chaine de Etat de l’engin
caractère
Vehicule Kilométrage Long Distance parcouru par la
voiture
SuiviVehicule Tsortie Date Sortie de vehicule
Tarrive Date Entrée de vehicule

Diagramme de classe détaillé

27
28
 Conclusion

Ce projet s’est révélé très enrichissant dans la mesure où il a consisté en une

approche concrète du métier d’ingénieur, au sens où nous avons traité
parallèlement, l’évolution logicielle de notre système suivant un axe fonctionnel
et un axe technique.

Il nous a permis d’appliquer nos connaissances à la modélisation et aussi

l’apprentissage de concepts à la pointe de la technologie et des tendances
actuelles dans le monde professionnel.

29