Projekt

Zámer projektu

Daná je nasledujúca rámcová téma:

Plánovanie ciest

Cesty môžu predstavovať veľmi zložité podujatia, ktoré naozaj môžu mať prospech zo softvérovej podpory. Často zahŕňajú odbočky za účelom navštívenia zaujímavých miest v blízkosti hlavnej trasy. Rôzne služby a udalosti môžu byť ponúkané na týchto miestach. Tieto miesta môžu byť odporúčané na základe potrieb a ohraničení cestujúceho. Počas cesty sa pôvodný plán môže zmeniť. Cestovanie v skupine môže zahŕňať synchronizáciu odbočiek. Či plán cesty vytvoril profesionál alebo samotní cestujúci, môže byť hodný zdieľania s ostatnými.

Vypracujte zámer projektu vývoja softvérového systému, ktorý patrí do oblastí definovanej rámcovou témou. Sústreďte sa na vybraný aspekt (netreba pokryť všetko). Projektu dajte vlastný a výstižný názov. Prípustný je len text v rozsahu do 200 slov – iná forma nemusí byť akceptovaná a môže byť slabšie hodnotená. Zámer projektu musí zodpovedať rámcovej téme, ale nemá ju opakovať.

Aj keď zámer projektu má byť sformulovaný aplikačne, z používateľského hľadiska – t. j. nemali by ste v ňom používať termíny z domény riešenia (objekt, trieda a pod.) – myslite na to ako v projekte využijete objektovo-orientované vlastnosti Javy. Vytvorte si na to dostatočný priestor. Nebojte sa formulovať zámer projektu aj širšie – to neznamená, že všetko budete musieť implementovať.

V programe, ktorý budete tvoriť podľa vášho zámeru, nebude potrebné riešiť sieťové záležitosti alebo súčasné používanie viacerými používateľmi (napr. reálnu komunikáciu viacerých používateľov cez sieť). Tieto činnosti stačí napodobniť (napr. dá sa prihlásiť ako jeden používateľ, a potom ako druhý). Rovnako nie je potrebné riešiť ani bezpečnosť. Sústreďte sa na objektovo-orientovanú modularizáciu.

Zámer projektu ozrejmite iniciálnym diagramom tried (tejto časti sa budete môcť venovať po prvých dvoch prednáškach). Aby ste sa dopracovali k diagramu tried, nakreslite najprv (pre seba) diagram objektov typickej situácie v predpokladanom systéme. Následne ich zovšeobecnite do diagramu tried. Sústreďte sa na niekoľko najdôležitejších objektov a následne ich zovšeobecnite do tried, medzi ktorými určíte najmä vzťahy asociácie (všeobecného súvisu) a dedenia. V triedach identifikujte niekoľko dôležitých atribútov a metód. S jednoduchým a flexibilným nástrojom na kreslenie diagramov sa oboznámite na cvičení 3, ale diagram môže byť nakreslený v čomkoľvek (akceptovateľný je aj sken diagramu nakresleného na papieri).

Svoj zámer včas konzultujte s vyučujúcim na cvičeniach.

Odovzdáva sa: text a diagram vo formáte PDF do AISu

Hodnotenie

Aby zámer projektu mohol byť hodnotený nenulovým počtom bodov, musia byť splnené nasledujúce podmienky:

1. Zámer projektu musí zodpovedať rámcovej téme.
2. Projekt musí mať vlastný názov.
3. Text musí byť sformulovaný zrozumiteľne a v plnohodnotných vetách.

Spôsob hodnotenia je nasledujúci:

• prehľadný a jasný zámer projektu s adekvátnym vlastným názvom projektu, s jasným diagramom tried – 5 b
• prevažne prehľadný a jasný zámer projektu alebo menej adekvátny názov projektu, s menej jasným diagramom tried – 3–4 b
• málo prehľadný, avšak stále akceptovateľný zámer projektu, s nejasným diagramom tried alebo bez diagramu tried – 0–2 b

Pracovná verzia programu

V organizácii práce na projekte vám pomôžu špeciálne úlohy na cvičeniach. Tieto úlohy budú zaradené od tretieho cvičenia. Pri realizácii projektu využite možnosť konzultácií s vyučujúcimi na cvičeniach.

Počas realizácie projektu by mali vzniknúť viaceré pracovné verzie programu. Na ich správu používajte systém GitHub (pokyny na registráciu dostanete). Progres na projekte prezentujte vyučujúcemu na cvičeniach.

Nevyhnutné je, aby ste do termínu odovzdania pracovnej verzie programu odovzdali aspoň jednu funkčnú pracovnú verziu programu pokrývajúcu významnú časť zadania a zámeru projektu.

Najneskôr na 7. alebo 8. cvičení – podľa toho, ako určí vyučujúci – prezentujete svoj program. Pracovná verzia programu tvorí významnú zložku hodnotenia programu. Preto využite možnosť prezentovať pracovnú verziu programu skôr, aby ste sa skôr dozvedeli, čo v programe máte opraviť a zlepšiť.

Odovzdáva sa: program (zdrojový kód) do GitHub classroomu vytvoreného pre tento predmet

• odovzdávajte výlučne do hlavnej vetvy (master branch) – spravte merge (skript na sťahovanie projektov iné nevyzbiera)
• nezabudnite si v GitHube nastaviť meno a priezvisko (Settings/Profile/Name)

Hodnotenie

Aby pracovná verzia programu mohla byť hodnotená nenulovým počtom bodov, musia byť splnené nasledujúce podmienky:

1. Program musí byť funkčný a pokrývať principiálne časti zadania a zámeru projektu.
2. Odovzdaný zdrojový kód musí zahŕňať všetky potrebné súbory a musí sa dať preložiť v prostredí Eclipse inštalovanom v učebni, v ktorej sa realizujú cvičenia.
3. Program bol aspoň raz uspokojivo prezentovaný vyučujúcemu na cvičeniach.

Spôsob hodnotenia je nasledujúci:

• program pokrývajúci významnú časť zadania a zámeru projektu, ako aj pokyny vyučujúceho, s adekvátne použitým dedením, polymorfizmom a agregáciou; oddelenie aplikačnej logiky od používateľského rozhrania – 9–10 b
• program pokrývajúci významnú časť zadania a zámeru projektu, ako aj pokyny vyučujúceho, s menej adekvátne použitým dedením, polymorfizmom a agregáciou – 7–8 b
• program aspoň spolovice pokrývajúci zadanie a zámer projektu, ako aj pokyny vyučujúceho – 5–6 b
• slabší program, ale ešte stále na akceptovateľnej úrovni a principiálne v súlade so zadaním a zámerom projektu – 0–4 b

Program a dokumentácia

Jadrom projektu je objektovo-orientovaný program v programovacom jazyku Java vypracovaný podľa zadania.

Program sprevádza dokumentácia, ktorá pozostáva z dvoch časti:

• správa o realizácii projektu
• Javadoc dokumentácia

V správe o realizácii projektu krátko (na niekoľkých stranách) informujete o svojom projekte. V správe uveďte:

Hlavnými kritériami pri hodnotení projektu sú miera splnenia zadania, uplatnenie objektovo-orientovaných mechanizmov v programe (predovšetkým vhodné využitie dedenia, polymorfizmu, zapuzdrenia a agregácie), organizácia kódu a kvalita dokumentácie.

Ďalšie kritériá zahŕňajú:

• použitie návrhových vzorov okrem návrhového vzoru Singleton – každý implementovaný návrhový vzor sa počíta ako splnenie jedného ďalšieho kritériá, ale implementácia všetkých návrhových vzorov sa posudzuje maximálne na úrovni splnenia troch ďalších kritérií
• ošetrenie mimoriadnych stavov prostredníctvom vlastných výnimiek – stačí jedna vlastná výnimka, ale musí byť skutočne vyhadzovaná a ošetrovaná
• poskytnutie grafického používateľského rozhrania oddelene od aplikačnej logiky a s aspoň časťou spracovateľov udalostí (handlers) vytvorenou manuálne – počíta sa ako splnenie dvoch ďalších kritérií
• explicitné použitie viacniťovosti (multithreading) – spustenie vlastnej nite priamo alebo prostredníctvom API vyššej úrovne (trieda Task a pod.)
• použitie generickosti vo vlastných triedach – implementácia a použitie vlastnej generickej triedy (ako v príklade spájaného zoznamu poskytnutého k prednáške 5)
• explicitné použitie RTTI – napr. na zistenie typu objektu alebo vytvorenie objektu príslušného typu (ako v hre s obrami a rytiermi pri zisťovaní počtu bytostí)
• použitie vhniezdených tried a rozhraní – počíta sa iba použitie v aplikačnej logike, nie v GUI, pričom rozhrania musia byť vlastné (jedna možnosť je v príklade vnútorných tried k prednáške 4)
• použitie lambda výrazov alebo referencií na metódy (method references) – počíta sa iba použitie v aplikačnej logike, nie v GUI (jedna možnosť je v príklade referencií na metódy a lambda výrazov k prednáške 4)
• použitie implicitnej implementácie metód v rozhraniach (default method implementation)
• použitie aspektovo-orientovaného programovania (AspectJ)
• použitie serializácie

Spôsob hodnotenia je nasledujúci:

• splnenie hlavných kritérií – max. 15 b
  • program v súlade so zadaním a zámerom projektu, ako aj pokynmi vyučujúceho, s adekvátne použitým dedením a polymorfizmom v aspoň dvoch oddelených hierarchiách dedenia, vrátane použitia rozhraní, a s korektným zapuzdrením a vhodným použitím agregácie; dôsledné oddelenie aplikačnej logiky od používateľského rozhrania; kód vhodne organizovaný do balíkov; prehľadná dokumentácia so všetkými položkami podľa opisu vyššie – 14–15 b
  • program v súlade so zadaním a zámerom projektu, ako aj pokynmi vyučujúceho, s adekvátne použitým dedením v aspoň dvoch oddelených hierarchiách dedenia a polymorfizmom v aspoň jednej z nich, vrátane použitia rozhraní, a s korektným zapuzdrením a vhodným použitím agregácie; principiálne oddelenie aplikačnej logiky od používateľského rozhrania; kód vhodne organizovaný do balíkov; prevažne prehľadná dokumentácia so všetkými položkami podľa opisu vyššie – 11–13 b
  • program v súlade so zadaním a zámerom projektu, ako aj pokynmi vyučujúceho, s menšími akceptovateľnými odchýlkami, s adekvátne použitým dedením a polymorfizmom v aspoň jednej hierarchii dedenia, a s prevažne korektným zapuzdrením a prevažne vhodným použitím agregácie; dokumentácia so všetkými položkami podľa opisu vyššie – 8–10 b
  • program v súlade so zadaním a zámerom projektu, ako aj pokynmi vyučujúceho, s ešte stále akceptovateľnými odchýlkami, s adekvátne použitým dedením a polymorfizmom v aspoň jednej hierarchii dedenia, a s obmedzeným využitím zapuzdrenia a použitím agregácie; ešte stále akceptovateľná dokumentácia – 0–7 b
• adekvátne splnenie ďalších kritérií (najmä tých, ktoré sú vymenované vyššie, pričom použitie príslušného mechanizmu nezakladá automaticky nárok na hodnotenie – vhodnosť posúdi vyučujúci) v súlade so zadaním a zámerom projektu, ako aj pokynmi vyučujúceho, s adekvátnym krátkym opisom v dokumentácii: splnenie každého kritéria bude hodnotené v rozpätí 0–4 b – max. 25 b

Záverečná prezentácia projektu

Súčasťou odovzdania projektu je aj jeho záverečná prezentácia. Neprezentovaný projekt nebude akceptovaný.

Po záverečnej prezentácii vám vyučujúci oznámi orientačné slovné hodnotenie. Definitívne rozhodnutie vrátane toho, či projekt spĺňa podmienky akceptovania, sa dozviete prostredníctvom AISu po detailnom prezretí projektov.

Odovzdáva sa: ústne prednesenie na 11. alebo 12. cvičení podľa pokynov vyučujúceho

Hodnotenie

Spôsob hodnotenia je nasledujúci:

• adekvátne preukázanie splnenia zadania a zámeru projektu, ako aj pokynov vyučujúceho, vrátane reakcie na otázky vyučujúceho – 5 b
• prevažne adekvátne preukázanie splnenia zadania a zámeru projektu, ako aj pokynov vyučujúceho, vrátane reakcie na otázky vyučujúceho – 3–4 b
• ešte stále akceptovateľná prezentácia a reakcie na otázky vyučujúceho – 0–2 b