Cílem semestrální práce je ověřit znalosti nabyté v rámci přednášek a cvičení, a umožnit studentům vyzkoušet si práci na větším projektu v Javě. Semestrální práci je možno vykonávat samostatně či ve dvojicích, větší skupiny nejsou dovoleny. Při práci ve dvojici se předpokládá, že rozsah celé práce bude větší než při samostatné práci. Studenti v týmu mohou být z různých paralelek - v tom případě se ale domluví s oběma cvičícími, u kterého z nich budou práci odevzdávat.
Téma semestrální práce si můžete určit sami, a pro formalizaci zadání je určen první checkpoint (viz níže); případně si můžete vybrat jedno z předpřipravených témat níže. V tom případě se však očekává, že dané zadání “obohatíte” o vlastní netriviální funkcionalitu. Předpřipravená zadání vám také mohou sloužit jako vodítko pro vlastní téma, abyste stanovili dostatečný rozsah práce. Rozsah bude případně korigován vašim cvičícím v jednotlivých checkpointech.
Nehledě na vybrané téma musí každá odevzdaná práce splňovat následující požadavky:
Timer). Například vytvořením hodin reálného času, které interagují s průběhem hry. Jelikož se jedná o aplikaci JavaFX, doporučuji používat třídy Task nebo Service namísto Thread.
public prvky v programu musí mít smysluplný Javadoc (v kódu, není třeba generovat dokument). Za triviální se považují například jednoduché gettery a settery bez vedlejších efektů.
V případě nesplnění některého z požadavků bude práce výrazně penalizována či vrácena studentovi k dopracování.
Průběžná práce a samotné odevzdání semestrálních prací probíhá ve třech “Checkpointech”, a to vždy v GitLab projektu, který vám byl automaticky založen na začátku semestru, a který naleznete na adrese https://gitlab.fel.cvut.cz/B252_B0B36PJV/username - tedy např. https://gitlab.fel.cvut.cz/B252_B0B36PJV/novakjan. Jednotlivé checkpointy zároveň vždy nahrajte i pod patřičný upload do BRUTE.
Cílem tohoto odevzdání je formalizovat zadání, na kterém budete dále pracovat. Zadání bude odevzdáno ve formě PDF dokumentu (případně wiki stránce ve vašem GitLab projektu) o rozsahu ~2x A4, ve kterém je popsáno kompletní fungování aplikace z pohledu uživatele, a který by měl obsahovat:
V této fázi byste tedy měli mít podrobně vymyšlený celý projekt, a mělo by stačit se pustit do programování. Pro inspiraci si můžete prohlédnout, jak by měla vypadat správně odevzdaná vize projektu, a jak naopak špatná (vč. komentářů, co je na dokumentu špatně).
Cvičící bude hodnotit podrobnost dokumentu, jeho formu i rozsah celé práce.
V rámci druhého checkpointu připravíte ve svém repozitáři (a odevzdáte pod patřičný upload do BRUTE):
Po tomto odevzdání by se základní struktura kódu neměla výrazně lišit, a mělo by stačit pouze doimplementovat předpřipravené třídy.
Poslední checkpoint je zaměřen nejen na dokončení celého projektu dle zadání z CP1, ale i finální prezentaci, jejíž formu vám sdělí cvičící na hodině.
Součástí odevzdání je i uživatelská dokumentace, která může být formou uživatelského manuálu, a která zahrnuje všechny podstatné aspekty aplikace (včetně jejího spuštění!). Inspirací vám může být například tato příručka pro hru FlatOut UC.
Dokončena by měla být i technická dokumentace, obohacena o dokumentaci ve formátu JavaDoc (není třeba generovat HTML formu!). Pokud bude použita komunikace po síti, doporučuje se specifikovat komunikační protokol - tedy jaká data a v jakém formátu se budou mezi serverem a klientem posílat.
Jiný termín odevzdání je možný pouze ve výjimečných případech (nemoc, apod.) a po předchozí domluvě s cvičícím minimálně týden před oficiálním deadlinem!
Za semestrální práci vám může být uděleno maximálně 45 bodů; minimálně však musíte získat:
Práce jsou hodnoceny dle následující tabulky:
| Položka | Max bodů | Poznámka | |
|---|---|---|---|
| CP1 | Vize projektu | 5 | 5b = jasně a podrobně popsaná vize projektu 4–3b = mírné nejasnosti v částech popisu 2–1b = výrazné nejasnosti v částech popisu či chybějící popis mechanik 0b = příliš obecný popis, chybějící odevzdání |
| CP2 | Objektový návrh | 7 | 7b = jasný a podrobný objektový návrh 6–4b = mírné nejasnosti/chyby v částech návrhu 3–1b = výrazné nejasnosti/chyby v částech návrhu či chybějící vlastnosti/vazby 0b = návrh bez vlastností/vazeb, chybějící odevzdání |
| CP3 | Rozsah implementace | 10 | Plný počet za implementaci všech funkcí uvedených v zadání až -2b za každou chybějící či nefunkční funkcionalitu |
| Kvalita kódu | 10 | Plný počet za vhodně navržený datový model, minimum duplicitního kódu a snadnou rozšířitelnost až -4b za nevhodnou strukturu tříd a metod až -3b za neduhy v datovém modelu až -3b za nečitelnost kódu (příliš dlouhé metody, jména proměnných apod.) |
|
| Funkčnost | 5 | Plný počet za korektní chování programu v běžných i hraničních případech -2b za každý neošetřený “edge-case”, spadnutí programu apod. |
|
| Dokumentace | 5 | až 2.5b za uživatelskou dokumentaci (instalace, návod k použití apod.) až 2.5b za technickou dokumentaci (diagramy, popis architektury, JavaDoc v kódu) |
|
| Správné použití GITu | 3 | 3–2b = vhodné používání větví, merge requestů, issues apod. 1b = základní práce s GITem (řádná velikost/pravidelnost commitů) 0b = neprokazatelná historie (moc málo/moc velké commity) |
|
| Celkem bodů | 45 | ||
Pozdní odevzdání každého z “checkpointů” je penalizováno 1b za každých započatých 72h.