Domáca úloha č.2
Použitím OO paradigmy navrhnite interfacy a nadizajnujte komponent programu. Komponent počas behu nemá ukladať žiadne dáta a nemusí byť thread-safe (t.j. design je už to, čo sme na prednáškach nazvali analytický model).
Ľahšia verzia - Malý informačný systém reštaurácie
Extrémne minimalistický doménový model informačného systému reštaurácie som ukazoval na prednáške (pozor ukazoval som aj doménový model reštaurácie, to je niečo iné). Tento model možno rozviť do analytického modelu. Upozorňujem však, že som si nie istý či všetky entity na diagrame z prednášky majú správenie (zodpovednosť), bez pridania ďalšej funkcionality sú to iba dátové typy. Pri prechode z doménového modelu IS do analytického modelu môže dôjsť k zmenám tried. Pridajte tomuto minimalistickému systému ďalšiu zodpovednosť napr.:
- počítanie ceny objednávky, zľavy (účty sem nechcem dávať, lebo legislatívne požiadavky);
- vernostný program;
- aby systém zabezpečoval, že jedlá sa pripravujú a prinášajú na stôl v zmysluplnom čase a poradí;
- hodnotenie jedál/obsluhy;
- ... kľudom buďte kreatívny, ale neprežeňte to, je ľahké podceniť zložitosť systému pred tým ako ho začneme vytvárať.
Ťažšia verzia - Uchovávanie výsledkov zápasov a určovanie poradia
Systém má uchovávať stav futbalovej kvalifikácie na MS 2018 v Európe a vedieť určiť postupujúcich do baráže a na MS. Na prednáške som prezentoval systém na uchovávanie stavu kvalifikácie. Upozorňujem vśak, že systém z tejto úlohy má málo spoločného so sestémom prezentovaným na prednáške:
- štruktúra skupín je jednoduchá;
- pravidlá pre poradie skupín a pre postup do baráže sú zložité (v mojom modeli toto nebolo rozvité - to by sa napr. udialo v ďalšej iterácii);
- systém z prednášky drží informácie o žltých kartách jednotlivých hráčov, aby sa vedelo;
či môžu nastúpiť na ďalší zápas. Váš systém to robiť nemusí;
- nemusíte zabezpečiť rozlosovanie do skupín.
O poradí v skupinách sa rozhoduje
takto.
O postupe na MS a do baráže sa rozhoduje
takto a
takto.
Ďalšie poznámky
- V zadaní máte voľnosť. Preto stručne napíšte o zodpovednostiach vašeho komponentu. Použitie konjunkcií tu nie je porušením SRP (na úrovni komponentov). Váš komponent má jednoducho popísateľnú úlohu v rámci systému (menežovať objednávky / stav kvalifikácie). Je ale potrebné vymedziť čo súčasťou systému je a čo nie.
- Špecifikujte hranice (interfacy) komponentu a presne popíšte.
- Skúste sa priblíźiť ideálom OO paradigmy tým, že implementácia najkomplikovanejšej metódy v systéme by mala byť čo najjednoduchšia.
- Najmä druhá úloha môže výrazne čerpať z design patternov.
- V prípade, že zodpovednosti objektu nie sú jasné z pomenovania triedy metód, pripojte stručný popis.
- Dizajn nemusíte urobiť v UML. V každom prípade však musíte prehľadňe zachytiť vzťahy a typy vzťahov medzi triedami systému.
- Okrem statického popisu systému je dobré poskytnúť aj dynamický aspekt. Vyberte si preto jeden scenár ktorý váš komponent má vedieť vykonať a demonštrujte jeho vykonanie tým, že popíšete ako sa budú volať jednotlivé metódy objektov. Tento scenár by mal ideálne odstrániť všetky moje nejasnosti o fungovaní systému. Nepreháňajte to s dĺžkou scenára
- V ideálnom prípade by som váš návrh mal vedieť bez intelektuálnej námahy prečítať a naprogramovať.