Restauracia je komplikovany system a jej popis treba urcite rozbit do viacerych casti
(podsystemov/komponentov), napr.: ObsluhaZakaznika, Kuchyna, Uctovnictvo, Sklad, Zamestnanci, atd.
Modelujem ObsluhuZakaznika. Tento podsystem vyuziva Kuchynu a Uctovnictvo. S podsystemom 
ObsluhaZakaznika by mohli mat vztah aj dalsie podsystemy: Zamestnanci (priradenie ludi casnikom),
JedalnyListok.


Dufam, ze nazvy Tried su samovysvetlujuce. Trosku pokecu by si vyzadovali stavy PolozkyObjednavky,
stavy Uctu a PredajAVydajObjednavok. Vynecham to, pretoze "Pedagogicky pokec" obsahuje c sebe
scenar, ktory vam to ujasni.



Pedagogicky pokec:

Asi najvacsim problemom vacsiny domacich uloh bola neuplnost modelu. Je pravda, ze tento model 
nezachycuje vsetko, to ani model nema robit. Napriklad tento model nezachycuje smeny casnikov.
To je OK pokial sa to nesnazime namodelovat. Ak vsak chceme namodelovat ObsluhuZakaznika, 
v nasom modeli by mal vediet prebehnut napr. use case ObsluhaZakaznika (OK, ani tu nie je model 
kompletny, je to verzia 1, rozne netradicne prechody use casom tam asi nie su). Nemam tu toalety,
to je ale v podstate nezavysly podsystem. Zakladny use case moj model vsak v pohode zvlada:


1. Zakaznik pozna polohu Miestnosti (vztah vznikol mimo modelu). Zakaznik pouzije svoj vztah 
s Miestnostou a sadne si za niektory Stol, cim vytvori vztah medzi Zakaznikom a Stolom.

2. Casnik ma priradene stoly, ktore obsluhuje (vztah vznikol mimo modelu) takze obcas pride
k stolu. Tym vznikne vztah Casnik je pri Stole a tym sa stane Casnik dostiahnutelny pre Zakaznika
(alternativne, som mohol vytvorit vztah Casnik je v Miestnosti a umoznit Zakaznikovi zakricat 
na Casnika aj ked nie je pri stole, sme ale v nobl restauracii :) ).

3. Ked je Casnik pri stole, Zakaznik si od neho vypyta jedalny listok. Casnik ide na OdkladiskoJL
a prenesie jeden JedalnyListokTlaceny na Stol. JedalnyListokTlaceny len presuva, je mu jedno 
co je to zac a zmena JedalnehoListkaTlaceneho pracu Casnika nijako neovplyvni, preto 
Casnik nie je zavisly od JedalnehoListkaTlaceneho.

4. Casnik sklontroluje, ci k danemu stolu eviduje nejaku Objednavku, alebo Ucet. Neeviduje a tak 
Casnik vytvori novu Objednavku prisluchajucu Stolu. (Ak by Objednavka existovala, tak ak bol 
predchadzajuci zakaznik poctivy, vsetky PolozkyObjednavky su zauctovane a Ucty zaplatene.
Ak predchadzajuci Zakaznik nezaplatil, musi Casnik k zadanym PolozkamObjednavky vytvorit Ucet
a nezaplatene Ucty vytvorene k Stolu odpisat, ale to nemusime riesit, lebo piseme scenar).

5. Zakaznik cita JedalnyListokTlaceny co sa objavil na Stole a ked sa opat objavi pri stole Casnik,
povie mu idPolozky. Casnik skontroluje ci sa idPolozky nachadza v JedalnomListku (v nobl restauracii 
urcite nemaju stary jedalny listok, zakaznik ale nemusi vediet citat). Pre kazde spravne idPolozky
vytvori na Objednavke PolozkuObjednavky v stave "objednana". 

6. Casnik pride k okienku (PrijemAVydajObjednavok) a da "uvarit" jedlo tym ze zada idPolozky a cislo
(Kuchyna ma svoju vlastnu reprezentaciu polozkyJL, ktora obsahuje aj recept, rozumie vsak idPolozky,
cislo kuchynu nezaujima, ale vrati ho, spolu s PripravenouPolozkou). Casnik zmeni stav 
PolozkyObjednavky z "objednana" do stavu "zadana".

7. Casnik sa obcas pozre na PrijemAVydajObjednavok z zisti ci "jeCoZobrat". Ak je, "zobere"
PripravenuPolozku. S nou sa dozvie aj cislo. Casnik vsak vie ze toto cislo je cislom Stola. 
Casni najde Objednavku ktora ma priradeny Stol s cislom a zmeni stav jednej polozkyObjednavky
s rovnakym idJedla zo stavu "zadana" do stavu "uvarena".

atd...



Poznamky:
-V domenovom diagrame nie je nevyhnutne specifikovat presne interfacy. Specifikujem len spravania
ktore su potrebne pre pochopenie fungovania modelu.
-Da sa akceptovat zlucenie PolozkyObjednavky a PolozkyJL (bude sa vsak dat zauctovat iba cela 
objednavka naraz), da sa akceptovat nerozlisovane JedalnehoListka a JedalnehoListkaTlaceneho (je 
to detajl) ale PripravenaPolozka a PolozkaJL su naozaj velmi velmi rozne veci.
-Pouzivanim idPolozky sa mi vyrazne znizil pocet zavislosti. Rovnako Objednavke a Ucetu by stacilo 
cisloStola, boli by o dve zavislosti menej => lepsi design (neurobil som to tak trochu naschval).
-Mnohi z vas si zvolili iny aspekt fungovania restauracie. Napr. ak ste sa zaoberali Pokladnou,
tvorbou ceny a zlavami, a ze neiektori zakaznici su VIP, v tomto systeme ak vystupuje Zakaznik
ako aktor, tak si treba dat velky pozor na to, ze v systeme mame dve entity, ktore by sme normalne 
nazvali Zakaznik, zakaznik ako aktor a reprezentacia zakaznika v nasom systeme VIP zakaznikov.


