Zadání témat projektů

Vyberte si téma a dva spoluautory – do příštího cvičení

Výběr spolupracovníků – projekt se vypracovává ve skupinách po třech studentech z jednoho cvičení (z důvodu času na konzultace). Doporučuji aby projekt vytvářel každý ze skupiny samostatně, poté jednotlivé verze srovnat, prokonzultovat a složit to nejlepší. Menší skupiny mohou být penalizovány.

Výběr tématu (typ kontejneru) a datových typů - stejné téma mohou mít maximálně dvě skupiny na cvičení. Seznam témat.

Nahlášení projektů

Nahlaste zvolené téma a skupinu spoluautorů ve svých cvičeních

Formulace zadání

Na základě předloženého formuláře napište vlastní zadání vašeho projektu

Napište zadání projektu podle předlohy. Ve formuláři nahraďte červené části textu na základě vlastností vašeho projektu. Zadání specifikuje základní metody, které musí třída mít z hlediska procvičení základních mechanizmů fungování tříd.
Zadání pište s vědomím toho, že se bude měnit – napište ho podle vašich současných znalostí či podle toho jak byste si představovali aby řešení vypadalo. Při odevzdání konečné podoby projektu uvedete nové znění zadání a důvody změn.

Odevzdání zadání

hodnocení úplnosti a kvality zadání - 2 body

Připomínky k zadání

„globální“ chyby v zadání

Tvorba a odevzdání hlavičkového souboru

Odevzdávané soubory by měly začínat komentářem, jehož součástí jsou jména autorů, název projektu, skupina. Jako součást odevzdání se budou hodnotit správně fungující třídy CItem uložené v projektu v adresáři: CItem a hlavičkový soubor kontejneru uložený v projektu v adresáři: Projekt. Všechny hlavičkové soubory by měly být standardně ošetřeny proti vícenásobnému načtení.

Zdrojové soubory CItem:

Třídy pro uložení prvku CItem jsou součástí připraveného projektu (společně s CItemBase, kterou však neměňte) a měly by být doplněny pro zvolené typy (různé od bool a TWeekDay) v hlavičkové i zdrojové části. Původní CItem pro bool a TWeekDay zůstávají součástí projektu. Určení, který z CItem je používán je realizováno pomocí jeho zveřejnění do globálního jmenného prostoru (ke změně dochází pouze na jediném místě v CItem.h).
Vámi vytvořené třídy CItem musí jít bez chyb přeložit proti původnímu dodanému souboru main v projektu CItem pro všechny čtyři třídy CItem. Zkompilovaný program musí po spuštění s dodaným souborem CItem\CItem\main.cpp správně fungovat!!! Očekáváme, že projekt CItem bude tyto třídy CItem obsahovat, tak abychom je mohli otestovat a opravit!!! Nepředpokládejte, že opravující si do projektu CItem budou Vámi vytvořené soubory dalších tříd CItem sami přidávat a laborovat nad následnými úpravami!!! To je Váš úkol!!!

Hlavičkové soubory kontejneru:

Projekt se „odevzdává“ do svn, kde v adresáři trunk je vytvořen podadresář Projekt, ve kterém na projektu budete průběžně pracovat (aby se nepřetěžovala svn, ověřte nakonfigurování clienta - viz www). Očekáváme, že projekt v svn bude vždy přeložitelný bez chyb (errors). Do stejného adresáře se bude později „odevzdávat“ i dokončený projekt.

Navržená třída kontejneru by měla pokrýt plně metody a funkce definované v zadání.
Těla metod a funkcí mohou (ale nemusí) být prázdná (zatím se hodnotí pouze rozhraní třídy), měly by ovšem alespoň vracet správné návratové hodnoty (metoda by již nyní měla vracet typ, který bude vracet v dokončeném projektu).
Třída by měla obsahovat členská data (atributy), včetně statických dat.
Funkce main projektu kontejneru bude obsahovat ukázkový program volající jednotlivé metody a operátory obsažené ve třídě (zatím bez funkčnosti, jde o kontrolu správnosti prototypů metod a operátorů, kontrola možnosti jejich volání). Funkce main (a samozřejmě kontejner) by měla být použitelná společně pro všechny třídy CItem (po jejich „přepnutí“) stejně tak jako je tomu u funkce main demonstrující použití tříd CItem.
Hlavičkový soubor kontejneru (včetně demonstrace volání navržených metod z ukázkového programu) by měl být přeložitelný bez errorů a zbytečných warningů.
V další práci může být samozřejmě obsah hlaviček dále modifikován. Rozdíly zhodnoťte v závěrečné dokumentaci.
Používáte-li více tříd, definujte je v samostatných zdrojových souborech (.h i .cpp).

Odevzdání tedy bude minimálně obsahovat:
- třídy CItem_XXX (cpp i h) původní i upravené pro vaše typy (různé od demonstračnch. Celkem 4 třídy) v projektu v adresáři: CItem.
- soubor CItem.h a třídu CItemBase (cpp i h), která bude originální (neprovádí se v ní změny)
- hlavičkový a zdrojový soubor třídy vašeho kontejneru v takovém stavu, aby bylo možné je přeložit a spustit a to v projektu v adresáři: Projekt. Metody třídy uvedené v hlavičce mohou mít prázdná těla až na předávání návratové hodnoty. Ve zdrojovém souboru třídy bude hodnocena pouze definice statických proměnných tj. ostatní zdrojové části třídy (těla metod, ...) jsou v současnosti nepovinné.
- demonstrační soubor, obsahující funkci main demonstrující použití navržených metod (a funkcí) kontejneru navržený tak aby fungoval bez úprav pro všechny CItem_XXX (po „přepnutí“).
- soubory pro kontrolu paměti check (cpp i h)

V rámci tvorby hlavičky by bylo dobré začít tvořit dokumentaci projektu (nebude hodnoceno v současném okamžiku ale až po odevzdání celého projektu). Pro tuto dokumentaci je určen adresář trunk/Dokumentace.

Hodnocení - podle kvality a úplnosti a počtu commitů do svn (každý člen pracující na projektu by měl minimálně jednou týdně upravit projekt smysluplným a výrazným způsobem) - 3 body

Zhodnocení hlaviček

„globální“ chyby v hlavičkových souborech.
Zapracování opravených souborů do projektu - (Před začátkem spojování Update.). Opravené a vaše soubory je možné „spojit“ pomocí (pravé tlačítko myši) tortoiseSVN/Merge na adresáři kde budeme spojovat (trunk), dále volba reintegrate branch („vedlejší“ větev se natrvalo vrací do původní), nastavit URL adresu (svn:\\savanna ....\tags\opravena_hlavicka) s opraveným projektem v adresáři \tags. Pomocí Test merge je možné překontrolovat zda nedojde ke kolizi. Následně se spojí „naostro“ pomocí volby merge a vyřeší se případné konflikty (změny na jednom řádku). Je-li výsledek v pořádku, je potřebné ho pomocí Commit zapsat do SVN.

Odevzdání zdrojů

Pro zdrojové texty platí v podstatě totéž co pro odevzdání hlavičky, pouze s tím rozdílem, že se doplní i tělíčka metod/funkcí/operátorů a program bude fungovat tak, jak se od něj (v konečném stavu) očekává. Součástí je ukázka činnosti projektu (okomentovaný zdrojový soubor s main, který ukáže volání všech vytvořených metod/funkcí a zajistí kontrolu správného fungování vaší třídy (automatické testování správné funkcionality třídy)). Testováním se myslí například vyzkoušení metod pro odebrání prvku z prázdného objektu, operátor = pro a = a, zjištění počtu prvků objektu po několika přidáních a odebráních ... Samotná třída nebude interaktivně komunikovat s uživatelem. V ideálním případě nebude vypisovat a číst z konzoly vůbec nic (kromě streamů). Chybové stavy může main funkce detekovat zvláštní metodou třídy nebo je možné využít výjimky. Demonstrační program (funkce main) naopak interaktivní být mohou. Program bude demonstrovat načítání dat z konzoly (předtím vypíše popis formátu vkládaných dat se vzorovým příkladem takovýchto dat). Většina hodnot tedy nemusí být zadávány „z venčí“ programu ale mohou být součástí programu (nastavení pomocí konstruktorů, setterů). Tisk obsahu vašeho objektu na konzolu by měl být součástí demonstrace, není však nutné tisknout každou proměnnou po zavolání jednotlivých metod. Program se správně implementovanou knihovnou check nebude hlásit žádné memoryleaky. Soubory budou obsahovat jednoduché komentáře. Očekává se zapracování všech připomínek z předchozích hodnocení a implementace metod v rozsahu (původního) zadání. Změny vůči zadání i odevzdané hodnocené hlavičce jsou povoleny, očekává se, že změny a jejich důvody budou následně popsány v dokumentaci.

Odevzdává se tedy do adresáře projekt minimálně: hlavičkový soubor třídy, zdrojový soubor třídy, soubory CItem (2x4ks), cpp soubor s ukázkou použití třídy (soubor s main), check, soubor vzorového zadání dat (je-li použit). Tyto soubory musí být přeložitelné (bez chyb a warningů) v prostředí MS Visual C (projekt prázdná konzola s default nastavením překladače).

Hodnocení zdrojů - kvalita zdrojových textů, demonstrační program prezentující práci se třídou s komentáři – 4 body,
kvalita projektu, splnění zadání, obtížnost - 2 body

Zhodnocení zdrojů

„globální“ chyby ve zdrojových souborech

Obhajoba

Krátká prezentace a obhajoba projektu (upřesněno cvičícím na předposledním cvičení) – cca 5 minut + dotazy - členové skupiny obhajují jednotlivě

Prezentace by měla obsahovat: úvod, datová reprezentace včetně variant, přehled zajímavých metod, zajímavý kód, ukázka volání, možnosti zlepšení. Prezentovat to v čem si myslíte, že váš projekt je výjimečný, čím byste mohli obohatit ostatní.
Soubor prezentace by měl být odlišný (stručnější) od dokumentace.
Pro soubor obsahující podklady k prezentaci doporučujeme formáty pdf, ppt, případně rtf. Soubor s názvem “Prezentace“ se nakopíruje do svn trunk\Dokumentace, při obhajobě bude k dispozici dataprojektor.
Při obhajobě zodpovíte dotazy – krátký test na autorství – dopište funkci, upravte kód ....

obhajoba bodování - 3 body – úvod, datová reprezentace včetně variant, přehled metod, zajímavý kód, ukázka volání, možnosti zlepšení

Odevzdání dokumentace

Dokumentaci, pouze ve formátu rtf (“Dokumentace.rtf“), odevzdávejte do svn trunk\Dokumentace.
Body v dokumentaci:
1) Jméno, skupina, název
2) Původní zadání (tj. zadaní které odevzdávali jako první)
3) Popis změn v zadání, které jste provedli (nejlépe spojit body 2 a 3: původní zadání - upravené zadání - zdůvodnění každé změny)
4) UML diagram nebo seznam private/public metod i atributů. Popis koncepce třídy – co reprezentují proměnné, jak spolu souvisejí ...
5) Popis činnosti a významu alespoň základních public metod (tj. manuál pro používání jednotlivých metod třídy). Popis parametrů metod a operátorů.
6) Výpis programu main (okomentovaný význam jednotlivých řádků).
7) Závěr (tj. Co jste případně nestihli. Proč jste byli nuceni změnit zadáni, hlavičku (oproti odevzdané verzi). Jaký k tomu byl důvod. ...)

Dokumentace se vztahuje k verzi ke dni odevzdání zdrojových textů. Po odevzdání zdrojových textů zůstává adresář trunk „otevřený“, ale ke změnám zdrojových textů již nebude přihlédnuto.

dokumentace bodování – zadání, hlavička (1b), filozofie návrhu, volba dat, (1b) privátní a veřejné funkce, konstruktory, UML diagram (1b), popis funkcí rozhraní (2b), … závěr (1b) – celkem 6 bodů

Zhodnocení projektů

„globální“ chyby v projektech