• Zadání domácích úkolů naleznete níže.
• Odevzdání řešení úkolů je termínováno, pro odevzdávání používejte system BRUTE: https://cw.felk.cvut.cz/brute/
• Pro odevzdání semestrálních prací pouzijte GitLab.
• Je potřeba odevzdat všechny 4 domácí úlohy.
• 1. domácí úloha se neboduje, ostatní 3 jsou ohodnoceny každá 5 body pokud ji odevzdáte včas

Zádání domácích úkolů: první, druhý, třetí, čtvrtý.

Pokud není řešeno jinak nebo to nevyplývá z kontextu tak, metodami se rozumí instanční metody, můžete definovat svoje pomocné atributy a metody a všechny vámi implementované neabstraktní třídy by měly mít konstruktor bez parametrů.

Hodnocení

• 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%)

Logistika

Úloha se vypracovává ve dvou studentech (ze stejného cvičení), 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 v gitu). 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í je do konce semestru. Ideálně před vánoci, maximálně konec semestru. Minimálně tři týdny před finálním odevzdáním je potřeba cvičícímu zaslat design vaší aplikace. Pokud by byl design špatný, došlo k odchýlení od zadání nebo naopak budete chtít poradit, tak bude konzultace provedena na cvičení, případně mimo cvičení po dohodě s cvičícím.

Zadání

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

• projekt_smart_home_v2.docx
• projekt_smart_factory_v2.docx
• projekt_food_chain_v2.docx
• projekt_dependency_injection_framework.docx
• https://docs.google.com/document/d/1QetIqo90p9-_umDb5f06Rxg5wgOTNV-Z8i5guKnYCpo/edit?usp=sharing

Hinty

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 …