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.
 Présentation de la méthode 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.
 I. Gestion des pilotes
1. Diagramme de cas d’utilisation
a) Diagramme

AEROCLUB

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

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.
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

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

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.

2. Diagramme de séquence
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()
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()
Edtier les noms avec ou sans caractéristiques

:IHM :Pilote

Gestionnaire
demande d'afficher

getAll()

Affichage de liste de tous les pilotes

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
 achat fournitures

:IHM :Pilote :Compte cpte_entreprise fourniture

Gestionnaire

Saisi des informations d'achats

validation des informations

getSolde()

Fonction qui
solde_suffisant()
compare le
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

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
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é

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
visite_medicale mouvement_comptable
0..1
- Type : String
- intitule : String
- date : Date - Nature : String
0..* - Date : Date
- heure : int
- Libelle : String
- Montant : int
Categorie
- type_avion : String
- description : String
+ get () : int
...

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
 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

b) Description textuelle des cas d’utilisation

Description textuelle des cas d’utilisation :

Cas d’utilisation : <<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.
3.1. Le système vérifie si les informations sont conformes.
 4. Le système renvoi un message de validation de l’enregistrement d’un plan de
vol.
 Scenario alternatif :

3.1. Les informations ne sont pas valides.

3.1.1. Le système renvoi un message d’erreur et ramène l’utilisateur à

l’étape1.

Cas d’utilisation : <<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.
2.1. Le système affiche la liste des vols de l’avions ou du pilote.
 Scenario alternatif :

2. l’avion ou le pilote n’existe pas dans le système.

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

nominal.

2. Diagramme de séquence
 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

 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

3. 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 Avion
1..* 1..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 () : void
- prix_vol : int correspond + Get_nbr_heure () : int
+ ajouter () : void
+ Get_liste () : Character
+ delete () : void
...
1..*
1..* correspond
effectue

1..1 categorie
1..* appartenir
possede + type_avion : Character
+ description : Character
mouvement_comptable
+ get () : j ava.lang.objet
1..1 + type : Character ...
affecter 1..*
+ date : Date
attribuer
Pilote + libelle : Character
+ montant : Float
+ nom : Character
+ prenom : Character + nature : Character
+ adresse : Character
+ habilitation : Character
1..* 1..*
+ Get () : java.lang.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 : Fl oat
+ matricule : Character
+ crediter () : void
+ Debi ter () : void ...
+ crediter () : void

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

4. 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
...
 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

b) Description textuelle des cas d’utilisation

Cas d’utilisation 1 : « 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.

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.

Cas d’utilisation 2 : « Vendre avion »

Objectif : supprimer un avion utilisable par les pilotes.

Acteur concerné : le gestionnaire.

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.

Cas d’utilisation 3 : « 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.
 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.

Cas d’utilisation 4: « 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.
Cas d’utilisation 5 : « 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.

2. Diagrammes de séquence
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
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
DiagrammeSequence perte

:IHM :avion :categorie

gestionnaire

loop [information non valide]

demande daffichage du formulaire

formulaire de declaration de perte

saisie des infos avi on

verificati on des infos saisi e

getavion()

alt avion nexi ste pas

cet avion nexi ste pas

else
confirmation de perte
validation perte

verifications
get cat()

get-al l()

opt [ avion seul ] <<destroy>>

delete cat ()

<<destroy>>
delete avion

avion perdu
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
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

3. 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

4. Diagramme de composant
 <<component>>
Composant avion

categorie
compte
- nom : char
- solde : float - type : char
+ debiter () : void - description : char
+ crediter () : void
compte
...
1..1
1..1
Port_1

gestion avion avion 1..*

- nom : char
- infotech : char
+ ajouter () : void
+ delete () : void
+ editer () : void 1..1
1..1 + get () : java.lang.Object
+ affecter () : void
1..* + get_nbre_heure () : int
...
1..*
mvtcomptable 1..*
- date : Date
- libele : char visite
- nature : char
- date : date

IV. Diagramme de déploiement

 serveur de base de donnees(MySql 5.5)

.sql

pc client

1..1

.ico
.js
TCP/IP 8080

.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 3306
1..1
.php

Fichier de
certification
pour le .crt
protocole
SSL

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 language uml. Pour
amplifier notre travail nous avons utilisé le logiciel POWER AMC afin de représenter les
différents diagrammes.