Cílem semestrální práce je vypracovat ve dvojici studentů (ze stejného cvičení) návrh a následnou implementaci komplexního systému, řešícího zadaný problém, vč. příkladné konfigurace (viz sekce zadání), přičemž je požadováno, aby každá osoba napsala přibližně stejně komplexní část aplikace a rozuměla i částem, které nepsala (bude kontrolováno). Semestrální úloha může být znovu otevřena u zkoušky. Skupiny po třech jsou výjimkou, kterou musí explicitně schválit cvičící, přičemž hodnocení bude přísnější.

Odevzdání probíhá formou třech samostatných odevzdání; přímo hodnoceno je pouze finální odevzdání, ostatní jsou však povinná a pomáhají cvičícímu utvořit si na vaši skupinu názor - mají tak vliv na výsledné hodnocení! 😉

Finální odevzdání je do začátku zkouškového, ideálně však před Vánoci.

Vyberte si jedno z následujících zadání:

• 🏠 Smart Home
• 👷 Smart Factory
• 🍅 Food Chain
• 🛠 Dependency Injection Framework

Po domluvě se cvičícím je možné navrhnout vlastní téma, které složitostí odpovídá výše uvedeným.

SW1 - konec 4. týdne

• Cílem je vytvořit dvojici a vybrat si téma SP.
• Co odevzdat:
  • Odevzdávejte TXT soubor, kde napíšete vybrané téma. Pokud vybíráte z předpřipravených, stačí napsat název; pokud vymýšlíte vlastní, je třeba jej podrobně rozepsat.
• Formát:
  • TXT soubor

SW2 - konec 9. týdne

• Zde již budete pracovat ve dvojici a vaším cílem je vytvořit návrh vaší SP.
• Co odevzdat:
  • Class diagram
  • Popis funkcionalit (stačí jako systémové požadavky s detailnějším popisem)
  • Výběr patternů a volitelně jejich diagramy pro řešení jednotlivých funkcí.
• Formát:
  • ZIP soubory (ideálně s PDF, kde bude celá dokumentace a současně i jednotlivé zdrojové soubory)

SW3 - konec 14. týdne

• Finální odevzdání semestrální práce.
• Co odevzdat:
  • Zdrojové kódy
  • Analýza
  • Popis aplikace
  • Spuštění
• Formát:
  • TXT soubor, kde bude odkaz na git repozitář.

• Za semestrální práci vám může být uděleno maximálně 25 bodů.
• Pro obdržení zápočtu není určené minimum; pouze za součet úkoly + semestrální práce (viz hlavní stránka).

1. Namodelujte use case diagram. Umožní vám identifikovat jací actors interagují v systém a jaké interakce provádí. Příklady zde: https://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html, https://stackoverflow.com/questions/53024593/using-printers-as-actors-in-use-case-diagram. Uvědomte si,že actor bude i fyzické zařízení. Odprostěte se od toho, že úlohu spouštíte jako simulaci reálného systému - use case diagram modelujte pro ten systém, který simulujete a ne pro tu simulaci. Aby v diagramu nebyl jeden actor (žák) a jeden use case (spuštění simulace).
2. Namodeluje první verzi class diagramu - zaměřte se na klíčové entity, neřešte jejich atributy. V další iteraci přidejte vazby, jejich kardinality. Postupně přidáváte i méně důležité entity a klíčové atributy v entitách. Dále pak klíčové služby (funkcionality) a jejich rozhraní. Příklady zde: https://www.researchgate.net/figure/Domain-model-for-Earth-Observation-UML-Class-diagram_fig2_268807373, https://cz.pinterest.com/pin/781444972817861095/
3. Rozpracovanou verzi Use case diagramu a Class diagramu si nechte zrevidovat cvičícím
4. Zamyslete se kde by se daly aplikovat jaké design patterny. Obvykle se postupuje obráceně, že nejdříve identifikujete problém a pak při hledání řešení se snažíte známé problémy řešit známým design patternem. Tedy cílem návrhu není obvykle snažit se “udat” za každou cenu design patterny, alt tady tomu půjdeme trochu naproti.
5. Simulaci neřešte pomocí více paralelních threadů, kde by thread např. reprezentoval konkrétní stroj. Problém se dá vyřešit sekvenčně v jednom threadu tím, že v každém “taktu” - diskrétní periodě reprezentující např. 10 minut - provedete po sobě změny na všech entitách a aplikujete reakce na tyto změny. Pak přecházíte k dalšímu taktu …