INSTITUT AFRICAINE AFRICAN INSTITUTE

D’INFORMATIQUE OF COMPUTER SCIENCES

Représentation du Cameroun Cameroon Office
BP: 13719 Yaoundé BP: 13719 Yaoundé
Fax: 22 12 11 64 Fax: 22 12 11 64
Site web: www.iaicameroun.com Site web: www.iaicameroun.com
Tel : 222 729 957 Tel : 222 729 957
e-mail: [email protected] e-mail: [email protected]

PROJET D‘UML

Modélisation d’une application pour la gestion

automatisée d’un aéroclub :
Le castellet

Membre du projet :
 KAMO NDIBATCHOU Jude Levy
 IPOUK Jeannette Herine Valérie
 PEGWE WANDJI Daniele Kemone
 OTSALIE MELONGO Joanne Salem
 NGOUMENE KENE Billy Brandown
 TOUOPA Willy Landry
 LOUOCDOM JOUONANG Auklin Jordan
 POHLA Franck
 TEMEU SIELENOU Vaneka
 MEKUATE KAMGA Oriane
 AHOUKENG DONWOUNG Audrey
 NKENG PEH Bruno Julien

Sous la coordination de :

Mr LENGUE DAMICO

ANNEE ACADEMIQUE 2016-2017

 SOMMAIRE

SOMMAIRE.....................................................................................................................................i
PRESENTATION DU PROJET.....................................................................................................1
PRESENTATION DE LA METHODE DE TRAVAIL.................................................................2
I. GESTION DES PILOTES....................................................................................................3
1. Diagramme de cas d’utilisation........................................................................................3
2. Diagramme de séquence...................................................................................................9
3. Diagramme de classe......................................................................................................16
4. Diagramme de composant...............................................................................................17
II. GESTION DES VOLS.......................................................................................................18
1. Diagramme de cas d’utilisation......................................................................................18
2. Diagramme de séquence.................................................................................................20
3. Diagramme de classe......................................................................................................22
4. Diagramme de composant...............................................................................................23
III. GESTION DES AVIONS...............................................................................................24
1. Diagramme de cas d’utilisation......................................................................................24
2. Diagrammes de séquence................................................................................................29
3. Diagramme de classe......................................................................................................34
4. Diagramme de composant...............................................................................................34
IV. DIAGRAMME DE DEPLOIEMENT............................................................................35
V. DIAGRAMME DE COMPOSANT GLOBAL..................................................................36
Conclusion.....................................................................................................................................37
BIBLIOGRAPHIE..........................................................................................................................ii

i
 PRESENTATION DU PROJET
Dans le cadre de l’atelier UML, du projet de conception portant sur la gestion de l’aéroclub
du Castellet, l’objectif principal est d'évaluer le degré de maîtrise de nos différentes notions
présentées en cours. Le texte relatif au projet est tiré d'un exemple traité par le groupe de travail
Anna Gram, constitué en janvier 1979, sous l'égide de l'AFCET. L'application demandée doit
permettre la gestion automatisée et simplifiée de cet aéroclub. Les besoins du club sont les
suivants : la gestion des pilotes, des vols, des avions. Chaque type de gestion correspond à un
certain nombre d’éléments à prendre en compte.

La gestion des pilotes permet de gérer les cas suivants : l’inscription d’un nouveau pilote,
le départ d’un autre, l’édition de la liste des pilotes et faciliter la gestion de la comptabilité plus
précisément en ce qui concerne les comptes des pilotes, les différentes cotisations.

La gestion des vols quant à elle consiste à enregistrer les informations sur les vols des
avions pour chaque pilote, pour l'ensemble des pilotes, pour un avion, pour l'ensemble des
avions.

La gestion des avions sert à enregistrer des avions, à les supprimer, à éditer leurs
caractéristiques. Les ventes et achats d’avion seront comptabilisés.

37
 PRESENTATION DE LA METHODE DE TRAVAIL
Un processus unifié est un processus construit sur UML (Unified Modeling Language).
Les processus unifiés sont le résultat de l’unification, non pas des processus, mais plus
exactement les meilleures pratiques du développement objet. Ils sont :

 Itératifs ;
 Pilotés par les risques ;
 Conduits par les cas d’utilisation ;
 Orientés composant.

La méthode de conception des systèmes d’information utilisée pour la réalisation de ce

projet est la méthode 2TUP (Two Track Unified Process). 2TUP est un processus de
développement logiciel qui implémente le processus unifié. Chacune des étapes du cycle découle
des précédentes.

La branche fonctionnelle sera scindée en 2 (deux), la capture des besoins fonctionnels qui
correspond aux diagrammes de cas d’utilisation et de séquence et l’analyse qui correspond au
diagramme de classe.

La branche du milieu correspond uniquement à la conception préliminaire qui sera

représentée par les diagrammes de composants et de déploiement.

37
 I. GESTION DES PILOTES
AEROCLUB

1. Diagramme de cas d’utilisation

a) Diagramme

S'inscrire

<<extend>> Editer
<<include>> Debiter Compte Caracteristiques

Acheter
Fourniture Editer Noms

Crediter Compte

Pilote
Gestionnaire

Editer le relevé de <<include>> Editer le relevé de

compte de l'ensemble compte d'un pilote
des pilotes

Subir Visite <<include>> Solder Compte

Medicale

Demander position
<<include>> du compte

Demissionner

37
 b) Description textuelle des cas d’utilisation

Scenario 1 : S’inscrire

Objectif : inscription d’un nouveau pilote.

Acteurs concernés : le pilote et le gestionnaire. Le pilote entrant ses informations et le

gestionnaire ayant pour but de l’enregistrer.

Pré condition : la machine allumée.

Post condition : le pilote est inscrit.

Scenario nominal :

1. Le pilote fourni ses informations.

2. Le système affiche le formulaire.
3. Le gestionnaire saisi les informations dédiées.
4. Le système valide.
5. Le gestionnaire crée le compte du pilote.
6. Le pilote effectue un versement initial et une cotisation de l’année en cours calculée
par le système.

Scenarios alternatifs :

1. Erreurs détectées lors de la saisie des informations.

2. Le cas d’utilisation reprend à l’action 1 du scénario nominal.

Scenario 2 : Démissionner

Objectif : permettre la démission d’un pilote.

Acteurs concernés : le pilote et le gestionnaire. Soit le pilote fait une demande de démission
soit le gestionnaire le retire du club en cas d’inactivités.

Pré condition : être membre du club.

Post condition : le pilote doit être supprimé de l’ensemble des membres du club.

37
Scenario nominal :

1. Le pilote fait une demande de démission.

2. Le gestionnaire ferme le compte temporairement.
3. Demander l’état du compte. Si solde non débiteur fermeture totale sinon fermeture
différée jusqu’à la régularisation du compte.

Scenario alternatif : aucun.

Scenario 3 : Edition des noms avec ou sans caractéristiques

Objectif : Permettre l’affichage de la liste des pilotes du club.

Acteur concerné : Le gestionnaire.

Pré condition : les pilotes doivent exister.

Post condition : aucun.

Scenario nominal :

1. Le gestionnaire faire une demande d’affichage.

2. Le système affiche la liste de tous les pilotes.

Scenario alternatif : Aucun

Scenario 4 : Edition d’un relevé de compte pour un pilote

Objectif : élaboration d’un relevé de compte comportant des débits et crédits pour une
période donnée.

Acteur concerné : le gestionnaire.

Pré condition : demandé par le pilote en question.

Post condition : aucun

37
Scenario nominal :

1. Le gestionnaire choisi le relevé de compte du pilote.

2. Le système génère le relevé de compte des débits et crédits de ce pilote.

Scenario alternatif : Aucun

Scenario 5 : Acheter une fourniture

Objectif : Retrait d’argent sur le compte

Acteur concerné : Le pilote ayant un solde débité dû à l’achat des fournitures.

Pré condition : compte doit être créditeur

Post condition : compte doit être débité

Scenario nominal :

1. Le gestionnaire enregistre l’achat du pilote

2. Le système retire la somme d’argent adéquate

Scenarios alternatifs : Erreurs détectées lors du retrait d’argent

1. Le système notifie le pilote sur l’état de son compte

2. Solde insuffisant pour l’achat des fournitures
3. Le pilote crédite son compte d’une somme appropriée aux fournitures
4. Le cas d’utilisation reprend à l’action 1 du scénario nominal

Scenario 6 : Crédit sur le compte d’un pilote

Objectif : Permettre à chaque pilote d’effectuer un versement d’argent dans son compte

Acteur concerné : Le pilote.

Pré condition : Compte activé

Post condition : Créditer compte du pilote

37
Scenario nominal :

1. Le pilote donne les informations de versement et la somme d’argent à verser

au gestionnaire
2. Le gestionnaire entre la somme que le pilote veut verser dans son compte

Scenarios alternatifs : Erreurs détectées lors du versement d’argent

1. Le système réaffiche le formulaire de versement d’argent en indiquant les

erreurs détectées.
2. Le pilote corrige les erreurs.
3. Le cas d’utilisation reprend à l’action 1 du scénario nominal.

Scenario 7 : Subir visite médicale

Objectif : Permettre à un pilote de faire une visite médicale à intervalle réguliers.

Acteurs concernés : Le pilote, gestionnaire.
Pré conditions : Etre membre du club.
Post conditions : La visite médicale doit être faite à intervalle réguliers.
Scenario nominal :
1. Le gestionnaire saisi les informations de visite donné par le pilote.
2. Le système valide et enregistre dans la visite médicale.
Scenario alternatif : Aucun.

Scenario 8 : Edition du relevé des comptes pour l’ensemble des pilotes

Objectif : Elaboration du relevé des comptes comportant des débits et crédits pour une
période donnée

Acteurs concernés : Le gestionnaire ayant pour but d’élaborer un relevé de compte pour
l’ensemble des pilotes du club.

Pré conditions : aucun

Post conditions : aucun

37
 Scenario nominal :

1. Le gestionnaire choisi l’ensemble des pilotes

2. Le système génère le relevé de compte des débits et crédits pour tous les pilotes

Scenarios alternatifs : Aucun

Scenario 9 : Edition des caractéristiques d’un pilote

Objectif : Modifier les caractéristiques d’un pilote

Acteurs concernés : Le gestionnaire ayant pour but d’élaborer un relevé de compte pour
l’ensemble des pilotes du club.

Pré conditions : demandé par le pilote en question

Post conditions : aucun

Scenario nominal : aucun

1. Le gestionnaire choisi le profil du pilote

2. Le gestionnaire modifie les informations du pilote
3. Le système valide et enregistre les informations

Scenarios alternatifs : Aucun

37
 2. Diagramme de séquence

a) S’inscrire
S'inscrire

IHM cpte_entreprise

Gestionnaire

loop [tant que information invalide]

Afficher formulaire

Saisir les informations

Verification des informations

<<create>>
:Pilote
creer_pilote

<<create>>
Compte
creer compte()

crediter()
<<create>>
:Mouvement_compt
creer()

Pilote inscrit

debiter() <<create>>
:mouvement_compt2
creer()

crediter()

37
 c) Démissionner
Demissioner

:IHM :Pilote :Compte

Gestionnaire

Affichage de la liste des pilote

choix du pilote
suppression du pilote

getSolde()

alt Si solde debiteur

desactiver()

Si solde non debiteur

supprimer()
<<destroy>>
detruire()

<<destroy>>
detruire()

37
 d) Edition des noms avec ou sans caractéristiques
Edtier les noms avec ou sans caractéristiques

:IHM :Pilote

Gestionnaire
demande d'afficher

getAll()
Affichage de liste de tous les pilotes

e) Edition d’un relevé de compte pour un pilote

Edition d'un releve de compte pour un pilote

:IHM :Pilote :Compte

Gestionnaire

choix du pilote
getPilote()
generer releve de compte
getCompte()
getOperations()

generation du releve de compte

releve de compte genere

37
 f) Acheter fourniture
achat fournitures

:IHM :Pilote :Compte cpte_entreprise fourniture

Gestionnaire

Saisi des informations d'achats

validation des informations

getSolde()

Fonction qui
compare le solde_suffisant()
solde et le prix
de la
fourniture
alt solde suffisant
debiter()
<<<<create>>>>
:mouvement_compt()
creer()
crediter()

creer()

Achat effectué

solde insuffisant

Impossible d'achater la fournitures solde insuffisant ou debiteur

37
 g) Crédit sur le compte d’un pilote
Crediter compte

:IHM :Pilote :Compte

Gestionnaire

loop [tant que information non valide]

Formulaire de versement

Saisi des informations de versement

validation

crediter() <<<<create>>>>
creer() :mouvement_compt

Vous venez de crediter votre compte

37
 h) Subir visite médicale
subir viste medicale

IHM :Compte :Cpte_Entre

Pilote

loop [informations non valides]

choix du formulaire visite medicale
affichage du formulaire

validation des informations

debiter()

crediter()

Votre compte a bien été debité

37
 i) Edition du relevé des comptes pour l’ensemble des pilotes
Edition dun releve de compte pour l'ensemble des pilotes

:IHM :Pilote :Compte

Gestionnaire

generer le reveler de compte de l'ensembles des pilotes

getAll()
getAllCompte()

generation du releve de compte

Affichage du eleve de compte general

j) Edition des caractéristiques d’un pilote

Edition des caractéristiques d'un pilote

:IHM :Pilote

Acteur_1

demander l 'affichage d'un pilote

getPilote()

loop [tant que informations invalides]

formulaire d'edition d'un pilote

edition des informations d'un pilote

validation et enregistrement des informations

setPilote()
Edtion des informations du pilote effectuée

37
 3. Diagramme de classe

pilote
- nom : String
- penom : String
- adresse : String
- date_naiss : Date
- heure_vol : int
1..1
- habilitation :
appartenance
+ get () : java.lang.Object
compte
+ set () : void
+ acheter () : void 1..1 - matricule : int
+ visite () : void propriétaire - Etat : String
+ heure_vol () : int - solde : int
+ debiter () : void
+ crediter () : void
1..1 1..1 Fournitures
1..1
patient propriete
0..1 - nom : String debit/credit
- montant : int
- description : String
0..*

Brevet
1..* - libellé : String
avoir 1..*
1..*
posseder
subir
mouvement_comptable
visite_medicale 0..1
- intitule : String - Type : String
- Nature : String
- date : Date
- heure : int 0..* - Date : Date
- Libelle : String
- Montant : int
Categorie
- type_avion : String
- description : String
+ get () : int
...

37
4. Diagramme de composant

<<component>>
pilote

fourniture
- nom : string
- prix : int 0,*
- description : string

0,1
pilote
- nom : String Port_1
- penom : String
- adresse : String compte
Port_2 - date_naiss : Date
gestion_pilote - habilitation : String visite medicale
1,1 1,*
+ get () : java.lang.Object - intitule : String
+ set () : void - date : Date
+ acheter () : void - heure : int
+ visite () : void

1..1

0..n

Brevet
- intitule : String
- type : char

<<component>>
compte

compte
- matricule : int
- Etat : String
- solde : int
+ debiter () : void
+ crediter () : void

Port_1 1,*
gestion_compte

1,*
mouvement_comptable
- Type : String
- Nature : String
- Date : Date
- Libelle : String
- Montant : int

37
 II. GESTION DES VOLS
1. Diagramme de cas d’utilisation
a) Diagramme
Modèle orienté objet
Modèle : DCU gestion vol
Package :
Diagramme : DCU GEST_VOL
Auteur : LUDOVIC Date: 16/02/2017
Version:

<<include>>

debiter compte pilote

enregistrer plan de vol

lister par avion

gestionnaire de vols
afficher vols

lister par
pilotes

k) Description textuelle des cas d’utilisation

Scenario1 : enregistrer un plan de vol

Objectif : ajouter un vol dans la liste des vols.

Acteurs concernés : gestionnaire de vols.
Pré condition : ouverture de l’application.
Post condition : création d’un nouveau vol.
Scenario nominal :
1. Le gestionnaire entre les informations liées au vol.
2. Le gestionnaire valide les informations saisies.
3. Le système vérifie les informations.
4. Le système vérifie si les informations sont conformes.
5. Le système renvoi un message de validation de l’enregistrement d’un plan de
vol.

37
 Scenario alternatif :
1. Les informations ne sont pas valides.
2. Le système renvoi un message d’erreur et ramène l’utilisateur à l’étape1.

Scenario 2 : afficher la liste des vols

Objectif : lister les différents vols.
Acteurs concernés : le gestionnaire de vols.
Pré condition : existence d’une liste de vol.
Post condition : le gestionnaire doit connaitre toutes les informations sur les vols par avions
et par pilotes.
Scenario nominal :
1. Le gestionnaire saisie les informations d’un avion ou d’un pilote.
2. Le système vérifie l’existence de l’avion ou du pilote.
3. Le système affiche la liste des vols de l’avions ou du pilote.

Scenario alternatif :

1. L’avion ou le pilote n’existe pas dans le système.

2. Le système renvoie un message d’erreur et renvoie à l’étape 1 du scenario
nominal.

37
 5. Diagramme de séquence
a) Enregistrer plan de vol
Modèle orienté objet
Modèle : DSE enregistrer plan de vol
Package :
Diagramme : enregistrer plan de vol
Auteur : LUDOVIC Date: 28/02/2017
Version:

enregistrer plan de vol

IHM brevet avion compte_pilote compte_entreprise

gestionnaire

saisie et validation des informations

verification des informations

alt
si information non valide
affiche message d'erreur et formulaire de
saisie des informations

information valide

<<create>>
creer un vol
vol

verifier brevet
affecter_avion()

return

debiter ()
crediter()

operation effectuer

message de confirmation de lenregistrement

37
 l) Afficher la liste des vols

Modèle orienté objet

Modèle : DSE afficher la liste des vols
Package :
Diagramme : afficher la liste des vols
Auteur : LUDOVIC Date: 16/02/2017
Version:

avion ou
pilote

afficher la liste des vols

IHM vol classe

gestionnaires
saisir information de recherche

GetId(code)

alt
si code n'existe pas
affiche message d'erreur et ramene au
formulaire de saisi

si code existe

Get_liste()

affiche la liste

37
 6. Diagramme de classe
Modèle orienté objet
Modèle : DCL gestion vol
Package :
Diagramme : DCL gestion vol
Auteur : LUDOVIC Date: 02/03/2017
Vol Version:
+ date_dep : Date 1..1 Avion
1..*
+ date_arriv : Date affecter
realise + immat : Character
+ compt_dep : int
- infotech : Character
+ compt_arriv : int
+ type_vol : Character + Get () : java.lang.objet
+ destination : Character 1..1 + Affecter () : voi d
- prix_vol : int correspond + Get_nbr_heure () : int
+ ajouter () : voi d
+ Get_liste () : Character
+ delete () : voi d
...
1..*
1..* correspond
effectue

1..1 categorie
1..* appartenir
possede + type_avion : Character
+ description : Character
mouvement_comptable
+ get () : java.lang.obj et
1..1 + type : Character ...
affecter 1..*
+ date : Date
attribuer
Pilote + libelle : Character
+ nom : Character + montant : Float
+ prenom : Character + nature : Character
+ adresse : Character
+ habilitation : Character
1..* 1..*
+ Get () : java.l ang.objet possede possede
+ set () : void
... 1..1 1..1
1..1 1..1
debiter/crediter credite
appartient appartient
Compte compte_entrprise
1..1
possede + solde : Float - solde : Float
+ matricule : Character
+ crediter () : void
+ Debiter () : void ...
+ crediter () : void

brevet
+ libelle : Character 1..1
1..* relier
peut avoir

37
 7. Diagramme de composant

<<component>>
vol

vol .
+ date_dep : Date
+ date_arriv : Date
+ compt_dep : int
+ compt_arriv : int correspond
+ type_vol : Character 1..1
pilote
+ destination : Character
..
+ Attribut_8 : float
+ get_liste () : Character
... possede
1..*
... avion
mouvement_compt
gestion_vol
+ type : Character
+ date : Date
+ libelle : Character
+ montant : Float
- nature : int

possede
1..*

compte_entrprise
- solde : Float
credite
+ crediter () : void 1..1
...

37
 III. GESTION DES AVIONS
1. Diagramme de cas d’utilisation
a) Diagramme

ajouter avion <<extend>>

editer table des tarifs

vendre avion

<<extend>>

Gestionnaire <<include>>

supprimer avion

perdre avion
<<include>>

editer caracteristique

controler visite technique

m) Description textuelle des cas d’utilisation

Scenario1 : ajouter avion

Objectif : ajout d’un avion.

Acteur concerné : le gestionnaire.

Précondition : l’avion ne doit pas exister.

Post-condition : liste des avions disponibles modifiée.

37
 Scénario nominale :

1. Le système affiche le formulaire d’ajout d’un avion.

2. Le gestionnaire saisit les informations liées à l’avion.
3. Le gestionnaire valide les informations.
4. Le système vérifie les informations.
4.1. Le système vérifie si les informations sont conformes.
4.2. Le système vérifie si les informations ne correspondent pas déjà à un autre avion.
4.3. Le système vérifie si la catégorie de l’avion existe.
5. Le système ajoute le nouvel avion.

Scénario alternatif :

4.1. Les informations ne sont pas valides

4.1. a. Le système retourne à l’étape 1.

4.2. Les informations saisies sont identiques à un avion existant.

4.2.a. Le système affiche un message d’erreur.

4.2.b. Le système demande de retourner en 1.

4.3. La catégorie saisie n’existe pas.

4.3.a. Le système affiche un message demandant d’ajouter une nouvelle catégorie.

4.3.b. Le gestionnaire ajoute la nouvelle catégorie.

4.3.c. Le système ajoute la nouvelle catégorie.

4.3.d. Le système demande d’éditer la table des tarifs.

4.3.e. Le gestionnaire édite la table des tarifs.

4.3. f. Le système enregistre les modifications.

Scenario2 : Vendre avion

Objectif : supprimer un avion utilisable par les pilotes.

Acteur concerné : le gestionnaire.

37
Précondition : l’avion doit être utilisable par les pilotes.

Post condition : l’avion est supprimé.

Scénario nominal :

1. Le système affiche le formulaire de vente d’un avion.

2. Le gestionnaire saisit les caractéristiques de l’avion vendu.
3. Le gestionnaire valide les informations saisies.
4. Le système vérifie les informations saisies.
4.1. Le système vérifie si les informations saisies correspondent à un avion.
5. Le système demande une confirmation de vente.
6. Le gestionnaire valide la vente.
6.1. Le système vérifie si l’avion n’est pas le seul de sa catégorie.
7. Le système supprime l’avion de la liste des avions utilisables par les pilotes.

Scénarios alternatifs :
4.1. Les informations saisies ne correspondent à aucun avion.
4.1.a. Le système affiche un message d’erreur.
6.1. L’avion est le seul de sa catégorie.
6.1.a. Le système supprime la catégorie correspondante à la table des tarifs.

Scenario3 : Perdre un avion

Objectif : supprimer un avion de la liste des appareils disponibles.

Acteur concerné : le gestionnaire.

Précondition : l’avion doit être dans la liste des appareils disponibles.

Scénario nominal :

1. Le système affiche le formulaire de perte d’un avion.

2. Le gestionnaire remplit ce formulaire avec les caractéristiques de l’avion perdu.
3. Le gestionnaire valide les informations saisies.
4. Le système vérifie les informations saisies.
4.1. Le système vérifie si les informations saisies correspondent à un avion.
5. Le système demande une confirmation de perte.

37
 6. Le gestionnaire valide la perte.
6.1. Le système vérifie si l’avion n’est pas le seul da sa catégorie.
7. Le système supprime l’avion de la liste des avions utilisables par les pilotes.

Scénario alternatif :

4.1. Les informations saisies ne correspondent à aucun avion.

4.1.a. Le système affiche un message d’erreur.
6.1. L’avion est le seul de sa catégorie.
6.1.a. Le système supprime la catégorie correspondante à la table des tarifs.

Scenario4 : Editer les caractéristiques d’un avion

Objectif : modification des caractéristiques d’un avion.

Acteur concerné : le gestionnaire.

Précondition : l’avion doit être existant.

Scénario nominal :

1. Le système affiche le formulaire d’édition des caractéristiques d’un avion.

2. Le gestionnaire sélectionne l’avion à modifier.
3. Le gestionnaire modifie les caractéristiques de l’avion sélectionné préalablement.
4. Le gestionnaire valide ces nouvelles caractéristiques.
5. Le système vérifie les caractéristiques.
5.1. Le système vérifie si les informations sont conformes.
5.2. Le système vérifie si les informations correspondent à un avion.
6. Le système enregistre les modifications.

Scénario alternatif :

5.1. Les informations saisies ne sont pas valides.

4.1.a. Le système affiche un message d’erreur.
4.1.b. Le système demande de retourner à l’étape 3.
5.2. Les informations saisies correspondent à un avion.
5.2.a. Le système affiche un message d’erreur.
5.2.b. Le système demande de retourner à l’étape 3.

37
 Scenario5 : contrôler visites techniques

Objectif : enregistrer une visite technique.

Acteur concerné : le gestionnaire.

Précondition : l’avion doit être existant.

Post-condition : enregistrement d’une visite technique.

Scénario nominal :

1. Le système affiche le formulaire des visites techniques.

2. Le gestionnaire saisit les informations de l’avion qui a subi une visite.
3. Le gestionnaire valide les informations saisies.
4. Le système vérifie les informations saisies.
4.1. Le système vérifie si les informations saisies sont valides.
4.2. Le système vérifie si les informations saisies correspondent à un avion.
5. Le système enregistre ces informations.
6. Le système notifie sur la date de la prochaine visite.

Scénario alternatif :

3.1. Les informations saisies ne sont pas valides.

3.1.a. Le système affiche un message d’erreur.

3.1.b. Le système demande de retourner en 2.

3.2. Les informations saisies ne correspondent pas à un avion.

3.2.a. Le système affiche un message d’erreur.

3.2.b. le système demande de retourner en 2.

37
 8. Diagrammes de séquence
a) Ajouter avion
DiagrammeSequence_1 ajout avion

IHM Avion Categorie

gestionnaire

loop [tant que informations invalides]

affichage du formulaire

saisie des informations

verications informations

verification avions

get avion()

alt avion existe

Cet avion existe deja

else
verification categorie

alt categorie n'existe pas

loop [informations non valide]

affiche formulaire de categorie

ajout d'une categorie

<<create>>
:categorie1
edition de la table de tarifs creer

demande d edition de la table des tarifs

enregistrer modification

ajout d un nouvel avion

add avion()

else
ajout de l avion

add avion()

ajout de l avion

create
:achat

37
 n) Vendre avion
DiagrammeSequence vente

:IHM :AVION :categorie

gestionnaire
loop [informations non valides]
demande daffichage du formulaire

affichage formulaire de vente

saisie des informations

verification d infos

get avion()

alt avion existe pas

cet avion n existe pas

else
confirmation de vente
validation
get cat()
get all()

opt [avion est seul]

<<destroy>>
delete cat()

<<destroy>>
delete avion()

<<create>>
:vente
creer
avion vendu

37
 o) Perdre un avion

DiagrammeSequence perte

:IHM :avion :categorie

gestionnaire

loop [information non valide]

demande daffichage du formulaire

formulaire de declaration de perte

saisie des infos avion

verification des infos saisie

getavion()

alt avion nexiste pas

cet avion nexiste pas

else
confirmation de perte
validation perte

verifications
get cat()

get-all()

opt [ avion seul]

<<destroy>>
delete cat ()

<<destroy>>
del ete avion

avion perdu

37
 p) Editer les caractéristiques d’un avion
DiagrammeSequence edition

:IHM :AVION

gestionaire

loop [infos non valide]

formulaire deition

saisie des informations

verifications d infos

verification avion

get avion()

alt avion nexiste pas

cet avion nexiste pas

else
validation dedition

enregistrement

37
 q) Contrôler visites techniques
visite technique

IHM :avion

gestionnaire
demande-d-avion

loop [ infos invalide]

form-visite

saisie-infos

verification infos

get-avion()

alt avion-n-existe-pas
cet avion n-existe pas

else
<<create>>
visite
creer

visite enregistree

37
 9. Diagramme de classe
categorie
- nom : char
- typre : char
- description : char
+ get() () : java.lang.Object
...
1..1
correspond

compte 0..*
- solde : char visite subit
+ debiter () : void - date : date
+ crediter () : void + get () : java.lang.Object 1..1 1..*
... apareil appartient
compte
... avion
1..1
debiter/crediter - immat : int
- infotech : char
+ ajouter () : void
+ perdre () : void
+ delete () : void
+ editer () : void
+ get () : java.lang.Object
+ affecter () : char
+ get_nbre_heure () : int
...
1..*
est concerné
0..*
posseder
0..1
mvtcomptable
concerne
- date : Date
- type : char
- libele : char
- nature : char

10. Diagramme de composant

<<component>>
Composant avion

categori e
compte
- nom : char
- sol de : float - type : char
+ debiter () : voi d - descri ption : char
+ crediter () : voi d
compte
...
1..1
1..1
Port_1

gestion avion avion 1..*

- nom : char
- i nfotech : char
+ aj outer () : voi d
+ del ete () : voi d
+ edi ter () : voi d 1..1
1..1 + get () : java.l ang.Object
+ affecter () : voi d
1..* + get_nbre_heure () : int
...
1..*
mvtcomptable 1..*
- date : Date
- l ibele : char visi te
- nature : char
- date : date

37
 IV. DIAGRAMME DE DEPLOIEMENT

serveur de base de donnees(MySql 5.5)

.sql

pc client

1..1

.ico
.js
TCP/IP 3306

.css .jpg
.html 1..1

CPU: 2.0 DUAL CORE RAM: 2Go DD:50Go serveur web (apache 2)

Bibliotheque
pour rendre les
pages html en
0..* fichier
.pdf pdf(factures)

TCP/IP 8080
1..1
.php

Fichier de
certification
pour le .crt
protocole
SSL

 Serveur web (apache 2) : Il contient des pages web qui seront distribuée au client en
interrogeant un serveur de base de données ;
 Serveur de base de données (MySQL 5.5) :il contient la base de données du système ;
 PC client :il contient un navigateur qui va se connecter avec le serveur web par des
requêtes HTTP

37
 V. DIAGRAMME DE COMPOSANT GLOBAL

gestionCastellet

......

<<component>>
castellet
<<component>>
.
avion
gestionAvion
<<component>> .....
... vol
....
gestionVol

<<component>>
.. pilote Port_2
gestionPilote

<<component>>
compte ......

gestionCompte

37
 Conclusion
Parvenu au terme de notre projet portant sur la modélisation d’une application de gestion
automatisée : l’Aéroclub du Castellet qui en son sein regroupe plusieurs besoins fonctionnels
(gestion pilote, gestion vols et gestion avion), il nous a été demandé d’analyser ce projet suivant
la méthode 2TUP (two track unified process) en utilisant le langage UML. Pour amplifier notre
travail nous avons utilisé le logiciel POWER AMC afin de représenter les différents
diagrammes.

37
 BIBLIOGRAPHIE
 Livre UML2 Joseph Gabay, David Gabay;
 Logiciel utiliser: PowerAMC

ii