Android pour la cuisine tunisienne - Part II : Analyse et spécification des besoins
Majeed Hm.
La mise en place d’un logiciel, passe essentiellement par une étude de l’existant, qui offre la connaissance précise et rigoureuse du contexte sur lequel nous opérons et guide ainsi à une décision pour démarrer ou simplement marqueter un tel projet. C’est le sujet de ce chapitre qui présentera les principaux aspects techniques et normatifs sur lesquels reposera notre travail.
Le but du projet est de concevoir et réaliser une application Android permettant « d’explorer » des menus et des plats traditionnels d’une région spécifique en Tunisie et de gérer tout un programme d’une sortie qui peut être partagé par plusieurs utilisateurs possédant des smartphones équiper d’un système Android.
Nous allons d’abord définir les concepts différents qui vont être utilisés dans ce document.
III. La spécialité du restaurant
Pour l’instant, on se limitera à la spécialité tunisienne mais comme perspectives pour des améliorations futures, on pourra ajouter d’autres spécialités.
IV. Cuisine dite traditionnelle [Source : Wikipedia]
Figure 1 : Une daube dite traditionnelle
La cuisine traditionnelle est la préparation de mets en adéquation avec la production agricole, donc de la tradition culinaire, d'une vallée, d'une contrée, d'un pays.
Elle consiste, en un lieu, à mettre en préparation des produits alimentaires du terroir et de saison correspondant à ce dit lieu dans des recettes dites classiques plus ou moins complexes (ex : la potée auvergnate, la ratatouille en été, le charcuterie en hiver...). Cette cuisine est pratiquée dans les ménages, dans les lieux commerciaux de restauration se voulant traditionnels, mais aussi par certaines chaînes de restauration.
V. Le restaurant [Source : Wikipedia]
Un restaurant est un établissement où l'on sert des plats préparés et des boissons à consommer sur place, en échange d'un paiement. Généralement, la nourriture y est préparée par un chef cuisinier. Le terme couvre une multiplicité de lieux et une grande diversité des types de cuisines, tant locales qu'étrangères.
Actuellement, pour organiser une petite sortie entre amis, on commence, généralement, par rechercher un ou plusieurs endroits à visiter et pour finir, rien qu’un apetissant menu dans un restaurant.
Si une étape du plan de la sortie déplaise à un des membres du groupe, ce dernier va réclamer son mécontentement pour passer vite à l’étape suivante.
Après cette analyse, nous remarquons que l’organisateur rencontre plusieurs contraintes lors de la planification de la sortie :
· La région, où se trouve le restaurant, n’est pas assez accessible à l’un des membres du groupe.
· Le restaurant choisi ne plaît pas à l’un des membres.
· Les menus proposés par le restaurant sont nouveaux ou leurs ingrédients sont méconnu ce qui empêche d’éviter les mauvaises surprises.
· Le budget proposé ne convient pas à l’un des membres.
Ainsi, pour réduire ces insuffisances, nous proposons de développer une application devant répondre aux exigences suivantes :
· Etre partagée via internet et accessible de n’importe quel mobile équipé d’un OS Android
· Gérer les profiles des utilisateurs
· Offrir un moyen meilleur pour la gestion des sorties
· Etre ouverte et flexible à toute modification ou amélioration.
Par conséquent, pour satisfaire ces exigences, l’application sera une application Android connecté à une base de données hébergée dans un serveur accessible sur la toile. Voici le diagramme de déploiement de cette solution.
Figure 2 : Diagramme de déploiement pour la solution proposée
(Vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne. A noter : ceci n'est pas une version fini et certains points peuvent être ajouter ou modifier à condition d'en discuter. L'étape suivante sera la création du diagramme des cas d'utilisation)
Majeed Hm.
Demain, je commencerai la création des "Tasks" pour le projet comme ça on pourra se partager les taches et chacun aura un "use case" à concevoir ;)
Majeed Hm.
- Recherche : Google App Engine + Web Services
- Recherche : Google App Engine + Magasin de données
- Recherche : Google App Engine + Google Cloud SQL
En ce qui me concerne, je suis pour la conception donc il reste 4.
Vous pouvez vous auto-affecter une tache de cette liste : http://code.google.com/p/tunis-gtug-android/issues/list
Amusez vous bien et je serai dispo pour plus de détaille ;)
Dhuieb Mohamed Anis
Mohamed Anis Dhuieb
Élève-Ingénieur troisiéme année Génie Informatique
École Nationale d'Ingénieurs de Sfax
GSM: +216 40.758.285
Contact me:
dhbmedanis
Taher Mestiri
mohamed kalboussi
Ahmed Ben Abid
Je propose qu'au lieu qu'un utilisateur doit s'identifier, on lui offre un accès aux restaurants et plats dans le cas où l'utilisateur veux y aller seul ou en famille.
je vous encourage majeed ce qui est clairement visible que vous faites un efforts généreux au début le mailing liste etait pleine de participation mais maintenant lorsque le projet avance t' a poster 3 mails et personne ne semble intéressé le prob que je suis intéressé j'ai des connaissance java mais ca m 'énerve le plateforme de développement sdk et eclipse pfff stp est ce qu'il existe un autre environnement majeed
Majeed Hm.
Majeed Hm.
Majeed Hm.
La modélisation UML
UML définit des diagrammes structurels et comportementaux pour représenter respectivement les vues statiques et dynamiques d’un système. Nous allons utiliser certains de ces diagrammes pour modéliser des fonctionnalités métiers de notre application.
L’outil, que je conseille à utiliser pour la génération des différents diagrammes UML, est le plugin « Eclipse » de « UMLet Version 11.3 ». UMLet est un outil UML open-source avec une interface utilisateur simple: dessine des diagrammes UML rapide, exporte les diagrammes vers des formats tel que EPS, PDF, JPG, SVG, et presse-papiers, partage des diagrammes via Eclipse et crée de nouveaux éléments UML personnalisés. Pour l’installer, il suffit de télécharger le jar « com.umlet.plugin_11.3.0.jar » et de le copier dans le répertoire « plugins » de « Eclipse ». Il existe une version « stand-alone » aussi.
Dans ce qui suit, nous présenterons les besoins fonctionnels et technique de l’application à implémenter.
Capture des besoins fonctionnels
Plusieurs recherches ont été effectuées pour identifier au mieux les besoins de l’application, et ceci afin de répondre aux attentes des utilisateurs. Ainsi, nous établissons le cahier des charges préliminaire suivant.
L’interface doit fournir principalement :
La gestion des utilisateurs (ajouter, modifier ou supprimer un compte utilisateur).
Affectation des plats aux sorties.
Gestion des sorties (ajouter, modifier ou supprimer une sortie).
Gestion des menus et des plats traditionnels (ajouter, modifier ou supprimer un plat d’une sortie).
Offrir un système de consultation des ingrédients généraux d’un plat.
Offrir un système de localisation (pour l’instant « google.map ») qui pourra renseigner sur l’adresse du restaurant.
L’invité peut :
Ajouter un compte utilisateur (utilisateur simple – la partie administration fera l’objet de perspective pour des améliorations futures).
Consulter les restaurants par région, les menus par restaurants, les plats par menu, les ingrédients par plat.
L’utilisateur dès son ajout au système, peut :
Consulter et modifier ses informations personnelles.
Ajouter, modifier ou supprimer une sortie.
L’organisation de cette section sera illustrée par la Figure 3 comme suit :
Figure 3 : Démarche suivie lors de la capture des besoins fonctionnels
Identification des acteurs
Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système, mais d’abord nous donnons une définition de ce que c’est un acteur. Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié. [Source : Pitman, N. (2006). UML2 en concentré]
(Voilà un petit coup de pousse pour Anis ;) et bien sur vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne.
A noter : ceci n'est pas une version fini et certains points peuvent
être ajouter ou modifier à condition d'en discuter. L'étape suivante
sera la création du diagramme des cas d'utilisation)
Dhuieb Mohamed Anis
Mohamed Anis Dhuieb
Élève-Ingénieur troisiéme année Génie Informatique
École Nationale d'Ingénieurs de Sfax
Membre Tunis GTUG
GSM: +216 40.758.285
Majeed Hm.
Majeed Hm.
Majeed Hm.
Les acteurs du système identifiés dans un premier temps sont :
Utilisateur invité : Un invité peut explorer l’application : consulter les restaurants par région, les menus par restaurants, les plats par menu et les ingrédients par plat. Il peut aussi consulter la liste des sorties organisées ainsi que les utilisateurs enregistrés.
Utilisateur simple : Un utilisateur simple peut gérer son profil (ses informations personnelles), ses propres sorties organisées ou tout simplement explorer l’application.
b. Identification des messages
Nous allons détailler les différents messages échangés entre le système et l’extérieur. Un message représente la spécification d’une communication unidirectionnelle entre les objets qui transportent de l’information avec l’intention de déclencher une activité chez le récepteur.
Le système émet les messages suivants :
Les sorties organisées par les utilisateurs.
Liste des utilisateurs du système.
Liste des régions disponibles en Tunisie.
Liste des restaurants.
Liste des menus.
Liste des plats disponibles.
Liste des ingrédients d’un plat.
Le système reçoit les messages suivants :
Ajout, modification et suppression d’un profil utilisateur.
Ajout, modification et suppression des sorties.
Affectation et retrait des plats à une sortie.
Affectation et retrait des utilisateurs à une sortie.
Modification du rang du plat dans une sortie.
Modification du mot de passe de l’utilisateur.
c. Modélisation du contexte
A partir des informations obtenues lors des deux précédentes étapes, nous allons modéliser le contexte de l’application. Ceci va permettre dans un premier temps, de définir le rôle de chaque acteur dans le système (Voir tableau 1 : Rôles de chaque acteur).
Utilisateurs finaux | Description des besoins fonctionnels |
Utilisateur invité | Consulter les restaurants par région, les menus par restaurants, les plats par menu et les ingrédients par plat Consulter la liste des sorties organisées Consulter la liste des utilisateurs enregistrés |
Utilisateur simple | S’authentifier Consulter et mettre à jours ses informations personnelles Gérer ses sorties Affecter ou retirer un plat à une sortie Affecter ou retirer un utilisateur à une sortie Modifier le rang d’un plat dans une sortie Modifier son mot de passe |
Tableau 1 : Rôles de chaque acteur
d. Identification des cas d’utilisation
Un cas d’utilisation représente un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier. Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné.
L’identification des cas d’utilisation une première fois, donne un aperçu des fonctionnalités futures que doit implémenter le système. Cependant, il faut plusieurs itérations pour ainsi arriver à constituer des cas d’utilisation complets.
(Peut être je fais vite les choses mais je ne peux plus attendre pour commencer le codage :p pourtant je m'amuse bien ;) vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne. A noter : ceci n'est pas une version fini et certains points peuvent être ajouter ou modifier à condition d'en discuter. L'étape suivante sera la création du diagramme des cas d'utilisation)
Beat of the moment : Outkast - Ms. Jackson (Spaceman Remix)
Majeed Hm.
Majeed Hm.
Cas d’utilisation | Acteur principal, acteurs secondaires | Messages émis/reçu par les acteurs |
Consulter la liste des sorties |
Utilisateur invité | Reçoit : Liste des sorties organisées |
Consulter la liste des utilisateurs |
Utilisateur invité | Reçoit : Liste des utilisateurs enregistrés | |
Consulter la liste des régions | Utilisateur invité | Reçoit : Liste des régions disponibles en Tunisie |
Consulter la liste des restaurants | Utilisateur invité | Reçoit : Liste des restaurants |
Consulter la liste des menus | Utilisateur invité | Reçoit : Liste des menus |
Consulter la liste des plats | Utilisateur invité | Reçoit : Liste des plats disponibles |
Consulter la liste des ingrédients | Utilisateur invité | Reçoit : Liste des ingrédients d’un plat |
Mettre à jour ses informations personnelles | Utilisateur simple | Émet : Modification de ses informations personnelles |
Affecter / retirer un plat à une sortie | Utilisateur simple | Émet : Modification d’une sortie Reçoit : Liste des plats de la sortie |
Affecter / retirer un utilisateur à une sortie | Utilisateur simple | Émet : Modification d’une sortie Reçoit : Liste des utilisateurs invités à la sortie |
Modifier le rang d’un plat dans une sortie |
Utilisateur simple | Émet : Modification d’une sortie Reçoit : Liste des plats de la sortie |
Modifier son mot de passe |
Utilisateur simple | Émet : Modification du mot de passe de l’utilisateur | |
Gérer les sorties | Utilisateur simple | Émet : Ajout, modification et suppression des sorties Reçoit : Liste des sorties organisées |
e. Diagrammes des cas d’utilisation
Nous illustrons dans les figures qui vont suivre les diagrammes des cas d’utilisation des différents acteurs du système préalablement identifiés.
Cas d’utilisation pour un utilisateur invité
Figure 4 : Diagramme de cas d’utilisation pour un utilisateur invité
Cas d’utilisation pour un utilisateur simple
Figure 5 : Diagramme de cas d’utilisation pour un utilisateur simple
(vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne. A noter : ceci n'est pas une version fini et certains points peuvent être ajouter ou modifier à condition d'en discuter. L'étape suivante sera la création du diagramme des cas d'utilisation)My beat of the moment : Kelis - Emancipate
Majeed Hm.
f. Description des cas d’utilisation
Nous allons maintenant détailler chaque cas d’utilisation qui doit faire l’objet d’une définition a priori qui décrit l’intention de l’acteur lorsqu’il utilise le système et les séquences d’actions principales qu’il est susceptible d’effectuer. Ces définitions servent à fixer les idées et n’ont pas pour but de spécifier un fonctionnement complet et irréversible.
Remarque : les descriptions vont être organisées de la façon suivante :
- Un sommaire d’identification : va résumer les propriétés du cas d’utilisation.
- Une description détaillée : des conditions au déclenchement du cas d’utilisation doivent être spécifiées, un scénario nominal décrivant celui-ci additionné à des scénarios alternatifs et d’exceptions.
- Les diagrammes (optionnels) : plusieurs diagrammes vont apparaître (mais pas nécessairement) pour apporter une compréhension additive au cas d’utilisation.
Taher Mestiri
Majeed Hm.
Taher Mestiri
Oui pourquoi pas. On pourra sauvegarder le login/mon de passe, les préférences personnelles, le dernier ecrant visité...
Majeed Hm.
selmi amel
Majeed Hm.
J'ai bien pris note ;) et on pourra s'inspirer de ces applications déjà existantes :)
Majeed Hm.
i. Mettre à jours ses informations personnelles
- Sommaire d’identification :
Titre : Mettre à jours ses informations personnelles But : Modifier des informations concernant un utilisateur Résumé : s’authentifier, consulter ses informations et entrer de nouvelles valeurs Acteur : Utilisateur simple |
- Descriptions des enchaînements :
Conditions 1. L’utilisateur est authentifié |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de modifier ses informations personnelles. Enchaînement (a) : Modifier un ou plusieurs champs Choisir les champs et leurs affecter de nouvelles valeurs. Enchaînement (b) : Valider la mise à jour Valider les informations. |
Exceptions |
[Exception1 : ChampVide] : un message d’erreur s’affiche devant le champ vide avisant l’utilisateur qu’il doit enter ses informations personnelles. [Exception2 : DupplicationInformation] : un message d’erreur s’affiche devant le champ ayant une information déjà affecter à un autre utilisateur comme le matricule, l’adresse email et le login. [Exception3 : ChampInvalide] : un message d’erreur s’affiche devant le champ ayant une valeur invalide comme un matricule avec des caractères alphabétiques, une adresse email ne respectant pas le format « n...@nom.dom », un login composé de moins de six caractères ou un mot de passe retapez deux fois différemment. |
Ce cas d’utilisation se termine lorsque l’utilisateur a validé son formulaire d’informations personnelles. |
- Diagramme d’activités :
Figure 6 : Diagramme d’activités pour « modifier ses informations personnelles »
ii. Consulter la liste des utilisateurs
- Sommaire d’identification :
Titre : Consulter la liste des utilisateurs But : Voir tous les utilisateurs du système Résumé : afficher la liste des utilisateurs Acteur : Utilisateur invité |
- Descriptions des enchaînements :
Conditions Aucune |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande de consulter la liste des utilisateurs du système. Enchaînement (a) : Consulter la liste des utilisateurs Affichage de la liste de tous les utilisateurs du système. |
Ce cas d’utilisation se termine lorsque l’utilisateur quitte l’écran. |
iii. Consulter la liste des sorties
- Sommaire d’identification :
Titre : Consulter la liste des sorties But : Voir tous les sorties aux quelles un utilisateur fait partie Résumé : afficher la liste des sorties disponibles Acteur : Utilisateur invité |
- Descriptions des enchaînements :
Conditions Aucune |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande de consulter la liste des sorties aux quelles il fait partie un utilisateur donné. Enchaînement (a) : Consulter la liste des sorties disponibles Affichage de la liste des sorties disponibles. |
Ce cas d’utilisation se termine lorsque l’utilisateur se déconnecte. |
iv. Modifier son mot de passe
- Sommaire d’identification :
Titre : Modifier son mot de passe But : Avoir un nouveau mot de passe Résumé : s’authentifier, taper l’ancien mot de passe puis le nouveau de passe et confirmer en retapant encore une fois le nouveau mot de passe Acteur : Utilisateur simple |
- Descriptions des enchaînements :
Conditions 1. L’utilisateur est authentifié |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande d’avoir un nouveau mot de passe. Enchaînement (a) : Demander un nouveau mot de passe L’utilisateur tape l’ancien mot de passe une fois puis deux fois le nouveau mot de passe pour confirmation. |
Ce cas d’utilisation se termine lorsque l’utilisateur se déconnecte. |
v. Affecter un utilisateur
- Sommaire d’identification :
Titre : Affecter un utilisateur But : Inviter un utilisateur à une sortie Résumé : s’authentifier, choisir une sortie, choisir un utilisateur puis inviter ce dernier à cette sortie Acteur : Utilisateur simple |
- Descriptions des enchaînements :
Conditions 1. L’utilisateur est authentifié 2. Au moins une sortie est organisée par l’utilisateur connecté 3. Au moins un autre utilisateur est disponible |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système d’inviter un autre utilisateur à sa sortie. Enchaînement (a) : Sélectionner une sortie L’utilisateur choisit une de ses sorties. Enchaînement (b) : Sélectionner un utilisateur Il choisi un des utilisateurs disponibles. Enchaînement (c) : Inviter l’utilisateur à sa sortie L’utilisateur doit valider l’action. |
Ce cas d’utilisation se termine lorsque l’utilisateur se déconnecte. |
vi. Modifier le rang d’un plat dans une sortie
- Sommaire d’identification :
Titre : Modifier le rang d’un plat dans une sortie But : Réorganiser l’ordre des plats dans la sortie Résumé : s’authentifier, choisir une sortie, choisir un plat et faire monter ou abaisser le rang du plat dans la liste de la sortie Acteur : Utilisateur simple |
- Descriptions des enchaînements :
Conditions 1. L’utilisateur est authentifié 2. Au moins une sortie est organisée par l’utilisateur 3. Au moins deux plats sont disponibles dans la liste |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de réorganiser la liste des plats dans une sortie pour avoir un plat avant un autre. Enchaînement (a) : Sélectionner une sortie L’utilisateur choisit une de ses sorties. Enchaînement (b) : Sélectionner un plat Il choisi un des plats disponibles. Enchaînement (c) : Faire monter ou abaisser le rang du plat dans la liste L’utilisateur doit valider l’action. |
Exceptions |
[Exception1 : ValeurInvalide] : un message d’erreur s’affiche lorsque le rang est inférieur ou supérieur aux bornes de la liste. |
Ce cas d’utilisation se termine lorsque l’utilisateur a validé le nouveau rang du plat. |
vii. Gérer les sorties
- Sommaire d’identification :
Titre : Gérer les sorties But : Ajouter, modifier et supprimer des sorties Résumé : s’authentifier, ajouter une sortie et lui affecter des plats Acteur : Utilisateur simple |
- Descriptions des enchaînements :
Conditions 1. L’utilisateur est authentifié |
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur lance l’application et demande d’ajouter, modifier ou supprimer une sortie. Enchaînement (a) : Ajouter une sortie L’utilisateur entre la date et l’heure. Il choisi les régions, les restaurants et les plats à ajouter. Il choisi les utilisateurs à inviter. Enchaînement (b) : Valider la sortie L’utilisateur doit avoir remplit toutes les informations obligatoires. Enchaînements alternatifs : Enchaînement (c) : Modifier une sortie L’utilisateur met à jours cette sortie quand cela est nécessaire. Enchaînement (d) : Supprimer une sortie L’utilisateur peut supprimer une sortie à tout moment. Si des utilisateurs y sont invités, ils seront alertés automatiquement avant de procéder à la suppression. |
Exceptions |
[Exception1 : DupplicationInformation] : un message d’erreur s’affiche devant le champ ayant une information déjà affecter. [Exception2 : ChampInvalide] : un message d’erreur s’affiche devant le champ ayant une valeur invalide comme une date ultérieure à la date de saisie, une adresse email ne respectant pas le format « n...@nom.dom » ou un login composé de moins de six caractères. |
Ce cas d’utilisation se termine lorsque l’utilisateur a validé la sortie. |
g. Organisation des cas d’utilisation
Cette phase va permettre de structurer les cas d’utilisations en groupes fortement cohérents. En ce qui nous concerne, nous allons choisi de décomposer l’application en divers « packages » dont chacun présente un aspect comportemental du système. Chaque « package » est décomposé soit en cas d’utilisation, soit en sous « packages » qui collaborent tous ensemble pour présenter le service initial rendu par l’application.
Définition : un package représente un espace de nommage qui peut contenir :
o Des éléments d’un modèle
o Des diagrammes qui représentent les éléments du modèle
o D’autres packages
La structuration des cas d’utilisations se fait par domaine d’expertise métier c'est-à-dire les éléments contenus dans un package doivent représenter un ensemble fortement cohérent et sont généralement de même nature et de même niveau sémantique.
(vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne.
A noter : ceci n'est pas une version fini et certains points peuvent
être ajouter ou modifier à condition d'en discuter. L'étape suivante
sera la création du diagramme des cas d'utilisation)
My beat of the moment : Tiziano Ferro - La differenza tra me e te
Majeed Hm.
Package | Acteurs | Cas d’utilisation |
Gestion des utilisateurs | Utilisateur invité | S’inscrire |
Consulter la liste des utilisateurs |
Utilisateur simple |
Mettre à jour ses informations personnelles |
Gestion des sorties | Utilisateur invité |
Consulter la liste des sorties |
Utilisateur simple | Gérer les sorties | |
Consultation | Utilisateur invité |
Consulter la liste des régions |
Consulter la liste des restaurants Consulter la liste des menus Consulter la liste des plats Consulter la liste des ingrédients | ||
Authentification | Utilisateur simple | S'authentifier |
Tableau 3 : La décomposition en package
11. Capture des besoins techniques
L'interface devrait répondre aux contraintes suivantes :
La performance : le système doit répondre convenablement aux spécifications précédemment indiquées.
Simplicité des interfaces : les interfaces doivent être simples, claires et ergonomique pour faciliter la tâche de l’utilisateur et garantir le bon fonctionnement de l’interface.
Rapidité des traitements : les traitements des données ne doivent pas excéder un temps limite.
L’ajout ou la mise à jour d’une sortie se fait par la spécification de plusieurs paramètres. L’interface doit offrir à l’utilisateur les différentes valeurs possibles pour chaque paramètre, s’il en existe.
L’extensibilité : il faut concevoir une architecture prête à accueillir toute extensibilité.
L’application doit être simple à installer et facile à maintenir.
12. Conclusion
Nous avons essayé à travers ce chapitre de réaliser une étude de l’existant qui énumère les différentes solutions qui existent sur le marché.
Dans le chapitre suivant, nous allons présenter les diagrammes de classes statiques ainsi que dynamiques en illustrant l’acheminement du premier au dernier par les diagrammes d’interaction et de collaboration.
(Maintenant, il va falloir qu'on fasse un peu de recherche pour la partie conception et architecture de l'application donc à plus tard pour la 3eme partie : "Conception". vous pouvez voir la doc en entier ici : Android pour la cuisine tunisienne.
A noter : ceci n'est pas une version fini et certains points peuvent
être ajouter ou modifier à condition d'en discuter. L'étape suivante
sera la création du diagramme des cas d'utilisation)
