• Login 

Hotelove Rezervace

UML - hotelové rezervace

Zadání

Aplikace umožňuje rezervovat pokoje v hotelu. Rezervace pokojů jsou minimálně na den, eviduje se typ požadovaného pokoje, datum od a do, údaje o zákazníkovi a volitelně pokoj. Při rezervaci se kontroluje, zda na daný termín je pokoj/ prostředek volný. Vytvořte návrhový diagram tříd, který umožní následující případ užití.

Případ užití 1: Rezervace hotelového pokoje zájemcem
Primární aktér: zájemce o ubytování
Rozsah: aplikace
Úroveň: uživatelský cíl
Vstupní podmínky: zájemce o ubytování je na WWW stránkách hotelu

Hlavní úspěšný scénář:
1. Zájemce zvolí v menu volbu “Rezervace ubytování”

2. Zájemce vyplní Typ pokoje, Datum příjezdu a Datum odjezdu,

3. Zájemce vyplní políčka Jméno, Příjmení, Ulice, Město, PSČ, E-mailová adresa a Telefon. Zájemce stiskne tlačítko Odeslat rezervaci.

4. Zájemce zvolí tlačítko „Volba konkrétního pokoje“.

5. Zájemce si zvolí jeden konkrétní pokoj.

Řešení s chybami

hr01

• Třídy Rezervace a Zákazník by bylo vhodné sloučit do jedné třídy,
• chybí seznam pokojů - bez něho nezjistíte volné pokoje,
• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj,
• metody jeVyplnenZakaznik() a jeVyplnenoDatum() patří do grafiky,

hr02

• u asociací chybí jména datových atributů,
• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj,
• abstraktní třída pokoj nemůže evidovat datum příjezdu a datum odjezdu - to by v jednom pokoji mohla být pouze jedna rezervace na roky dopředu,

hr03

• u asociací od třídy Gui Vám chybí jména datových atributů,
• nerozumím třídě RezervacePokoju, která má u Vás tři datové atributy: seznam instancí třídy Zákazník, seznam instancí Datum a seznam pokojů. Pokud by tato třída měl představovat jednu rezervaci, tak by měla odkazovat na jeden pokoj, jednoho zázazníka a jeden datum. Potom ale chybí někde umístěný seznam pokojů.
• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj,
• někde by měla být umístěna metoda, která bude zjišťovat, zda je v daném termínu volný pokoj,

hr04

• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• některé asociace máte obráceně - nemá být vztah od termínu ke třídě EvidencePokoju, ale spíš obráceně,
• některé třídy a názvy vztahů popisují postup činnosti při vyplňování údajů - třída ZajemceOUbytováni s jediným datovým atributem rezervujePokoje. Dále datové atributy vyberTypuPokoje a vyberKonkretnihoPokoje.
• chybí třída popisující jeden pokoj.
• Třída SeznamVolnýchPokojů je podezřelá - seznamy jsou obvykle realizovány před datové atributy; když se pokoj obsadí, tak se měl asi přesunout do jiného seznamu - to je neobvyklé; není jasný pojem volný pokoj - volný je, když na něj není žádná rezervace nebo není rezervace v konkrétním termínu.

hr05

• u asociací mají být v návrhovém diagramu tříd jména datových atributů a ne popisy vztahů,
• u asociací chybí šipky,
• duplicitní informace mezi třídami Zajemce a Rezervace jsou chybou - ponechal bych pouze třídu Rezervace,
• nepoznám, zda někde je seznam pokojů,
• od rezervace by měla být asociace na pokoj,

hr06

• u některých asociací chybí jméno datového atributu,
• nechápu atribut vsechnyPovinneUdaje ve třídě rezervace,
• třída odeslat je nejspíš nesmysl, neboť označuje činnost, ne obsah,
• jména atributů označují činnosti - "zobrat upozorneni", "vyber pokoje", "je volný", "vyplní" či "zadá údaje" - to jsou názvy pro metody a ne pro datové atributy,

hr07

• třída "Zájemce WWW" do diagramu nepatří - to je uživatel aplikace,
• nechápu, proč ve třídě Rezervace je datový atribut typPokoje typu List - správně by zde měl být datový atribut typPokoje vyjádřený pomocí asociace ke třídě TypPokoje,
• od rezervace by měla být dále asociace ke třídě Pokoj - uživatel si může vybrat konkrétní pokoj,
• třída "SeznamDostupnychPokoju" je divná - není jasné, co bude obsahem třídy. Dle mne je to úplně zbytečná třída.
• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• metoda kontrolaUdaju() ve třídě Rezervace patří spíš do grafiky a ne do třídy Rezervace,

hr08

• dědičnost od třídy Udaje je nesmyslná - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné. Zde to jsou navíc konkrétní datové atributy ze třídy Rezervace.
• u některých asociací chybí jména datových atributů,
• uvedené datové atributy u asociací jsou nesmyslné - např. ve třídě TypPokoje by měl být dle Vás datový atribut obsadenyTyp typu Rezervace - nechápu. Obdobně ve třídě Datum je nesmyslný datový atribut "obsadenyDatum" typu Rezervace.

hr09

• třída Rezervace má dle Vás dva datové atributy se jménem typPokoje - jednou u asociace ke třídě TypyPokoju, podruhé u asociace ke třídě ZabranePokoje,
• názvy tříd by měli být v jednotném čísle,
• chybí Vám třída se seznamem pokojů. Možná by mohl být ve třídě ZabranePokoje, ale u ní nechápu název třídy a hlavně proč má datové atributy datumOd, datumDo a typPokoje.
• není příliš logické, aby třída TypyPokoju evidovala počet pokojů konkrétního typu - znamenalo by to, že vytvoříte nový pokoj, zařadíte někam do seznamu pokojů a ještě k tomu bude připočítávat jedničku do čítače u typu pokojů. Jednodušší by bylo, kdyby třída evidující pokoje měla metodu, která spočítá počet pokojů konkrétního typu.
• nemáte dobře kompozici - když se zruší jeden pokoj, tak by se měl zrušit i odpovídající typ pokoje (např jednolůžkové pokoje),

hr10

• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj,
• u třídy Pokoj nerozumím datovému atributu "Chybové hlášení" typu rezervace - zde se snažíte popsat činnost uživatelského rozhraní,
• ani datový atribut "seznam pokoju" typu Pokoj ve třídě Rezervace není dobře - každá rezervace si má pamatovat seznam pokojů?
• do diagramu nepatří třída Zajemce - to je uživatel aplikace a ne předmět aplikace,

hr11

• u asociací nemáte napsány jména datových atributů, ale činnosti - např. "odeslatRezervaci" je název pro metodu, která odešle mailem rezervaci a ne jméno datového atributu typu Osoba ve třídě RezervaceUbytování (navíc by jste poté měl dva datové atributy typu Osoba).
• V jedné instanci třídy Pokoj by neměl být evidován seznam pokojů (a navíc typu RezervaceUbytovani),
• Nechápu třídu VolnyPokoj a ani třídu DataObsazeni.
• Nemáte nikde seznam rezervací - bez tohoto seznamu nejste schopni zjistit, zda je k danému termínu volný pokoj příslušného typu.
• V řešení by měla být třída TypPokoje, popř. výčtový typ - zákazník si může zarezervovat pouze typ pokoje.

hr12

• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné. U Vás mají stejný datový atribut, ale s různými hodnotami - to ale spíš ale odpovídá 4 instancím stejné třídy.
• u asociací Vám občas chybí jména datových atributů,
• duplikování datových atributů mezi třídami je obvykle chybou - třída Formular odpovídá grafickému rozhraní a neměla by být v návrhovém diagramu tříd.
• Ve Vašem případě by bylo nejjednodušší sloučit třídy Formular, EvidenceRezervaci a EvidencePokoju do jedné třídy, která bude obsahovat seznam pokojů, seznam rezervací. A bude zjišťovat, zda je volný pokoj v daném termínu.
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj. Na tuto třídu by odkazovala třída Pokoj. Ve třídě EvidencePokoju nemají smysl samostatné sety pro jednotlivé typy pokojů.
• ve třídě Pokoj bych zrušil datový atribut objednaneTerminy a místo něho udělal asociaci ke třídě Rezervace,

hr13

• datové atributy id... patří do relačního schématu a ne do objektového modelu zaznamenaného v diagramu tříd,
• pro vztahy mezi třídami se obvykle používá asociace se jménem datového atributu a ne závislost,
• k zjištění, zda je nějaký pokoj volný v daném termínu, potřebujete mít někde seznam všech pokojů a seznam všech rezervací,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj,

hr14

• názvy datových atributů se píší k asociacím
• datové atributy id a podobné patří do databázového relačního modelu a ne do objektového modelu, který se kreslí pomocí diagramu tříd,
• ze zadání nevyplývá, že by jeden zájemce měl více rezervací, tj. třídy Zajemce a Rezervace je možné/vhodné sloučit,
• jak může třídy TypPokoje vrátit pole pokojů, když je neeviduje,
• zákazník má možnost zvolit si pouze typ pokoje a ne konkrétní pokoj, tj. měla by být asociace od Rezervace ke třídě TypPokoje,
• proč má třída Pokoj metodu rezervuj s parametry od, do a zajemce, když neeviduje ani časy, ani zájemce.
• v diagramu tříd se nepoužívá rozsah 0..N ale 0..*

hr15

• Není jasné, zda máte seznam rezervací - u oboustranné asociace mezi EvidenceRezervací a Rezervace je uveden pouze jeden atribut a ten dle umístění říká, že jedna instance třídy Rezervace se odkazuje na seznam instancí třídy EvidenceRezervací.
• dědičnost typů pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• od třídy TypPokoje vedou dvě asociace se jménem typPokoje - to by znamenalo, že ve třídě TypPokoje budou dva datové atributy stejného jména. Správně mají být obě dvě asociace obráceně.
• třída, která bude zjišťovat zda je volný pokoj, musí mít k dispozici seznam pokojů a seznam rezervací - sloučit třídy SeznamPokoju a EvidenceRezervací dohromady,
• metoda zobrazVolnePokoje - dle názvu bych to odhadoval na nějakou metodu z grafiky. Určitě ale nemůže být ve třídě Pokoj, neboť potřebuje mít k dispozici seznam pokojů a seznam rezervací.

hr16

• název třídy "Webová stránka" odkazuje na uživatelské rozhraní - to nepatří do návrhového diagramu tříd,
• u asociací chybí jméno datového atributu a šipka,
• výčtový typ "Typ pokoje" se nikde nepoužívá, takže je je zbytečný,

hr17

• u asociací nejsou jména datových atributů, mnohdy chybí i šipky,
• Třídy Rezervace a Zákazník by bylo vhodné sloučit do jedné třídy,
• chybí seznam pokojů - bez něho nezjistíte volné pokoje. Chybí také seznam rezervací. Dokáži si představit, že tyto seznamy by mohly být ve třídě nyní pojmenované Kontrola
• dědičnost pokojů je problematická - pokud se potomci neliší v datových atributech či aspoň metodách, tak jsou zbytečné,
• měla by existovat třída či enum TypPokoje - zájemce si nejdříve vybírá pouze typ pokoje, poté teprve konkrétní pokoj. Ve Vašem případě asi typ pokoje představuje abstraktní třída Pokoj.
• každá instance třídy KonkretniPokoj by nejspíš neměla obsahovat seznam volných pokojů - při obsazení jednoho pokoje by se museli upravovat všechny pokoje. Existence seznamu volných pokojů je obecně problematická - vždy závisí na konkrétním termínu, pro různé termíny jsou to různé seznamy.

Správné řešení

• místo výčtového typu TypPokoje může být použita klasická třída TypPokoje