WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d'une application pour le suivi de passagers


par Désiré BOLONGO
ISP Budjala - I.G. 2021
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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">&copy; 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






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Des chercheurs qui cherchent on en trouve, des chercheurs qui trouvent, on en cherche !"   Charles de Gaulle