Memoire Online - Conception d'un logiciel multiplateforme pour la gestion d'un restaurant moderne

Conception d'un logiciel multiplateforme pour la gestion interactif d'un restaurant

Travail réalisé et défendu en vue de l'obtention du diplôme de grade en faculté des Sciences Economiques

EPIGRAPHES

« La plus part des gens abandonnent juste au moment où ils sont sur le point de connaitre le succès. Ils laissent tout tomber alors qu'ils sont à moins d'un mètre du but. »

« Un voyage d'un millier de kilomètre commence toujours par un premier pas. »

DEDICACE

A mon père Raphael
A toute ma Famille ;
A tous ceux qui m'ont soutenu dans mes études ;
A tous ceux qui m'aiment.

REMERCIEMENTS

Au terme de notre cycle (Premier) en sciences économiques et de gestion, nous adressons nos sincères remerciements à l'Eternel DIEU tout puissant pour sa riche protection et sa grâce qu'il n'a cessé de nous combler pour tout travail durant notre séjour dans la vie estudiantine.

Nous remercions, d'une manière particulière, la famille SIKAKULYA pour son sacrifice, amour et soutien de nos études depuis notre bas âge jusque maintenant ; qu'ils trouvent ici le fruit de leur dévouement inestimable. Sans oublier les frères, soeurs, oncles, tantes, grand-mères, fils, filles, etc.

Nos gratitudes s'adressent au corps académique et scientifique de l'université adventiste de Lukanga UNILUK, pour son savoir-faire et savoir être louable, Nos sincères remerciements au Professeur Docteur Osée MUHINDO MASIVI qui en dépit de ses occupations multiples a bien voulu diriger ce travail.

Nous resterons très reconnaissants à nos frères, camarades et amis avec qui nous avons traversés des terribles difficultés et qui n'ont cessé de nous encourager : Franck, Antoine, Consolée, Hugues, Moises, Charles, Alexandre, Joseph, Gloire, Alain, Fabiola, Joël, Sammy, Kid qu'ils trouvent ici notre gratitude. Que tous ceux qui me sont chers et dont les noms ne sont pas repris trouvent aussi l'expression de nos sincères gratitudes.

LISTES DES SIGLES ET ABREVIATIONS

LISTES DE FIGURES

TABLEAU

TABLE DES MATIERES

0. INTRODUCTION

0.1 Problème et questions de recherche

Depuis des nombreuses décennies, les systèmes d'informations sont présents dans les organisations. D'abord sous forme physique ensuite sous forme électronique, ils prennent quotidiennement une place de choix dans les organisations, d'une part à cause du renforcement de la concurrence sur les marchés et la masse d'informations à gérer et d'autre part grâce au développement constant des nouvelles technologies de l'information qui apportent des solutions plus pertinentes (Dayan et Al, 2004).

A ce titre, l'informatique devient un support de connaissances de l'humanité, aux fins de leur traitement, de leur conservation dans le temps et leur communication dans l'espace ; c'est ainsi que l'informatique bouscule les habitudes dans l'organisation, impose ses règles et finit par devenir un incontournable outil de gestion rationnelle, moderne de l'entreprise.

La diversité qui existe dans le domaine mobile et des ordinateurs, notamment le nombre important de systèmes d'exploitation qui utilisent des technologies différentes, engendre cependant une « fragmentation : environnement IOS/Objective-C pour l'iPhone et l'iPad, SDK Java spécifique pour Androïde, J2ME pour Symbian, C++ pour Windows, C pour linux, etc. » Conscients de l'importance d'une défragmentation et soucieux d'optimiser les processus de conception des applications mobiles et desktop, les

développeurs ont cherché à mettre en place plusieurs méthodes afin de parvenir à développer pour plusieurs plateformes à la fois, d'où le développement multiplateforme.

L'arrivée des tablettes mobiles n'a fait qu'intensifier cet engouement que suscite cette nouvelle technologie. « Plus interactifs, plus pratiques, plus transportables, parfois plus esthétiques ; les qualificatifs ne manquent pas pour décrire les évolutions qu'ont apportées ces appareils dans la recherche de la satisfaction en masse des consommateurs » (Héritier, 2004)

Certes, les difficultés que connait la plus part de restaurant comme la gestion de commandes ses clients et comme aussi la carte de menu ne laisse pas la tâche facile aux clients de retrouver un plat. Vue que ce menu n'a pas d'image du plat proposer et qu'il change souvent, cette forme de travail cause souvent des préjudices, pour cela, le choix d'un système informatique multiplateforme avec ses influences devant permettre de fluidifier le processus de traitement des commandes et d'éviter ainsi la falsification constatée en forte période reste indispensable.

C'est dans ce cadre que s'inscrit notre projet de fin d'étude. En effet, nous cherchons à mettre sur pied un environnement qui renvoie à une conception et réalisation d'un logiciel multiplateforme pour la gestion interactif d'un restaurant.

De tout ce qui précède, nous nous trouvons face à trois problèmes qui vont nous préoccuper dans notre recherche scientifique.

? Comment stocker et traiter les différentes informations d'un restaurant moderne en rapport avec les achats des clients?

? Comment permettre une communication entre les clients et les servants dans un restaurant?

? Comment faciliter une réservation de choix place de clients tout en étant loin du restaurant?

0.2 Objectif du Travail

Sans objectif préalable pour tout travail scientifique digne de ce nom, il est peu de chance que l'on aboutisse à un résultat conséquent et logique. Se faisant, nous nous sommes fixés l'objectif dans cet exercice, celui de mettre à la disposition de tout le restaurant moderne un logiciel informatique qui mettra fin aux difficultés de client et du restaurateur. Ceci nous amènera donc au regard des problèmes sus évoqués d'aboutir à :

? La proposition d'un logiciel sous Windows pour la réception de sélection de
plat choisie par les clients à partir de la tablette.

? Et enfin la réalisation d'une plateforme web pour la réservation de
place(Table) en ligne dans le site du restaurant.

0.3 Choix et intérêt de l'étude

Toute organisation est tenue de suivre le développement rapide du monde de la technologie, et en profiter le plus possible afin d'assurer sa continuité et accroître sa compétitivité dans une époque où la concurrence ne cesse de s'accroître.

Le choix de notre travail et de faire un logiciel interactif c'est à dire qui permettra de faire des actions réciproques entre le client et la tablette (Windows Mobile) ou soit entre le restaurateur et son ordinateur. Et ce dernier pourras être avantageux et aux clients du restaurant et aux restaurateur.

Son intérêt avec l'acquisition de tablette et l'application de ce logiciel pourra faire une souplesse dans l'action de commande de repas. Enfin d'ouvrir une broche aux futurs chercheurs quand à ce qui concerne les développements multiplateforme des logiciels informatique.

0.4 Délimitation du sujet

Nous avons pensé limiter notre étude par rapport au contenu, à l'espace et au

temps. Par rapport au contenu et à l'espace, ce travail s'inscrit dans la limite des normes de

restaurant moderne en RDC en nous intéressant au problème du client et du restaurateur. Il

Par rapport au temps, nos investigations couvrent une période allant du mois de Février 2015 au mois de Juillet 2015.

0.5.1 La modélisation

Pour mener à bien notre analyse, dès la conception jusqu'à réaliser notre système d'information, nous utiliserons la méthodologie UML (Unified Modeling Language, «langage de modélisation unifié») suivant ses trois points de vue classiques de modélisation : fonctionnel, statique et dynamique. Ainsi nous insisterons pour chacun sur le ou les diagrammes UML prépondérants qu'il comporte et qui lui permet de se focaliser sur un aspect particulier du développement

0.5.2 Technique Documentaire

Dans cette section nous passerons en revue les TFC, les mémoires, thèses, ouvrage, livres, etc. Enfin apporter quelque chose d'originale à notre recherche.

0.6 Subdivision du Travail

Hormis la partie introductive qui est l'orientation globale de ce travail et la conclusion, le présent travail sera subdivisé en trois parties qui sont les suivantes:

La première partie intitulée « Revue de Littérature » dans ce dernier nous allons fournir les informations de fond en ce qui concerne notre sujet pour comprendre les termes clés qui constituent notre thème.

La deuxième partie intitulée «Méthodologie» qui sera consacré à la présentation des méthodologies et outils du travail que nous utiliserons pour atteindre nos objectifs

La troisième partie «Conception de la Solution» qui nous présentera la modélisation des données et des traitements c'est-à-dire les résultats obtenus de l'analyse, bref la conception de notre système d'information.

En fin la quatrième partie « Réalisation de la solution » ou nous présenterons les différents résultats obtenue de notre prototype

fonctionner partout. » est le fameux slogan de Sun Microsystems1 pour définir la notion de

Chapitre I

REVUE DE LITTERATURE

1.1 Système multiplateforme

Dans cette partie de notre travail, nous allons définir la notion de multiplateforme en nous basant sur les logiciels car les applications mobiles sont aussi assimilables à ces derniers, ensuite nous allons tenter de relater l'intérêt du développement multiplateforme en toute généralité.

1.1.1 Définition du développement multiplateforme

Selon (CHEHADE, 2011), Un logiciel multiplateforme est un logiciel conçu pour fonctionner sur plusieurs plates-formes, c'est-à-dire le couple liant ordinateur et système d'exploitation. En anglais on parle souvent de « cross-Platform software » ou « Platform Independent software » ou encore de « multi-Platform software ». Donc, nous pouvons dire que le développement multiplateforme peut être défini comme le procédé par lequel un développeur conçoit un logiciel pouvant être déployé sous différentes plateformes.

(VANDERDONCKT, 2012), est parvenue à mettre en place un logiciel qui fonctionner sous trois plateforme (tablette et PC) utilisant le system Ios, son logiciel était chargé de faire de réservation de clients pour la visite d'un salon d'exposition

1.1.2 Intérêt du développement multiplateforme

« Write once, run anywhere » qui signifie en français « Écrire une fois, faire

multiplateforme. En effet, le fait de pouvoir déployer un logiciel sur plusieurs environnements permet non seulement d'économiser du temps (temps passé à reproduire le code pour chaque plateforme cible) mais aussi d'économiser des ressources (coût de production). De plus, un gain non négligeable émane de cette notion de développement multiplateforme : la maintenance. Dans le domaine informatique, la maintenance constitue en moyenne près de 70% des coûts, avoir ainsi un seul logiciel à maintenir reviendrait considérablement moins cher que si on en avait plusieurs.

1.1.3 Interfaces utilisateurs multiplateformes

Lorsqu'on parle d'interface utilisateur multi-cibles (une cible étant une plateforme, un type d'utilisateur ou un environnement physique), il est nécessaire de se familiariser avec quelques notions et termes qui y sont intimement liés.

1.1.3.1 Contexte d'utilisation

Un contexte d'utilisation peut être défini comme étant la combinaison des trois éléments suivants :

? La plateforme, représentant l'ensemble des moyens logiciels et matériels permettant de supporter la tâche de l'utilisateur. Elle est modélisée en termes de ressources (les moyens d'entrées et sorties de données de la plateforme par exemple).

-l'utilisateur type, qui est supposé utiliser et/ou utilise effectivement le système. Ce dernier peut être défini par un ensemble de caractéristiques physiques et cognitives. Ces dernières peuvent par exemple être des handicaps divers, ce qui peut dans certains cas fortement influencer les interfaces.

? L'environnement physique dans lequel les interactions homme-machine interviennent.

Il est constitué de tout ce qui entoure l'utilisateur lorsqu'il utilise effectivement la plateforme (objets, personnes, événements) et peut éventuellement modifier le comportement du système et/ou de l'utilisateur.

1.1.3.2 Utilisabilité

Selon (Jaber, 2008), ce concept nous donne une définition générale de ce terme. « L'utilisabilité (ou usabilité) d'un système ou d'un produit, quel qu'il soit, consiste à mesurer jusqu'à quel point des utilisateurs spécifiques peuvent atteindre des buts spécifiques dans un environnement précis et ce, dans des conditions acceptables d'efficacité, d'efficience, de confort et de plaisir.» » Cette définition générale reprend trois notions qu'il est également intéressant de définir pour bien cerner le terme utilisabilité, toujours d'après et reprises ci-dessous.

? L'efficacité est la capacité d'arriver à ses buts. Être efficace, c'est produire les résultats escomptés et réaliser les objectifs fixés dans les domaines de la qualité. L'objectif est le résultat, par exemple trouver une information sur un site internet sans regarder les moyens utilisés pour y arriver.

? L'efficience désigne le fait de réaliser un objectif avec le minimum de moyens engagés possibles. Selon l'exemple du point précédent, il s'agirait ici de trouver l'information en un temps minimal.

? La satisfaction est le nom donné à l'état d'âme et/ou du corps qui accompagne l'assouvissement d'un objectif. La satisfaction découle directement du degré d'efficacité et d'efficience atteint. Ces définitions confirment l'intuition qu'il faut apporter un maximum de satisfaction aux utilisateurs d'interfaces. Il est pour cela nécessaire de leur apporter une navigation à la fois efficace et efficiente, c'est bien évidemment vers quoi nous allons essayer de nous diriger.

1.1.4 Techniques de développement

Différentes techniques existent pour le développement d'interfaces utilisateurs multiplateformes, résultat de la recherche et de l'expérience acquises dans le domaine des interactions homme-machine. Quelques-unes sont succinctement reprises ci-dessous. La première est une technique de développement primitive. Il s'agit de développer chaque interface indépendamment des autres, pour chaque plateforme. C'est à dire, un appareil égale un développement complet. Si un nouvel appareil fait son apparition, un nouveau cycle de développement complet devra être entrepris. Ceci a un gros avantage : une bonne adaptation du logiciel à la plateforme, car il en utilisera de matière native toute les capacités. Au niveau des inconvénients par contre, ils sont multiples.

Premièrement, il est coûteux de développer une solution complète pour chaque appareil qui sort, car il y en a beaucoup, et ceux-ci sont de moins en moins similaires, impliquant qu'une réutilisation du code développé précédemment n'est pas toujours possible. Ensuite, si une fonctionnalité veut être ajoutée à toutes les plateformes, il est nécessaire de modifier toutes les applications pour l'y incorporer, ou en d'autres termes : un coût de maintenance non-négligeable. A notre connaissance, de nombreuses entreprises utilisent malheureusement cette technique, principalement car elles ont de gros moyens financiers et qu'elles préfèrent maîtriser tous les maillons de la chaîne.

La Fourchette manager est un logiciel qui a été développez dans type primitive et conçu main dans la main avec les partenaires restaurateurs afin d'être parfaitement adapté aux besoins des restaurants. Ce logiciel pour la restauration vous permet de gérer vos réservations et vos clients de A à Z, elle est sous deux plateforme pour le mobile avec androïde et pour desk top avec le system Windows ( http://www.theforkmanager.com/fr/fonctionnalites/?i=1420#sthash.lt2wjz2y.dpuf).

Nous voyons que cette approche est théoriquement possible, mais peu efficace. Il convient alors de trouver d'autres techniques permettant de diminuer les coûts de développement et de maintenance, tout en maintenant le nombre de plateformes cibles. Il existe, par exemple, la possibilité de ne développer qu'une seule interface pour toutes les plateformes cible.

Il est évident que cette solution n'est viable que si les plateformes cibles sont semblables du point de vue des caractéristiques.

Une troisième technique consiste à développer une description pour la partie commune à toutes les plateformes, pour ensuite développer les descriptions supplémentaires correspondant aux caractéristiques spécifiques des autres plateformes.

Le développement d'interfaces utilisateurs basé sur des modèles (modelbased) est intéressant dans le cas où il existe différentes plateformes cibles car il fournit un certain degré d'abstraction par rapport à celles-ci, nous ne sommes plus obligés de nous intéresser aux modalités d'interactions dans les premières phases du développement. Plusieurs modèles existent tels que ARCH ou le Caméléon Reference Framework et des modèles développé dans WinDev. C'est ce dernier qui nous intéresse ici car il est relativement simple à appliquer à notre cas et il est également facilement adaptable à notre développement.

(Mathieu & Grégory , 2012), ont dans leur thèse intitulée " Développement d'un système d'information multiplateformes générique pour la visite de salons d'exposition" parler de l'étude d'un cycle de vie de développement, allant de l'analyse des besoins à l'implémentation, d'un système d'information multi plateforme, sous la forme d'un site web, avec application à un domaine d'activité : l'organisation d'un salon. L'organisation et

la visite d'un salon constituant un domaine d'application éminemment multiplateformes car divers profils d'utilisateurs (p. ex. visiteurs, exposants, organisateurs, etc.) utilisent différentes plateformes logicielles (p. ex. des ordinateurs fixes, mobiles) dans différentes configurations

1.2 Les standards de restaurant selon la législation congolaise

Selon (ORDONNANCE 41-291, 1995) un restaurant est tout établissement commercial qui, quelle que soit la dénomination sous laquelle s'exerce son activité, fournit des repas contre rétribution, que ce soit de façon régulière, intermittente ou temporaire.

1.2.1 La licence d'exploitation

L'administrateur de territoire ou le bourgmestre, selon le cas, pourra sur avis motivé de l'autorité sanitaire compétente, suspendre provisoirement la licence d'exploitation d'un établissement ou d'une partie d'un établissement si les conditions indispensables de salubrité y font défaut ou lorsque l'exploitant refuse d'exécuter les travaux d'assainissement prescrits ou néglige d'observer les dispositions de la présente ordonnance. Il pourra, sur pareil avis, retirer définitivement la licence d'exploitation lorsque les mesures essentielles d'hygiène ne peuvent plus être observées en raison soit de l'emplacement, soit des conditions de construction de l'établissement (art 4, Ord. 1959).

Le gouverneur de province statuera sur le recours, sur avis motivé d'une commission comprenant le chef du service provincial des affaires économiques, président, un médecin-hygiéniste et un fonctionnaire désignés par le gouverneur de province (art 4, Ord. 1969)

1.2.2 Des conditions d'exploitation

L'ensemble de l'établissement, de ses installations et de son matériel doit satisfaire aux exigences de l'hygiène.

Une boîte aux réclamations sera établie au bureau de réception ou, à défaut, dans un endroit bien apparent de chaque hôtel ou restaurant. Elle portera visiblement l'inscription «Boîte aux réclamations». L'administrateur de territoire ou le bourgmestre selon le cas, ou leur délégué en possédera seul la clef (art7, 1959).

Dans les localités pourvues d'un réseau téléphonique, l'établissement y sera raccordé. Dans chaque établissement, d'une manière visible et bien lisible au bureau de réception et/ou au comptoir (art8, 1959).

Dans les locaux où la nourriture et les boissons sont préparées ou servies, ou dans lesquels les ustensiles sont nettoyés, le parquet sera construit de manière à pouvoir être maintenu dans un Constant état de propreté. Les murs de ces locaux seront lisses et lavables jusqu'à une hauteur de 1,70 mètre; ils seront, ainsi que les plafonds, maintenus propres et en bon état d'entretien (art8, 1959).

Les cuisines auront une surface d'au moins 16 m Elles seront convenablement éclairées et largement ventilées de façon à assurer l'évacuation rapide des fumées, vapeurs graisseuses et autres (art21, 1959).

Les armoires, tables, étagères, armoires frigorifiques, éviers et tout autre équipement en usage dans les locaux où la nourriture et les boissons sont préparées ou servies, ou dans lesquels les ustensiles sont nettoyés, seront construits de façon à pouvoir être aisément et complètement nettoyés et seront maintenus dans un constant état de propreté(art23, 1959)..

Tous les ustensiles employés au restaurant, à la cuisine ou au débit de boissons seront, après chaque usage, lavés à l'eau chaude contenant un produit détergent antiseptique inoffensif; ils seront ensuite séchés mécaniquement ou avec un linge propre et conservés à l'abri de la poussière, des insectes et autres causes de souillure ou de contamination (art24, 1959).

1.2.3 La surveillance et la répression

Le contrôle des conditions d'exploitation des hôtels, restaurants et débits de boissons est assuré par l'administrateur de territoire ou le bourgmestre, selon le cas, et le médecin-hygiéniste du ressort ou par leur délégué. Chaque établissement sera soumis à une inspection mensuelle soit par le médecin-hygiéniste du ressort ou son délégué, soit par l'administrateur de territoire ou le bourgmestre, selon le cas, ou par leur délégué (art43, 1959).

Chaque inspection fera l'objet d'un rapport, suivant modèle annexé à la présente ordonnance. Le rapport d'inspection d'un hôtel ou d'un restaurant sera établi en triple exemplaire, dont un exemplaire est destiné aux archives du territoire ou de la commune où l'établissement est situé, un exemplaire sera adressé au chef du service provincial des affaires économiques et au médecin-hygiéniste du ressort.

1.3 Proposition

Nous n'avons pas touché tous les travaux spécifiquement et logiciel liés au nôtre. Mais, d'après ces quelques exemples, il est sied de noter que notre travail n'est pas le premier à aborder le système multiplateforme, et pour ce qui est de notre logiciel nous comptons en automatisant le restaurant que nous soyons à mesure de :

? établir une communication entre client et restaurateur à travers le menu de plat du restaurant automatiser que les autres logiciel passer en revu n'ont pas était à mesure de réaliser,

? permettre au client éloigner du restaurant de pouvoir réserver une table dans le restaurant comme ce qui se fait dans la plus part de site de réservation en ligne....

Chapitre II

METHODOLOGIE

Ce chapitre est consacré à la présentation des méthodologies que nous utiliserons pour atteindre nos objectifs. Notre objectif principal est de concevoir un logiciel multiplateforme pour la gestion interactif d'un restaurant. Pour y arriver, il nous faut combiner quelques approches méthodologiques de la recherche scientifique en informatique. Etant donné que le fondement d'une méthode c'est l'objet de la science dans la quelle l'on fait sa recherche. Pour notre cas en science informatique, tout au long de la présentation de nos méthodologies, nos regards resteront plus braqués sur la modélisation, la définition des algorithmes, le prototypage, l'expérimentation et la simulation.

1.1 La modélisation

Dans la conception d'un système d'information, la modélisation des données est l'analyse et la conception de l'information contenue dans le système. Il s'agit essentiellement d'identifier les entités logiques et les dépendances logiques entre ces entités. La modélisation des données est une représentation abstraite, dans le sens où les valeurs des données individuelles observées sont ignorées au profit de la structure, des relations, des noms et des Formats des données pertinentes, même si une liste de valeurs valides est souvent enregistrée. Le modèle de données ne doit pas seulement définir la structure de données, mais aussi ce que les données veulent vraiment signifier (sémantique). Ainsi, les techniques de modélisation sur lesquels nous nous limiterons dans

ce travail font parties de la méthodologie UML (Unified Modeling Language, «langage de modélisation unifié») normalisé par l'Object Management Group « OMG » en 1997 et qui permet notamment de concevoir un système d'information d'une façon standardisée et méthodique. Quand nous construirons les tables d'une base de données dans un logiciel de gestion des bases de données (Oracle, SQL Server, DB2, Access, MySQL, PostGresql, Hyperfilesql ...) nous allons résoudre deux types de problème :

Voilà pourquoi il est donc nécessaire de recourir à une étape préliminaire de conception du système d'information. Cette étape préliminaire c'est l'analyse (GABILAUD, 2010).

Le Système d'Information représente l'ensemble des éléments participant à la gestion, au traitement, au transport et à la diffusion de l'information au sein de l'organisation. La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer.

Comme outils de modélisation nous avons utilisé ArgoUML pour la représentation de la réalité en vue de se concentrer sur les caractères qui nous influencera plus sur notre problème.

Comme nous l'avons dit tantôt, pour mener à bien notre analyse, concevoir jusqu'à réaliser notre système d'information, nous utiliserons la méthodologie UML (Unified Modeling Language, «langage de modélisation unifié») suivant ses trois points de vue

classiques de modélisation : fonctionnel, statique et dynamique. Ainsi nous insisterons pour chacun sur le ou les diagrammes UML prépondérants qu'il comporte et qui lui permet de se focaliser sur un aspect particulier du développement (Fraigniaud, 2013).

2.1.1 Du point de vue fonctionnel

Ce point de vue nous a permis d'illustrer les cas d'utilisation et les acteurs qui interviennent ou qui interagissent avec eux. Dans cette optique, nous allons construire le diagramme de cas d'utilisation, le premier modèle UML de haut niveau reliant les acteurs et les cas d'utilisation et le diagramme de séquence ou le diagramme d'activité qui précisera le point de vue fonctionnel en détaillant les différentes façons dont les acteurs peuvent utiliser le système.

2.1.2 Du point de vue statique

Ce point de vue va nous a permis de donner la représentation statique du système à développer. Cette représentation sera centrée sur les concepts de classe et d'association. Dans cet important point de vue, nous allons produire le diagramme de classes, le diagramme de packages, le diagramme d'objets, le diagramme de structure composite et le diagramme de déploiement. Le diagramme de classes sera le point central dans notre développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représentera la structure de notre code orienté objet ou, à un niveau de détail plus important, les modules du langage de développement. Le diagramme de classes mettra en oeuvre des classes, contenant des attributs et des opérations, et reliées par des associations ou des généralisations.

2.1.3 Du point de vue dynamique

Ce point de vue va nous a aidé d'illustrer pas à pas la vue dynamique par les diagrammes UML lié à ce point de vue. En commençant par identifier les acteurs et les cas d'utilisation, nous dessinerons tout d'abord un diagramme de séquence « système ».

Il s'est agi de fournir la solution à notre problème. La première étape consistera donc à analyser le problème, c'est-à-dire à cerner les limites et le mettre en forme dans un langage descriptif, on parle généralement d'analyse pour décrire le processus par lequel le problème est formalisé. L'algorithme est le langage de description utilisé pour écrire le résultat de l'analyse. L'étape suivante consistera à traduire l'algorithme dans un langage de programmation spécifique, il s'agira de la phase de programmation (Doré., 1998). Et dans notre cas nous avons utilisé le langage de programmation de la 5eme génération qui n'est autre que le Wlangage.

2.2 Le prototypage

Cette phase a consisté à donner un prototype de notre modèle c'est-à-dire un exemple réduit d'un système, partiellement réalisé et fonctionnel, pas robuste et lent, destiné à montrer ce que nous comptons mettre à la disposition des clients et administrateurs de restaurants moderne en République démocratique du Congo. Ainsi, le prototypage servira de véhiculer l'expérimentation, et sa construction fournira un nouvel aperçu sur le modèle prototypé.

Voilà pourquoi il nous faudra avoir un style qui traitera de la manière dont les solutions aux problèmes ou les algorithmes seront formulées. C'est ainsi que nous nous fixons la Programmation Orientée Objet (POO), toujours couplée avec la méthodologie UML, d'où l'approche orienté objet comme paradigme de programmation c'est-à-dire une

vue de l'exécution du programme que nous aurons tout au long de l'activité de programmation.

La Programmation Orientée Objet consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces entités informatiques sont appelées objets. Il s'agit de données informatiques regroupant les principales caractéristiques des éléments du monde réel (taille, couleur, ...).

2.3 L'expérimentation

(HARO, 2010) A écrit : « Un bon logiciel n'est ni celui dont on peut exhiber la preuve, ni celui qui fait ce qui est demandé, mais celui dont les utilisateurs se servent encore trois ans après sa création ».

L'expérimentation nous permettra de tester notre modèle et d'observer les effets. Ainsi, nous soumettrons le système que nous allons réaliser à une expérimentation c'est-à-dire à un ensemble des expériences et des opérations destinées à étudier et à tester notre système. Notre expérimentation sera conduite sous les conditions contrôlées c'est-à-dire en laboratoire. L'efficacité ou la performance de nos algorithmes sera liée au temps d'exécution (complexité temporelle) et à l'espace ou ressource mémoire (complexité spatiale). La complexité de nos algorithmes dépendra :

? Du matériel ou machine (hardware) sur lequel ils s'exécuteront ; ? Du système d'exploitation (software) ;

Chapitre III

CONCEPTION DE LA SOLUTION

Par Ce chapitre nous allons présenter la modélisation des données et des traitements c'est-à-dire les résultats obtenus de l'analyse, bref la conception de notre système d'information. Par modélisation des données nous avons analysé et concevoir les informations contenues dans le système en implémentant les procédures de communication pour passer commande, de gestion de la facturation et de la réservation de place par rapport à la gestion d'un restaurant moderne en république démocratique du Congo.

3.1 Modélisation

3.1.1 Les acteurs du système d'information.

Les acteurs internes sont ici ceux qui échangent régulièrement des informations dans le cadre de la gestion d'un restaurant. Pour notre cas, il s'agit du serveur du restaurant ainsi que les clients du restaurant qui sont donc directement impliqués dans la gestion quotidienne d'un restaurant moderne.

3.1.2 Les acteurs externes

3.1.3 Modélisation Fonctionnelle

3.1.3.1Diagramme des cas d'utilisation

Pour cette figure, le cas d'utilisation commander un plat hérite de celui de parcourir le plan du menu raison pour laquelle nous avons mis la flèche avec la mention Include

3.1.3.2 Diagramme d'activité

Commander un plat: vu que le cas d'utilisation parcourir les photos est inclus dans celui de commander un plat, nous avons décidé de faire un même diagramme d'activité pour le deux cas d'utilisation.

Client		Administrateur (Servant(e))
Parcourir les photos du
plat du Menu du restaurant
Dét ail non Vérification inté Détail du plat ress
ant
Si detail intéressant
Passer Commande
	Si com	pas
	Si Commande Existe		Validation Commande
			Établir facture
			Livrer la commande

Régler Facture
			Clôture du dossier

Client	Administrateur (Servant(e))
Voir les Pub du restaurant
Si pas Vérification de de type de réservation typ e vo ulu
Si type de place et de plat intéressant
	Validation
Réserver une table	réservation par
	Eil
Si table existe	ou non
Message de validation de de ou non validation	Clôture du dossier
réservation

3.1.4 Modélisation Statique

3.1.4.1 Règles de gestions des données

Cette partie décrit le fonctionnement de l'organisation portant sur les données manipulées. Ces contraintes sont les suivantes :

3.1.4.2 Diagramme de Classes

Réservation IDreservation: integer Nomreservation : char Date : date HeureDebut : time Heurefin : time

Chapitre IV

REALISATION DE LA SOLUTION

Cette partie a été pour nous une opportunité de présenter la traduction des algorithmes dans le langage Wlangage. Nous avons présenté les fonctions utilisées dans le programme et les fichiers des données. En outre, nous avons présenté le test de nos algorithmes et l'argumentation du résultat.

4.1 Configuration de l'ordinateur

La mise en oeuvre et les tests seront être exécutés sur une tablette Windows mobile Pocket et un ordinateur personnel classique avec les propriétés suivantes :

- Processeur : Intel(R) Core (TM) i3 CPU M @ 2.20GHz ; - Mémoire (RAM): 2.00GB (1.80 GB utilisable).

4.2 Présentation du Prototype

4.2.1 Logiciel et langages de programmation

- Système d'exploitation : Windows 7 Professionnel (système d'exploitation 32 bits) - Langage de programmation :

? WinDev, WinDev Mobile version 17 de la maison PC soft avec son langage de programmation Wlangage.

? Le PHP sa version 5.4.16 pour la réservation de place en ligne - Système de gestion de base des données :

? Le System de gestion de base des données : MySQL Version 5.6.12 pour la partie du site web de réservation de table en ligne.

4.3 Base des données

Pour réaliser notre base des données, nous avons utilisé le SGBDR intégré à notre outil de développement (WinDev 17 et WinDev mobile 17) qui n'est autre que l'Hyperfilesql pour traduire nos classes dans notre outil de développement nous a amené à produire la figure suivante :

Et pour la partie du site web avec MySQL pour la réservation de table en ligne nous avons produit la figure suivante :

4.4 Modularité

4.4.1 Le diagramme de package

contiendra l'affichage de tous les plats du restaurant via la tablette, la recherche d'un plat non répertorié sur le menu de la tablette et la commande du plat choisit.

? La partie « Publicité et réservation de table en ligne », incluant les publicité de tous les plat du restaurant en ligne via le site web du restaurant, la réservation d'une table en ligne via le site du restaurant et la vérification de diffèrent prix de plats.

			Plat
Facture	Facture	Plat
			Idphoto idplatordreaffich photo ordreaffichage
Numclient idclient phone	NumFacture Datefacture Platnom Quantité Prixunit	Idplat Nomplat Descriptionplat Prix photo libcat ordreaffichage idphotos
Ajouter() Supprimer Fermer()
	Ajouter() Supprimer Fermer()		Ajouter() Supprimer() Modifier() Fermer()

		Ajouter() Supprimer Fermer()

Dans notre prototype nous avons un modules coté application desktop gérant le choix de plat

par les clients via la tablette que nous avons appelé « RestoArmagedonPC », un module différents cotés applications web appelé communément « RestoArmagedonline » pour la réservation de table en ligne et un modules coté Mobile sur tablette gérant le menu du restaurant sur tablette et l'envoi de plat sélectionner par ce dernier que nous avons appelé « ProjetArmagedon».

4.5 Expérimentation du logiciel

4.5.1 Entrée des données

Cette fenêtre va nous permettre d'ajouter de nouveaux plats dans le BD, nous pouvons par exemple avoir ce donné pour pouvoir les entrer dans notre logiciel

Nom du plat	Description du plat	Prix du plat	Libellé	Photos	Idphotos
Plat du poulet	Juste un plat de la poule bien grillé	15$	poulet	Photos	1
Plat du riz	Juste un plat du riz aux haricots	1$	riz		2
Plat de la soupe	Juste un plat de la soupe bouillon	1$	soupe		3
Plat de la viande	Juste un plat de la viande	5$	viande		3
Plat du Poisson	Voici un bon plat du poisson aux tomates	5$	Poisson		4
Plat du sandwitch	Juste un plat	2$			5

Voici donc un exemple du plat que le restaurateur insère dans la base de donné de notre programme

Avec ce tableau nous allons voir comment on peut insérer les achats de client dans notre programme à partir des donné que les deux ce sont échanger à travers la communication intégrer dans notre programme.

Date facture	Nom client	Libelle	Quantité	Prix Unitaire	Prix Total	Identifiant facture
17/07/2015	Johnson Sikakulya	Plat Poisson	2	5$	10$	1
17/07/2015	ALAIN PABYA	Plat riz	1	1$	10$	2
17/07/2015	Milca Suhya	Plat soupe	1	2$	2$	3
18/07/2015	Gloire Patayo	Plat Poulet	2	15$	30$	5

Ce qui nous ramène d'entré les données à partir de ce formulaire de la manière suivante

Ses interfaces réalisent les opérations suivantes décrites dans nos modèles : saisies des

données, enregistrement des données, modification et modification de données.

4.5.2 Sorties de données

Cette fenêtre nous montre le menu des plats du restaurant du coté restaurateur à partir du formulaire du tableau

Cette fenêtre nous aide à réserver une table via le site du restaurant, ceci est juste

Et enfin voilà un extrait d'une facture d'un client qui vient de passer commande et qui vient d'enregistrer les données à partir du formulaire du tableau 2

4.5.3 La communication

Quantité commande	Nom du client	Nom du Plat	Numéro de la table
2	Johnson Sikakulya	Plat du poisson	Table2
1	Gloire Patayo	Plat Poulet	Table 1
1	Alain Pabya	Plat Riz	Table3

Pour ce qui est de la communication de donné pour le moment notre logiciel n'est pas à mesure de stocker ces donner. Une foi le client déconnecté du réseau de l'entreprise les données disparaissent.

Cette fenêtre nous montre comment le client communique avec le restaurateur pour pouvoir commande son plat préférer

4.6 Discussion des résultats

pages précédentes, les différents acteurs du système d'information sont en mesure

Considérant la brique logicielle que nous venons de mettre en place à travers les

Au cours de nos investigations, nous nous sommes heurtés à des difficultés que voici :

d'échanger l'information, envoyer son choix du plat sélectionner sur tablette à la machine du restaurateur à travers notre plateforme mobile et ceci grâce à l'utilisation de socket qui nous a permis de réaliser cette fastidieuse tache, à travers notre plateforme web Les client peuvent maintenant voir de plat en ligne, le prix de diffèrent plat, le témoignage de client et réserver une table gratuitement en ligne ce qui permet une très bonne politique de marketing pour tous le restaurant qui emboiterons leur pas dans ces actions.

? Un client peut voir tous le plat que le restaurant propose et après cela il est libre de pouvoir passer une commande à travers cette tablette grâce à la méthode de socket seulement en se connectant au réseau du restaurant en suite en écrivant son nom , le nom des plats qu'il désire manger et le numéro de la table ou il se trouve.

? Apres qu'un client aie complété et envoyer ses choix un message de confirmation est envoyé au client lui notifiant que ses sélections viennent dans l'immédiat et lui remerciant d'avoir choisi le resto.

? Sur la Platform web, un client peut voir le pub du restaurant, voir le prix de différents plats, l'environnement du restaurant et enfin réserver une table en ligne

? A la fin de la réservation de la table dans la plateforme web, un message de confirmation est envoyé au client lui notifiant de la prise en charge de sa réservation par email.

? Un état de sortie pour la facture de l'achat du client et produit à chaque
commande du client.

? La partie de la réservation de tables en ligne a été testé en local host vue la mangue de moyen pour l'achat d'un domaine.

? Nous n'avons pas testé nos algorithmes sur internet faute d'un environnement de travail nous permettant de le faire, mais nous avons simulé un environnement dans le PC qui nous a permis de les tester.

? Avec la méthode de socket que nous avons utilisé, nous n'avons pas été à mesure de canaliser chaque réponse d'une commande a un client spécifique car tous les messages et les réponses sont visible par tous les monde, et nous passons que les autres chercheurs peut être dans l'amélioration de ce travail pourrons palier à ce problème.

CONCLUSION

Nous voici au terme de notre travail portant sur la conception d'un logiciel multiplateforme pour la gestion interactif d'un restaurant. Nous avons été motivés par les soucis : de mettre à la disponibilité de clients d'un restaurant moderne une carte de menu automatisé, vue que cette carte devrait leur faciliter de communiquer avec le restaurateur pour lutter contre le problème de retard dans le service. Aussi le restaurateur devra facilement communiquer avec le client et gérer leur facturation à partir de commande sur le menu automatisé.

Pour y parvenir nous avons utilisé les technique documentaire et expérimentale, analyser certain travaux d'une part et d'une autre part tester notre application. Suivant les instructions du restaurant selon la législation congolaise, nous avons utilisé le langage de modélisation UML et enfin de concevoir nos algorithme nous avons opté pour le choix de AGL (atelier de génie logiciel) de de pc soft (WinDev et WinDev mobile 17) avec son puissant langage de la 5eme génération le Wlangage et pour optimiser le traitement de nos données nous avons utilisé le moteur de donné HyperfileSQL.

Pour cet fin, nous avons opté pour la mise en place d'un prototype sous tablette( Windows Mobile) pour faciliter aux clients la sélection du plat qu'ils désirent et la communication avec le restaurateur, la proposition d'un prototype sous Windows pour la réception de sélection de plat choisie par les clients à partir de la tablette et enfin la mise en ligne d'une plateforme web pour permettre la réservation de place(Table) par les clients éloigner du restaurant. Tous trois adaptables aux réalités de restaurant moderne en République démocratique du Congo.

Conscients de ce qu'une application informatique ne peut être certifié qu'à l'issue d'un test méticuleux, nous soumettons notre modeste travail à ce test et promettons, dans la mesure de nos propres limites, de prendre en compte toute remarque constructive.

Stum, A. (2014). Système multiplateforme distribué pour la gestion des établissements de l'E.S.U. Lukanga: Uniluk.

BIBLIOGRAPHIE

(Mutwelusiku. (2010). Conception du système de gestion informatisé de l'hôtel restaurant du lac Uvira. travail de fin de cycle, Uvira.

CHEHADE, W. E. (2011). Contribution au Déploiement Multiplateforme d'Applications

Multitâches par la Modélisation Comportementale Haut Niveau des Services d'Exécution. Paris.

GABILAUD. (2010). Administration de bases de données avec SQL Server Management Studio 2008. Paris: ENI.

Legislature. (1955 , septembre 2 ). Hôtels, restaurants, pensions de famille et débits de. Ord. 41-291.

Mathieu, & Grégory. (2012). Développement d'un système d'information multi-plateforme générique pour la visite de salons d'exposition. Louvain-la-neuve.

Oussama. (2009). Suivi automatisé de la gestion de stock dans un hotel : Cas de l'hôtel CONGOMANI AFRICANUS.

Pcsoft. (2013). Documentation d'autoformation windevmobile 17. Paris. Récupéré sur www.pcsoft.fr.

Roels, C. (s.d.). MOOC_UML/1emepartie/Débutez l'analyse logicielle avec UML.htm. (M. nebra, Éditeur, E. s. informatique, Producteur, & OpenClassrooms) Récupéré sur www.openclassrooms.fr.

Annexe

2001-2006 : Ecole Primaire Malepe/ Beni : obtention du certificat d'études primaires.

NOM ET POSTNOM

FONCTION

CONTACTS

1. Pr Dr Osée MUHINDO MASIVI

2. Ass. KATSON MALIRO

3. WEMA Kennedy

Directeur de NTIC (Nouvelle Technologie d'information et de Communication

Assistant à l'ISEAB

Directeur du Journal KENGELE

+243974054330 omasivi@yahoo.fr

+243 993136666

+243 998549170

Je déclare en âme et conscience que les informations ci-haut fournies sont sincères et vérifiables.