===== Semestrální práce =====
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.
==== Zadání ====
Vyberte si jedno z následujících zadání:
* [[courses:b6b36omo:sem:smart_home|🏠 Smart Home]]
* [[courses:b6b36omo:sem:smart_factory|👷 Smart Factory]]
* [[courses:b6b36omo:sem:food_chain|🍅 Food Chain]]
* [[courses:b6b36omo:sem:dependency_injection|🛠 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.
/*
* {{ :courses:b6b36omo:hw:projekt_smart_home_v2.docx |}}
* {{ :courses:b6b36omo:hw:projekt_smart_factory_v2.docx |}}
* {{ :courses:b6b36omo:hw:projekt_food_chain_v2.docx |}}
* {{ :courses:b6b36omo:hw:projekt_dependency_injection_framework.docx |}}
* https://docs.google.com/document/d/1QetIqo90p9-_umDb5f06Rxg5wgOTNV-Z8i5guKnYCpo/edit?usp=sharing
*/
==== Termíny ====
**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ář.
==== Hodnocení ====
* 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 [[courses:b6b36omo:start|hlavní stránka]]).
=== Základní hodnocení ===
^ Položka ^ Maximum bodů ^ Poznámka ^
^ Rozsah implementace | 6 | Propracovanost aplikace, ošetření edge-casů apod. - na posouzení cvičícím |
^ Počet implementovaných design patternů | 5 | počet bodů = počet patternů - 3\\ (tj. pro 5 patternů 2 body apod.) |
^ Správnost použití design patternů | 4 | správná implementace vybraných patternu |
^ Vhodnost použití design patternů | 3 | nepoužití patternů "na sílu" |
^ Čistota kódu | 2 | Čitelnost a udržitelnost zdrojového kódu |
^ Správné použití GITu a coding konvencí | 2 | |
^ Dokumentace | 3 | Uživatelská (jak se aplikace používá apod.) i technická (diagramy, JavaDoc v kódu) |
^ Celkem bodů ^ 25 | |
=== Bonusy a penalizace ===
^ Položka ^ Počet bodů ^ Poznámka ^
^ Implementace bonusového požadavku | až +2 body za každý | dle náročnosti implementace |
^ Chybějící povinný požadavek | až -3 body za každý | dle náročnosti implementace |
^ Funkcionální programování | až +2 body | Použití Stream API, FUP design patternů apod. |
^ Přidané funkcionality nad rámec práce | až +4 bodů | výrazná aktivita a ochota studenta nad rámec zadání |
^ Pozdní odevzdání | -1 bod za každý týden po termínu | |
/*
* Aktuální hodnotící tabulka: https://docs.google.com/spreadsheets/d/1i3d6iiUiubS6MyhwksFV4zR4YdFMqlNn7nJglOKXdV8/edit#gid=0
* Čistota softwarového designu aplikace, použití design patternů (50%)
* Množství naimplementovaných funkčních požadavků (50%)
* Vlastní inovace - nový funkční požadavek, který jste přidali nebo zajímavý softwarový design (5%)
*/
==== Hinty ====
- 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).
- 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/
- Rozpracovanou verzi Use case diagramu a Class diagramu si nechte zrevidovat cvičícím
- 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.
- 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 ...