Rapport de fin d'études axel legué

A.D.R.A.R

Développement d’une application Android Développement d’une application sous Android

Axel Legué

23/01/2017

Axel Legué Développement d’une application Android 1

Préambule

Dans le cadre du projet nécessaire à l'obtention du titre de développeur logiciel j’ai décidé de

vous présenter, parmi mes réalisations de cette année, une application Android. J’ai choisi

l’application, car elle m’a permis de mettre en œuvre les apprentissages de ma formation de

développeur logiciel, et également de découvrir des problématiques auxquelles sont

confrontés les développeurs : organisation, implication, recherches d’informations,

approfondissement des connaissances. De plus ce travail sur ce projet s’est effectué en équipe

réduite composée de deux développeurs stagiaires et notre tuteur en chef de projet.

Notre tuteur de stage souhaite développer une application qui permette la prise de

commande ainsi que des outils de gestion de stock pour un de ses clients.

La mise en œuvre de cette application me permettra de mettre en application un grand

nombre de notions étudiées durant cette année de formation, notamment la programmation

orientée objet, mais aussi du PHP et du SQL.

L’application devra permettre à son utilisateur de prendre une commande, d’imprimer une

note et de connaitre la quantité de produit sorti du stock. Elle devra aussi intégrer une partie

administration pour l'ajout, la suppression, la modification de produit.

Je vais donc vous détailler dans la suite de ce rapport les différentes étapes mis en place

dans ce but.


Abstract

As part of a project required to obtain the degree specializing in software development, I

decided that I would submit, among my accomplishment, an Android application.

I have chosen to present this application, as it allowed me, to implement most technologies

being studied during this training as well as to find out about the challenges developers face

such as organization, involvement, information search, knowledge enhancement.

Furthermore, this work has been made by a small team compose of two trainees and the

tutor as a project manager.

Our trainees supervisor wishes to build an application that will allow to take orders from

customers as well as provide tools for stock management.

The implementation of the application will give me the opportunity to apply most

technologies being studied during this training. Indeed, for this project I will use the Java,

PHP, MySQL, SQLite and some framework.

The application should propose many features that ensure its good working such as order

intake, user management, print receipt, data storage. It shall include an administrative part

for the changes, removals and updates of products.

So I’m going to detail the different stages implemented for this purpose.


Table des matières

Introduction ........................................................................................................................................... 7

1 – Cahier des charges .......................................................................................................................... 8

1.1 -Objectif de l’application ? ................................................................................................... 8

1.2 - Technologie et limitation ? ...................................................................................................... 8

1.3 - Que doit faire l’application ? .................................................................................................. 8

2 - L'analyse des besoins .................................................................................................................... 10

2.1 - Définir le contexte de la future application. ....................................................................... 10

2.1.1 - Liste des acteurs principaux (humains) : ..................................................................... 10

2.1.2 - Liste de l'acteurs secondaire (non humain) : ............................................................... 10

2.1.3 - Représentation du système : .......................................................................................... 10

2.1.4 - Réalisation du diagramme de contexte ........................................................................ 11

2.2 - Décomposition du système en parties appelées « package » ........................................... 11

2.2.1 - Diviser en package .......................................................................................................... 11

2.2.2 - Réalisation du diagramme de « packages » ................................................................ 11

2.3 - Les cas d'utilisations .............................................................................................................. 12

2.4– Les descriptions textuelles..................................................................................................... 15

2.5– Les diagrammes de séquences. ............................................................................................. 16

2.6 – Réalisation du « Wireframe » ............................................................................................... 21

2.7 – Réalisation du diagramme de classe Java .......................................................................... 22

3 – Conception de la base de données Interne à l’application ..................................................... 23

3.1 – Modélisation conceptuel des données (MCD) .................................................................. 23

3.1.1 - Mise en place des règles de gestion .............................................................................. 23

3.1.2 - Réalisation du dictionnaire de données ....................................................................... 24

3.1.3 - Les dépendances fonctionnelles entre les données .................................................... 25

3.1.4 - Elaboration du MCD ....................................................................................................... 25

3.2 – Modélisation de la base de données au niveau relationnel et passage au SQLite ....... 27

3.2.1 - Les relations ..................................................................................................................... 27

4 – Développement de l’application ................................................................................................ 34

4.1 - Introduction ............................................................................................................................ 34

4.2 - Environnement de travail ..................................................................................................... 34

4.2.1 - Logiciels utilisés .............................................................................................................. 34

4.2.2 - Langages utilisés ............................................................................................................. 34


4.2.3 - Design Pattern ................................................................................................................. 35

4.3 - Plan de l'application............................................................................................................... 35

4.4 - Présentation du système Android ...................................................................................... 36

4.4.1 – Les fragments sous Android ......................................................................................... 37

4.5 - Description de l’application ................................................................................................. 37

4.5.1 - Ecran réglage .................................................................................................................... 37

4.5.2 - Ecran Accueil ................................................................................................................... 45

4.5.3 Ecran Bilan .......................................................................................................................... 49

4.5.4 Ecran Consommation ........................................................................................................ 51

Conclusion ........................................................................................................................................... 53

Annexe ................................................................................................................................................. 54

1 – Descriptions Textuelles ............................................................................................................ 54

2 - Wireframes ................................................................................................................................. 66


Table des figures

Figure 1 - Représentation des acteurs principaux .......................................................................... 10

Figure 2 - Représentation de l'acteur secondaire ........................................................................... 10

Figure 3 - Représentation du système ............................................................................................. 10

Figure 4 - Diagramme de contexte ................................................................................................... 11

Figure 5 - Représentation d'un « package » .................................................................................... 11

Figure 6 - Diagramme de « packages » ............................................................................................ 12

Figure 7 - Cas d'utilisation « Prendre une commande » ............................................................... 12

Figure 8 - Diagramme de cas d'utilisation, « package » prise de commande V1 ...................... 13

Figure 9 - Diagramme de cas d'utilisation, « package » prise de commande V2 ...................... 14

Figure 10 - Diagramme de cas d'utilisation, package gestion administrative ........................... 14

Figure 11 - Diagramme de séquences : faire une note et l'imprimer ........................................... 16

Figure 12 - Diagramme de séquences : consulter le bilan et l'imprimer ..................................... 17

Figure 13 - Diagramme de séquences : consulter et mettre à jour le stock ................................. 18

Figure 14 - Diagramme de séquences : ajouter, modifier et supprimer une catégorie ............. 19

Figure 15 - Diagramme de séquences : ajouter, modifier et supprimer un produit ................. 20

Figure 16 – Wireframe de la page d'accueil .................................................................................... 21

Figure 17 - Diagramme de classe de l’application ......................................................................... 22

Figure 18 - Dictionnaire de données, application Gestion Commande ...................................... 24

Figure 19 - Représentation des entités ............................................................................................. 25

Figure 20 - Formalisation d'une association ................................................................................... 26

Figure 21 - Association entre les entités "Produit" et "Categorie" ................................................ 26

Figure 22 - Association entre les entités "Produit" et "Commande" ............................................ 26

Figure 23 - MCD application Gestion de commande .................................................................... 27

Figure 24 - Représentation d’une association avec cardinalités de type « 0/1,N » ................... 28

Figure 25 - Représentation d’une association avec au moins une cardinalité de type « 1/1» . 29

Figure 26 - Représentation du MLD ................................................................................................ 30

Figure 27 - Classe MyDaoGenerator de greenDAO ...................................................................... 31

Figure 28 - Création d'une table categorie ...................................................................................... 31

Figure 29 - Ajout des attributs dans la table categorie .................................................................. 31

Figure 30 - Table Produit ................................................................................................................... 32

Figure 31 - Table Categorie ............................................................................................................... 32

Figure 32 - Création de la relation « 1,1/0,n » entre "produit" et "categorie"............................ 32

Figure 33 - Génération des tables ..................................................................................................... 32

Figure 34 - Base de données SQLite ................................................................................................. 33

Figure 35 - Schéma du modèle MVC ............................................................................................... 35

Figure 36 - Arborescence de l'application ....................................................................................... 35

Figure 37 - cycle de vie simplifiée d'une activité ........................................................................... 36

Figure 38 - Menu de navigation, Activité principale ..................................................................... 38

Figure 39 - Sélection de l'item du menu .......................................................................................... 39

Figure 40 - Méthode gotoReglage .................................................................................................... 39

Figure 41 – AlertDialog gérant la connexion à l’écran réglages .................................................. 40

Figure 42 - Méthode changeFragment de DrawerActivity ........................................................... 40

Figure 43 - Présentation de l'écran réglage ..................................................................................... 41


Figure 44 - Boite de dialogue d'ajout de catégorie ........................................................................ 41

Figure 45 - Outil de sélection de couleurs ....................................................................................... 42

Figure 46 - Une catégorie sélectionné .............................................................................................. 42

Figure 47 - Boite de dialogue permettant la modification d'une catégorie ................................ 42

Figure 48 - Requête qui permet la suppression d'une catégorie .................................................. 43

Figure 49 - Sélection des options du menu ..................................................................................... 44

Figure 50 - Méthodes déclenchés dans l'AsyncTask ...................................................................... 44

Figure 51 - Méthode de sauvegarde de la base de données ......................................................... 44

Figure 52 - Méthode qui permet la sauvegarde de la table catégorie ......................................... 45

Figure 53 - Ecran d'accueil de l'application .................................................................................... 45

Figure 54 - Ajout d'un produit favoris à la note ............................................................................. 46

Figure 55 - Sélection d'une catégorie ............................................................................................... 46

Figure 56 - Sélection d'une catégorie et ajout d'un produit .......................................................... 47

Figure 57 - CallBack vers ProductAdapter ..................................................................................... 47

Figure 58 - Méthode d'ajout d'un produit à la note ....................................................................... 48

Figure 59 - sauvegarde de la commande en base de donnée ....................................................... 49

Figure 60 - Ecran bilan ....................................................................................................................... 50

Figure 61 – Boîte de dialogue permettant de sélectionner une date ........................................... 50

Figure 62 - Ecran consommation ...................................................................................................... 51

Figure 63 - Sélection de la quantité recommandée ........................................................................ 52

Figure 64 - Menu de navigation ....................................................................................................... 66

Figure 65 - Ecran bilan ....................................................................................................................... 66

Figure 66 - Boite de dialogue, ajout de produit ............................................................................. 66

Figure 67 - Ecran réglages ................................................................................................................. 67

Figure 68 - Ecran stock ....................................................................................................................... 67


Introduction

L’objectif de ce document est de présenter les différentes étapes de ce projet qui ont permis

d’aboutir à la création d’une application Android opérationnelle.

Nous commençons logiquement par la « définition des objectifs et l’analyse des besoins »,

avant de passer à la « conception générale et détaillées », pour terminer sur la partie

technique, « la programmation ».

Notre tuteur nous demande le développement d’une application mobile pour tablette sous

Android permettant la saisie de commande par un serveur de bar. Cette application vient en

remplacement d’une application vieillissante et peu ergonomique.

Dans les grandes lignes, l’application devra permettre :

La saisie de commande.

Impression d’un ticket de caisse.

Consulter des informations sur la consommation des produits proposées.


1 – Cahier des charges

Pour la réalisation de ce projet nous avons réalisé un cahier des charges avec l’aide du client.

Qui est notre client ?

Notre client est formateur Java Android et souhaite déléguer la réalisation d’une de ses

applications.

1.1 -Objectif de l’application ?

L’application devra permettre la prise de commande d’un client par un serveur1, elle devra

permettre l’impression d’une note ainsi que fournir des outils de gestion de stock au

responsable.

1.2 - Technologie et limitation ?

Application Android 4 et supérieur.

Utilisation de GreenDAO (ORM, “object/relational mapping”) pour base de données.

1.3 - Que doit faire l’application ?

L’utilisateur doit pouvoir :

Prendre une commande

Imprimer une note

Consulter le stock

Consulter le bilan du jour, semaine, mois, année.

L’administrateur doit pouvoir :

Paramétrer des catégories dans l’application :

o Nom de la catégorie

o Type de la catégorie (couleur)

Paramétrer des produits dans l’application :

o Type de produit (couleur)

o Type de contenant (bouteille, paquet…)

o Nom

o Tarif

o Quantité par unité de remplacement

o Favori

Mettre à jour le stock

Consulter le stock

Consulter le bilan

1 Personne employée dans un café, un restaurant, pour servir la clientèle.


L’utilisateur ne doit pas pouvoir :

Modifier le stock

L’application ne devra pas :

Posséder de système d’encaissement

Etre relier au stock réel

Je suis ensuite passé dans la phase d'analyse des besoins


2 - L'analyse des besoins

Dans cette phase le but est de bien comprendre et de décrire de façon précise les besoins de

l'utilisateur et du client. Pour cela je me suis rapproché du modèle UML2. C'est un langage de

modélisation qui permet de représenter graphiquement le besoin des utilisateurs sous forme

de diagrammes.

2.1 - Définir le contexte de la future application.

Il nous a fallu dans un premier temps déterminer les acteurs principaux qui agissent

directement sur le système. Le système dans ce cas-ci représente l'application « Gestion de

commande ».

Puis, ensuite nous avons dû déterminer la liste des acteurs secondaires qui n'ont pas de

besoins d'utilisation du système.

2.1.1 - Liste des acteurs principaux (humains) :

Figure 1 - Représentation des acteurs principaux

2.1.2 - Liste de l'acteurs secondaire (non humain) :

Figure 2 - Représentation de l'acteur secondaire

2.1.3 - Représentation du système :

Figure 3 - Représentation du système

2 U.M.L: Unified Modeling Language.


Une fois que nous avons déterminé les différents acteurs qui agissent sur le système nous

avons pu réaliser le diagramme de contexte.

2.1.4 - Réalisation du diagramme de contexte

Figure 4 - Diagramme de contexte

2.2 - Décomposition du système en parties appelées « package »

Dans cette partie nous avons découpé l’application en différentes parties distinctes qui vont

regrouper des fonctionnalités similaires afin de les analyser de façon séparée par la suite.

2.2.1 - Diviser en package

L'objectif est d'identifier les parties différentes. Dans le cadre de ce projet nous avons

identifié deux parties distinctes :

1. La prise de commande, qui regroupe la sélection des produits, l’impression d’une

note et la clôture de la commande.

2. La gestion administrative, qui regroupe l’ajout, la modification et la suppression de

catégories et/ou produits. Elle contient également la partie gestion du stock et

consultation du bilan.

2.2.2 - Réalisation du diagramme de « packages »

Grace à ce découpage en « packages » nous avons pu compléter le diagramme de contexte et

ainsi créer le diagramme de « package ».

Figure 5 - Représentation d'un « package »


Figure 6 - Diagramme de « packages »

2.3 - Les cas d'utilisations

L’objectif des cas d’utilisations et de définir en détail les besoins de chaque acteur au sein de

chaque « package ».

Dans cette partie nous avons détaillé le processus permettant de réaliser les cas d’utilisations

pour la prise de commande.

Pour ce projet nous avons déterminé qu’un serveur doit pouvoir prendre une commande via

l’application. « Prendre une commande » est donc un cas d’utilisation.

Figure 7 - Cas d'utilisation « Prendre une commande »


Donc pour ce package nous nous retrouvons avec le diagramme de cas d’utilisation suivant :

Figure 8 - Diagramme de cas d'utilisation, « package » prise de commande V1

Cependant ce cas d’utilisation peut être détaillé avec des cas d’utilisations internes.

Par exemple pour le cas « prendre une commande » un serveur doit forcément :

Sélectionner une catégorie

Sélectionner un produit

Imprimer une note

Finaliser une commande

Mais le serveur peut aussi :

Annuler un produit commandé si au moins un produit a été sélectionné.

Annuler tous les produits commandés si au moins un produit a été sélectionné.

Ajouter à la commande un produit favoris sans passer par la sélection de catégorie.

Nous avons donc dû créer des cas d’utilisations internes qui seront liés au cas d’utilisation

principal « prendre une commande ».

Nous avons également remarqué que les cas d’utilisations : « annuler un produit » et

« annuler tous les produits » ; seront des cas d’utilisations internes du cas d’utilisation

« sélectionner un produit » et « sélectionner un favori ».


Nous avons donc complété notre diagramme de cas d’utilisation :

Figure 9 - Diagramme de cas d'utilisation, « package » prise de commande V2

Nous avons donc aussi réalisé le diagramme de cas d’utilisation pour le package « gestion

administrative »

Figure 10 - Diagramme de cas d'utilisation, package gestion administrative


2.4– Les descriptions textuelles.

Les descriptions textuelles permettent de décrire la chronologie des actions qui devront être

réalisées par les acteurs et le système.

Exemple d’une description textuelle pour le scénario « imprimer une note » :

Nom : Imprimer une note (package « Prise de commande ») Acteurs : Serveur / imprimante Bluetooth Description : Imprimer une note concerne le serveur, il doit pouvoir imprimer un ticket de caisse lors de la validation de la commande. Auteur : Axel & Allan Date : 15/11/2016 Préconditions : un produit doit être sélectionné Démarrage : le serveur a sélectionné un produit. Scénario nominal 1. Le système affiche le/les produit(s) sélectionné(s) 2. Le serveur sélectionne l’impression. 3.Le système envoi une demande d’impression. 4. L’imprimante donne l’autorisation. 5. Le système envoi les informations à l’imprimante Bluetooth. 6. L’imprimante réceptionne les informations du système. 7. L’imprimante lance l’impression du ticket de caisse. 8. Le système affiche que l’impression s’est bien déroulé. Scénario alternatif : Aucun Scénario d’exception 3a. L’impression du ticket n’a pas réussi Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation). Fin :

Scénario nominal : à l’étape 8 sur décision du serveur.

Scénario d’exception : 3a l’impression du ticket a échoué, un message s’affiche sur le système.

Post-conditions : Scénario nominal : aucun. Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtres pop-up.

Nous avons réalisé ces descriptions pour chaque cas d’utilisations. Ces descriptions sont

disponibles en annexe pour ne pas alourdir la lecture du rapport.

Une fois les descriptions textuelles effectuées nous avons réalisé les diagrammes de

séquences.


2.5– Les diagrammes de séquences.

Ces diagrammes permettent de décrire les scénarios complets d’utilisation de l’application.

Figure 11 - Diagramme de séquences : faire une note et l'imprimer


Figure 12 - Diagramme de séquences : consulter le bilan et l'imprimer


Figure 13 - Diagramme de séquences : consulter et mettre à jour le stock


Figure 14 - Diagramme de séquences : ajouter, modifier et supprimer une catégorie


Figure 15 - Diagramme de séquences : ajouter, modifier et supprimer un produit


Nous sommes ensuite passé au maquettage de l’application.

2.6 – Réalisation du « Wireframe »

Le « wireframe » permet d’indiquer le contenu présent dans chaque écran de l’application et

de structurer l’interface. Dans cette partie, je vais vous montrer uniquement le « wireframe »

de la page d’accueil cependant le « wireframe » complet de l’application est disponible en

annexe.

Figure 16 – Wireframe de la page d'accueil


2.7 – Réalisation du diagramme de classe Java

Le diagramme de classe va permettre de représenter une vue statique du système. Ce

diagramme nous servira pour structurer le code de notre application.

Figure 17 - Diagramme de classe de l’application


3 – Conception de la base de données Interne à l’application

3.1 – Modélisation conceptuel des données (MCD)

Le MCD est une représentation graphique et structurée des informations mémorisées par un

système d’information 3(SI).

L'élaboration du MCD passe par les étapes suivantes :

La mise en place de règles de gestion,

L'élaboration du dictionnaire des données,

La recherche des dépendances fonctionnelles entre ces données,

L'élaboration du MCD (création des entités, puis des associations et ensuite ajout des

cardinalités).

3.1.1 - Mise en place des règles de gestion

Pour la création des tables nous avons dû recueillir les besoins de notre client concernant le

fonctionnement de l’application par ses utilisateurs et lui-même.

Une catégorie est identifiée par un numéro unique.

Pour chaque catégorie nous devons connaitre son nom, sa couleur.

Un produit est identifié par un numéro unique.

Pour chaque produit nous devons connaitre son nom, prix et lot.

Un produit doit être organisé dans des catégories.

Un produit ne peut appartenir qu’a une seule catégorie.

Un produit ne peut être modifié, ajouté ou supprimé que par l’administrateur.

Une commande doit contenir le ou les produits commandés et leurs prix, la date de

commande et le prix total de la commande.

Une commande finalisée entraine forcément l’impression d’un ticket.

Une commande contient au minimum un produit.

Un serveur ne peut prendre qu’une commande à la fois.

Un serveur n’a pas à s’identifier.

L’administrateur doit avoir un mot de passe.

Pour modifier, ajouter ou supprimer les catégories ou produits, il faut être connecté

en tant qu’administrateur.

3 Système d’information : l'ensemble des moyens humains, matériels et immatériels mis en œuvre afin de gérer l'information au sein d'une unité (dans ce cas-ci Studio Sage).


3.1.2 - Réalisation du dictionnaire de données

Le dictionnaire des données est un document qui va regrouper toutes les données que nous

allons avoir à conserver dans notre base de données. Pour chaque donnée il indique :

Le code mnémonique : il s’agit du nom symbolique d’une donnée (par exemple

UserID).

La désignation : décrit à quoi sert la donnée.

Le type de donnée :

« AN » lorsque la donnée est de type alphanumérique.

« Date » lorsque la donnée est de type date.

« Booléen » lorsque la donnée est Vrai ou Fausse.

« N » lorsque la donnée est de type numéraire.

La taille des données.

Parfois des remarques ou observations.

Figure 18 - Dictionnaire de données, application Gestion Commande


3.1.3 - Les dépendances fonctionnelles entre les données

Pour deux données distinctes « D1 » et « D2 », on dit que « D1 » et « D2 » sont reliées par une

dépendance fonctionnelle (DF) si et seulement si une valeur de « D1 » permet de connaitre

une et une seule occurrence de « D2 ».

Cette dépendance est représentée comme ceci :

D1 -> D2

A partir de mon dictionnaire de données j’ai pu établir les « DF » suivantes :

- idProduit -> nomProduit, prixProduit, lotProduit, favoriProduit,

consommationProduit, lotRecommandeProduit

- idCategorie -> nomCategorie, couleurCategorie

- idCommande -> dateCommande

Ça signifie donc qu’à partir de :

L’identifiant du produit, nous obtenons le nom du produit, son prix, son lot, s’il est

favori, sa consommation et sa quantité recommandée.

De l’identifiant de la catégorie, nous obtenons son nom et sa couleur.

De l’identifiant de la commande, nous obtenons la date de commande.

L’identifiant de la commande et l’identifiant du produit, nous récupérons la quantité

consommée.

3.1.4 - Elaboration du MCD

Pour l’élaboration du MCD je vais utiliser le logiciel « JMerise » qui permet de créer le MCD

et générer le modèle relationnel de données.

3.1.4.1 - Les entités

Chaque entité est unique et est décrite par un ensemble d’attributs.

Un des attributs de l’entité est l’identifiant qui doit avoir des occurrences uniques et doit être

la source des dépendances fonctionnelles avec toutes les autres propriétés de l’entité.

Nous avons donc maintenant créé les entités sous formes de tableau :

Figure 19 - Représentation des entités


3.1.4.2 - Les associations

Dans cette partie je vais détailler deux exemples qui permettent de définir les associations 4

au sein de mon modèle.

Une association est formalisée de cette façon :

Figure 20 - Formalisation d'une association

Le nom de l’association est un verbe qui définit le lien entre les entités, ces entités sont reliées

par cette association.

1er exemple : association entre les entités « Produit » et « Categorie » :

Figure 21 - Association entre les entités "Produit" et "Categorie"

Dans cet exemple l’association « Contenir » traduit les deux règles suivantes :

1. Une « Categorie » peut contenir aucun ou plusieurs produits.

2. Un « Produit » doit être contenu dans une et une seule « Categorie ».

Ces règles de gestion sont caractérisées par les cardinalités qui sont représentées sous forme

d’annotations « 1, 1 », « 0, n ».

Le premier chiffre de la cardinalité indique le minimum et le second le maximum.

2ème exemple : association entre l’entité « Produit » et « Commande » :

Figure 22 - Association entre les entités "Produit" et "Commande"

Dans cet exemple l’association « Generer » traduit les deux règles de gestion suivantes :

1. Un produit peut générer zéro ou plusieurs commandes.

2. Une commande peut être généré par zéro ou plusieurs produits.

4 Une association définit un lien entre une ou plusieurs entités


Cependant dans le cadre d’une association de type « 0,n/0,n », l’association « Generer » peut

être identifiée par la concaténation des attributs « idProduit » et « idCommande ». Nous

avons donc pu en déduire une dépendance fonctionnelle.

IdProduit, idCommande -> quantite

« quantite » et donc une donnée portée par l’association « Generer ».

3.1.4.3 - Elaboration du MCD

Maintenant que nous connaissons nos entités et nos associations, nous pouvons réaliser le

MCD ci-dessous :

Figure 23 - MCD application Gestion de commande

3.2 – Modélisation de la base de données au niveau relationnel et

passage au SQLite

Dans cette partie, nous avons établi une modélisation des données au niveau relationnel à

partir du modèle conceptuel et pour finir nous avons réalisés la création des tables en SQLite

via greenDAO qui est un ORM 5.

3.2.1 - Les relations

Une relation est composée d’attributs.

Une relation possède un nom qui correspond en général à celui de l’entité ou de l’association

qui lui correspond.

5 O.R.M : Object/relationnal mapping


Une relation possède généralement une clé-primaire qui permet d’identifier sans ambiguïtés

chaque attribut de cette relation. Il est important de noter qu’une clé-primaire peut être

composée de plusieurs attributs.

3.2.1.1 - Règles de conversion

Règle 1 : conversion d’une entité.

Toute entité du MCD devient une relation dont la clé est l’identifiant de cette entité. Chaque

propriété de l’entité devient un attribut de la relation correspondante.

Règle2 : conversion d’une association n’ayant que des cardinalités de type « 0/1,N ».

Une association ayant des cardinalités « 0,N » ou « 1,N » de part et d’autre devient une

relation dont la clé est constituée des identifiants des entités reliées par cette association. Ces

identifiants seront donc également des clé-étrangères respectives.

Exemple :

Figure 24 - Représentation d’une association avec cardinalités de type « 0/1,N »

L’association « Generer » devra être traduite comme ceci :

Légende :

X : relation

X : clé-primaire

X # : clé-étrangère

Generer (idProduit #, idCommande #, quantite)

Règle3 : conversion des associations ayant au moins une cardinalité de type « 1,1 ».

Nous ajoutons une clé-étrangère dans la table qui correspond à l’entité se situant du coté de

cette cardinalité « 1,1 ».

Lorsque deux entités sont toutes deux reliées avec une cardinalité « 1,1 », par une même

association, nous pouvons placer la clé-étrangère de n'importe quel côté. Par convention,

nous choisissons de la placer du côté de la relation correspondant à l'entité ayant le plus de

liaisons avec les autres.


Exemple :

Figure 25 - Représentation d’une association avec au moins une cardinalité de type « 1/1»

L’association « Contenir » devra être traduite comme ceci :

Produit (idProduit, nomProduit, prixProduit, lotProduit, favoriProduit,

consommationProduit, lotRecommandeProduit, idCategorie #)

Categorie (idCategorie, nomCategorie, couleurCategorie)

Règle4 : conversion des associations ayant au moins une cardinalité de type 0,1 et

dont les autres cardinalités sont de type 0,1/N

Nous procédons de la même façon que pour la règle 3.

3.2.1.2 - Elaboration du MLD et passage au SQL

Avec ces différentes règles de conversion j’ai pu convertir le MCD au complet :

Produit (idProduit, nomProduit, prixProduit, lotProduit, favoriProduit,

consommationProduit, lotRecommandeProduit, idCategorie #)

Generer (idProduit #, idCommande #, quantite)

Categorie (idCategorie, nomCategorie, couleurCategorie)

Commande (idCommande, dateCommande)


Ou encore sa représentation graphique :

Figure 26 - Représentation du MLD

Pour que mon MLD soit valide il faut que chacune de ses relations soit au moins en 3ème

forme normale. Ce qui est le cas dans mon MLD.

Pour rappel des règles de vérification des niveaux de normalisations :

Pour être en première forme normale (1FN ou 1NF) : Les attributs d'une relation

doivent être atomiques et doivent être en dépendance fonctionnelle avec la clé

primaire de cette dernière.

Pour être en deuxième forme normale (2FN ou 2NF) : Il faut être en 1NF et que toutes

les dépendances fonctionnelles entre la clé primaire et les autres attributs de la

relation soient élémentaires. Autrement dit, les attributs doivent dépendre de la

totalité de la clé.

Pour être en troisième forme normale (3FN ou 3NF) : Il faut être en 2NF et que toutes

les dépendances fonctionnelles entre la clé primaire de la relation et les autres

attributs soient directes.

Les règles de passages au SQLite sont les suivantes :

Chaque relation devient une table

Chaque attribut de la relation devient une colonne de la table correspondante

Chaque clé primaire devient une « Primary key »

Chaque clé étrangère devient une « Foreign key »


La création de la base de données relationnelle sera faite par greenDAO à l’intérieur d’une

classe Java nommée MyDaoGenerator :

Figure 27 - Classe MyDaoGenerator de greenDAO

La création d’une table sous greenDAO :

Figure 28 - Création d'une table categorie

L’ajout des attributs sous greenDAO :

Figure 29 - Ajout des attributs dans la table categorie


Exemple de création de la relation entre la table « categorie » et la table « produit » sous

greenDao :

Figure 30 - Table Produit

Figure 31 - Table Categorie

Figure 32 - Création de la relation « 1,1/0,n » entre "produit" et "categorie"

Pour réaliser la relation nous avons ajouté un attribut « CategorieID » à l’intérieur de la table

produit.

Puis nous avons indiqué qu’il y a une relation addToOne de produit vers catégorie, cela

signifie qu’un produit ne peut appartenir qu’à une et une seule catégorie.

Nous indiquons ensuite une relation addToMany de catégorie vers produit pour indiquer

qu’une catégorie peut contenir plusieurs produits.

Puis pour générer les tables nous ajoutons le code suivant à la fin de la class

MyDaoGenerator :

Figure 33 - Génération des tables


Au final nous avons obtenu la base de données relationnel suivante :

Figure 34 - Base de données SQLite


4 – Développement de l’application

4.1 - Introduction

Après avoir réalisé l'étude et la conception de notre application nous sommes passés à la

phase d'implémentation. Cette étape présente le résultat du travail effectué durant ce stage

de fin d'études.

Nous allons vous présenter les outils de développement utilisés puis nous clôturerons cette

partie par des captures d'écrans afin de présenter les fonctionnalités de notre application.

4.2 - Environnement de travail

4.2.1 - Logiciels utilisés

Les logiciels utilisés pour la réalisation de ce projet sont :

4.2.1.1 - Android Studio

C'est un environnement de développement intégré (EDI) permettant la

création d'applications Android.

4.2.1.2 - PhpStorm

C'est un EDI multiplateforme pour PHP.

4.2.1.3 - WampServer

C'est une plateforme de développement Web sous Windows. Il comprend

deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi

qu'une partie administration Web des bases MySQL.

4.2.1.4 - GreenDao

C'est un ORM (Object-Relational Mapping) qui permet de créer l'illusion d'une

base de données orientée objet à partir d'une base de données relationnelle en

définissant des correspondances entre cette base de données et les objets du

langage utilisé.

4.2.2 - Langages utilisés

4.2.2.1 - PHP (Hypertext Preprocessor)

C'est un langage de scripts permettant la réalisation de page web dynamique

et la connexion à des bases de données.

4.2.2.2 - Java

C'est un langage de programmation orienté objet. De plus Java permet de

créer des programmes qui s'exécutent sur n'importe quel système du moment

qu'ils possèdent une machine virtuelle Java (JVM).


4.2.3 - Design Pattern

Nous sommes partis sur le modèle MVC (Modèle Vue Contrôleur), cela permet d’avoir un

code plus structuré, plus évolutif et plus facilement maintenable.

Figure 35 - Schéma du modèle MVC

4.3 - Plan de l'application

Je vais maintenant vous présenter l'arborescence de l’application :

Figure 36 - Arborescence de l'application

L’application est composée d’un menu de navigation accessible sur l’ensemble des écrans, et

elle est composée de quatre écrans différents.


4.4 - Présentation du système Android

Android est un système d’exploitation à destination des terminaux mobiles. Le langage

Android à la particularité de ne pas centraliser tout le code d’une application sur une

méthode « main » mais fonctionne sur le principe des activités, qui ont un cycle de vie bien

défini. Une activité est constituée d’un « contexte » et d’une interface graphique. Le contexte

fait le lien entre l’application et le système alors que l’interface graphique affiche les données

à l’écran permettant ainsi à l’utilisateur d’interagir avec l’activité.

Figure 37 - cycle de vie simplifiée d'une activité


En Android, le code doit comprendre les actions spécifiques à chaque état possible de

l’application ; de plus une des spécificités est que l’interface graphique et le code contenant

les évènements de l’application sont pratiquement indépendants. Le seul lien entre ces deux

interfaces est la liste des identités, des « greffons », contenus dans le fichier XML renvoyant

sur les différents éléments graphiques de l’application.

Lors de la création d’un projet Android nous avons accès à des fichiers ressources qui

contiennent des informations qui ne sont pas du code et qui ne sont pas dynamique. Les

ressources possèdent un rôle précis :

La partie « drawable » regroupe les fichiers de type image qui devront s’afficher sur

l’application.

La partie « layout » qui regroupe les fichiers XML qui seront attachés aux activités

pour mettre en place différentes vues.

La partie « values » qui contient des valeurs pour les chaines de caractères, les

dimensions, les couleurs etc.

La partie « menu » qui contient les déclarations des éléments pour confectionner les

menus.

Il est important de noter que les ressources génèrent un identifiant unique dans le fichier

R.java permettant ainsi de les récupérer dans la partie Java de l’application.

4.4.1 – Les fragments sous Android

Pour notre application notre tuteur nous a demandé de réaliser l’application par

l’implémentation de « fragment ».

Les fragments sont à mi-chemin entre les activités et les vues. Ils permettent de définir des

morceaux d’interfaces, un ensemble de vues, qu’il est possible de contrôler et de réutiliser

sur plusieurs écrans.

Il est important de noter que les fragments ont un cycle de vie qui leur est propre. Leur cycle

de vie est lié au cycle de vie de l’activité hôte en cours d’exécution. Un « fragment » est

attaché à une activité. De plus chaque fragment possède sa propre interface graphique.

4.5 - Description de l’application

4.5.1 - Ecran réglage

Dans cette partie nous allons vous décrire le code qui permet de créer l’écran réglage. Cet

écran est le plus important car c’est celui qui permet le remplissage de la base de données sur

laquelle repose toute l’application. Il gère également la sauvegarde et la réinitialisation de la

base de données via un webservice.


4.5.1.1 – Introduction

L’idée de cet écran est de présenter une interface graphique simple et lisible permettant à

l’administrateur de structurer et renseigner les produits qui seront proposés par son

établissement à ses clients.

La procédure est la suivante : l’administrateur doit rentrer un mot de passe pour pouvoir

accéder à l’écran, si le mot de passe est correct alors il va pouvoir déclencher l’insertion, la

suppression ou la modification de produit en base de données. Il pourra également générer

une sauvegarde de sa base de données en ligne ou la recharger à un état antérieur. Ces

interactions avec la BDD seront faites via un ORM pour ce qui concerne les produits

proposés ou par l’intermédiaire d’un Webservice réalisé en PHP pour la sauvegarde de cette

dernière.

4.5.1.2 – Connexion

Figure 38 - Menu de navigation, Activité principale

Pour accéder à l’écran réglage nous devons passer par notre menu de navigation. Ce menu

est en fait notre activité principale qui est lié à un fragment. Par défaut il s’agit du fragment

de la page d’accueil. Chaque item de ce menu appel un fragment qui sera ensuite lié à

l’activité principale à la place du fragment de la page d’accueil.


Voici le code permettant d’appeler un nouveau fragment :

Figure 39 - Sélection de l'item du menu

Nous remarquons que lors de la sélection de l’item Reglage du menu nous appelons une

méthode gotoReglage(true) qui prend un booléen en paramètre.

Figure 40 - Méthode gotoReglage

Cette méthode permet de vérifier dans un premier temps dans quel fragment nous nous

trouvons. Si nous ne sommes pas sur le Fragment réglage alors nous appelons la méthode

loginDialog de la classe AlertDialogutils.


Cette méthode lance une boite de dialogue qui fait une demande de mot de passe à

l’utilisateur :

Figure 41 – AlertDialog gérant la connexion à l’écran réglages

Une fois les opérations de contrôle du mot de passe effectuées nous pouvons rediriger

l'utilisateur sur la page réglage, si le mot de passe est correct, via la méthode changeFragment

de DrawerActivity.

Figure 42 - Méthode changeFragment de DrawerActivity


Nous nous retrouvons donc redirigé vers l'écran réglage qui est composé de trois parties.

Figure 43 - Présentation de l'écran réglage

La première partie, en rouge, correspond à la zone des catégories. C'est ici que sont

gérées les actions concernant les catégories ;

La deuxième partie, en vert, correspond à la zone des produits. C'est ici que sont

gérées les actions concernant les produits ;

La troisième partie, en jaune, correspond à la zone de sauvegarde et restauration de la

base de données.

4.5.1.2 – Gestion des catégories

4.5.1.2.1 - Ajouter une catégorie

L'administrateur doit pouvoir ajouter une catégorie de façon simple, nous avons opté de

passer par un bouton qui à l'activation lance une boite de dialogue permettant de renseigner

les champs nécessaires à la création d'une catégorie, c'est à dire un Nom et une Couleur.

Figure 44 - Boite de dialogue d'ajout de catégorie


Le nom est renseigné via un champ de saisie de texte. Tandis que la couleur est renseignée à

l'aide d'un outil de sélection de couleur.

Figure 45 - Outil de sélection de couleurs

4.5.1.2.2 - Modifier, supprimer une catégorie

L'administrateur doit pouvoir également modifier ou supprimer une catégorie existante.

Figure 46 - Une catégorie sélectionnée

Pour cela il doit sélectionner la catégorie qu'il veut modifier, lors de la sélection nous

remarquons l'apparition de 2 boutons :

Le premier bouton permet de modifier une catégorie existante par l'intermédiaire

d'une boite de dialogue ;

Figure 47 - Boite de dialogue permettant la modification d'une catégorie


Le second bouton sous forme d'image permet quant à lui de supprimer une catégorie

existante de la base de données en appelant la méthode deleteCategorie.

Figure 48 - Requête qui permet la suppression d'une catégorie

4.5.1.3 – Gestion des produits

La gestion des produits est similaire à celle d'une catégorie. Je ne vais donc pas la présenter.

4.5.1.4 - Sauvegarder, restaurer la base de données via un serveur distant.

Les actions qui interagissent avec la base de données se situent dans le menu du fragment

qui correspond à la zone en jaune (voir figure n°43).

4.5.1.4.1 – Format et méthodes pour échanger des fichiers

Pour pouvoir réaliser les sauvegardes vers un serveur il est obligatoire de passer par

une AsyncTask qui est une classe permettant de réaliser des tâches de manière asynchrone.

Lors du développement d’application, il faut réaliser les tâches consommatrices de

ressources dans un Thread6 séparé car si le Thread principal reste bloqué trop longtemps

l'application se ferme automatiquement.

Pour une sauvegarde de la base de données l'AsyncTask transmet au WebService la totalité

de la base de données au format JSON (JavaScript Object Notation). Le format JSON permet

de stocker et d'échanger des données au format texte entre un Webservice et un serveur.

Pour restaurer la base de données à un état antérieur l'application récupère un fichier JSON

provenant du serveur et transmis via le WebService.

6 Thread : permet de dérouler plusieurs suites d'instructions, en parallèle, à l'intérieur du même processus.


4.5.1.4.1 - Sauvegarder, restaurer la base de données

L'administrateur peut à tout instant sauvegarder ou restaurer sa base de données via

les options du menu du fragment réglage.

Figure 49 - Sélection des options du menu

Cela déclenchera donc une AsyncTask qui exécutera les méthodes nécessaires à la

sauvegarde ou la restauration de la base de données.

Figure 50 - Méthodes déclenchés dans l'AsyncTask

Prenons l’exemple d’une sauvegarde de la base de données.

L’utilisateur va donc déclencher la méthode saveData de la classe WSutils.

Figure 51 - Méthode de sauvegarde de la base de données


Cette méthode appel en fait quatre autres méthodes qui permettent de retranscrire les

données de la base sous la forme d’un fichier JSON qui est ensuite envoyé à l’URL

correspondante.

Figure 52 - Méthode qui permet la sauvegarde de la table catégorie

4.5.2 - Ecran Accueil

4.5.2.1 – Introduction

L’idée de cet écran est de proposer à l'utilisateur une interface regroupant tous les produits

proposés par l'établissement de façon structurée facilitant ainsi la prise de commande.

La procédure est la suivante : l'utilisateur sélectionne une catégorie, une liste de produit

appartenant à cette catégorie apparait et il ne reste plus qu'à l'utilisateur de sélectionner le

produit commandé pour l'ajouter à la note.

Cet écran proposera également une liste de produit favoris afin d'avoir un accès direct aux

produits les plus commandés.

Il y aura également des fonctionnalités permettant la suppression d'un produit de la note ou la suppression de la note entière mais aussi l'impression d'une note (fonctionnalité non développée pour le moment).

Lors de la validation de la note la base de données est mise à jour.

4.5.2.2 - Présentation de l'écran

L'écran accueil peut être découpé en trois zones :

Figure 53 - Ecran d'accueil de l'application


La première zone, en rouge, correspond à la zone de commande. C'est ici que sont

affichés les produits qui sont commandés et les boutons qui ont une action sur la

note.

La deuxième partie, en jaune, correspond à la zone des catégories. C'est ici que sont

affichés les catégories disponibles en base de données.

La troisième partie, en vert, correspond à la zone des produits. Cette zone est en fait

divisée en deux parties :

- Une partie qui affichera les produits en fonctions de la catégorie sélectionnée.

- Une partie qui affichera les produits favoris sans avoir à sélectionner de

catégorie.

4.5.2.3 - Prise d'une commande

Je vais vous présenter le fonctionnement de l'écran et de son code en prenant un exemple : la

prise d'une commande par un client. Le client en question commandera un café long et un

jus d'orange.

L'utilisateur dans un premier temps sélectionnera le jus d'orange via la zone des produits

favoris en cliquant sur le bouton correspondant, ajoutant ce dernier à la note.

Figure 54 - Ajout d'un produit favoris à la note

Ensuite l'utilisateur sélectionnera la catégorie des cafés :

Figure 55 - Sélection d'une catégorie


Au niveau du code cette action entrainera le remplissage d'une ArrayList de produits en

fonction de la catégorie sélectionnée. Puis cette liste sera affichée dans la zone des produits

par l'appel de la classe ProductAdapter qui permet de gérer l'affichage des produits sur les

différents écrans de l'application.

Figure 56 - Sélection d'une catégorie et ajout d'un produit

Il restera ensuite à sélectionner le « café long » à ajouter à la note.

Pour cela nous appelons la méthode clicOnProduit() qui récupère le clic sur le

productAdapter pour signifier à l'écran accueil que c'est ce produit que nous avons

sélectionné.

Figure 57 - CallBack vers ProductAdapter


Cette méthode appel à son tour une méthode addProduitToNote().

Figure 58 - Méthode d'ajout d'un produit à la note

Elle récupère l'identifiant du produit que nous voulons ajouter à la note que nous passerons

en paramètre de la méthode. Puis nous effectuons différentes actions qui permettent de :

Vérifier que l'identifiant du produit que nous passons n'est pas nulle ;

Vérifier si le produit que nous souhaitons ajouter à la note est déjà présent dans la

note en cours. Si c'est le cas alors nous incrémentons de 1 la quantité du produit

présent dans la note. Sinon nous ajoutons le produit à la note.

Une fois le produit ajouter à la note nous mettons à jour le solde de la note.


Il ne nous reste plus qu'à valider la commande, pour cela il suffit de sélectionner le bouton

off.client qui va alors appeler la méthode saveCommande().

Figure 59 - sauvegarde de la commande en base de donnée

Cette méthode va parcourir la liste des produits contenu dans la note et modifier la valeur de

la consommation de chacun de ses produits en base de données, afin de pouvoir gérer le

stock des produits.

Puis dans un second temps nous ajoutons en base de données la commande via la méthode

insertConsommeList de la classe ConsommeBddManager.

Une fois l'ajout faite en base de données nous supprimons la note via la méthode

deleteNote();

Dans la méthode saveCommande() nous gérons aussi une sauvegarde automatique

quotidienne de la base de données sur le serveur lors de la première commande du jour.

4.5.3 Ecran Bilan

4.5.3.1 Introduction

L’idée de cet écran est de proposer à l’utilisateur une interface permettant d’afficher la liste

des produits qui ont était commandés sur une période donnée.

Pour cela l’utilisateur a la possibilité de choisir une date précise ou alors un intervalle de

dates, lui permettant ainsi d’avoir des statistiques sur les ventes réalisées pour les périodes

données.


4.5.3.2 Présentation de l’écran

Figure 60 - Ecran bilan

La partie haute de l’écran est composée de quatre boutons et de deux champs sur lesquels

nous pouvons cliquer, ces deux champs cliquables vont permettre l’ouverture d’une boîte de

dialogue, qui contient un calendrier pour permettre à l’utilisateur de sélectionner une date

précise du calendrier.

Figure 61 – Boîte de dialogue permettant de sélectionner une date

Les boutons servent chacun à sélectionner une période de date de la façon suivante :

Bouton « Jour » : Permet de sélectionner la date du jour.

Bouton « Semaine » : Permet de sélectionner la semaine courante.

Bouton « Mois » : Permet de sélectionner le mois courant.

Bouton « Année » : Permet de sélectionner l’année courante.


Sur la deuxième partie de l’écran sera afficher la liste des produits qui correspondent aux

dates sélectionnées, sur chaque ligne nous aurons les informations suivantes :

Le nom du produit.

Le prix unitaire du produit.

Le total de quantité vendu du produit.

Le prix total de l’ensemble des ventes du produit.

4.5.4 Ecran Consommation

4.5.4.1 Introduction

L’idée de cet écran est de proposer à l’utilisateur une interface permettant d’afficher la liste

des produits qui ont été consommés et de proposer une réinitialisation du stock lors d’une

commande.

La procédure est la suivante : l'utilisateur sélectionne un produit qui est à commander, il

indique la quantité qu’il a recommandée et réinitialise le stock du produit correspondant.

4.5.4.2 Présentation de l’écran

Figure 62 - Ecran consommation

Cet écran est composé d’une partie qui gère l’affichage des produits et de boutons qui ont

une action sur l’ensemble des produits qui peuvent être recommandés.


4.5.4.3 Recommande du stock

Pour indiquer à l’application qu’un produit a été recommandé il suffit de sélectionner la

quantité de ce dernier grâce au « number picker »

Figure 63 - Sélection de la quantité recommandée

Le bouton « Mettre à max » permet de mettre au maximum les valeurs de tous les « number

picker ».

Le bouton « Mettre à zéro » permet de réinitialiser à 0 les valeurs de tous les « number

picker ».

Le bouton « Valider » permet quant à lui de modifier la quantité de produit consommé en

fonction de la quantité qui a été recommandé dans la base de données.


Conclusion

Dans le cadre de ce stage de fin d’études nous avions comme projet la réalisation d’une

application Android selon un cahier des charges fourni par notre tuteur.

La réalisation de cette application a nécessité une répartition des tâches au sein du binôme. Il

s’avère que le travail en groupe nous a permis d’atteindre l’essentiel des objectifs fixés par

notre tuteur grâce à une répartition des tâches et une communication efficace.

Nous sommes globalement satisfaits de ce que nous avons réalisé. En effet, à la fin du stage

l’application est fonctionnelle. Pour la mise en production il ne reste plus que l’impression

du ticket à gérer, qui sera faite ultérieurement par notre tuteur. De plus, l’architecture de

l’application permet à notre tuteur de développer par la suite, s’il le souhaite, des

fonctionnalités supplémentaires. Par exemple du « reporting » sur la base de données pour

suivre l’activité de l’entreprise, réaliser des statistiques sur les consommations …

Au final, ce projet nous a permis d’appréhender un travail plus professionnel avec des

délais, un cahier des charges, des retours réguliers sur le travail effectué pouvant entrainer

des modifications du cahier des charges et donc des fonctionnalités de l’application.

Pour ma part, ce stage m’a fait prendre conscience de la complexité que représente la

construction d’une application, de sa conception à la production, et la nécessité de réaliser

une bonne phase de conception pour faciliter ce travail.

Il s’avère que durant ce projet j’ai souvent été confronté à des problèmes techniques liés à la

programmation objet. Malgré ça, j’ai beaucoup appris durant cette période et souhaite

approfondir mes connaissances sur la programmation objet afin de pouvoir travailler dans le

milieu du développement mobile par la suite.


Annexe

1 – Descriptions Textuelles

Cas n°1 Nom : Prendre une commande (package « Prise de commande ») Acteurs : Serveur Description : La prise de commande concerne le serveur, il doit pouvoir enregistrer les produits demandés par les consommateurs. Auteur : Axel & Allan Date : 15/11/2016 Préconditions : aucune. Démarrage : l’utilisateur a lancé l’application. Scénario nominal 1 : Le système affiche la page d’accueil. 2 : Le système fait appel au cas d’utilisation interne « sélectionner une catégorie ». 3 : Le système fait appel au cas d’utilisation interne « sélectionner un produit ». 4 : Le système fait appel au cas d’utilisation interne « imprimer une note ». 5 : Le système fait appel au cas d’utilisation interne « finaliser une commande ». Scénario alternatif : 3a. Le serveur annule un produit commandé. 3b. Le serveur annule toute la commande. 3c. Le serveur sélectionne un produit favori. Scénario d’exception 4.a L’impression du ticket n’a pas réussi. Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation). Fin :


Scénario alternatif : 3b sur décision du consommateur.

Post-conditions : Scénario nominal : la commande est envoyée en base de donnée et un ticket est imprimé. Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up.


Cas n°2 Nom : Sélectionner une catégorie (package « Prise de commande ») Acteur(s) : Serveur Description : Le serveur doit pouvoir sélectionner la catégorie du produit commandé par le client. Auteur : Allan & Axel Date(s) : 15/11/2016 Préconditions : aucune Démarrage : Le serveur prépare une commande. Le scénario nominal 1. Le système affiche une page contenant la liste des catégories de produits. 2. Le serveur sélectionne une des catégories. 3. Le système recherche les produits qui appartiennent à cette catégorie. 4. Le système affiche les produits trouvés. Fin Scénario nominal : sur décision du serveur après l’étape 4. Cas n°3 Nom : Sélectionner un produit (package « Prise de commande ») Acteurs : Serveur Description : La sélection du produit concerne le serveur, il doit pouvoir enregistrer les produits demandés par les consommateurs. Auteur : Axel & Allan Date : 15/11/2016 Préconditions : Une catégorie doit-être sélectionné. Démarrage : l’utilisateur a sélectionné une catégorie. Scénario nominal 1 : Le système affiche les produits de la catégorie sélectionné. 2 : Le serveur peut sélectionner un produit parmi ceux affichés. 3 : Le système affiche le produit sélectionné. 4. Le serveur peut sélectionner d’autres produit parmi ceux affichés. Scénario alternatif : 2a. Le serveur annule un produit commandé. 2b. Le serveur annule toute la commande. 2c. Le serveur sélectionne un produit favori. Scénario d’exception Aucun. Fin :


Scénario d’exception : 2b sur décision du consommateur.

Post-conditions : Scénario nominal : aucun. Ergonomie : aucun


Cas n°4 Nom : Sélectionner un favoris (package « Prise de commande ») Acteur(s) : Serveur Description : Le serveur doit pouvoir sélectionner un produit qui est disponible dans les favoris. Auteur : Allan & Axel Date(s) : 15/11/2016 Préconditions : aucune Démarrage : Le serveur prépare une commande. Le scénario nominal 1. Le système affiche une page contenant la liste des favoris. 2. Le serveur sélectionne un produit dans les favoris. 3. Le système affiche le produit sélectionner. Fin Scénario nominal : sur décision du serveur après l’étape 3

Cas n°5 Nom : Imprimer une note (package « Prise de commande ») Acteurs : Serveur / imprimante Bluetooth Description : Imprimer une note concerne le serveur, il doit pouvoir imprimer un ticket de caisse lors de la validation de la commande. Auteur : Axel & Allan Date : 15/11/2016 Préconditions : un produit doit être sélectionné Démarrage : le serveur a sélectionné un produit. Scénario nominal 1. Le système affiche le/les produit(s) sélectionné(s) 2. Le serveur sélectionne l’impression. 3.Le système envoi une demande d’impression. 4. L’imprimante donne l’autorisation. 5. Le système envoi les informations à l’imprimante Bluetooth. 6. L’imprimante réceptionne les informations du système. 7. L’imprimante lance l’impression du ticket de caisse. 8. Le système affiche que l’impression s’est bien déroulé. Scénario alternatif : Aucun Scénario d’exception 3a. L’impression du ticket n’a pas réussi Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation). Fin :


Scénario d’exception : 3a l’impression du ticket a échoué un message s’affiche sur le système.

Post-conditions : Scénario nominal : aucun. Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up.


Cas n°6 Nom : Finaliser une commande (package « Prise de commande ») Acteur(s) : Serveur Description : Le serveur doit pouvoir terminer une commande une fois que le ticket de caisse est imprimé. Auteur : Allan & Axel Date(s) : 15/11/2016 Préconditions : « Imprimer une note » Démarrage : Le serveur a imprimé un ticket. Le scénario nominal 1. Le système affiche que le ticket a bien était imprimé. 2. Le serveur décide de terminer la commande. 3. Le système envoie les informations de la commande à la base de données. 4. Le système affiche que l’envoie c’est bien déroulé. Scénario d’exception 3a. L’envoie en base de donnes a échoué. Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation) Fin Scénario nominal : sur décision du serveur après l’étape 4. Scénario d’exception 3a : L’envoie en base de données a échoué, un message s’affiche sur le système. Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up. Cas n°7 Nom : Gestion de stock (package « Gestion administrative ») Acteurs : administrateur, serveur Description : La gestion de stock concerne essentiellement l’administrateur mais peut être consulter par le serveur. Auteur : Axel & Allan Date : 16/11/2016 Préconditions : l’administrateur doit être authentifier pour la mise à jour du stock Démarrage : l’administrateur / serveur a sélectionné la page « Stock » Scénario nominal 1.Le système affiche la page de stock. 2. Le système fait appel au cas d’utilisation interne « consulter le stock ». 3. Le système fait appel au cas d’utilisation interne « mettre à jour le stock ». Scénario alternatif : Aucun Scénario d’exception 3.a Le serveur essaye de mettre à jour le stock. Le système affiche un message indiquant qu’il n’a pas les droits nécessaires. Fin :



Post-conditions : Scénario nominal : Le stock recommandé est envoyé en base de données Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up. Cas n°8 Nom : Mettre à jour le stock. (Package « Gestion administrative ») Acteurs : l’administrateur Description : Mettre à jour le stock concerne uniquement l’administrateur, il permet d’envoyer en base de données la quantité des produits recommandés. Auteur : Axel & Allan Date : 16/11/2016 Préconditions : l’administrateur doit être authentifier. Démarrage : l’administrateur incrémente une quantité recommandée sur la page « stock » Scénario nominal 1a. L’administrateur rempli la quantité recommandée à l’aide de bouton +1 / -1 pour chaque produit recommandé. 1b. L’administrateur rempli la quantité recommandée à l’aide de bouton min/max pour chaque produit recommandé. 1c. L’administrateur indique que tous les produits sont recommandés à l’aide du bouton « mettre à max » 2. Le système modifie les valeurs affichées. 3. L’administrateur valide les modifications en appuyant sur le bouton valider. 4. Le système envoi les informations dans la base de données. 5. Le système modifie l’affichage des valeurs de la page stock. Scénario alternatif : Aucun Scénario d’exception 4a. l’envoi des données a échoués. Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation). Fin :

Scénario nominal : à l’étape 5 sur décision de l’administrateur.

Post-conditions : Scénario nominal : aucun. Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up. Cas n°9 Nom : Consulter le stock. (Package « Gestion administrative ») Acteurs : l’administrateur/ serveur Description : Consulter le stock concerne l’administrateur et le serveur, il permet de visualiser la quantité de stock consommé et le stock a recommandés. Auteur : Axel & Allan Date : 16/11/2016 Préconditions : aucune. Démarrage : l’administrateur/serveur a sélectionné la page stock


Scénario nominal 1. Le système affiche la quantité de stock consommé. 2. l’utilisateur visualise les informations Scénario alternatif : Aucun Scénario d’exception Fin :

Scénario nominal : à l’étape 2 sur décision de l’utilisateur.

Post-conditions : Scénario nominal : aucun. Ergonomie : aucun Cas n°10 Nom : S’authentifier (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et des produits. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : Démarrage : L’utilisateur a décidé de s’authentifier. Le scénario nominal 1. Le système affiche une page d’authentification. 2. L’administrateur rentre son identifiant et son mot de passe. 3. Le système vérifie les données entrées par l’administrateur en les comparant aux données présente dans la base de données. 4. Le système affiche que la connexion a réussie. 5. L’administrateur peut accéder à la partie administrative. Scénario d’exception 4a. Le système affiche que la connexion à échoué, retour à l’étape 2. Fin Scénario nominal : sur décision de l’administrateur après l’étape 5. Scenario d’exception : sur décision de de l’administrateur après l’étape 2.


Cas n°11 Nom : Gestion des catégories (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et des produits. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion de catégories. Le scénario nominal 1. Le système affiche une page avec toutes les catégories. 2. Le système fait appel au cas d’utilisation interne « ajouter une catégorie » 3. Le système fait appel au cas d’utilisation interne « modifier une catégorie » 4. Le système fait appel au cas d’utilisation interne « supprimer une catégorie » Fin Scénario nominal : sur décision de l’administrateur après l’étape 4. Cas n°12 Nom : Ajouter une catégorie (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et ajouter une nouvelle catégorie. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion de catégories. Le scénario nominal 1. Le système affiche une page avec toutes les catégories. 2. L’administrateur peut ajouter une catégorie. 3. Le système affiche un formulaire de saisie pour créer une nouvelle catégorie. 4. L’utilisateur peut valider les données saisies. 5. Le système envoie les données à la base de données. 6. Le système affiche que l’ajout a bien était pris en compte. Scénario d’exception 6a. Le système affiche l’échec de l’ajout a la base de données, retour à l’étape 3. Fin Scénario nominal : sur décision de l’administrateur après l’étape 6. Scenario d’exception : sur décision de de l’administrateur après l’étape 3.


Cas n°13 Nom : Modifier une catégorie (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et modifier une catégorie. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion de catégories. Le scénario nominal 1. Le système affiche une page avec toutes les catégories. 2. L’administrateur peut modifier une catégorie. 3. Le système affiche un formulaire de saisie pour modifier la catégorie. 4. L’utilisateur peut valider les données saisies. 5. Le système envoie les données à la base de données. 6. Le système affiche que la modification a bien était prise en compte. Scénario d’exception 6a. Le système affiche l’échec de la modification de la base de données, retour à l’étape 3. Fin Scénario nominal : sur décision de l’administrateur après l’étape 6. Scenario d’exception : sur décision de de l’administrateur après l’étape 3. Cas n°14 Nom : Supprimer une catégorie (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et supprimer une catégorie. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion de catégories. Le scénario nominal 1. Le système affiche une page avec toutes les catégories. 2. L’administrateur peut supprimer une catégorie. 3. Le système envoie les données à la base de données. 4. Le système affiche que la suppression a bien était prise en compte. Scénario d’exception 4a. Le système affiche l’échec de la suppression de la catégorie dans la base de données, retour à l’étape 2. Fin Scénario nominal : sur décision de l’administrateur après l’étape 4. Scenario d’exception : sur décision de de l’administrateur après l’étape 2.


Cas n°15 Nom : Gestion des produits (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et des produits. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion des produits. Le scénario nominal 1. Le système affiche une page avec tous les produits. 2. Le système fait appel au cas d’utilisation interne « ajouter un produit » 3. Le système fait appel au cas d’utilisation interne « modifier un produit » 4. Le système fait appel au cas d’utilisation interne « supprimer un produit » Fin Scénario nominal : sur décision de l’administrateur après l’étape 4. Cas n°16 Nom : Ajouter un produit (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et ajouter un nouveau produit. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion des produits. Le scénario nominal 1. Le système affiche une page avec tous les produits. 2. L’administrateur peut ajouter un produit. 3. Le système affiche un formulaire de saisie pour créer un nouveau produit. 4. L’utilisateur peut valider les données saisies. 5. Le système envoie les données à la base de données. 6. Le système affiche que l’ajout a bien était pris en compte. Scénario d’exception 6a. Le système affiche l’échec de l’ajout a la base de données, retour à l’étape 3. Fin Scénario nominal : sur décision de l’administrateur après l’étape 6. Scenario d’exception : sur décision de de l’administrateur après l’étape 3.


Cas n°17 Nom : Modifier un produit (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et modifier un produit. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion des produits. Le scénario nominal 1. Le système affiche une page avec tous les produit. 2. L’administrateur peut modifier un produit. 3. Le système affiche un formulaire de saisie pour modifier le produit. 4. L’utilisateur peut valider les données saisies. 5. Le système envoie les données à la base de données. 6. Le système affiche que la modification a bien était prise en compte. Scénario d’exception 6a. Le système affiche l’échec de la modification de la base de données, retour à l’étape 3. Fin Scénario nominal : sur décision de l’administrateur après l’étape 6. Scenario d’exception : sur décision de de l’administrateur après l’étape 3. Cas n°18 Nom : Supprimer un produit (package « Gestion administrative ») Acteur(s) : Administrateur Description : L’administrateur peut se connecter pour pouvoir accéder à la partie de gestion des données des catégories et supprimer un produit. Auteur : Allan & Axel Date(s) : 16/11/2016 Préconditions : L’utilisateur doit être connecté Démarrage : L’utilisateur accède à la page gestion des produits. Le scénario nominal 1. Le système affiche une page avec tous les produits. 2. L’administrateur peut supprimer un produit. 3. Le système envoie les données à la base de données. 4. Le système affiche que la suppression a bien était prise en compte. Scénario d’exception 4a. Le système affiche l’échec de la suppression du produit dans la base de données, retour à l’étape 2. Fin Scénario nominal : sur décision de l’administrateur après l’étape 4. Scenario d’exception : sur décision de de l’administrateur après l’étape 2.


Cas n°19 Nom : Consulter le bilan (Package « Gestion administrative ») Acteurs : l’administrateur/ serveur Description : Consulter le bilan permet d’avoir un affichage de l’ensemble des produits vendu selon le jour, le mois ou l’année. Auteur : Axel & Allan Date : 16/11/2016 Préconditions : aucune. Démarrage : l’administrateur/serveur a sélectionné la page bilan Scénario nominal 1a. Le système affiche le bilan des produits vendu dans la journée. 1b. l’utilisateur visualise les informations selon le jour. 1c. l’utilisateur visualise les informations selon la semaine. 1d. l’utilisateur visualise les informations selon le mois. 1e. l’utilisateur visualise les informations selon l’année. Scénario alternatif : Aucun Scénario d’exception Fin : • Scénario nominal : à l’étape 1 sur décision de l’utilisateur. Post-conditions : Scénario nominal : aucun. Ergonomie : aucun


Cas n°20 Nom : imprimer le bilan. (Package « Gestion administrative ») Acteurs : l’administrateur/ serveur Description : imprimer le bilan concerne l’administrateur et le serveur, il permet d’imprimer la quantité de produits consommé sur une période donnée. Auteur : Axel & Allan Date : 16/11/2016 Préconditions : aucune. Démarrage : l’administrateur/serveur a sélectionné la page bilan Scénario nominal 1. Le système affiche la quantité de produit consommé de la journée 2b. L’utilisateur sélectionne la quantité de produit consommé sur une semaine. 2c. L’utilisateur sélectionne la quantité de produit consommé sur un mois. 2d. L’utilisateur sélectionne la quantité de produit consommé sur une année. 3. Le système affiche les valeurs sur la page bilan 4. L’utilisateur sélectionne l’impression du bilan. 5. Le système envoie les informations à l’imprimante en Bluetooth. 6. L’imprimante réceptionne les informations. 7. L’imprimante imprime le ticket. Scénario alternatif : Aucun Scénario d’exception 5a. L’impression n’a pas fonctionné. Le système affiche un message sur l’écran. (Arrêt du cas d’utilisation) Fin :

Scénario nominal : à l’étape 7 sur décision de l’utilisateur.

Scénario d’exception : à l’étape 5a.

Post-conditions : Scénario nominal : aucun

Ergonomie : Les éventuels messages aux utilisateurs doivent être fournis à l’aide de fenêtre pop-up.


2 - Wireframes

Figure 64 - Menu de navigation

Figure 65 - Ecran bilan

Figure 66 - Boite de dialogue, ajout de produit


Figure 67 - Ecran réglages

Figure 68 - Ecran stock

Presentations & Public Speaking

Rapport de fin d'études axel legué