Conception d'une application web de suivi des passagers sur tous les vols nationaux et internationaux en RDC

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 »