Discussion :

[alband85]

Bonjour,

« pour le plaisir », j'ai lancé le développement d'un petit logiciel de gestion de bar personnel. L'idée est de gérer les stocks d'ingrédients (bouteilles, fruits, épices...) et de proposer les recettes pour lesquelles tous les ingrédients sont présents.

Si je me fais une bonne idée « en français » de la chose, je bloque un peu sur sa formalisation (et je me suis promis de ne pas commencer à coder tant que je n'aurai pas une conception propre et solide).

Un ingrédient est caractérisé par :

• son nom ;
• une description ;
• une unité de mesure (un volume, une masse, une pincée...).

Un cocktail est ensuite (outre son nom et sa description) une liste d'ingrédients quantifiés (il faut N mL de tel ingrédient, etc).

Le bar, lui, compte également des ingrédients quantifiés... mais pas les mêmes. Pour gérer les stocks, je pensais à quelque chose comme ceci :

• ingrédient ;
• quantité disponible ;
• quantité initiale ;
• ingrédient générique (par exemple, Zubrowka aura pour ingrédient générique Vodka).

L'idée de quantité initiale permet de gérer les stocks plus finement (au lieu de dire j'ai 2,5L de jus d'orange, je peux dire j'ai 3 bouteilles de jus d'orange, deux pleines et une ne contenant plus que 0,5L). C'est la solution que j'ai trouvé suite à ma question précédente.

Reste à modéliser tout ça proprement (c'est donc mon problème). Faut-il créer une classe Ingredient puis l'instancier dans CocktailIngredient (qui sera instanciée elle-même dans Cocktail) ?

Faut-il au contraire créer une classe Cocktail qui ne contient que sa description, utiliser la classe Ingredient telle que définie juste au-dessus (nom, description, unité de mesure) puis définir une classe d'association CocktailIngredient qui contient un objet Cocktail, un objet Ingredient et un entier (ou un flottant) qui représenterait la quantité ?

Les mêmes questions se posent pour le stock.

Avec ça, ma plus grosse question sera résolue... et je trouverai peut-être moi-même la solution à mes autres problèmes (questions existentielles ?).

Merci d'avance donc !

Alban

[Mat.M]

Reste à modéliser tout ça proprement (c'est donc mon problème). Faut-il créer une classe Ingredient puis l'instancier dans CocktailIngredient (qui sera instanciée elle-même dans Cocktail) ?

Faut-il au contraire créer une classe Cocktail qui ne contient que sa description, utiliser la classe Ingredient telle que définie juste au-dessus (nom, description, unité de mesure) puis définir une classe d'association CocktailIngredient qui contient un objet Cocktail, un objet Ingredient et un entier (ou un flottant) qui représenterait la quantité ?


Alban

euuhh j'ai l'impression que c'est un peu compliqué pour peu de choses :un Cocktail est composé de plusieurs ingrédients.
Si tu dois gérer une base de données un conseil je suggère de modéliser cela sous Ms Access avec l'outil qui permet de faire des relations entre les tables ce sera plus clair...
Après si tu veux t'assurer que ta base de donnée est cohérente qu'il n'y a pas de doublons alors il suffit de faire des petites requêtes SQL..
En faisant quelques requêtes d'affichage ,de tri,d'insertion d'ingrédients tu verras si ta base de donnée tient la route ou non..
Access est un excellent outil pour cela...
Si c'est par programmation c'est un éditeur UML qu'il faut..
Qu'importe le language de programmation, pour la persistance des données tu seras obligé d'avoir une base de données derrière et faire des requêtes SQL ( Access,MySQL...)
Des fichiers c'est bien mais c'est pas aussi souple qu'une base de donnée relationnelle.

[alband85]

Merci pour ta réponse.

En fait, le schéma de base de données, je le visualise assez bien, il ne me pose pas de problème.
Mon souci est plutôt du côté génie logiciel... que je ne maîtrise pas bien.

À la rigueur, je veux bien poster un schéma de base qui répond à mon besoin si ça permet de modéliser plus facilement l'application qui va taper dedans.

[alband85]

C'est parti, je rajoute mon MCD.


Les ID sont assez mal représentés... je n'ai utilisé Analyse SI que pour avoir un dessin propre.

Histoire de l'expliquer un peu :

• UNIT est l'unité de mesure d'un ingrédient (volume, pincée, masse...). Le is_substractable est simplement là pour dire si on peut facilement gérer les quantités ou pas (difficile de quantifier une pincée par exemple).
• STOCK représente les ingrédients disponibles. is_parent permet de définir un ingrédient « générique » (par exemple « jus d'orange » pour l'ingrédient « tropicana orange »), mais je pense qu'il vaut mieux ne pas en tenir compte dans un premier temps (ne compliquons pas les choses).
• INGREDIENT et COCKTAIL, je pense que c'est explicite.
• INGREDIENT_COCKTAIL de même : on précise juste la quantité d'ingrédient à utiliser dans le cockail.

Je rajoute le MPD généré (donc pas top top...) :


Et à partir de ça, il me reste à construire mes classes.
Je coince donc sur « ce qu'il y a entre » stock et ingredient, ainsi que pour la chaîne ingredient, cocktail_ingredient, cocktail.

A priori, ce n'est pas très compliqué... mais il s'agit de ma première application objet « tout seul » (et en autodidacte). Je manque donc un peu de recul.

Merci d'avance !

Alban

[Mat.M]

A priori, ce n'est pas très compliqué... mais il s'agit de ma première application objet « tout seul » (et en autodidacte). Je manque donc un peu de recul.

Merci d'avance !

Alban

Salut Alban mais je ne vois pas trop bien ou tu veux en venir.
Le MCD semble correct encore une fois il faudra l'ajuster au besoin lors du développement du projet.
Mais tu ne dis pas quel outil tu veux utiliser pour développer justement coté logiciel.
Par exemple tu peux prendre des outils AGL comme Windev, AGL ( je ne connais pas trop ces outils je le dis tout de suite..)
Par exemple je sais qu'avec Windev à partir du MCD on peut avoir le code correspondant en quelque sorte avec les traitements des flux de données..

[alband85]

À vrai dire, côté outil... je pensais tout faire à la main.
Après, s'il y a des choses qui le font à ma place (du moment que c'est bien fait et que ça ne demande pas trop de retouches), ça peut valoir également le coup.

En fait, techniquement, je me demandais comment représenter sous forme d'un ensemble de classe (c'est ça qu'on appelle modéliser ?) ce qui correspond à ce MCD.
Une classe Ingrédient, c'est facile. Une classe Cocktail, c'est facile aussi.
Ensuite, associer la classe Ingrédient à une quantité pour en faire une liste liée à cocktail... c'est là que ma maîtrise de la chose est un peu limitée. Qu'est-ce qu'on met au milieu pour que ça fonctionne ?
En gros, je cherche à faire le diagramme de classes de mon application.

Merci en tout cas !

Alban

[alband85]

Dites-moi si je suis bête ou pas... mais en fait, ça me semble tout simple là tout de suite...
(oui, je réfléchis pendant mes pauses café )


Pour résoudre mon problème :

• je créé une classe Ingredient avec juste nom, description et unité de mesure (et éventuellement un ingrédient générique "père" ;
• un ingrédient à cocktail est tout bêtement une classe qui hérite de Ingredient en ajoutant un attribut de quantité (et des méthodes qui vont bien) ;
• le stock est une collection d'ingrédients "de stock", soit un autre héritage de Ingredient avec des attributs de quantité initiale et de quantité actuelle.

Ca semble cohérent ou je fais n'importe quoi ?

Merci !

Alban (qui cherche au passage un bon bouquin de génie logiciel pour s'initier facilement à ce genre de choses...)

[JPhi33]

Bonjour Alban,

Un petit mot à propos de ton MCD qui est correct sauf l'entité STOCK.
Celle-ci est identifiée par la propriété STO_QTY dont on imagine aisément qu'il s'agit d'une quantité en stock.
Pour pouvoir être identifiant d'une entité, une propriété (= un attribut) doit posséder plusieurs caractéristiques et notamment :

• que ses valeurs doivent être discriminantes --> deux occurrences distinctes de l'entité ne peuvent pas avoir la même valeur d'identifiant ;
• que ses valeurs doivent être stables --> une fois fixées, elle ne doivent pas changer.

STO_QTY ne présente aucune de ces deux caractéristiques (le stock varie dans le temps et deux ingrédients différents peuvent avoir un stock de même valeur) et, par conséquent, ne peut pas être identifiant de STOCK.


Ceci étant, l'existence même de l'entité STOCK est à remettre en cause. Manifestement, la quantité en stock est une propriété de INGREDIENT. Pourquoi chercher à la mettre à part ? Peut-être à cause de la différence entre l'ingrédient générique (Vodka) qui entre dans la composition du cocktail (la recette) et les matérialisations de cet ingrédient (Zubrowka, Smirnoff, etc...) pour lesquels on gère les stocks.

Ce raisonnement permet d'aboutir à l'émergence d'une entité INGREDIENT_STOCK dont le stock est une propriété. Tu étais en bonne voie avec la réflexion ci-dessous :

• je créé une classe Ingredient avec juste nom, description et unité de mesure (et éventuellement un ingrédient générique "père" ;
• un ingrédient à cocktail est tout bêtement une classe qui hérite de Ingredient en ajoutant un attribut de quantité (et des méthodes qui vont bien) ;
• le stock est une collection d'ingrédients "de stock", soit un autre héritage de Ingredient avec des attributs de quantité initiale et de quantité actuelle.

Pour le modèle objet, si tu adoptes une démarche "guidée par les données", comme c'est bien souvent le cas dans les projets mettent en oeuvre une base de données, les classes seront :

• COCKTAIL
• INGREDIENT
• UNIT
• COCKTAIL_INGREDIENT (classe-association)
• INGREDIENT_STOCK

[alband85]

Bonjour,

désolé pour le temps de réponse.

Entièrement d'accord pour l'entité Stock... je ne sais pas pourquoi elle était comme ça sur le MCD. J'ai du oublier un attribut quand je l'ai créée. En théorie, j'ai bien un ID.

Le fait d'utiliser Stock était bien pour gérer les matérialisations, mais je la remets de plus en plus en cause.
D'un côté, certains cocktails demandent un produit bien spécifique dans sa catégorie (on peut imaginer un cocktail à base de Zubrowka... qui ne serait pas du tout le même avec une vodka non-aromatisée).
Mais d'un autre côté, c'est suffisamment rare pour que le signaler en commentaire puisse suffire (rajout d'un attribut comment dans cocktail_ingredient par exemple).

En tout cas, merci pour ce retour, ça me cale mieux les idées en tête.
Je vais pouvoir passer à l'implémentation histoire de confronter tout ça à la réalité ;-)