|
REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
UNIVERSITE PROTESTANTE DE LUBUMBASHI
Faculté des Sciences Informatiques
Octobre 2011
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
(UnifiedModelingLanguage) en utilisant la démarche UP (UnifiedProcess)
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 OrientedDeveloppement) 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 (Unifiedprocess) 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 UnifiedProcess)
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 UnifiedProcess) 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 TrackUnifiedProcess» .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"><imgsrc="logo.jpg" alt="" width="473" height="106"
/></td>
</tr>
</table>
<div id="bas"><p align="center"
class="Style1"><span class="Style2">©
Tousdroitsréservés.Alain M</span>.</p>
</div></body></html>
CONCLUSION
Comme 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 BekrBelkaid 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 BekrBelkaid 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
| 
