# Příklady na SI1 zkoušku

Kdybyste chtěli, můžete sem přidat řešení nějakého příkladu.

(Můžete to klidně vyfotit z papíru)

Pokud už u příkladu řešení je, tak k tomu můžete psát poznámky, jestli byste tam něco dělali jinak nebo jestli tam je něco blbě.

## Vyplněné příklady
- [x] Vzorová písemka
- [x] bankovnictví
- [ ] evidence pacientů u lékaře
- [x] Fakultní anketa
- Potřeba kontrola příkladu 5 🤷‍♂️
- [x] Internetový obchod (< to bylo docela hard)
- [x] Restaurace
- Potřeba kontrola příkladu 1
- [ ] tábor
- [ ] vláda
- [ ] zahrádkářský spolek
- [ ] zdravotnické zařízení

## Typy diagramů co jsme se učili
- [UML diagram aktivit](https://moodle-vyuka.cvut.cz/pluginfile.php/506236/mod_resource/content/6/02.prednaska.pdf)
- [Business domenovy model](https://moodle-vyuka.cvut.cz/pluginfile.php/506236/mod_resource/content/6/02.prednaska.pdf)
- [Analýza požadavků](https://moodle-vyuka.cvut.cz/pluginfile.php/506241/mod_resource/content/7/03.prednaska.pdf)
- požadavky
- diagram balíčků
- [Use Case Model (případy užití)](https://moodle-vyuka.cvut.cz/pluginfile.php/506241/mod_resource/content/7/03.prednaska.pdf)
- [Analytický Doménový model](https://moodle-vyuka.cvut.cz/pluginfile.php/506247/mod_resource/content/5/04.prednaska.pdf)
- [Stavový diagram](https://moodle-vyuka.cvut.cz/pluginfile.php/506247/mod_resource/content/5/04.prednaska.pdf)
- [Databázový model](https://moodle-vyuka.cvut.cz/pluginfile.php/506252/mod_resource/content/6/05.prednaska.pdf)
- [Návrh architektury (balíčky)](https://moodle-vyuka.cvut.cz/pluginfile.php/506252/mod_resource/content/6/05.prednaska.pdf)
- [Návrhový model tříd](https://moodle-vyuka.cvut.cz/pluginfile.php/506252/mod_resource/content/6/05.prednaska.pdf)
- [Sekvenční diagram](https://moodle-vyuka.cvut.cz/pluginfile.php/506256/mod_resource/content/3/06.prednaska.pdf)
- [Rozhraní a komponenty](https://moodle-vyuka.cvut.cz/pluginfile.php/506261/mod_resource/content/5/07.prednaska.pdf)
- [GoF](https://moodle-vyuka.cvut.cz/pluginfile.php/506261/mod_resource/content/5/07.prednaska.pdf)
- [Diagram objektů](https://moodle-vyuka.cvut.cz/pluginfile.php/506265/mod_resource/content/4/08.prednaska.pdf)

## ✅ Vzorová písemka - knihovna
2022-05-09 10:28

Analyzujte a navrhněte systém pro podporu provozu malé knihovny. Systém by měl být primárně zaměřen na podporu běžné činnosti knihovníka, ke které patří především zaznamenávání informací o provedení výpůjček a vrácení dříve vypůjčených výtisků. Kromě této činnosti by měl systém podpořit evidenci nově zakoupených výtisků a registraci nových čtenářů, kterou provádí také knihovník.

Knihovna eviduje knihy, o kterých uchovává informace jako: název, isbn, rok vydání, klíčová slova pro vyhledávání, stručný popis a autora knihy. Autorů může být u každé knihy více. Pro každou evidovanou knihu má knihovna k dispozici alespoň jeden její výtisk. Pokud je o knihu velký zájem, nakupuje knihovna více výtisků od jedné knihy. Každý výtisk je opatřen evidenčním číslem. Kromě evidenčního čísla je u výtisku sledován rok, kdy byl zakoupen, jeho pořizovací cena a případně i datum vyřazení, pokud došlo k takovému poškození výtisku, který znemožňuje jeho další půjčování čtenářům. V rámci každé výpůjčky je evidována informace o tom, který výtisk si čtenář půjčuje, kdy k zapůjčení došlo a kdy byl výtisk vrácen. Aby si mohl návštěvník knihovny vypůjčit výtisk a donést si ho domů, tak musí být registrovaným čtenářem této knihovny. U každého čtenáře se uchovávají informace o jeho jméně, příjmení, emailu, telefonu a čísle průkazky, které mu je při registraci přiřazeno.

Kromě usnadnění práce knihovníkovi by měl systém registrovaným čtenářům usnadnit vyhledávání informací o knihách a vytváření jejich rezervací. Tyto služby jsou dostupné pouze registrovaným čtenářům. Bez registrace není možné se systémem nijak pracovat. Registrovaný čtenář si může v knihovně vytvořit rezervaci knihy, kterou by si rád přečetl, ale aktuálně nemá knihovna k dispozici žádný volný výtisk. Rezervaci může čtenář provést při osobní návštěvě knihovny, kdy o zaznamenání požadavku na rezervaci požádá přímo knihovníka (který požadavek zadá do systému), nebo on-line přímo z domova prostřednictvím tohoto systému. Po zadání požadavku na rezervaci do systému, je rezervace ve stavu nová a celý proces rezervace je pozastaven do doby, než některý z čtenářů vrátí výtisk rezervované knihy. Při obdržení této informace/signálu proces pokračuje dále tak, že nejprve knihovník kontaktuje čtenáře, který si knihu rezervoval, a oznámí mu dostupnost výtisku rezervované knihy a rezervace se dostává do stavu aktivní. Následně se čeká tři dny na to, zda si čtenář výtisk vyzvedne. Pokud si čtenář výtisk během tří dní vyzvedne, tak celý proces rezervace končí a rezervace se dostane do stavu dokončená. Pokud si čtenář dosud výtisk nepřevzal, tak dojde po třech dnech ke zrušení rezervace a výtisk je zařazen jako volný zpět do regálu, kde si ho mohou ostatní čtenáři vypůjčit. V tomto případě se stav rezervace změní na zrušená. Tyto zrušené rezervace jsou nadále v systému evidovány pro statistické účely

1. ✅Nakreslete analytický doménový model. Nezapomeňte uvést násobnosti vztahů a tam, kde to zvýší čitelnost modelu, i jejich název.

2. ✅Nakreslete diagram aktivit, který zachycuje proces vytvoření rezervace a její zpracování. Pro přehlednost digramu používejte zóny zodpovědnosti (swimlanes). V diagramu zachyťte také objekty, se kterými se v rámci daných aktivit pracuje a jejich stavy.

3. ✅Nakreslete diagram stavů rezervace. Neopomeňte popsat podmínky přechodu mezi jednotlivými stavy a události, které přechod do jiného stavu spouští

4. ✅Identifikujte aktéry systému a vytvořte use case diagram obsahující minimálně dva případy užití pro každého aktéra. Ke každému případu užití doplňte krátký popis.

5. ✅Vytvořte návrhový model tříd, který by zajistil naplnění nefunkčního požadavku, který požaduje snadné napojení na externí zdroj informací o knihách. Rozšíření by mělo být možné udělat v budoucnu bez zásahu do existujících zdrojových kódů. Nadefinujte rozhraní BookInfoFinder, které pro zadané isbn, poskytne informace o dané knize. Informace načítané o knihách jsou: isbn:String, nazev:String, vydavatalestvi:String, stručný obsah:String a rokVydání:Date. Zakreslete návrhový model tříd, který obsahuje i třídu implementující toto rozhraní s názvem BookCatalog.

## ✅ Př. Bankovnictví


### Zadání
1. Analytický doménový model, nutno popsat všechny hrany
2. Diagram aktivit - Popsat jednorázové příkazy k úhradě (nemusí být swimlines), diagram musí znázorňovat i všechny stavy objektů(!)
3. Stavový diagram - Popsat jednorázové příkazy k úhradě včetně všech popisů a všech podmínek
4. Sekvenční diagram na vrácení stavu konta za jeden měsíc. K dispozici je účet který má metodu vratKonto(mesic), účet si sám na sebe volá vratPohyby(což jsou odchozí a přichozí transakce) a na transakce se dá volat vratCastku(). **Transakce je polymorfní** (odchozí/příchozí) a v diagramu je potřeba to rozlišit.
5. Aspoň 5 Use Cases spolu se všemi účastníky a použít border na ohraničení aplikace a internetového bankovnictví

### Řešení
1. ✅ **Doménový model**

2. ✅ **Diagram aktivit**

3. ✅ **Diagram stavový**

4. ✅ **Sekvenční diagram**

5. ✅ **Use Case**

TODO

## Př. Praktický lékař

IS pro evidenci pacientů u lékaře.

Lékař má evidované pacienty (jméno, příjmení, rodné číslo, pojišťovna)

Zaznamenává se historie přechodů pacienta, když změní pojišťovnu.

Pacient má zdravotní kartu.

Na zdravotní kartu se zaznamenávají návštěvy a jejich záznamy se verzují, protože záznam o návštěvě nezle editovat (vytvoří se revize záznamu). Záznam se může nacházet ve stavu „upravovaný“, „uzamčený“, „nahrazený novým záznamem“.

Návštěva zaznamenává diagnózu a úkony. Úkony mají cenu a číslo odbornosti. Číselník odbornosti i seznam diagnóz dodává hlavní pojišťovna.

Dále se na zdravotní kartu píší neschopenky a neschopenka má zadanou diagnozu.

Na zdravotní kartu se evidují předpisy na léky a každý předpis obsahuje maximálně dva léky s údaji o jejich dávkování.

Na zdravotní kartu se evidují provedená vyšetření. Existují speciální vyšetření jako měření tlaku (navíc má atributy systolický a diastolický tlak a tep) a speciální vyšetření jako sedimentace (navíc má atribut naměřené hodnoty).

Systém je nasazen na osobní počítač v ordinaci doktora. Data jsou uložena na témže stroji v databázi. Data z databáze jsou pravidelně zálohována na externí zařízení, na kterém běží komponenta pro synchronizaci dat. Nějaký data aplikace tahá ze serverů pojišťovny přes rozhraní SOAP.

### Zadání
1. Analytický doménový model
2. Diagram aktivit
3. Sekvenční diagram výpočtu vyúčtování pro jednu pojišťovnu za jeden měsíc (za předpokladu, že máme třídu AccountManager, která má metodu vratCastku(Pojistovna, mesic) a třídu Pojistovna, která má metody vratPocetPacientu(mesic) a vratVykony(mesic)).
4. Stavový diagram záznamu u doktora (stavy Rozpracovaný, Zamčemý, Nahrazený…)
5. Diagram nasazení za předpokladu, že systém běží pod .NET na PC u doktora, na stejném PC běží i databáze PostgreSQL. Data z DB se pravielně zálohují na externí zařízení NAS. Aplikace komunikuje se serverem pojišťovny, na kterém běží komponenta XYZ - komunikují přes protokol SOAP, komponenta pojišťovny nabízí rozhraní sendRequest.
6. Aspoň 5 UC, aspoň jedno «include» a «extend» + scénář jednoho netriviálního případu
7. Diagram komunikace
8. Navrhovy vzor State

### Řešení
(Některý věci jsou blbě: https://www.fit-wiki.cz/%C5%A1kola/p%C5%99edm%C4%9Bty/bi-zsi/zsi_zkouska_2013-1-15)

## ✅ Př. Fakultní anketa

Vytvoření systému pro správu anket o předmětech a jejich hodnocení studenty. Anketa je vytvořena správcem ankety, který do ní přidá předměty, kterých se bude týkat, a jednotlivé odpovědi.

U předmětů se eviduje jejich kód, název a popis.

Odpověď může být buď ve formě známky (1 - výborný, 2 - ucházející, 3 - špatný) nebo může odbsahovat i názor studenta ve formě textu. Po připravení je anketa postoupena garantovi ankety, který ji může otevřít studentům k vyplňování, nebo ji vrátí správci k přepracování.

Pokud je anktera otevřena, studenti se přihlásí svým uživatelským jménem a heslem a anketu vyplňují. Každý student může danou anketu vyplnit pouze jednou a za předpokladu, že má zapsané předměty kterých se anketa týká. Každá odpověď je evidována s ohledem na anonymitu, takže odpovědi nesmí být možné přiřadit ke konkrétnímu studentovi.

Systém každý den kontroluje, zda vypršel čas pro vyplnění ankety. Po vypršení časového limitu je anketa uzavřena a správce musí zkontrolovat, zda neobsahuje nevhodné komentáře.

Po provedení kontroly jsou výsledky ankety zveřejněny. Hodnocení jednotlivých předmětů se uchovává, aby bylo možné sledovat vliv změn ve výuce během doby běhu předmětu.

### Zadání
1. Vytvořte doménový model (10b)
2. Nakreslete stavový diagram ankety se všemi podmínkami a akcemi, které přechod spustí (8b)
3. Nakreslete diagram aktivit zachycující životní cyklus ankety a zahrňte do něj předešlý stavový diagram. Použijte swimlines (8b)
4. Nalezněte všechny účastníky a uveďte alespoň 5 případů užití (6b)
5. Aplikace má 3 komponenty - GUI, CORE, REST_API. GUI komunikuje s CORE pomocí rozhraní SpravaVysledku a SpravaAnkety. REST_API komunikuje s CORE pouze pomocí rozhraní SpravaVysledku. SpravaVysledku ma implementaci SpravaVysledkuImpl. Zachyťte výše uvedené informace ve formě UML diagramu. (8b)

### Řešení
1. ✅**Doménový model**

2. ✅**Stavový diagram**

3. ✅**Diagram aktivit**

4. ✅**Use Case**
Garant: vytvoření předmětu
Správce: vytvoření ankety, odstranění nevhodných komentářů, publikace ankety
Student: vyplnění ankety

5. ❓**Rozhraní a komponenty**

Nevím, jestli jsou ty čárky od GUI a od RestAPI správně - HonzaJ


## ✅Př. Internetový obchod

Internetový obchod nabízí různé druhy zboží (produktů). Každý produkt je charakterizován svým názvem a popisem. Cena každého produktu se v čase mění a je nutné sledovat aktuální hodnotu i vývoj této ceny v historii. V každém okamžiku může být platná pouze jedna cena, za kterou je produkt nabízen. Není možné prodávat současné jeden produkt za různé ceny.

Produkty jsou zařazeny do kategorií, které se odlišují svým názvem. Kategorie tvoří hierarchickou strukturu, takže jedna kategorie může obsahovat několik podkategorií. Každá kategorie však má maximálně jednu nadřazenou kategorii. Jeden produkt může být zařazen do více kategorii.

Zákazník internetového obchodu (u kterého evidujeme, jméno, příjmení, email a adresu) může přidávat jednotlivé produkty do košíku. Pro každou položku v košíku je nutné ukládat informace o množství (počet kusů produktu), které si zákazník přeje koupit a cenu za každý kus. Platnost košíku je 30 minut od posledního přidání nebo odebrání položky z košíku. Poté je obsah košíku vyprázdněn.

Když si zákazník vloží do košíku veškeré požadované zboží, může provést jeho objednávku. Je nutné zaznamenat datum vytvoření objednávky a také datum poslední změny objednávky. Pro každou objednanou položku je nutné udržovat informaci o její ceně v době vytvoření objednávky bez ohledu na cenu, za kterou se aktuálně zboží nabízí ostatním zákazníkům. Během vytváření objednávky si uživatel zvolí způsob úhrady (bankovním převodem nebo dobírkou) a následně musí potvrdit souhlas s vytvořenou objednávkou. Po potvrzení souhlasu je objednávka považována za vytvořenou a je zpracována pracovníkem obchodu. Jestliže uživatel zvolil bankovní převod jako typ platby, pak pracovník zašle zákazníkovi informace o požadované platbě, kterými jsou číslo účtu, kód banky, variabilní symbol a částka. Poté čeká objednávka 7 dní na příchod platby v požadované výši a s odpovídajícím variabilním symbolem. V případě, že v této lhůtě nedojde k uhrazení objednávky, je objednávka zrušena.

Když je objednávka uhrazena nebo byla zvolena platba dobírkou, pak je objednávka odeslána k doručení. Přepravní společnost je informována, o požadavku na převzetí zásilky přes integrovaný systém. K objednávce je nutné zaznamenat jednoznačný identifikátor doručovaného balíku. Ve chvíli, kdy si přepravní společnost zboží převezme, je v systému evidována objednávka jako doručovaná. Když doručovací společnost doručí balík zákazníkovi, zašle notifikaci do systému o jejím doručení. Jestliže zákazník není na uvedené adrese zastižen nebo nezaplatí za zboží (v případě dobírky), je balík vrácen přepravní společnosti zpět do internetového obchodu a objednávka je zrušena.

### Zadání
1. Analytický doménový model (10b)
2. Nakreslete diagram aktivit zachycující zpracování objednávky (pozn. od té chvíle co převezme zaměstnanec). Použijte swimlines (8b)
3. Nakreslete stavový diagram objednávky se všemi podmínkami a akcemi, které přechod spustí (8b)
4. Use case diagram, 6 use case dohromady pro min. 2 aktéry (8b)
5. Model nasazení. Aplikace e-shopu běží na centrálním serveru na PHP nad Apachem. Databáze na stejném stroji jako Apache na MySQL. Se servery dopravních společností komunikuje přes SOAP. Servery dopravních společností nabízejí rozhraní(?) kterým je e-shop notifikuje aby si vyzvedli objednávku. E-shop nabízí rozhraní(?) přes které je dopravní společnost notifikuje o dodání. (6b)

### Řešení
1. ✅**Doménový model**

2. ✅**Diagram aktivit**

3. ✅**Stavový diagram**

4. ✅**Use Case**

Zákazník:
- Vytvoření objednávky
- Přidání věci do košíku
- Zaplacení objednávky
- Zrušení objednávky

Dopravce:
- Převzetí balíku
- Oznámení o doručení balíku

5. ✅**Model nasazení**
Pozn. ty "Rozhraní" jsem neřešil :D - HonzaJ

## ✅ Př. Restaurace

Systém má sloužit restauraci. V restauraci jsou různé stoly s různou kapacitou. Zákazníci si mohou vytvořit rezervaci na konkrétní časové období a počet osob. Tuto rezervaci musí potvrdit obsluha restaurace a přiřadit konkrétní stůl s dostatečnou kapacitou. Pokud zákazník na domluvený čas nedorazí (a rezervaci nezruší), je jeho rezervace zrušena obsluhou s penalizací.

### Zadání
1. Vytvořte doménový diagram (20 b)
2. Vytvořte stavový diagram rezervace (20 b)

### Řešení
1. ❓ **Doménový diagram**

Fakt nevim, jestli to dělat takhle :D -HonzaJ


2. ✅**Stavový diagram**

## Př. tabor

Namodelujte systém pro podporu organizování letních táborů. Každý tábor musí mít určen datum zahájení, datum ukončení, místo konání, krátký popis a cenu, kteou musí každý účastník zaplatit. Jednotlivá místa, a kterých lze tábor uskutečnit, jsou evidována nezávisle na táborech a při zakládání nového tábora hlavní vedoucí určí, na kterém místě se bude konat. Systém musí kontrolovat, zda se na vybraném místě v této době nekoná již jiný tábor.
Každý tábor musí mít jednoho hlavního vedoucího tábora, který zodpovídá za celý průběh tábora. Dále má přiřazeny ostatní vedoucí, kteří pomáhají s organizováním činností, které budou na táboře probíhat. U každého vedoucího je evidováno jeho jméno, příjmení, email a přezdívka, které je v rámci systému jedinečná. Na jednoho vedouího může připadnout maximálně 5 přihlášených účastníků na tábor. U každého účastníka je nutné evidovat jeho jméno, příjmení, rodné číslo, datum narození, telefon nebo email, pohlaví a zákonného zástupce v případě, že nemá občanský průkaz. U každého zákonného zástupce musí být evidovány stejné údaje jako u účastníků. Jedna osoba může být zákonným zástupcem několika účastníků. Zákonný zástupce může být také účastníkem tábora.
Systém musí umožňovat přihlašování jednotlivých účastníků přímo z domova z jejich počítačů. Je-li účastník systému již registrován, není nutné při podávání přihlášky na tábor, zadávat žádné další údaje. Stačí pouze vybrat tábor, kterého se chce zúčastnit. Po dokončení vyplňování žádosti a potvrzení souhlasu se zpracováním jeho údajů, dojde k provedení kontroly systémem. Pokud všechny kontroly projdou v pořádku, pak dojde k závaznému přihlášení a systém musí účastníkovi zobrazit příkaz k úhradě, který bude obsahovat číslo účtu a kód banky konkrétního tábora, dále variabilní symbol, který odpovídá rodnému číslu účastníka. V rámci kontrol systém kontroluje, zda je na tábor přiřazeno dostatečné množství vedoucích a není překročena maximální kapacita lůžek tábora. Pokud není kapacita dostatečná, pak se uživatel může rozhodnout, zda chce přihlášení a přesto dokončit. V případě, že ano tak zůstává přihláška nadále evidována (čeká na uvolní kapacity). Pokud ne je přihláška zrušena (zůstává však nadále evidována). Pokud dojde k navýšení kapacity lůžek (které může provádět pouze hlavní vedoucí) a přihlášení dalších vedoucích jsou automaticky informování účastníci, kteří si přihlášku podali a kterým nebylo vyhověno. Součástí informace je i příkaz k úhradě, který má účastník zaplatil. Informace se zasílá pouze tolika čekajícím, kolik volných míst se uvolnilo. Nedojde li platba na táborový účet do 10 dnů od závažné ho přihlášení na tábor, je přihláška automaticky zrušena zůstává však nadále evidována. Přihlášky čekající na uvolnění kapacit jsou automaticky zrušeny v den zahájení tábora.
Součástí každého tábora musí být evidována ubytovací zařízení, ve kterých budou účastníci bydlet. Ubytovacím zařízením může být stan, stan s podsadou nebo chatka. Každý ubytovací zařízení má uveden počet lůžek. V případě chatky je počet lůžek dán součtem počtu lůžek na jednotlivých pokojích. Při závazném přihlášení je vždy účastník automaticky přiřazen na konkrétní ubytovací zařízení. Přednostně jsou obsazovány ubytovací zařízení, které jsou již částečně obsažena. Na jednom ubytovacím zařízení nemůžou být ubytováni účastníci různých pohlaví.

1. Analyticky domenovy model (10b)
2. Diagram aktivit se swimlanes uzivatele pri podani zadosti (8b)
3. Sekvencni diagram na metodu vratCelkovouKapacitu s ohledem na jednotlive typu ubyt. zarizeni (stan a chatka zvlast dohromady)
4. Sekvenční diagram - výpočet celkového počtu lůžek (8b)
5. Use case model - 5 případů, použití `extend` a `include`, popsat slovne jak probiha pripad uziti prihlasit ucastnika na tabor (8b)
6. Stavovy diagram zadosti o prihlaseni
7. Stavový diagram - stavy ubytovacího zařízení (8b)

## Př. Vláda

![[Pasted image 20220509101955.png]]

1. Doménový model (10b)
2. Diagram aktivit při vyzvedávání léků v lékárně. Nezapomenout na autorizace uživatele (kartou, heslem?) (8b)
3. Stavový diagram předpisu, v případě že existuje alternativní lék, toto brát jako speciální stav. (8b)
4. Napsat 5 případů užití, alespoň jednou include a extends, jeden ze scénářů rozepsat. (7b)
5. Diagram nasazení. Systém běží jako webová aplikace na Oracle Application Serveru. Ten je fyzicky oddělen od databáze Oracle Database 11g. Na počítači ve zdravotnickém zařízení běží extra software, ten umí komunikovat se čtečkou karet, která je k tomuto PC připojená, přes RS485. Program pak komunikuje s aplikací na serveru přes IPSec. Uživatel pak může v prohlížeči zobrazovat z aplikace nějaký info. (7b)

## Př. Zahrádkářský splek

### Originál Zadání
Záhradkársky spolok je rozdelený na parcely eviduje sa rozloha a majiteľ, ktorý musí byť členom záhradkárskeho spolku a myslím že sa evidovala aj história majiteľov odkedy dokedy. Na parcele sú objekty, každý objekt má elektrickú prípojku. Elektrická prípojka bude pripojená elektrikárom po podaní žiadosti o pripojenie, prípojka prejde do stavu čaká na pripojenie. Ak sa elektrikár nevie k prípojke dostať zmení stav na nedostupná alebo niečo také, potom majiteľ musí problém odstrániť a zmeniť stav na problém odstránený a proces sa opakuje, ak sa elektrikárovi prípojku podarí pripojiť je prípojka pripojená. Elektrikár následne spraví odpočet z čoho cez aplikáciu vypočíta výšku poplatku. Pri poplatku sa eviduje výška poplatku, odpočty na ktoré sa poplatok vzťahuje (teda počiatočný a koncový odpočet) a dátum splatnosti. Poplatok musí byť do dátumu splatnosti uhradený na bankové konto záhradkárskeho spolku. Administratívny pracovník kontroluje bankové konto ak poplatok nie je uhradený do dátumu splatnosti pošle majiteľovi upozornenie, ak poplatok nie je uhradený ani do mesiaca od odoslania upozornenia, elektrikár prípojku odpojí. Ak chce majiteľ prípojku zase zapojiť musí zaplatiť poplatok a podať žiadosť o pripojenie.

### Zadání v češtině (google překladač)
Zahrádkářský spolek je rozdělen na parcely eviduje se rozloha a majitel, který musí být členem zahrádkářského spolku a myslím že se evidovala i historie majitelů odkdy dokdy. Na parcele jsou objekty, každý objekt má elektrickou přípojku. Elektrická přípojka bude připojena elektrikářem po podání žádosti o připojení, přípojka přejde do stavu čeká na připojení. Pokud se elektrikář neumí k přípojce dostat změní stav na nedostupná nebo něco takového, pak majitel musí problém odstranit a změnit stav na problém odstraněn a proces se opakuje, pokud se elektrikáři přípojku podaří připojit je přípojka připojena. Elektrikář následně provede odpočet z čehož přes aplikaci vypočítá výši poplatku. Při poplatku se eviduje výše poplatku, odpočty na které se poplatek vztahuje (tedy počáteční a koncový odpočet) a datum splatnosti. Poplatek musí být do data splatnosti uhrazen na bankovní konto zahrádkářského spolku. Administrativní pracovník kontroluje bankovní konto, pokud poplatek není uhrazen do data splatnosti, pošle majiteli upozornění, pokud poplatek není uhrazen ani do měsíce od odeslání upozornění, elektrikář přípojku odpojí. Pokud chce majitel přípojku zase zapojit musí zaplatit poplatek a podat žádost o připojení.

### Zkouška 1

1. Doménový model
2. Diagram aktivit, swimlines
3. Stavový diagram elektrickej prípojky
4. Diagram nasazení, nepamätám si presne ale je to na servery Glassfish, služba beží na Jave a komunikuje s DB(fyzicky oddelená) cez niečo, elektrikár pristupuje do služby pomocou aplikácie prípojka na OS Android a klienti so službou komunikujú cez web browser
5. 6 Use case diagramov pre 3 rôzne osoby, pre každú osobu 2 diagramy, zložitejšie diagramy netreba kresliť stačí napísať scenár (neviem čo presne mysleli pod zložitejším, keďže use case diagramy sú pomerne jednoduché, asi mysleli tie opakujúce sa časti i guess, nevšimol som si požiadavky na include a extend)

### Zkouška 2
- 1) Nakreslit doménový model tříd. (10b) Není dobrý nápad zde začínat, protože to se dá kreslit celý čas písemky a stejně nebudete hotovi.

- 2) Nakreslit diagram aktivit, kdo za co zodpovídá (5b)

- 3) Nakreslit diagram stavů přípojky, včetně toho na základě čeho ke změnám dochází (5b)

- 4) Nakreslit diagram nasazení, s tím že databáze běží na serveru, běžný uživatel se připojuje přes webové rozhraní a servisní technik přes speciální aplikaci. (5b)

- 5) Nakreslit usecase diagram s alespoň sedmi příklady užití, použít „includes“ a „extends“ vazbu.

- 6) Samostatné zadání - knihovna půjčuje knihy, limit je deset knih na osobu, pokud knihu nevrátíte včas, dostanete na rok penalizaci snížení povoleného počtu výpůjček o 1 (od data kdy se kniha měla vrátit) - Namodelujte tuto podmínku v OCL (5b)

- 7) Teoretická otázka - Jaké „něco - kdo si pamatuje doplňte - modely?“ jsou definovány v rámci OMG. Něco ve smyslu modely MDA (5b)

### Zkouška 3
- 1) Nakreslit doménový model tříd. (10b) Není dobrý nápad zde začínat, protože to se dá kreslit celý čas písemky a stejně nebudete hotovi.

- 2) Nakreslit diagram aktivit, kdo za co zodpovídá (5b)

- 3) Nakreslit diagram stavů přípojky, včetně toho na základě čeho ke změnám dochází (5b)

- 4) Nakreslit diagram nasazení, s tím že databáze běží na serveru, běžný uživatel se připojuje přes webové rozhraní a servisní technik přes speciální aplikaci. (5b)

- 5) Nakreslit usecase diagram s alespoň sedmi příklady užití, použít „includes“ a „extends“ vazbu.

- 6) Samostatné zadání - knihovna půjčuje knihy, limit je deset knih na osobu, pokud knihu nevrátíte včas, dostanete na rok penalizaci snížení povoleného počtu výpůjček o 1 (od data kdy se kniha měla vrátit) - Namodelujte tuto podmínku v OCL (5b)

- 7) Teoretická otázka - Jaké „něco - kdo si pamatuje doplňte - modely?“ jsou definovány v rámci OMG. Něco ve smyslu modely MDA (5b)

## Př. Zdravotnická zařízení

V různých zdravotnických zařízeních jsou zařízení (přístroje), která vyžadují pravidelnou revizi. Datum další revize je evidováno u každého zařízení. Četnost revizí je dána typem zařízení. Nové zařízení vždy vyžaduje nejprve revizi, kterou provádí technik společnosti a eviduje do systému. Zařízení s platnou revizí jsou měsíc před koncem platnosti označena k revizi, aby jejich kontrolu technik naplánoval. Pokud se revize nestihne, je revize propadlá. Pokud zařízení projde revizí, nastaví se datum další revize na termín dle typu zařízení. Pokud neprojde, je třeba zařízení s neplatnou revizí opravit, než jej lze opět používat.

Zkouška 1
1. Vytvořte doménový model systému. (20b)
2. Vytvořte stavový model pro zařízení. (20b)
3. Popište alespoň 3 případy užití a jejich aktéry. (10b)

Zkouška 2
1. Doménový model 12b
2. Business diagram - práce technika za jeden den 10b
3. Stavový diagram - stavy ve kterých se může vyskytnou přístroj 8b
4. Sekvenční diagram - technik chce zjistit seznam návštěv, co musí ten den udělat 10b

Zkouška 3
1. Doménový model
2. Business diagram - práce technika za jeden den
3. Stavový diagram - stavy ve kterých se může vyskytnou přístroj
4. Sekvenční diagram - technik chce zjistit seznam návštěv, co musí ten den udělat
5. 5 Use case - (technik, zákazník a _systém_ - co dělá automaticky se muselo napsat) + jeden detailní scénář

## Teoretické otázky, co byly u zkoušky
- Unified process - 4 fáze (pouze vyjmenovat, není potřeba popis) (4b)
- Co je to Liskov substitution principle? (6b)
- Vyjmenujte fáze projektu dle metodiky SCRUM. Popište typické činnosti vykonávané v jednotlivých fázích. (6b)
- Popište REST technologii používanou pro integraci aplikací. (4b)
- Možnosti poskytované Subversion-SVN ke správě verzovaného kódu. Jejich výhody a nevýhody (6b)
- Popište MVC (4b)
- FURPS - popsat co ta zkratka znamená + ke každému říct nějaký konkrétní příklad
- GRASP + Nízká provázanost + Vysoká soudružnost - vysvětlit, o co se jedná
- SCRUM fáze - popsat ty tři fáze (předehra, dohra, hra)
- Co je to REST
- Modely MDA(CIM,PIM,PSM,ISM) a ke každému poznámku.
- Polymorfismus tabulek ABC.
- Popsat, jakými způsoby lze v doménovém modelu implementovat dědičnost (1, 2 nebo 3 tabulky).
- Popište metody MDA a u každé zkratky popište, o co se jedná.
- Aspoň 6 věcí o extrémním programování
- Aspoň 4 věci, které odhalí statická analýza kódu.
- co je to Prubezna integrace (4b)
- popis state designe patternu a jeden priklad (6b)
- Zpusoby provadeni testu na zaklade znalosti SW
- Vse o agilni metodice SCRUM
- integrační vzory a jejich popis (4b)
- Co je to FURPS, u každého napsat příklad co to znamená. (5b)
- Popis design patternu State, konkrétní příklad. (5b)