|
REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
UNIVERSITE PROTESTANTE DE LUBUMBASHI
 
Faculté des Sciences Informatiques
Octobre 2011
Fait par CHIKURU MUGISHO Alain
Travail présenté et défendu pour
l'obtention du grade de gradué en sciences informatiques
Conception d'une application web de Suivi des passagers
sur tous les vols nationaux et internationaux
(Cas de la RVA Lubumbashi)
REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
UNIVERSITE PROTESTANTE DE LUBUMBASHI
  
Faculté des Sciences Informatiques
Année Académique 2010-2011
Fait par CHIKURU MUGISHO Alain
Travail présenté et défendu pour
l'obtention du grade de gradué en sciences informatiques
Dirigé par : Ass. Patrick KASONGA
Le Bonheur n'est ni un simple plaisir, ni une
conséquence de la richesse,
C'est le résultat d'un travail actif bien plus que la
jouissance passive du plaisir.
Votre succès dépend de votre propre effort
individuel dans le voyage de la vie et dans la façon d'éviter
certains écueils dangereux.
La formation personnelle, suite de ce que vous avez appris
à l'école, est nécessaire.
Va de l'avant avec confiance.
Pilote ton canot toi-même.
LORD BADEN POWELL
EPIGRAPHE
DEDICACE
A mes chers parents MUGISHO Dieudonné et NALULERHA
Anastasie en témoignage de leur amour et tendresse, leur sacrifice, leur
éducation spirituelle et morale qu'ils m'ont transmise ainsi que
leurs précieux conseils qui m'ont conduit à la réussite
dans mes études ;
A tous mes frères et soeurs,
A tous ceux qui m'ont aidé dans la réalisation de
ce travail ;
Et à tous ceux que j'aime et qui m'aiment ;
A vous tous, je dédie ce travail
CHIKURU MUGISHO Alain
AVANT-PROPOS
Les règlements universitaires ont institué
depuis plusieurs années l'exigence pour tout finaliste d'un cycle
universitaire de rédiger un travail scientifique. C'est dans ce cadre
que nous réalisons ce présent travail. Etant donné que ce
travail est un fruit des efforts de plusieurs personnes, nous ne pouvons passer
sans leur faire un mot de gratitude.
Nous profitons de cette occasion pour remercier le tout
puissant, notre Dieu, qui nous a donné cette grâce d'être
toujours en vie pour parvenir à cette réalisation.
Nous remercions de façon particulière l'Ass.
Patrick KASONGA, qui malgré ses multiples occupations académiques
et familiales s'est mis à notre disposition et a accepté de
diriger notre travail. Ses observations, ses remarques, ses conseils nous ont
permis d'élaborer un travail répondant aux normes
scientifiques.
Nos remerciements s'adressent aussi à toutes les
autorités académiques et administratives ainsi qu'à tous
les professeurs, chefs de travaux et assistants de la faculté des
sciences informatiques de l'Université Protestante de Lubumbashi pour
leur formation intellectuelle.
Nous exprimons notre sincère gratitude à
l'égard de nos parents : papa MIKOMBE KIBAWA et maman SAFI, MUGISHO
D. et NALULERHA A. pour leur encadrement et leur soutient qui nous ont permis
à arriver à cette réalisation.
J'adresse aussi ma plus vive reconnaissance à Papa
Willy KAHAMANYI et sa famille, au Père Franco BORDIGNON, à Papa
Roger BIRHINGANINE et sa famille, à Papa Dieudonné BULAKALI et sa
famille, à l'oncle Honoré CHIBI et sa famille ; pour leur
encouragements et conseils ainsi que leur soutiens dans des moments
difficiles.
Nous n'avons pas oublié nos tantes, oncles,
frères et soeurs, cousins et cousines : Aline CHITO, Eveline
BISIMWA, Yvette MUKONGO, Jackson ZAHINDA, Bienfait HAMULI, Faida BALIMBA, Ida
CHIBI, Delphin MULUMEODERWA; trouvez ici nos sincère remerciements pour
votre amour et soutient.
A vous tous amis et compagnons de lutte : Alain CIMANGA,
Cyrille MYAMPI, Delphin ASTAJABU, KIHUYA NGOY, Paulin DEPOORTER, Etienne
MUSAFIRI, Landry KABANGI, André NGOY, Chancelle KYUNGU, Jimmy
MEMBA, Cherif AMISI, KALUME Mick, Bertin FUNDISHO, Delphin MUKUPA, Alain
KABANZA, Touraco YANNICK, Gaylord KASONGO, Innocent BULAKALI, Justin BYAMUNGU,
Vincent KIBAWA, Jules MAMBO, Ass. Ruphin, Francine KANANE,...merci pour avoir
combattu à nos côtés pour un seul et même but.
Finalement, je remercie tous ceux qui n'ont
épargné aucun effort, de près ou de loin, pour me
permettre d'accomplir mon travail et j'espère que ça sera le bon
départ pour des travaux ultérieurs.
O. INTRODUCTION
0.1 GENERALITES
Le moyen de communication a toujours été
un besoin et une nécessité pour l'être humain. Le fait de
chercher à échanger le plus grand nombre d'informations dans un
délai plus court et parfois à des distances plus grandes
constitue un grand défi que les inventeurs et les chercheurs se sont
décidés de relever en faisant progresser des techniques de la
communication et de l'information : de l'invention de l'écriture
à la création des réseaux organisés de
télécommunication, installés depuis plus d'un
siècle dans notre vie quotidienne.
L'internet, incontournable que ce soit dans notre vie
privée ou sociale, offre divers services parmi lesquels la messagerie
électronique, le web, etc.
Le web, nom anglais signifiant « Toile »
et contraction de Wold Wide Web (toile mondiale), est une possibilité
offerte sur le réseau internet de naviguer entre des documents (pages
web) via des liens hypertextes. Ainsi, le web offre une opportunité
à toute organisation d'automatiser son système d'échange
d'information et de communication avec ses différents partenaires.
Les possibilités d'accès à distance aux
applications de gestion via internet ont permis à ces organisations de
rendre plus rentables leurs activités principales et plus rapide le
traitement de grandes quantités d'informations.
Pour ce faire, ces organisations sont appelées à
observer, analyser, comprendre leur système pour concevoir des
applications web qui correspondent à leurs besoins.
En informatique, lorsqu'un ensemble de codes permet aux
utilisateurs de réaliser des tâches spécifiques dans le
cadre d'une activité d'un domaine spécifique, ces codes sont
qualifiés d'application. Alors, si ce sont des documents web, lorsque
ceux-ci sont composés de manière structuré pour permettre
aux utilisateurs d'accomplir des tâches relatives à une
activité, on parlera d'application web. Sachant que chaque organisation
a toujours des problèmes spécifiques qui lui sont propres,
exigeants une étude bien appropriée, dans le cadre de notre
travail nous allons faire une étude de mise au point d'une application
web de suivi des passagers sur tous les vols (nationaux et internationaux) et
cela dans le cadre de la Régie des Voies Aériennes (RVA) Katanga.
0.2 PROBLEMATIQUE
Dans le transport aérien le suivi des passagers est un
domaine très important pour la sécurité nationale ainsi
que celle des passagers eux-mêmes.
En ce jour à la RVA/Katanga, le suivi et
l'identification des passagers est encore manuel, ce qui occasionne de la
lenteur dans le travail, la possibilité de perte de certaines
informations importantes liées aux passagers, la possibilité
d'erreur dans l'élaboration manuelle des manifestes, la
possibilité d'intrusion des passagers ne figurant pas sur le manifeste
passager dans l'appareil de vol au profit des agences d'aviation ou autres
agents de la RVA, ainsi que la mauvaise conservation des données sur des
papiers et cahiers exposés à l'usure ou aux intempéries.
Pour arriver à pallier à ces différents
problèmes et à automatiser le suivi des passagers, nous
préconisons la mise au point d'une application web. Pour y parvenir nous
nous posons les questions suivantes :
§ Comment pouvons-nous arriver à modéliser
le suivi des passagers sur tous les vols au niveau de la RVA/Katanga ?
§ Quelle application convient le mieux à cette
gestion ?
0.3 HYPOTHESE
Etant donné que la problématique a
déjà été posée, il est important d'y
assimiler quelques réponses provisoires, les quelles réponses
pourront être confirmées ou infirmées à la fin de ce
travail.
Ainsi, vu notre sujet, nous pouvons envisager les
possibilités suivantes :
· Utiliser le langage UML avec la méthodologie UP
pour bien modéliser le suivi des passagers sur tous les vols.
· Pour ce suivi, nous avons trouvé que
l'application qui convient est une application web.
0.4 DELIMITATION
SPATIALE
Dans l'espace notre étude porte sur la
Régie des Voies Aériennes (RVA) Katanga sise à
l'aéroport de la Luano à Lubumbashi. Nous nous limiterons juste
au contrôle des passagers affectés sur différents vols.
0.5 CHOIX ET INTERET DU
TRAVAIL
Nous avons choisi de fixer notre étude sur la
conception d'une application web de contrôle des passagers sur tous les
vols parce que nous avons constaté que dans la plupart des
aéroports congolais, ce contrôle, permettant de connaitre
l'identité des passagers, est encore manuel.
Etant donné que le champ d'action de notre sujet est
trop vaste, nous avons décidé de faire notre étude
seulement dans le cas de la RVA/Katanga. Cette étude peut
intéresser :
Ø Le gouvernement de la République
Démocratique du Congo dans le cadre de son devoir de garantir une forte
sécurité à sa population.
Ø Les responsables de la RVA dans l'objectif de rendre
plus souple le contrôle et l'identification des passagers sur base d'un
manifeste numérique.
Ø Différentes agences de renseignement qui
peuvent y trouver un moyen plus aisé de retrouver les suspects qui
entrent ou qui quittent le pays par voie aérienne.
Ø Tout chercheur, étudiant ou professionnel,
ainsi que toutes les personnes qui pourront lire ce travail ; ils y
trouveront une matière pouvant leur permettre de bien comprendre la
pratique de la conception et développement des applications web et
d'approfondir les recherches dans ce domaine.
0.6 METHODES ET
TECHNIQUES
0.6.1 Méthode
La méthode est définie comme l'ensemble des
règles pour conduire raisonnablement, logiquement nos pensé ou
encore la voie à suivre pour atteindre le but qu'on s'est
fixé1(*).
Dans le cas de notre étude nous avons choisi de
concevoir notre système d'information avec le langage de
modélisation UML (Unified Modeling Language) en utilisant la
démarche UP (Unified Process) comme méthode de developpement.
Le langage UML est né de la fusion de 3 trois grandes
méthodes : l'OMT (Object Modeling système) de James
RUMBAUGH, l'OOD (Object Oriented Developpement) de Grady BOOCH et l'OOSE
(Object Oriented Software Engineering) d'Ivar JACOBSON. Le processus de
développement UP, associé à UML, met en oeuvre les
principes suivants 2(*):
· processus guidé par les cas
d'utilisation,
· processus itératif et incrémental,
· processus centré sur l'architecture,
· processus orienté par la réduction
des risques.
Ces principes sont à la base du processus unifié
décrit par les auteurs d'UML.
Les avantages du développement itératif se
caractérisent comme suit :
· les risques sont évalués et
traités au fur et à mesure des itérations,
· les premières itérations
permettent d'avoir un feed-back des utilisateurs,
· les tests et l'intégration se font de
manière continue,
· les avancées sont évaluées
au fur et à mesure de l'implémentation.
0.6.2 Techniques :
Selon Madeleine GRAWITZ « La technique
représente les étapes d'opération limitées,
liées à des éléments pratiques concrets
adaptés à un but défini, (...)3(*) ».
En effet, les informations et données collectées
et utilisées dans le cadre de notre étude, ont été
réunis en utilisant les techniques suivantes :
· Technique d'interview : cette technique est
définie comme un outil permettant un contact entre l'enquêteur et
l'enquêté afin de recueillir certaines informations au près
de l'enquêté concernant un objet ou un fait précis4(*). Cette technique nous a permis
de contacter et de poser différentes questions à certains agents
de la RVA pour arriver à trouver des informations utiles pour la
compréhension de notre domaine de travail.
· Technique documentaire : Cette technique a
été un objet utile pour la réalisation du corps de notre
travail suite à une lecture approfondie de certains documents. Elle
consiste à analyser, à étudier les documents porteurs
d'informations étant en relation avec notre objet d'étude.
0.7 SUBDIVISION DU
TRAVAIL
Notre travail est subdivisé en cinq grandes parties
essentielles, il s'agit de l'introduction, trois chapitres et la conclusion.
Pour avoir une idée d'ensemble de notre travail nous
donnons un aperçu de ce que nous allons faire dans tous les trois
chapitres.
Ø Le chapitre I : Intitulé
« Analyse préalable » portera sur une étude
profonde du système existant pour en déduire les failles.
Ø Le chapitre II : « Analyse et
conception du système Informatique » va nous amener à
modéliser le système futur à mettre en place.
Ø Le chapitre
III : « Implémentation et
déploiement ».Dans ce chapitre il sera question de faire le
choix de la technologie logiciel à utiliser pour le déploiement
de notre application et à présenter quelques interfaces de notre
application.
Chap. I ANALYSE
PREALABLE
Dans cette partie, l'objectif est d'effectuer une étude
profonde nous permettant de bien prendre connaissance de notre domaine
d'application et ainsi établir des points faibles et des points forts
permettant une approche du problème.
1.1 PRESENTATION DE LA
RVA
1.1.1 Historique
La RVA est une entreprise publique créée par
l'ordonnance loi n° 72-013 du 21/02/1972 régie par la loi
n°72-002 du 06/01/1978 et l'ordonnance loi n°78-200 du 05/05/1978.
Elle est placée :
-techniquement : sous la tutelle du ministère de
transport et de communication ;
-administrativement : sous le ministère de
portefeuille
La RVA a ses représentants autonomes dans toutes les
provinces de la République Démocratique du Congo dont celle du
Katanga.
1.1.2 Objectif de la RVA
Entant qu'entreprise publique, la RVA a pour mission de taxer
et de percevoir les redevances aéronautiques et
extra-aéronautiques sur l'étendue de la province du Katanga. Elle
s'occupe aussi de la gestion de la réhabilitation des infrastructures
aéroportuaires.
Les objectifs peuvent se résumer en ces quatre
points :
- construire, aménager et entretenir les
aérodromes et leurs dépendances ;
- assurer la sécurité de la navigation
aéronautique ;
- percevoir pour son compte les redevances et les taxes
instituées sur les aéroports et leur dépendance ;
- participer, à l'aide des autorités
compétentes, à l'élaboration du plan de formation et de la
perfection du personnel.
Notons de ce fait que la RDC compte au moins 130
aérodromes dont 101 sont ouverts à la circulation aérienne
publique (CAP) et 6 aérodromes à usage restreint (militaire).
Selon l'organisation internationale de l'aviation civile (OACI), 4
aéroports de la RDC sont ouvert au trafic international, il s'agit
de :
· l'aéroport de N'djili à Kinshasa
· l'aéroport de Luano de Lubumbashi
· l'aéroport de Goma à Goma
· l'aéroport de Bangoka à Kisangani
Il est à noter que la RVA Luano est repartie en 6
divisions chapotées chacune par un chef de division ; celui-ci
assisté par des services et des bureaux ; il s'agit de :
1. la division de circulation aérienne
2. la division administrative & financière
3. la division radioélectrique
4. la division sureté et facilitation
5. la division de moyens généraux
6. la division commerciale
1.2 DESCRIPTION TEXTUELLE
DU PROCESSUS METIER
Le processus de notre domaine se déroule
de la manière suivante :
La Régie des Voies Aériennes possède un
contrat avec toutes les compagnies d'aviation oeuvrant en RDC. Le jour
où une compagnie a un vol ; deux heures avant, elle dépose
au bureau de navigation (BNA) de la RVA différents documents en rapport
avec le vol, dont le manifeste passager, le manifeste fret, le plan de vol,
etc.
Pour ce qui est de notre domaine d'étude, le document
concerné est le manifeste passager. Ce document est
élaboré par la compagnie et contient les informations
suivantes :
- La date du vol
- Le lieu d'embarquement
- Le lieu de débarquement
- L'identifiant de l'avion
- Le trajet complet
- Le numéro du vol
- Le numéro, nom et prénoms du passager
- Le numéro de fauteuil du passager
- Son genre : celui-ci peut être soit masculin,
féminin, bébé ou enfant
- Le nombre de bagage du passager
- Le poids des bagages du passager
- Le numéro du ticket du passager
Un passager est du genre bébé s'il a un
âge qui va de 0 à 2 ans et du genre enfant si son âge varie
entre 2 et 6 ans. Pour les passagers dont l'âge est supérieur
à 6, le genre est déterminé par leur sexe : F pour le
féminin et M pour le masculin. Il est à noter que dans le bureau
de navigation, il y a trois services différents :
Ø La vérification des trafics aériens
(VTA) : ce service se charge du control des passagers figurants sur le
manifeste et ceux qui monte dans l'appareil de vol. Ce control se passe au pied
de l'avion avant le décollage.
Ø Le bureau de navigation (BNA) :c'est le service
qui porte le nom de tout le bureau et qui se charge de la réception des
tous les documents ayants trait au vol dont le manifeste passager après
leur élaboration par les compagnies d'aviation. C'est ce service qui
communique avec la tour de contrôle et le bureau de statistique pour leur
renseigner sur les différents mouvements de vol.
Ø Le service commercial : ce service se charge du
calcul de différentes redevances à payer par les compagnies en
tenant compte des informations se trouvant sur le manifeste ainsi que sur
d'autres documents qui concernent le vol. C'est ce service qui se charge aussi
de l'élaboration du formulaire de trafic. Voici la liste de quelques
redevances :
· Taxe de stationnement : se calcul en fonction de
l'écart d'heure entre l'heure et jour d'atterrissage d'un appareil et
l'heure et jour de son départ par la formule suivante :
Ecart d'heure*0.2$*poids de l'appareil
· Le frais de formulaire fixé à 4$
· Frais de balisage
· Frais de fret taxé à 0.009$ par Kg pour
les vols nationaux et à 0.036$ par Kg pour les internationaux
· La taxe d'embarquement : celle-ci est fixé
en tenant compte du nombre de passagers à embarquer, du nombre de
siège que contient l'appareil et l'espace aérienne à
parcourir par l'appareil (soit le national, soit l'international). Pour les
vols internationaux, la taxe d'embarquement est fixée à 21$ par
passager pour un appareil ayant au maximum 20 sièges et à 26$ par
passager pour un appareil ayant plus de 20 sièges. Pour les vols
internationaux, la taxe d'embarquement est fixé à 35$ par
passager quelque soit le nombre de siège que peut contenir l'appareil.
Ceci peut se résumer dans un tableau comme suit :
|
NOMBRE DE SIEGES
|
TAXE D'EMBARQUEMENT
|
ESPACE DE VOL
|
|
0 à 20
|
21$ par passager
|
NATIONALE
|
|
21 à N
|
26$ par passager
|
|
0 à N
|
35$ par passager
|
INTERNATIONALE
|
· La taxe d'atterrissage : Cette taxe est
fixée en tenant compte du poids de l'appareil (en termes de tonnes).
Voici dans un tableau les différents taux de taxation à
l'atterrissage.
|
POIDS DE L'APPAREIL (en Tonnes)
|
TAXE D'ATTERISSAGE REDEVABLE
|
ESPACE DE VOL
|
|
1à 3 T
|
5$
|
Nationale
|
|
12.50$
|
Internationale
|
|
4 à 25 T
|
Poids appareil * 1.6$
|
Nationale
|
|
Poids appareil * 4$
|
Internationale
|
|
26 à 75 T
|
(Poids appareil*3.2$)-40$
|
Nationale
|
|
(Poids appareil*8$)-100$
|
Internationale
|
|
76 à n T
|
(Poids appareil*4.40$)-130$
|
Nationale
|
|
(Poids appareil*11$)-325$
|
Internationale
|
Après réception du manifeste par le BNA,
celui-ci le transmet au service commercial pour l'élaboration d'un autre
document : le formulaire de trafic qui reprend les informations sur le
fret et les passagers. Ce document est remis à la compagnie ou une
quittance à sa place. Une fois les redevances figurants sur le
formulaire sont payées, le service commercial transmet le manifeste
à la VTA pour la vérification au pied de l'avion.
Le formulaire de trafic est constitué de deux sous
formulaires de couleurs différentes :
Ø Le rose pour le départ : celui-ci
contient les informations suivantes :
- Le nom de l'exploitant (la compagnie)
- Le nom de l'aéroport de départ
- Le nom et le code de la ville où se trouve
l'aéroport de destination
- Le code de la ville où se trouve l'aéroport de
départ
- La date de départ
- La nature du vol (régulier ou non régulier)
- Le type de l'aéronef
- L'immatriculation de l'aéronef
- L'heure de décollage
- Piste en service
- Le régime de vol ;
Par balisage, on entend l'ensemble de repères qui
aident le pilote à avoir une vision nette de la piste. Cela, si
l'atterrissage ou le décollage s'est effectué la nuit.
Un vol est de régime VFR (Visual Flight Roul) ou vol
à vue si le pilote voit des repères naturels, c.à.d. le
relief, la flore, l'hydrographie ; il est de régime IFR (Instrument
Flight Rouler) ou vol aux instruments humaines (routes, chemins de fer, ville,
monument...).
Un vol est dit régulier s'il exploite
régulièrement une ou plusieurs lignes et dans le cas contraire il
est dit irrégulier.
Ø Le vert pour l'arrivé : il contient les
informations semblables à celles du formulaire de départ à
la seule différence qu'ici on parlera de l'aéroport de
provenance, de la date d'arrivé, de l'heure d'arrivé et du
stationnement.
Comme le formulaire de trafic renseigne sur les
passagers et les frets, on peut y retrouver les éléments ci
après :
- AD (adulte) : désigne les passagers adultes
- CH (enfants) : désigne les passagers enfants
- INF(Infant) : désigne les bébés
- Les frets sont mentionnés en Kg
La quittance est un document reprenant les mêmes
informations que le formulaire de trafic. Celle-ci est remise à la
compagnie pour preuve de paiement des taxes liées au vol. La quittance
est donc une preuve de paiement pour les compagnies d'aviation.
1.3 MODELISATION DU
METIER
Objectif de la modélisation du
métier
La modélisation du métier
vise à mieux connaître le fonctionnement et les règles qui
régissent le système organisationnel dans lequel on envisage
implanter un nouveau système informatisé. Si l'on souhaite que le
système informatique à concevoir corresponde aux exigences
réelles du métier ciblé, il est vital de bien identifier
les objectifs, les priorités, les règles de gestion et les
processus clés de l'organisation avant toute tentative
d'informatisation.
L'importance que revêt cette
activité pour le reste du projet justifie son positionnement en amont
par rapport aux autres activités.
Présentation du langage de modélisation
UML
UML (Unified process) se définit comme un langage de
modélisation graphique et textuel destiné à comprendre et
décrire des besoins, spécifier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer
des points de vue.5(*)
UML n'est pas une méthode (i.e. une description
normative des étapes de la modélisation) : ses auteurs ont en
effet estimé qu'il n'était pas opportun de définir une
méthode en raison de la diversité des cas particuliers. Ils ont
préféré se borner à définir un langage
graphique qui permet de représenter, de communiquer les divers aspects
d'un système d'information (aux graphiques sont bien sûr
associés des textes qui expliquent leur contenu). UML est donc un
métalangage car il fournit les éléments permettant de
construire le modèle qui, lui, sera le langage du projet.
UML 2 s'articule autour de treize types de diagrammes, chacun
d'eux étant dédié à la représentation des
concepts particuliers d'un système logiciel. Ces types de diagrammes
sont répartis en deux grands groupes :6(*)
· Six diagrammes structurels :
- Diagramme de classes : il montre les briques
de base statiques : classes, associations, interfaces, attributs,
opérations, généralisations, etc.
- Diagramme d'objets : il montre les instances
des éléments structurels et leurs liens à
l'exécution.
- Diagramme de packages : il montre
l'organisation logique du modèle et les relations entre packages.
- Diagramme de structure composite : il montre
l'organisation interne d'un élément statique complexe.
- Diagramme de composants : il montre des
structures complexes, avec leurs interfaces fournies et requises.
- Diagramme de déploiement - Il montre le
déploiement physique des « artefacts » sur les ressources
matérielles.
· Sept diagrammes comportementaux :
- Diagramme de cas d'utilisation : il
montre les interactions fonctionnelles entre les acteurs et le système
à l'étude.
- Diagramme de vue d'ensemble des interactions :
il fusionne les diagrammes d'activité et de séquence pour
combiner des fragments d'interaction avec des décisions et des flots.
- Diagramme de séquence : il montre la
séquence verticale des messages passés entre objets au sein d'une
interaction.
- Diagramme de communication : il montre la
communication entre objets dans le plan au sein d'une interaction.
- Diagramme de temps : il fusionne les
diagrammes d'états et de séquence pour montrer l'évolution
de l'état d'un objet au cours du temps.
- Diagramme d'activité : il montre
l'enchaînement des actions et décisions au sein d'une
activité.
- Diagramme d'états : il montre les
différents états et transitions possibles des objets d'une
classe.
La demarche UP (Unified Process)
Processus unifié (PU ou UP en anglais pour Unified
Process) est une méthode de prise en charge du cycle de vie d'un
logiciel et donc du développement, pour les logiciels orientés
objets. Le Processus Unifié (UP, pour Unified Process) est un processus
de développement logiciel « itératif et incrémental,
centré sur l'architecture, conduit par les cas d'utilisation et
piloté par les risques.7(*)
On dit de la méthode UP qu'elle est
générique c.à.d. qu'elle définit un certain nombre
de critères de développement, que chaque société
peut par la suite personnaliser afin de créer son propre processus plus
adapté à ses besoins. C'est dans ce cadre que la
société Valtech a crée la méthode 2TUP. 2TUP
signifie « 2 Track Unified Process» .C'est un processus qui
répond aux caractéristiques du Processus Unifié.
Le processus 2TUP apporte une réponse aux contraintes
de changement continuel imposées aux systèmes d'information de
l'entreprise. En ce sens, il renforce le contrôle sur les
capacités d'évolution et de correction de tels systèmes.
« 2 Track» signifie littéralement que le processus suit deux
chemins. Il s'agit des « chemins fonctionnels » et «
d'architecture technique », qui correspondent aux deux axes de changement
imposés au système d'information.
1.3.1 Identification des
acteurs du métier:
Nous allons maintenant énumérer les
acteurs qui interagissent avec le système dans notre métier, mais
d'abord nous donnons une définition de ce que c'est un acteur.
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é8(*).
Les acteurs du système identifiés dans un
premier temps sont :
1. COMPAGNIE : la compagnie
établie le manifeste passagers. Elle peut le modifier ou le supprimer.
Elle transmet aussi le manifeste passager à la RVA.
2. BNA : Reçoit le manifeste de la part de la
compagnie, le transmet à la VTA et au service commerciale.
3. VTA : s'occupe de la vérification des
passagers lors de leur monté dans l'avion.
4. SERVICE COMMERCIALE : Elabore le formulaire de trafic
en fonction des données se trouvant sur le manifeste ; il s'occupe
aussi de la taxation des redevances.
1.3.2 Diagramme de
contexte du métier:
Le diagramme de contexte est un outil nous permettant d'avoir
une vision globale des interactions entre les activités et les liens
vis-à-vis de l'extérieur. Il permet également de bien
délimiter le champ d'étude.
SERVICE COMMERCIAL
VTA
Système de control de passager
BNA
« ACTOR »
COMPAGNIE
1.3.3 Diagramme
d'activité du métier
Le diagramme d'activités n'est autre
que la transcription dans UML de la représentation du processus telle
qu'elle a été élaborée lors du travail qui a
préparé la modélisation : il montre l'enchainement des
activités qui concourent au processus.9(*)
1.3.4 Capture des besoins
fonctionnels du métier
Cette phase va nous permettre d'identifier
les différents cas d'utilisations de notre métier. Par le biais
des cas d'utilisation, nous serons en contact permanent avec les acteurs du
système en vue de définir les limites de celui-ci, et ainsi
éviter de trop s'éloigner des besoins réels de
l'utilisateur final.
Un cas d'utilisation est une unité cohérente
représentant une fonctionnalité visible de l'extérieur. Il
réalise un service de bout en bout, avec un déclenchement, un
déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation
modélise donc un service rendu par le système, sans imposer le
mode de réalisation de ce service.10(*)
Les différents cas d'utilisation retenus pour notre
métier sont les suivants :
|
NOM DU CAS D'UTILISATION
|
INTENTION
|
ACTION
|
|
Etablir manifeste
|
Transcrire la liste des passager sur un manifeste une fois un vol
est confirmé
|
Saisir les coordonnés de chaque passager, les modifier et
même annuler un passager
|
|
Payer redevances
|
Permettre à la compagnie de s'acquitter des exigences de
la RVA avant tout vol
|
Renseigner paiement, modalité et montant
|
|
Réceptionner manifeste
|
Recevoir tout manifeste venant des compagnies et l'enregistrer
|
Enregistrer manifeste et le transmettre au service commerciale
|
|
Autoriser control
|
Donner l'autorisation à la VTA pour aller faire un control
des passagers montant dans l'appareil
|
Saisir l'autorisation, Annuler et modifier
|
|
Contrôler passager
|
Se rendre compte du nombre de passagers par rapport à
celui se trouvant sur le manifeste
|
Compter le nombre de passager qui montent dans l'appareil
|
|
Elaborer formulaire
|
Permettre au service commerciale d'élaborer un formulaire
de trafic renseignant sur les redevances à par la compagnie
|
Remplir le formulaire de trafic
|
|
Encaisser paiement
|
Percevoir l'argent provenant de la compagnie en fonction du
montant figurant sur le formulaire de trafic
|
Enregistrer paiement, établir une quittance prouvant le
paiement
|
Diagramme de cas d'utilisation du métier
C'est un diagramme qui représente la
structure des grandes fonctionnalités nécessaires aux
utilisateurs du système. C'est le premier diagramme du modèle
UML, celui où s'assure la relation entre l'utilisateur et les objets que
le système met en oeuvre.
Etude des relations entre les cas d'utilisation
1.3.5 Classement des cas
d'utilisations en itération
|
NOM CAS D'UTILISATION
|
PRIORITE
|
RISQUE
|
ITERATION
|
|
Etablir manifeste
|
Haute
|
Haut
|
1
|
|
Etablir formulaire
|
Moyenne
|
Moyen
|
3
|
|
Payer redevance
|
Moyenne
|
Moyen
|
4
|
|
Contrôler passager
|
Haute
|
Moyen
|
7
|
|
Réceptionner Manifeste
|
Haute
|
Haut
|
2
|
|
Autoriser contrôle
|
Moyenne
|
Moyen
|
6
|
|
Encaisser Paiement
|
Moyenne
|
Moyen
|
5
|
1.3.6 Regroupement des cas
d'utilisation en Package
Pour améliorer notre modèle, nous allons
organiser les cas d'utilisation et les regrouper en ensembles fonctionnels
cohérents. Pour ce faire, nous utilisons le concept
général d'UML, le package.
Le package est un mécanisme
général de regroupement d'éléments en UML, qui peut
être utilisé par exemple pour regrouper des cas d'utilisation,
mais aussi des acteurs, des classes.11(*)
Ce diagramme donne une vue d'ensemble du système
structuré en paquetage. Chaque paquetage représente un ensemble
homogène d'éléments du système (classes,
composants...).12(*)
1.3.7 Description textuelle des
cas d'utilisation
1. Nom du cas d'utilisation : Etablir
manifeste
- But : Donner la liste des passagers qui voyagent
à la RVA.
- Résumé : Lorsqu'un vol est
confirmé, l'élaboration du manifeste permet de donner les noms
des passagers qui voyagent dans ce vol.
- Acteurs concernés : Compagnie
- Pré conditions :
· Confirmation d'un vol
· Qu'il y ait au moins un passager
- Scénario nominal :
1. Consulter la liste de réservation
confirmée
2. Remplir les coordonnées des clients sur le
manifeste
3. Saisir les informations sur les bagages des clients
4. Saisir les informations qui concernent le vol
5. La compagnie valide le manifeste
- Flux alternatif :
· Informations manquantes : Dans ce cas le
système averti que les informations obligatoires sont manquantes. Ainsi,
le système reprend à l'étape un (1) du scénario
nominal.
· Informations mal rempli: la compagnie peut modifier les
données mal remplies et ainsi revenir à l'étape cinq (5)
du scénario nominal.
- Post conditions : Manifeste établi et
disponible
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons facilement les concepts métiers suivants :
· Manifeste
· Liste de réservation
· Passager
· Bagage
· Compagnie
2. Nom du cas d'utilisation : Réceptionner
manifestes
- But : Avoir les précisions sur les passagers et
le vol
- Résumé : Après élaboration
du manifeste, la compagnie le remet à la RVA qui le reçoit pour
se rendre compte du nombre de passagers qui voyagent.
- Acteurs concernés : BNA (Principal)
- Pré conditions : Néant
- Scénario nominal :
1. Recevoir dans les mains d'un agent de la compagnie un
manifeste
2. Enregistrer manifeste
3. Valider réception
- Flux alternatif : Néant
- Post conditions : Manifeste reçu au BNA
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons les concepts métiers suivants :
· Manifeste
· Compagnie
3. Nom du cas d'utilisation : Etablir formulaire
de trafic
- But : Mettre au point un document qui montre les
différentes taxes à payer par la compagnie compte tenu du vol.
Résumé : Une fois le manifeste
réceptionné, le service commercial élabore un formulaire
de trafic portant les taxes à payer par la compagnie.
- Acteurs concernés : Service Commerciale
- Pré conditions : -
· Manifeste réceptionné
· Autres documents en rapport avec le vol
réceptionnés
- Scénario nominal :
1. Consulter le manifeste et autre documents en rapport avec
le vol
2. Faire le calcul des redevances
3. Remplir le formulaire de trafic
- Flux alternatif :
· Informations manquantes ou erreur dans le calcul:
dans ce cas il y a alerte signalant qu'il ya erreur dans le calcul et on
reprend à l'étape un (1) du scénario nominal
· Formulaire mal rempli: le service commercial peut
modifier les informations mal remplies
- Post conditions : Formulaire de trafic rempli et les
redevances à payer par la compagnie sont connues.
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons facilement les concepts métiers suivants :
· Manifeste
· Formulaire trafic
· Vol
· Compagnie
4. Nom du cas d'utilisation : Payer
redevances
- But : La compagnie paie sa dette envers la RVA pour
avoir accès au vol.
- Résumé : Après élaboration
du formulaire de trafic, celui-ci est remis à la compagnie pour qu'elle
se rende compte du montant à payer .Après cela la compagnie paie
cette somme au près du service commerciale de la RVA
- Acteurs concernés : Compagnie (Principal),
Service commerciale (Secondaire)
- Pré conditions : - formulaire de trafic
établi
- Scénario nominal :
1. Consulter le formulaire de trafic
2. Passager au guichet du service commercial
3. Payer montant figurant sur le formulaire de trafic
4. Le service commerciale valide le paiement
- Flux alternatif :
· Le montant payé est inferieur au montant
prévu : dans ce cas on revient à l'étape trois (3) du
scénario nominal
- Post conditions : Redevance payé par la
compagnie
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons facilement les concepts métiers suivants :
· Formulaire trafic
· Compagnie
5. Nom du cas d'utilisation : Autoriser
Control
- But : Permettre au service de vérification (VTA)
de faire un control des passagers montant dans l'appareil.
Résumé : Une fois les redevances
payés par la compagnies, le BNA donne une permission au VTA de passer
à un control des passagers au pied de l'avion en fonction du
manifeste.
- Acteurs concernés : BNA (principal), VTA
(secondaire)
- Pré conditions : - Redevances payés et
Paiement validé
- Scénario nominal :
1. Consulter fiche paiement
2. Autoriser control verbalement ou par écrit
- Flux alternatif : Néant
- Post conditions : Control autorisé
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons facilement les concepts métiers suivants :
· Vol
· Compagnie
6. Nom du cas d'utilisation : Contrôler
passager
- But : Vérifier si le nombre de passager inscrit
sur manifeste est le même que celui des passagers qui montent dans
l'avion.
Résumé : Lors du control si le nombre de
passager qui montent dans l'appareil est supérieur à celui de
ceux qui figurent sur le manifeste, la compagnie est appelée à
rentrer au service commerciale pour payer le surplus.
- Acteurs concernés :VTA
(principal) ,Compagnie (secondaire), Service commerciale (secondaire)
- Pré conditions : Autorisation control
accordée
- Scénario nominal :
1. Récupérer liste passagers (manifeste)
2. Aller au pied de l'avion (tarmac)
3. Compter le nombre de passager montant dans l'avion
4. Comparer le nombre obtenu à celui du manifeste
5. Autoriser vol
- Flux alternatif :
· Nombre passager supérieur à celui du
manifeste : dans ce cas on rentre au service commercial pour que la
compagnie puisse payer la taxe pour les passagers de surplus et le processus
reprend à l'étape cinq (5) du scénario nominal.
- Post conditions : Autorisation vol accordée
- Classes candidates du CU : pour ce cas d'utilisation,
nous retenons facilement les concepts métiers suivants :
· Manifeste
· Passager
· Compagnie
1.3.8 Diagramme de classe du
domaine
1.4 CRITIQUE DE
L'EXISTANT
Cette étape a pour objet l'élaboration,
après analyse du domaine d'étude, d'un diagnostic sur les
procédures existantes dans le but d'en dégager les points
positifs et négatifs.
a) Points négatifs : Nous avons
constaté que le système de communication entre compagnies
d'aviation et la RVA en ce qui concerne le dépôt des manifestes
(surtout le manifeste passager) à la RVA est exposé à des
sérieux problèmes et difficultés que nous
détaillons ci-dessous :
En effet, on commence par établir un manifeste au
niveau de la compagnie d'aviation une fois un vol est confirmé ;
après cela le manifeste est apporté par un agent de la compagnie
à la RVA. Ce qui ne permet pas un bon suivi du manifeste du fait que ce
dernier peut subir certaines modifications à l'insu de la RVA pourtant
ce document est d'une grande importance dans le calcul des redevances des
compagnies envers la RVA. Il est à noter que toutes les
opérations depuis l'élaboration du manifeste jusqu'à
l'élaboration du formulaire de trafic sont encore manuelles, ce qui pose
les risques suivants :
- Possibilité de modification des informations
réelles du manifeste par certains agents.
- Possibilité d'erreur lors de l'élaboration du
formulaire de trafic
- Perte éventuelle d'un document avec toutes les
informations qu'il porte
- Recherche peut aisée des informations
antérieurs du fait que celle-ci sont dans des classeurs et tiroirs.
- Contrôle presque difficile de la cohérence et
la redondance des informations
- Impossibilité de partager simultanément les
données entre différents postes de travail.
- Difficulté d'identification des passagers d'un vol
dans le cas de crash ou autre accident mortel.
b) Points positifs : A la régie
des voies aériennes, le contrôle des opérations est bien
géré par des agents bien qualifié qui travaillent sur
différents bureaux dont certains utilisent un ordinateur au niveau de la
comptabilité (service commerciale) et les autres travaillent
manuellement.
Proposition de solution : Vu les
difficultés liées à la communication entre Compagnie
d'aviation et RVA lors de l'élaboration et la transmission du manifeste
passager, nous suggérons la mise en place d'une application informatique
qui permettra l'élaboration et la transmission automatique du manifeste
par les agences d'aviation à la RVA
CHAP II ANALYSE ET
CONCEPTION DU SYTEME INFORMATIQUE
2.1 DEFINITION DES BESOINS
FONCTIONNELS DU SYSTEME INFORMATIQUE
Les besoins du système informatique déterminent
ce que le système doit faire, fournissent aux développeurs une
meilleure compréhension des fonctionnalités du système
qu'ils doivent développer, définissent les contours du
système et fournissent la base de la planification du reste des
activités de développement.
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
3.1 Choix de l'architecture
logique
La technologie Objet requiert une architecture. C'est cette
architecture qui organise les interactions entre objets. On a l'habitude de
regrouper ces objets en classes, ces classes en domaines, et ces domaines en
couches.
Les couches permettent de présenter l'architecture de
l'application. Les équipes de réalisation s'attribuent alors des
responsabilités sur le développement de chaque couche. Aussi, si
modéliser est indispensable, construire une architecture à couche
est un critère de qualité dans le cadre d'un développement
Objet. Reste à choisir le nombre de couches et à définir
leur contenu.
Pour notre application, nous choisissons une architecture en 3
couches distinctes : la couche présentation, la couche
Métier (ou applicative) et la couche d'accès aux données
(DAO).
F La couche « Présentation » est
chargé de tout ce qui est affichage et visible par l'utilisateur
F La couche « Métier » est la
logique métier de l'application, elle est le coeur et c'est elle qui
définit toutes les règles régissant le fonctionnement de
l'application.
F La couche d'accès aux données est
l'intermédiaire entre les autres couches et la Base de
données.
3.1.1 Diagramme de
composants
Le diagramme de composant permet de représenter les
composants logiciels d'un système ainsi que les liens existant entre ces
composants.13(*)
Ce diagramme montre les unités logicielles à
partir desquelles on a construit les systèmes informatiques, ainsi que
leur dépendance ; il représente aussi les concepts connus de
l'existant pour installer et dépanner le système. Il s'agit de
déterminer la structure des composants d'exploitation que sont les
librairies dynamique, les instances de base de données, les
applications, les pros logiciels, les objets distribués, les
exécutables, etc.14(*) Ainsi un composant représente une
entité logicielle d'un système. (Fichier de code source,
programmes, documents, fichiers de ressource .etc.).
Un composant est représenté par une boîte
rectangulaire, avec deux rectangles dépassant du côté
gauche.
Chaque composant est assimilé à un
élément exécutable du système. Il est
caractérisé par :
F un nom ;
F une spécification externe sous forme soit d'une ou
plusieurs interfaces requises, soit d'une ou plusieurs interfaces fournies;
F Un port de connexion.
Le port d'un composant représente le point de connexion
entre le composant et une interface. L'identification d'un port permet
d'assurer une certaine indépendance entre le composant et son
environnement extérieur.
Un composant est représenté par un classeur
avec le mot-clé « composant » ou bien par un classeur
comportant une icône représentant un module.
3.1.2 Déploiement du
système
Dans cette partie nous allons décrire l'implantation
physique de notre application grâce à un diagramme proposé
par UML : le diagramme de déploiement.
Le diagramme de déploiement permet de
représenter l'architecture physique supportant l'exploitation du
système. Cette architecture comprend des noeuds correspondant aux
supports physiques (serveurs, routeurs...) ainsi que la répartition des
artefacts logiciels (bibliothèques, exécutables...) sur ces
noeuds. C'est un véritable réseau constitué de noeuds et
de connexions entre ces noeuds qui modélise cette architecture.15(*)
F Un noeud correspond à une ressource
matérielle de traitement sur laquelle des artefacts seront mis en oeuvre
pour l'exploitation du système. Les noeuds peuvent être
interconnectés pour former un réseau d'éléments
physiques.
F Un artefact est la spécification
d'un élément physique qui est utilisé ou produit par le
processus de développement du logiciel ou par le déploiement du
système. C'est donc un élément concret comme par exemple :
un fichier, un exécutable ou une table d'une base de données.
3.2 Conception de la
persistance
Dans le premier et le deuxième chapitre nous avons eu
à spécifier notre système, la question ici est de savoir
comment seront stockées les informations de notre base de
données. Les bases de données relationnelles sont au centre des
systèmes d'information modernes. La standardisation du langage SQL en
1987 et la mise en réseaux des postes de travail mettent à la
disposition de tous, les données de l'entreprise pour être
analysées, mise en page, médiatisées...
Pour effectuer ce passage du fichier à la relation, du
programme à la requête, nous tiendrons compte des concepts de
bases du modèle relationnel et sa mise en application avec le langage
SQL.
La notation UML (Rational Rose parle de profil UML pour les
bases de données) permet de modéliser un schéma
relationnel (le diagramme de classes représentant un ensemble de
tables). Pour préciser qu'une classe représentera une table, on
utilise le stéréotype <<Table>>. La classe contient
des attributs. On peut relier plusieurs classes entre elles en prenant garde
d'insérer convenablement les clés étrangères. Il
est aussi possible d'utiliser les agrégations pour renforcer le couplage
d'une association.
3.3 Dérivation du
model logique des données.
Nous décrivons dans cette phase les transformations
à effectuer afin de dériver un schéma logique relationnel
ou objet.
Le modèle relationnel est à l'origine du
succès que connaissent aujourd'hui les grands éditeurs de
SGBD (système de gestion de bases de données), à savoir
Oracle, IBM, Microsoft, Informix, Sybase et CA-Ingres. Le but initial de ce
modèle était d'améliorer l'indépendance
données/ traitements.16(*)
Règles de
transformation :
F Chaque entité devient une relation.
F L'identifiant de l'entité devient clé primaire
pour la relation.
F Chaque classe du diagramme UML devient une relation.
F Il faut choisir un attribut de la classe pouvant jouer le
rôle d'identifiant (PK).
F Si aucun attribut ne convient en tant qu'identifiant, il
faut en ajouter un de telle sorte que la relation dispose d'une clé
primaire (les outils proposent l'ajout de tels attributs).
F Transformation des associations
Les règles de transformation que nous allons voir
dépendent des cardinalités/multiplicités maximales des
associations. Nous distinguons trois familles d'associations :
· un-a-plusieurs ;
· plusieurs-a-plusieurs ou classes-associations, et
n-aires ;
· un-a-un.
Associations un-à-plusieurs
Il faut ajouter un attribut de type clé
étrangère(FK) dans la relation fils de l'association. L'attribut
porte le nom de la clé primaire de la relation père de
l'association. On peut se rappeler cette règle de la manière
suivante : la clé de la relation père migre dans la relation
fils.
Associations un-à-un
La règle est la suivante, elle permet
d'éviter les valeurs NULL dans la base de données. Il faut
ajouter un attribut clé étrangère dans la relation
dérivée de l'entité ayant la cardinalité minimale
égale à zéro. Dans le cas d'UML, il faut ajouter un
attribut clé étrangère dans la relation
dérivée de la classe ayant la multiplicité minimale
égale à un. L'attribut porte le nom de la clé primaire de
la relation dérivée de l'entité (classe) connectée
à l'association.
Ainsi la transformation nous donne le modèle
suivant :
Model physique des
données (démonstration sous MySQL)
Le niveau physique correspond à la définition
des structures de données et à la programmation SQL
nécessaires à mettre en oeuvre.17(*) Nous utiliserons une syntaxe SQL2 (MySQL) pour les
scripts s'appliquant aux bases de données relationnelles.
Le langage SQL
Le langage SQL permet de déclarer tous les
éléments d'une base de données, en particulier les tables,
qui sont les conteneurs d'informations.
Le succès que connaissent les grands éditeurs de
SGBDR repose notamment sur SQL se base sur:
· SQL peut s'interfacer avec des langages de
troisième génération (C, Ada ou Cobol), mais aussi avec
des langages plus évolués (C++, Java, Delphi, C#).
· L'indépendance entre les programmes et les
données (la modification d'une structure de données
n'entraîne pas forcément une importante refonte des
programmes).
· Ces systèmes sont bien adaptés aux
grandes applications informatiques de gestion et ont acquis une maturité
sur le plan de la fiabilité et des performances, même avec de
forts volumes (actuellement plusieurs dizaines de téraoctets).
· Ils intègrent des outils de développement
comme les pré compilateurs, les générateurs de code,
d'états, de formulaires, et des outils d'administration, de
réplication, de sauvegarde, de surveillance, etc.
· Ils offrent la possibilité de stocker des
informations non structurées (texte, images...) dans des champs
appelés BLOB (Binary Large OBject).
Mise en oeuvre sous
MySQL :
Dans cette partie nous allons détailler la structure de
chaque table de notre model logique une fois créée sous MySQL
Création de la Base de données
CREATE DATABASE `rva_trafic`;
Structure de la table manifeste
CREATE TABLE `MANIFESTE` (
`nummanif` INT NOT NULL ,
`datemanif` DATE NOT NULL
,
`type` VARCHAR( 10 ) NOT NULL ,
`codecomp` VARCHAR( 5 ) NOT NULL
,
`numvol` INT NOT NULL ,
`numpass` INT NOT NULL ,
PRIMARY KEY (
`nummanif` )
) ENGINE = MYISAM ;
Structure de la table Vol
CREATE TABLE `VOL` (
`numvol` INT NOT NULL ,
`datevol` DATE NOT NULL
,
`heurevol` TIME NOT NULL ,
`destination` VARCHAR( 20 ) NOT NULL
,
`villedepart` VARCHAR( 20 ) NOT NULL ,
`codecomp` VARCHAR( 5 ) NOT NULL
,
PRIMARY KEY ( `numvol` )
) ENGINE = MYISAM ;
Structure de la table Compagnie
CREATE TABLE `COMPAGNIE` (
`codecomp` VARCHAR( 5 ) NOT NULL ,
`nom` VARCHAR( 20 ) NOT
NULL ,
`nrc` VARCHAR( 10 ) NOT NULL ,
PRIMARY KEY ( `codecomp` )
) ENGINE = MYISAM ;
Structure de la table Rapport_control
CREATE TABLE `RAPPORT_CONTROL` (
`numero` INT NOT NULL ,
`date` DATE NOT NULL ,
`remarque`
VARCHAR( 25 ) NOT NULL ,
`numvol` INT NOT NULL ,
PRIMARY KEY ( `numero` )
) ENGINE = MYISAM ;
Structure de la table Passager
CREATE TABLE `PASSAGER` (
`numpass` INT NOT NULL ,
`nomcomplet` VARCHAR( 25 ) NOT NULL
,
`datenaiss` DATE NOT NULL ,
`lieunaiss` VARCHAR( 5 ) NOT NULL
,
`genre` VARCHAR( 3 ) NOT NULL ,
`nationalite` VARCHAR( 20 ) NOT NULL
,
`telephone` INT NOT NULL ,
`photo` BLOB NOT NULL ,
PRIMARY KEY (
`numpass` )
) ENGINE = MYISAM ;
Structure de la table Bagage
CREATE TABLE `BAGAGE` (
`numbag` INT NOT NULL ,
`numpass` INT NOT NULL ,
`poid` INT
NOT NULL ,
`emballage` VARCHAR( 20 ) NOT NULL ,
`nature` VARCHAR( 15 )
NOT NULL ,
`quantite` INT NOT NULL ,
PRIMARY KEY ( `numbag` )
) ENGINE = MYISAM ;
Structure de la table Formulaire_trafic
CREATE TABLE `FORMULAIRE_TRAFIC` (
`numerof` INT NOT NULL ,
`datef` DATE NOT NULL
,
`designation` VARCHAR( 15 ) NOT NULL ,
`montanttotal` FLOAT NOT NULL
,
`taxembarquement` FLOAT NOT NULL ,
`taxaterissage` FLOAT NOT NULL
,
`taxepassager` FLOAT NOT NULL ,
`nummanif` INT NOT NULL ,
PRIMARY
KEY ( `numerof` )
) ENGINE = MYISAM ;
Description de
l'application utilisateurs
Dans cette partie nous allons donner certaines vues de notre
application associées à quelques lignes de code qui les
composent.
Page d'accueil :
Cette page est la première à voir une fois on
accède à notre application ; elle permet aux
différents utilisateurs de notre système de s'authentifier et
ainsi avoir accès aux services rendus par le système.
Extrait du Code source de la page
d'accueil :
<?php
session_start();
$login = "";
$password = "";
if(isset($_POST['login']) and isset($_POST['mp'])){
$login = $_POST['login'];
$password = $_POST['mp'];
include('cnx.php');
$res = $db->prepare("SELECT id AS code, login, mot_de_passe
AS pwd, qualite AS groupe, nom_user FROM compte");
$res->execute();
// print_r($res->errorInfo());
$donne = $res->fetchAll();
$flag_trouve = false;
foreach($donne as $enregistrement)
{ if ($enregistrement['login'] == $login and
$enregistrement['pwd'] == $password)
{ $flag_trouve = true;
$_SESSION['login'] = $enregistrement['login'];
$_SESSION['code'] = $enregistrement['code'];
$_SESSION['groupe'] = $enregistrement['groupe'];
$_SESSION['user'] = $enregistrement['nom_user'];
$groupe = $enregistrement['groupe'];
break;
}
}
if ($flag_trouve == true)
{
/*Afficher le menu en fonction du groupe de l'utilisateur*/
header('location:index_'.$groupe.'.php');
}
else
{ echo "<h2>Désolé ! Erreur mot de passe !
réessayez ";
}
} ?>
NB. : Vue le nombre de ligne de code de notre
application, nous allons nous limiter à donner juste les capture
d'écrant de quelques pages de l'application.
Capture de l'interface visible aux
différentes compagnies :
C'est à partir de ce formulaire que
la compagnie pourra créér un manifeste et l'envoyer à la
RVA,
Pour ce qui concerne les passagers, notre application apporte
une nouvelle technique : celle de joindre une image (photos) du passager
à son identité lors de l'élaboration du manifeste ;
ainsi dans le cas de crash par exemple on peut facilement identifier les
passagers en se basant sur leurs photos se trouvant dans notre base de
données. Ainsi, en faisant une recherche sur base du numero du manifeste
et l'identifiant du vol on retrouve facilement toutes les photos des passagers
de ce vol.
Illustration et extrait de code:
<h1>Ecran de Recherche passager d'un manifeste
</h1>
<form method = "POST" action =
"Manifeste_passager.php">
<fieldset>
<legend>Fiche de recherche
</legend>
<p>
<label>Chosir le maniste :
</label>
<select name = "manifeste" title =
"Sélectionnez le manifeste"/><option =
"">Choisir</option>
<?php
{
echo
'<option>Choisir</option>';
echo $m;
}?></select></p>
<p class="boutons"><input type="submit"
value="Rechercher"/><input type="reset" value="Annuler"
/></p>
</fieldset>
</form>
Si on clique sur le numéro du passager (encerclé
en rouge sur l'image ci haut), on obtient le détail sur son
identité sous forme de carte d'identité.
Page d'administration du système (suivi de son code
source) :
<?php
session_start();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"
lang="fr">
<head>
<link type="text/css" rel="stylesheet"
href="css/design_general.css" />
<style type="text/css">
<!--
.Style1 {color: #FF0066}
.Style2 {color: #0000FF}
.Style3 {color: #000066}
.Style6 {color: #000066; font-weight: bold; }
-->
</style>
</head>
<body>
<div id="gauche">
<div id="menu">
<h3>RVA</h3>
<ul>
<li class="info_user">User: <?php echo
$_SESSION['login'];?></li>
</ul>
<h3>Options</h3>
<ul>
<li class="item_menu"><a
href="Ecran_compte.php">Créer compte
utilisateur</a></li>
<li class="item_menu"><a
href="Liste_compte.php">Gérer compte user</a></li>
<li class="item_menu"><a href="Index.php">Se
Déconneter</a></li>
</ul>
</div>
</div>
<table width="484" height="362" border="1">
<tr> <td width="474"
height="101"><img src="logo.jpg" alt="" width="473" height="106"
/></td>
</tr>
</table>
<div id="bas"> <p align="center"
class="Style1"><span class="Style2">© Tous droits
réservés.Alain M</span>.</p>
</div> </body> </html>
CONCLUSION
C
omme le soleil se lève à l'Est et se couche
à l'ouest, de même tout travail scientifique commence par une
introduction et se termine par une conclusion.
Notre travail a porté sur le suivi des passagers sur
les vols nationaux et internationaux, et notre champ d'investigation a
été la RVA/ Katanga.
Comme le travail de conception a toujours été le
plus grand dans la fabrication des logiciels, une mauvaise conception produit
toujours un logiciel raté.
Pour arriver à solutionner un problème de ce
genre, en informatique, on procède à plusieurs phases d'essai et
jusqu'à la solution finale, c'est ainsi que, après notre
analyse, nous avons pu faire une ébauche juste pour simuler quelques
scenarios de notre application d'étude. Nous pouvons ainsi souligner que
l'implémentation que nous avons faite est à titre illustratif et
nous laissons le travail ouvert à toutes personnes pouvant en faire
objet d'une étude approfondie.
Néanmoins nous pouvons dire que les solutions que nous
avons proposées dans notre travail d'analyse, portent solutions à
notre problématique et optimisent les résultats des
opérations de suivis et d'identification des passagers sur
différents vols nationaux en qualité, en quantité ainsi
qu'en temps.
Mais étant donné qu'il s'agit d'un travail
scientifique, nous ne pouvons pas estimer avoir tout épuisé pour
ce qui concerne ce sujet vu le domaine dans lequel il est traité, vu sa
complexité et vu l'intérêt qu'il présente.
Ainsi, nous laissons le libre arbitre à toutes
personnes qui se sentiraient intéressées de traiter encore
davantage ce sujet en vue d'une quelconque amélioration. Il y a encore
beaucoup à traiter.
BIBLIOGRAPHIE
I. OUVRAGES
F Laurent AUDIBERT, UML 2.0
F Pascal ROQUES, UML 2 par la pratique,
5ème Edition EYROLLES 2006
F Joseph GABAY, UML 2 Analyse et Conception, DUNOD,
Paris, 2008
F Gilles ROY, Conception des bases de données avec
UML
F P. ROQUES, UML 2 Modéliser une application
web, 4ème Edition EYROLLES
F P. ROQUES et Franck VALEE, UML en action : de
l'analyse des besoins à la conception en Java,
2ème Edition EYROLLES, 2003
F Christian SOUTOU : UML2 Pour les bases de
données, Ed. EYROLLES
II. MEMOIRES ET TFC
F K.A. BASSIM, Suivie des enseignements du LMD par
application de la méthode 2TUP ; Projet de Fin d'Etudes pour
l'obtention du Diplôme d'Ingénieur d'Etat en Informatique Option
informatique industrielle ; Université Abou Bekr Belkaid de
Tlemcen, Novembre 2007
F KAMBALE TATSOPA Wilson, Création d'une application
web d'entreprise pour la facilitation des imports/ exports en république
démocratique du Congo, cas de l'importation et exportation des
vivres frais au Katanga, TFC, UPL, 2010
F KENA WABO Muteba, Gestion automatisé de la vente
des billets et de la réservation des places dans une compagnies
d'aviation, cas de la CAA, TFC, UPL, 2009
III. COURS
F D. CANDA, Initiation au travail scientifique(IRS), G1
Informatique/UPL/ 2008-2009, inédit
IV. SITES
F www.developpez.com
F www.design-up.com
F www.siteduzero.fr
F www.wikipedia.com
Table des matières
EPIGRAPHE
I
DEDICACE
II
AVANT-PROPOS
III
O. INTRODUCTION
1
0.1 GENERALITES
1
0.2 PROBLEMATIQUE
2
0.3 HYPOTHESE
2
0.4 DELIMITATION SPATIALE
3
0.5 CHOIX ET INTERET DU TRAVAIL
3
0.6 METHODES ET TECHNIQUES
3
0.7 SUBDIVISION DU TRAVAIL
5
Chap. I ANALYSE PREALABLE
6
1.1 PRESENTATION DE LA RVA
6
1.1.1 Historique
6
1.1.2 Objectif de la RVA
6
1.2 DESCRIPTION TEXTUELLE DU PROCESSUS METIER
8
1.3 MODELISATION DU METIER
12
1.3.1 Identification des acteurs du
métier:
14
1.3.2 Diagramme de contexte du
métier:
15
1.3.3 Diagramme d'activité du
métier
15
1.3.4 Capture des besoins fonctionnels du
métier
16
1.3.5 Classement des cas d'utilisations en
itération
19
1.3.6 Regroupement des cas d'utilisation en
Package
20
1.3.7 Description textuelle des cas
d'utilisation
20
1.3.8 Diagramme de classe du domaine
25
1.4 CRITIQUE DE L'EXISTANT
25
CHAP II ANALYSE ET CONCEPTION DU SYTEME
INFORMATIQUE
28
2.1 DEFINITION DES BESOINS FONCTIONNELS DU SYSTEME
INFORMATIQUE
28
2.1.1 Identification des acteurs du système
informatique
28
2.1.2 Détermination des cas d'utilisation du
système informatique
29
2.2 ANALYSE DES CAS D'UTILISATION
31
2.2.1 Identification des classes participantes
31
2.2.2 Découpage par catégorie
34
2.2.3 Développement du model dynamique
35
CHAP III IMPLEMENTATION ET DEPLOIEMENT
49
3.1 Choix de l'architecture logique
49
3.1.1 Diagramme de composants
50
3.1.2 Déploiement du système
52
3.2 Conception de la persistance
53
3.3 Dérivation du model logique des
données
55
Règles de transformation :
55
Model physique des données
(démonstration sous MySQL)
57
Mise en oeuvre sous MySQL :
57
Description de l'application utilisateurs
60
CONCLUSION
67
BIBLIOGRAPHIE
68
* 1 D. CANDA, Initiation au
travail Scientifique(IRS), G1 Informatique/UPL/2008-2009,inédit
* 2 J. GABAY, UML2 Analyse et
conception, Dunod, Paris, 2008
* 3 D. CANDA, Initiation au
travail Scientifique(IRS), G1 Informatique/UPL/2008-2009, inédit
* 4 Ibidem
* 5 Pascal ROQUES, UML2
Modéliser une application Web, Edition EYROLLES
* 6 Ibidem
* 7 P. ROQUES, Opsit
* 8 K.A. BASSIM, Suivie des
enseignements du LMD par application de la méthode 2TUP ; Projet de
Fin d'Etudes pour l'obtention du Diplôme d'Ingénieur d'Etat en
Informatique Option informatique industrielle ; Université Abou
Bekr Belkaid de Tlemcen, Novembre 2007
* 9 Laurent AUDIBERT, cours UML
2.0, Paris, 2006
* 10 Laurent AUDIBERT, Op.cit.,
Page26
* 11 Pascal ROQUES, UML2
Modéliser une application Web, Edition EYROLLES
* 12 Joseph GABAY, UML2
Analyse et conception, Dunod, Paris, 2008
* 13 Joseph GABAY, UML2 Analyse
et Conception, DUNOD, Paris, 2008
* 14 P. ROQUES et Franck
VALLEE, UML en Action : De l'Analyse des besoins à la Conception,
Ed. EYROLLES
* 15 J. GABAY, UML2 Analyse et
Conception, Dunod, Paris, 2008, p50
* 16 Christian SOUTOU :
UML2 pour les Bases de données, Ed. Eyrolles, p 103-104
* 17 Christian SOUTOU :
UML2 Pour les bases de données, Ed. EYROLLES, p-177
| 
