Discussion :

[softstar]

bonjour tout le monde

excusez du derangement , mais j'aurais besoin d'un petit coup de pouce

svp

en fait,je suis en train de realiser mon dossier d analyse pour mon travail

de fin d'études de mon graduat d'analyste-programmeur,en cours du soir

le sujet c est : gestion d'un café-restaurant

j'y gere donc la caisse,les articles et produits,le stock en temps réel , ainsi que les commandes et les livraisons

je viens de finir mon schéma en uml

et ce serais pour savoir si il y a une bonne âme ici qui serait d'accord que

je lui envoye mon schéma (format .jpeg) afin qu on me dise si c est bon

ou si je dois encore changer des choses ?

je vous remercie tous d'avance en tout cas

et merci au créateurs de ce merveilleux forum , il m'a souvent aidé

pour la programmation en C++

[Matthieu Brucher]

Tu peux mettre le diagramme ici au besoin

[softstar]

donc en quelques mots,puisque chaque cas est differents

je realise la gestion complete d un café-restaurant (cfr le debut de mon

post)

et donc une des particularité c est que ce café restaurant a un systeme

a plusieurs tickets de caisses :

1) Ticket Bar (Ticket provisoire que le serveur apporte au barman pour qu il prépare les boissons)

2) Ticket Restaurant (Ticket provisoire que le serveur apporte en cuisine pour qu on prépare la nourriture)

3) Ticket définitif (qui reprends donc le total de ce que le client a commandé)

voila

si vous savez jetez un oeil a mon schéma et me dire si je dois encore rajouter des choses et surtout si il est correct ?

je vous en remercie tous d avance

SCHEMA UML :

[BizuR]

Perso, je n'etais plus sur dvp a l'heure ou tu as posté ton modèle alors a 2h du mat', tu t'imagines bien que je faisais autre chose

Pour ma part, je vais juste faire une légère remarque d'un point de vue "compréhensibilité" de ton modèle sur la gestion des tickets. en effet, apres quelques (plusieurs) minutes de reflexion, j'ai compris l'intéret du "XOR" entre les deux tickets (ou tout du moins, je PENSE avoir compris) :

table ==> tickets de commande (bar et restau)
client ==> ticket définitif

?

Si cela est le fonctionnement, voici mes questions :
- On peut payer un ticket provisoire ? Et récupérer cet article payé sur le ticket définitif sans avoir a le payer ? ou bien ces tickets provisoires servent ils juste à commander un article ?
- Le client recoit le ticket définitif et la table les provisoires ? ou bien on peut tout mélanger ?

Si ce n'est pas cela ... (le fonctionnement décrit ci-dessus), et bien finalement j'aimerai bien avoir une explication du mécanisme pour savoir si ton modèle cole avec les besoins.

Mon idée en fait, pour le rendre lisible aurait ete de modéliser une héritage a partir du ticket afin de bien dissocier :
- soit les trois types de tickets (et ainsi associer proprement ces derniers avec le reste en évitant les 0..1)
- soit modéliser plutot les tickets provisoires et le ticket définitif (si les deux tickets provisoire ont les mêmes particularité de gestion).

on aurait donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
//CAS OU CLIENT == Definitif et TABLE == Provisoire
 Ticket (abstract) <|------ Ticket Provisoire (extends) ------ Table
                   <|------ Ticket définitif (extends) ------ Client

Et l'on comprendrait ainsi un peu mieux le concept des tickets . Encore mieux, il y aurait peut etre ainsi moyen de faire disparaitre ce XOR qui est assez difficile à traduire en objet ... a moins que :

Tu peux aussi considérer le cas ou tout le monde peut demander n'importe quel ticket et la, ta modélisation peut se définir ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
//CAS OU TOUT LE MONDE PEUT TOUT DEMANDER
 Ticket ------ Destinataire (Interface)  <|------ Client (implements) 
                                         <|------ Table (implements)

Et tu peux toujours combiner les deux pour une meilleure lecture dans ce même cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
//CAS OU TOUT LE MONDE PEUT TOUT DEMANDER (bis)
 Ticket (abstract) ------ Destinataire (Interface)  <|------ Client (implements) 
 ^    ^                                             <|------ Table (implements)
 |    |
 |    Ticket Définitif (extends)
Ticket Provisoire (extends)

Voila pour ma part (et désolé pour les dessins, je fais avec les moyens du bord )

[softstar]

yop ,merci de me répondre en tout cas

en fait pour le XOR

c est le fait que ce café-restaurant conserve dans sa base de données

les coordonnées de ses clients habitués

donc j ai ajouté une contrainte XOR pour dire que

le ticket correspond a un CLIENT HABITUE

ou le ticket correspond a une TABLE

mais pas les 2 ensembles

voila , j espere t avoir éclairé sur ce point

n'hésite pas si tu as d autres questions,et merci encore de m'aider

[BizuR]

en fait pour le XOR
c est le fait que ce café-restaurant conserve dans sa base de données
les coordonnées de ses clients habitués
donc j ai ajouté une contrainte XOR pour dire que
le ticket correspond a un CLIENT HABITUE
ou le ticket correspond a une TABLE
mais pas les 2 ensembles

ok donc essaie plutot de t'orienter vers le troisième exemple que j'avais décris. Ca permettra une bien meilleure compréhension du modèle (pas forcé de conserver le terme hideux "destinataire", je savais pas quoi mettre tout simplement !)

Par contre, pour les autres questions ?
Peut on payer un ticket provisoire ou juste les tickets definitifs ? Comment se passent les regles de gestion au niveau des reglements ? (cela justifiera peut etre encore mieux l'héritage des tickets que j'ai décrit)

[softstar]

yop , je crois que le plus simple

c est que je te mette ici le lien vers les 2 petites interview que j ai eu

avec l un des serveurs, et le patron

ce sont 2 documents .doc (format word)

merci en tout cas de m aider

document 1 : interview avec le serveur

http://perso.latribu.com/softstar/in...e serveur).doc

document 2 : interview avec le patron

http://perso.latribu.com/softstar/in...le patron).doc

[BizuR]

Après la lecture de l'interview serveur ... je vais confirmer que le ticket provisoire ne sert qu'a prevenir le barman/cuisto de la preparation d'un article donc, tu peux de suite considérer mon hypothese 3 qui répondra à mon avis au mieux a ton cas mais surtout que tu peux ainsi agir de la maniere suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 Ticket (abstract) ------ Destinataire (Interface)  <|------ Client (implements) 
  ^    ^                                             <|------ Table (implements)
 |     |
 |    Ticket Définitif (extends) ------ Paiement (et ce qui va avec)
Ticket Provisoire (extends)

Après, tu peux également supprimer l'objet Type_Ticket puisqu'ici tu peux identifier les tickets entre eux ... si tu veux encore plus affiner la hierarchisation du modele, tu peux découper plus finement comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 Ticket (abstract) ------ Destinataire (Interface)  <|------ Client (implements) 
 ^    ^                                             <|------ Table (implements)
 |    |
 |    Ticket Définitif (extends) ------ Paiement (et ce qui va avec)
Ticket Provisoire (extends) (abstract)
  ^   ^            
 |   |
 |    Ticket BAR (extends)
Ticket RESTO (extends)

pour faire totalement disparaitre la notion de type de tickets

[softstar]

merci beaucoup de ton aide poto

je vois + ou - ce que tu veut dire

mais je comprends pas trop bien ton type de schématisation

arrette moi si je me trompe

mais donc

je dois utiliser de l heritage , c est bien ca ?

j aurais donc 2 classes (ticket provisoire,ticket définitif) qui héritent de la classe ticket

c est bien cela ?

merci de m eclairer sur ce point

et au sinon a pars ca,le reste du schéma est bon selon toi ,suivant les contraintes dites dans les 2 interviews ?

merci d avance pour tout en tout cas

[BizuR]

ui, c'est exactement cela ... si j'explique par "hierarchie" :

1er niveau : TICKET, une classed abstraite contenant tous les tickets possibles dans le restaurant (donc contenant aussi les attributs communs aux trois, si il y en a ). Elle permet surtout de stipuler qu'un ticket est en relation avec un "Destinataire" (Client ou Table)

2eme niveau : TICKET DEFINITIF et TICKET PROVISOIRE qui sont respectivement concret et abstrait et héritent tout deux de TICKET. le TICKET DEFINITIF sera entre autres lié au PAIEMENT et composé de l'addition alors que le second devra etre instancié à un niveau inférieur encore...

3eme niveau : TICKET BAR et TICKET RESTO qui héritent tout deux de TICKET PROVISOIRE et permettent d'identifier facilement lesquels constituent quoi

pour "destinataire" on aura une interface qui permettra de dire qu'un ticket est destiné a un DESTINATAIRE, sans se soucier si ce dernier est soit un CLIENT soit une TABLE (car ilsb implémenteront (c'est aussi un héritage) tout deux DESTINATAIRE).

Sinon, pour le reste, désolé de ne pas avoir tout scruté à la loupe ... mais dans l'ensemble, cela ne me semble pas incohérent... a toi de revérifier derriere

[softstar]

bonjour bizur,

est ce bien comme ceci ?

et concernant l inerface,on n a pas apris ca en uml,donc je vois pas ce que c est

voici mon nouveau schéma donc (je n ai repris que la caisse ici)

j'espère que c est bien comme cela que tu voulais dire ?

je te remercie de bien vouloir m'éclairer sur ce sujet

Schéma :



Pour la cardinalité 1->1..* entre paiements et ticket_definitif
,c est bien juste ? merci d'avance de ton aide en tout cas

[BizuR]

Pour les tickets, c'est exactement ca. On comprend ainsi mieux comment se déroule le fonctionnement des tickets ... mis à part, peut etre, l'association Tickets/Articles.

En gros, d'après mes souvenirs et ce que j'avais lu :
- Un ticket définitif permet de lister la commande et de facturer (donc l'asso Article/Ticket est juste
- Un ticket provisoire n'est attenant qu'a un et un seul article non ? Il serait peut-être intéressant de revoir la liaison pour mieux préciser cette idée (toutefois, je suis bien conscient que la modélisation actuelle est juste. C'est uniquement que cette contrainte, si elle est juste, n'est pas exprimée.
- un ticket bar ne concerne que des boissons
- un ticket resto concerne les plats

Peut etre devrais-tu faire aussi un heritage sur article pour le diviser en ArticleResto et ArticleBar, tu aurais ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
                                      Ticket_____________________
                                         |                       |
Article ------------------------ TicketDefinitif        TicketProvisoire
|    |                                                   |         |
|    |____ArticleBar----------------------------- TicketBar        |
ArticleResto ---------------------------------------------- TicketResto

Mais bon, a chacun son affinage du modèle... certains penseraient peut etre aussi que le modèle devient trop détaillé... A vrai dire, tout probleme a plusieurs solutions, reste à choisir soi-même celui qui décrira au mieux ce dernier

Pour les paiements, tu pourrais de maniere analogue faire un héritage de Paiement pour obtenir PaiementCheque, PaiementCB et PaiementEspece ... mais bon, je ne garantis pas l'utilité d'une telle opération sauf si ces derniers auront des traitements différents selon les paiements.

Enfin pour l'"interface", je parlais en terme POO et non UML, tu peux simplement le traduire ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
-------------------
|  <<Interface>>  |
|  Destinataire   |
-------------------

Et faire un simple héritage ...

Pour Ticket, tu peux le mettre ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 -------------------
|   <<Abstract>>   |
|      Ticket      |
-------------------