ANALYSE, CONCEPTION, ET PROGRAMMATION ORIENTEE OBJET

RAPPORT DE PROJET LOGICIEL DE GESTION DE COMPAGNIE DE TRANSPORT MARITIME

C E L I N E HE N R Y C O M B E S PIERRE LUCE

L3 INFORMATIQUE DECEMBRE 2010

I.

RESUME
Ce document prsente les points cls du dveloppement dun logiciel laide des technologies oriente objet . A travers un projet de travaux pratique servant de support, nous prsenterons les phases danalyse et de conception utilisant le langage UML pour modliser le mtier et concevoir une solution rpondant aux spcifications, et nous verrons aussi son implmentation grce au langage C++. A chaque choix que nous avons d effectuer o plusieurs solutions soffraient nous, nous les justifions et dveloppons nos raisons.

INTRODUCTION
Au premier semestre de la Licence 3 dInformatique lUniversit de Limoges, nous avons eu a ralis un logiciel de gestion pour une compagnie de transport maritime. Il sagissait deffectuer lanalyse dun cahier des charges, de concevoir une solution et de limplmenter pour obtenir un programme fonctionnel, dans le cadre du cours dAnalyse et Programmation Oriente Objet. Fort de notre apprentissage des langages UML et C++, nous les avons utilis respectivement pour la modlisation et pour limplmentation. Dans un premier temps, nous vous prsenterons lanalyse effectue et le modle conu pour le logiciel, tandis que dans une deuxime partie, nous aborderons les choix architecturaux et limplmentation retenue.

TABLE DES MATIERES

Rsum ...................................................................................................................................................................................2 Introduction .........................................................................................................................................................................3 PREMIERE PARTIE : ANALYSE ET CONCEPTION DU LOGICIEL 5 I. II. Analyse du Cahier des Charges ......................................................................................................................5 Modlisation et Conception .............................................................................................................................6 Gestion des passagers .............................................................................................................................................6 Gestion des Navires .................................................................................................................................................6 Gestion des trajets ....................................................................................................................................................7 Gestion des membres dequipages ....................................................................................................................8 Conclusion ...................................................................................................................................................................8 SECONDE PARTIE : ARCHITECTURE ET IMPLEMENTATION I. II. III. 10

Le modle MVC .................................................................................................................................................. 10 Une premire implmentation de la vue : la console ........................................................................ 12 La vue dfinitive et la bibliothque Qt4.............................................................................................. 12 Construction de linterface ................................................................................................................................ 13 Intgration des interfaces .................................................................................................................................. 13

IV.

Design Patterns utiliss ............................................................................................................................. 14

PREMIERE PARTIE : ANALYSE ET CONCEPTION DU LOGICIEL

I. ANALYSE DU CAHIER DES CHARGES

Le cahier des charges fournit comme consigne au projet est relativement prcis sur la description du modle mtier de lentreprise. Les fonctionnalits attendues sont plus vagues, mais la plupart dcoulent directement du modle et sont implicites. Les oprations particulires sont explicites et clairement exprimes. Il sagit donc de grer les oprations de type CRUD (Create, Retrieve, Update, Delete) sur un certain nombre dobjets mtiers : les navires, les trajets, les passagers, les membres dquipage Ainsi que de permettre lachat des billets, laffectation des quipages, ldition de plusieurs documents. Voici, prsent sous forme dun diagramme de cas dutilisation, lensemble des fonctionnalits attendue :

FIGURE 1: DIAGRAMME DE CAS D'UTILISATION

II.

MODELISATION ET CONCEPTION

Il sagissait dans un premier temps de comprendre la dfinition et linteraction des diffrents objets mtiers de la compagnie maritime. Une lecture du sujet nous a rapidement permis de les trouver, et de les organiser sur un diagramme de classe. Nanmoins, la conception la plus smantiquement correcte nest pas ncessairement la plus fonctionnelle, ni la plus pratique limplmentation comme lutilisation . Nous vous prsentons ici notre diagramme de classe finale en plusieurs parties pour plus de clart. GESTION DES PASSAGERS

FIGURE 2: DIAGRAMME DE CLASSE DE LA GESTION DES PASSAGERS

Lorganisation ci-dessus est presque triviale la lecture du sujet, mise part dans la partie concernant la gestion des diffrentes catgories de passagers. Nous avions dans un premier temps choisi de crer une classe par catgorie de passagers, hritant de la classe Passager et porteuse de linformation tarifaire. Nanmoins, cette solution manque de flexibilit : il est impossible dajouter de nouvelles catgories ou de changer les tarifs sans modifier le code, et cette opration est loin dtre improbable. Nous avons donc choisi de dlguer linformation de tarif une classe spcialise CategoriePassager, dont une instance est conserve pour chaque Passager. GESTION DES NAVIRES

FIGURE 3: DIAGRAMME DE CLASSE DE LA GESTION DES NAVIRES

Ici il peut paraitre surprenant de ne pas utiliser dhritage pour diffrencier les navires de fret des navires mixtes. Effectivement, il y a peu de chance quun nouveau type de navire apparaisse. Nanmoins, labsence dhritage se justifie par un autre problme : la persistance des donnes. Elle est en effet rendue plus difficile en prsence dun arbre dhritage, mme simple. Lutilisation dune base de donne impliquera par exemple la ncessit de passer par un ORM (Object Relational Mapping) suffisamment volu pour grer ces cas. Nous avons donc fait le choix de conserver linformation de type dans une chaine de caractre, et de condenser les informations particulires aux navires mixtes dans une seule classe Navire. GESTION DES TRAJETS

FIGURE 4: DIAGRAMME DE CLASSE POUR LA GESTION DES TRAJETS

Cette partie de la conception peut se diviser en deux groupes : Le squelette : constitu des classes Port, TypeTrajet, et TypeTraverse, il modlise une traverse type , un modle, sur lequel sera bas le deuxime groupe de classe Le rel : les classes Trajet et Traverse reprsente les traverse concrte.

Ainsi, la travers du Samedi 11 dcembre entre Sein et Ouessant en passant par Molne, partant 8h34, serait reprsent par le diagramme dobjet suivant :

FIGURE 5 : DIAGRAMME D'OBJETS REPRESENTANT UNE TRAVERSEE

On peut donc, en partant dune traverse donne, retrouver toutes les informations ncessaires, et on peut facilement, partir dun type de traverse, crer une nouvelle traverse concrte. GESTION DES MEMBRES DEQUIPAGES

FIGURE 6 : DIAGRAMME DE CLASSES POUR LA GESTION DES MEMBRES D'EQUIPAGE

Il a t dcid ici de ne pas faire dhritage non plus, encore une fois pour faciliter la persistance. Nous aurions pu faire une sous-classe officier pour les capitaines et seconds, mais nous avons prfr donner un rle au membre dquipage. Cela permettrait en outre de pouvoir prciser, si besoin dans le futur, sil est mcanicien, navigateur, etc CONCLUSION Nous avons donc retenu un modle simple, sans pour autant renier les apports de la conception objet. En effet, lutilisation de lhritage dans le seul but de factoriser les attributs est, notre sens, une fausse bonne ide , qui rend plus difficile la persistance. En revanche, son utilisation pour du polymorphisme est privilgier.

FIGURE 7 : DIAGRAMME DE CLASSE COMPLET

SECONDE PARTIE : ARCHITECTURE ET IMPLEMENTATION

I. LE MODELE MVC

Afin de faciliter le travail en quipe et la rpartition des tches, ainsi que les volutions futures du logiciel, nous avons opt pour une architecture dite Modle Vue Contrleur . Cette faon de structurer un programme spare en trois couches distinctes le modle , ensemble des classes dcrivant les objets mtiers, la vue , cest dire linterface dutilisation, et les contrleurs , qui sont les classes liant la vue aux modles en ralisant des oprations mtiers et en renvoyant le rsultat. Ainsi un changement de vue nimplique aucun changement dans le code.

FIGURE 8 : DIAGRAMME DE SEQUENCE REPRESENTANT UNE OPERATION THEORIQUE DANS UNE ARCHITECTURE MVC

Notre code source se divise donc en trois types de classes, rparties dans trois rpertoires : src/vue, src/controleur et src/modele, dont les noms sont explicites. Voici le diagramme de composant dcrivant les relations physiques entre les fichiers de dfinition et dimplmentation des classes.

FIGURE 9 DIAGRAMME DE COMPOSANTS

II.

UNE PREMIERE IMPLEMENTATION DE LA VUE : LA CONSOLE

Lors de la ralisation dun prototype, le plus rapide moyen dobtenir une interaction avec lutilisateur est dutiliser la console en ligne de commande fournie avec tous les systmes dexploitation. Facilement manipulable de base avec C++, elle noffre nanmoins que des possibilits ergonomiques limites. La cration des diffrentes vues tant une tche assez rptitive, nous avons cherch acclrer le processus en factorisant une partie des oprations. En effet, tous les menus auront un comportement commun : 1. Ils affichent une liste doptions 2. Demandent et enregistrent une saisie utilisateur 3. Excutent loption choisie Nous avons donc mis profit les avantages de la conception oriente objet et notamment du polymorphisme, en mettant en place larchitecture suivante : La classe TemplateVue est abstraite et expose deux mthodes : rendu() qui affiche les diffrentes options du menu, et choix() qui effectue la saisie de lutilisateur et excute le traitement associ. Les options sont ajoutes dans le constructeur de la classe concrete grce la mthode ajouterOption(string). La correspondance option-traitement se fait dans la mthode traiterSaisie(int) qui doit donc tre redfinie, par exemple sous forme dun switch/case. Il est donc possible de crer rapidement de nouveaux menus, de nouvelles pages dans le logiciel. Les FIGURE 10 : SYSTEME DES VUES diffrentes mthodes tant dfinie virtual, elles sont surchargeables dans les classes hritant de TemplateVue, offrant ainsi la possibilit de personnaliser laffichage des menus. Ainsi, un prototype est rapidement ralis pour permettre le test des couches infrieures et de la logique mtier. III. LA VUE DEFINITIVE ET LA BIBLIOTHEQUE QT4

Lergonomie propose par une interface en ligne de commande tant limite, nous avons ressenti le besoin de fournir lutilisateur une exprience plus agrable. Tout programme digne de ce nom ayant pour cible des non-informaticiens possde donc depuis maintenant 30 ans une interface graphique utilisateur (GUI), le plus souvent sous

la forme de fentre manipulable, possdant des tableaux et des champs de formulaire, interagissant grce au clavier et la souris. La ralisation de ces interfaces pouvant tre longue et fastidieuse, nous avons choisis dutiliser une bibliothque spcialise : Qt 4. Open-source et multiplateformes, elle dispose dune importante documentation, dune large communaut de programmeurs et de prcieux outils de dveloppement. Les librairies quelle propose ne concernent pas uniquement linterface graphique, mais propose aussi des classes reprsentant des donnes (Date, heure) plus compltes que les standards (quand elles existent). CONSTRUCTION DE LINTERFACE Loutil QtDesigner livr avec la bibliothque propose la conception dinterfaces graphique laide dun diteur WYSIWYG (What You See Is What You Get : ce que tu vois est ce que tu obtiendras) trs pratique, permettant la construction de fentres complexes en relativement peu de temps. Ce logiciel fonctionne sur un principe simple de glisser-dposer dlments, dune table de proprit pour chacun des objets composant linterface (boutons, tables) et dispose de beaucoup dexemples. Il est possible dditer aussi de faon sommaire la gestion des vnements : elle se fait sous Qt grce lassociation de signaux mis par un lment, et de slots, mthode dun objet recevant le signal. Par exemple, le signal clicked() de lobjet ajouterNavireButton sera associ la mthode traiterAjoutNavire() de la fentre courante grce au code :
connect(ajouterNavireButton,SIGNAL(clicked()),this,SLOT(traiterAjoutNavire()));

Ce code peut tre partiellement gnr par QtDesigner. Ainsi, plus de temps est pass sur limplmentation des fonctionnalits mtiers plutt que sur un travail technique fastidieux. INTEGRATION DES INTERFACES QtDesigner gnre au final un fichier *.ui, lequel sera transform la compilation en un banal fichier C++ *.h, qui dfinira la classe reprsentant la fentre que lon a cr. Si lon souhaite modifier le comportement de la fentre (en ajoutant des vnements par exemple), on doit alors crer une sous-classe en hritant, et appeler celle-ci dans notre programme. La principale difficult rside dans la compilation, qui passe par une tape intermdiaire : il est ncessaire de construire le fichier makefile avec lutilitaire qmake fourni avec la bibliothque. La compilation se droule donc en trois tapes : 1. qmake project (crit un fichier *.pro) 2. qmake (crit le fichier makefile daprs le *.pro, et compile les *.ui en *.h)

3. make (compile) IV. DESIGN PATTERNS UTILISES

Le pattern le plus utilis est ici le Singleton, cest--dire le patron de conception qui permet de sassurer de lunicit de linstance dune classe travers tout le programme. Il sagit, sommairement, de dlguer la construction dun objet une mthode statique dlivrant toujours la mme instance. Il est utilis principalement pour deux types de classes : Les contrleurs : une seule instance suffit, et est mme ncessaire sils grent le stockage des donnes mtiers. Les fentres : ainsi, les modifications entraines sur une fentre sont rpercutes en mme temps sur les autres fentres de la mme classe.

De plus, le gain mmoire est intressant si on utilise des objets de grande taille ne ncessitant pas dtre prsent en plusieurs exemplaires.

CONCLUSION
Ce travail danalyse puis de programmation a t une bonne exprience pour plusieurs raisons. Tout dabord, ce fut loccasion de mettre en application une fois de plus les mthodes danalyse oriente objet, dans le cadre dun sujet complet et proche de la ralit. Ensuite, limplmentation en C++ nous a permis dapprofondir notre connaissance de ce langage, et notamment de nous initier la cration dinterface graphique, dont nous avions dj lexprience en Java. Enfin, tout exercice donne loccasion damliorer ses bonnes pratiques, et ce fut l aussi le cas.