2.1.1
Identification des acteurs du système informatique
Dans cette partie nous allons identifier les acteurs du
système informatique en prenant compte de ceux du métier qui
toucheront de façon direct ce système. Les acteurs du
métier qui sont impliqué dans le système informatique
sont :
- Compagnie
- Service commercial
- VTA
A ceux-ci nous augmentons un autre acteur du système
informatique qui est l'Administrateur du système.
a. COMPAGNIE : il est l'acteur qui élabore
le manifeste. Pour accéder à l'application cet acteur doit avant
toute chose s'authentifier. Le processus d'authentification comprend la
définition d'un code d'identification, du nom de la compagnie et d'un
mot de passe.
b. SERVICE COMMERCIALE : C'est l'acteur qui rempli
le formulaire de trafic, qui encaisse et valide le paiement des redevances. Cet
acteur accède à l'application via une authentification
composée de son identifiant et son mot de passe.
c. VTA : C'est l'acteur qui valide le vol
après qu'il aie établi un rapport de control de passagers. Son
accès à l'application est conditionné par une
authentification comprenant son identifiant et son mot de passe.
d. ADMINISTRATEUR : c'est l'acteur qui
attribue les droits d'accès au système.
Diagramme de contexte du système informatique
2.1.2
Détermination des cas d'utilisation du système informatique
Pour constituer les cas d'utilisations, nous allons
considérer l'intention fonctionnelle de chaque acteur par rapport au
système dans le cadre de l'émission ou de la réception de
massage. Ainsi lorsque nous regroupons ces intentions fonctionnelles en
unité cohérentes, nous obtenons les cas d'utilisations
suivants :
Ø S'authentifier
Ø Etablir manifeste
Ø Taxer vol
Ø Gérer profil
Ø Editer rapport control
Ø Encaisser paiement
Diagramme des cas d'utilisation du système
informatique
2.2
ANALYSE DES CAS D'UTILISATION
2.2.1
Identification des classes participantes
a. Diagramme des classes participantes du C.U.
« Etablir manifeste »
Ces classes sont tirées de la description textuelle du cas
d'utilisation Etablir manifeste.
b. Diagramme des classes participantes du C.U.
« Etablir Rapport »
c. Diagramme des classes participantes du C.U. « Taxer
vol »
2.2.2
Découpage par catégorie
Dépendances entre catégories
2.2.3
Développement du model dynamique
1ère Itération : C.U.
« Etablir manifeste »
Parmi tous les scénarios possibles du cas d'utilisation
(C.U.) établir manifeste nous allons nous intéresser aux
scénarios suivants :
· Créer manifeste : {créer passager,
créer bagage, créer vol}
· Modifier manifeste : {modifier passager, modifier
bagage, modifier vol}
· Annuler Manifeste : {supprimer passager, supprimer
bagage, supprimer vol}
a. Opération système « Créer
manifeste » :
Ø Responsabilité : Cette classe a pour
responsabilité permettre à la compagnie de remplir les
informations attachées à un vol.
Ø Référence : cas d'utilisation Etablir
manifeste
Ø Pré conditions : - la compagnie doit
être authentifiée
-Au moins un vol programmé
Ø Scénario Nominal
1. Cette opération commence lorsque la compagnie demande
au système de créer un manifeste
2. Elle saisi les informations obligatoires attachées
à un manifeste
3. La compagnie attache à un manifeste un vol
programmé
4. Il valide le manifeste
Ø Cas d'exception (scénario d'erreur)
En cas d'informations manquantes : un message d'erreur est
affiché à l'écran de la compagnie et lui demande de
ressaisir ces informations. Après cela le processus reprend à
l'étape 2 du scénario nominal.
Ø Post conditions
· Une instance de la classe manifeste mf est crée
avec ses attributs (numéro, type, date)
· Un objet de la classe vol est attaché à un
manifeste
· Un objet passager est crée et attaché
à un vol
· Un objet bagage est crée et attaché à
un passager.
Ø Exigences non fonctionnelles
· L'application est fiable, robuste, efficace
· Le manifeste est sécurisé pendant son
établissement et aucune information ne peut se perdre.
Ø Description formelle
Pour modéliser ce scénario nous allons faire
collaborer les objets suivants :
· Un acteur compagnie qui sera devant l'écran
· Un objet manifeste qui sera crée en cours du
scénario
· Un objet vol qui sera attaché à un
manifeste
· Un objet passager qui sera attaché à un
vol
· Un objet bagage qui sera attaché à un
passager
Ø Diagramme de séquence vue comme boite blanche
pour l'opération système « créer
manifeste »
b. Diagramme de séquence opération
système « Modifier Manifeste » :
c. Diagramme de séquence Opération
système « Annuler manifeste » :
Diagramme de classes de
conception « Cas d'utilisation :
Etablir Manifeste ».
Nous allons compléter nos classes en ajoutant les
comportements (méthodes) pouvant permettre aux objets de se communiquer.
Ainsi le diagramme ci-après démontre les différentes
classes recensées dans ce scénario. 2ème Itération : C.U.
« Taxer Vol »
Parmi tous les scénarios possibles du cas d'utilisation
(C.U.) taxer vol nous nous intéresserons aux scénarios
(opérations système) suivants :
· Créer formulaire trafic
· Modifier formulaire trafic
· Annuler formulaire trafic
a. Opération système « Créer
formulaire trafic » :
Ø Responsabilité : Permettre au service
commercial de remplir les informations nécessaires ayant trait aux
redevances de la compagnie.
Ø Référence : cas d'utilisation Taxer
vol
Ø Pré conditions : -Manifeste
déjà établie
Ø Scénario Nominal
1. Cette opération commence lorsque le service commercial
demande au système de créer un formulaire de trafic
2. Il saisi les informations obligatoires attachées
à un formulaire de trafic
3. Le service commercial calcul les redevances de la compagnie
4. Il valide le formulaire de trafic
Ø Scénario d'erreur
En cas d'informations manquantes : un message d'erreur est
affiché à l'écran du service commercial lui demandant de
ressaisir ces informations. Après cela le processus reprend à
l'étape 2 du scénario nominal.
Ø Post conditions
· Une instance de la classe formulaire trafic ft est
crée avec ses attributs (numéro, date, type)
Ø Exigences non fonctionnelles
· Le formulaire de trafic est bien sécurisé et
aucune information y figurant ne peut se perdre
· Le système est fiable, robuste
Ø Description formelle
Pour une bonne modélisation de ce scénario nous
allons y faire collaborer les objets suivants :
· Un acteur service commercial qui sera devant
l'écran
· Un objet formulaire trafic qui est crée en cours du
scénario
Diagramme de séquence vue comme boite blanche pour
l'opération système « créer formulaire
trafic »
 Diagramme de classe de conception cas d'utilisation
« Taxer Vol »
3ème Itération : C.U.
« Gérer profil »
Parmi tous les scénarios possibles du cas d'utilisation
(C.U.) taxer vol nous nous intéresserons aux scénarios
(opérations système) suivants :
· Créer compte {créer utilisateur,
créer login, créer mot de passe}
· Modifier compte {modifier utilisateur, modifier login,
modifier mot de passe}
· Supprimer compte {Supprimer utilisateur, supprimer login,
supprimer mot de passe}
a. Opération système « Créer
compte » :
Ø Responsabilité : créer un nom et un
mot de passe d'authentification pour chaque utilisateur du système en
vue de veiller sur la sécurité et la fiabilité de ce
dernier.
Ø Référence : cas d'utilisation
gérer profil
Ø Pré conditions :
- L'administrateur est connecté
- L'administrateur est authentifié
Ø Scénario Nominal
1. L'administrateur attribue un mot de passe et un nom
d'identification
2. Il saisie les coordonnées du nouveau compte
d'utilisateur
3. Il octroi des privilèges au nouveau utilisateur
4. Il valide la création du compte
Ø Scénario d'erreur
En cas d'un compte qui existe déjà, un message
d'erreur est affiché à l'écran de l'administrateur lui
avertissant qu'un compte existant porte le même nom et lui recommande de
ressaisir les informations de création du compte et le cas d'utilisation
reprend à l'étape 2 su scénario nominal.
Ø Post conditions
· Une instance de la classe compte utilisateur cu est
crée avec ses attributs (numero, datecreation, login, motdepasse,
type)
Ø Exigences non fonctionnelles
· Le compte ainsi que ses informations sont bien
sécurisé et durant la session de travail de l'administrateur
· Le système est fiable, robuste
Ø Description formelle
Pour une bonne modélisation de ce scénario nous
allons y faire collaborer les objets suivants :
· Un acteur administrateur qui sera devant l'écran
· Un objet compte qui est crée en cours du
scénario
· Un contrôleur de compte
· Un objet écran
Diagramme de communication de l'opération
système « créer compte » 
b. Opération
système « Modifier compte »
Diagramme de communication « Modifier
compte »
c. Opération système « supprimer
compte »
Diagramme de communication « supprimer
compte »
Diagramme de classes de conception « Composant :
Gérer Profil »
CHAP III
IMPLEMENTATION ET DEPLOIEMENT
| 
