Nagy házi feladat – követelmények

Czirkos Zoltán, Nagy Gergely · 2023.06.16.

A nagy házi feladat követelményei. A beadással kapcsolatos tudnivalók, értékelés, pontozási táblázat.

A tárgyban kötelező egy nagy házi feladat megoldása. A feladat szabadon választott. Lehet a listából is választani, vagy azokhoz hasonló nehézségű, az elvárásoknak megfelelő saját problémák is megoldhatóak. (Egyetlen kivétel a plágiumkereső – azt nem szabad választani, mert az a minta házi.)

A nagy házi megoldásához néhány tipp és segédlet egy külön oldalon található.

1. Követelmények

A nagy házi feladat a következő követelményeknek kell megfeleljen:

  • A feladatválasztást a laborvezető jóvá kell hagyja.
  • A kész megoldás és a dokumentáció bemutatása kizárólag személyesen történhet, legkésőbb az utolsó oktatási hét végéig.
  • A személyes bemutatáson a a HSzK gépein gcc-vel a -Wall -Werror fordítási opciókkal le kell fordulnia a programnak.
  • C nyelvű program, amely a nyelv lehetőségeit kihasználja: strukturált felépítés, több modulra bontás, dinamikus memóriakezelés és fájlkezelés.
  • A program mellé el kell készüljön a programozói és a felhasználói dokumentáció.

A fentiek között logikai és kapcsolat értendő: ha bármelyik hiányzik, a házi feladat nem elfogadható.

Dinamikus memóriakezelést kell használni a program lényegét adó adatszerkezetnél. Nem elegendő ilyet beépíteni a programnak olyan részébe, amely akár elhagyható is lenne. Például egy olyan játék, amelyben dinamikus memóriakezelés csak a dicsőséglistánál van, nem teljesíti ezt a követelményt.

A dinamikus memóriakezelés követelményt formálisan is megadjuk. Az adatszerkezetben az indirekciók száma legalább kettő kell legyen, azaz dinamikusan foglalt területen kell legyen dinamikusan foglalt terület címe. Az egydimenziós tömb nem elegendő – olyan feladatot kell választani, amely ennél összetettebb adatszerkezetet igényel. Az indirekciók száma az adatszerkezet működéséből kell adódjon; pl. egydimenziós tömb, amelynek kezdőcíme céltalanul dinamikus memóriaterületen van, nem teljesíti a követelményt.

A dinamikus memóriakezelés ellenőrzésére a programnak használnia kell a tárgyban használt debugmalloc könyvtárat vagy ahhoz hasonló eszközt.

A fájlkezelésben olyan adatokat kell tudni kezelni, amelyek száma változik, vagy változhatna. Nem teljesíti a követelményt pl. egy olyan program, amelyik az elindításainak számát (egyetlen egy egész számot) tárol fájlban. Teljesíti viszont egy olyan, amelyik egy játék 10 elemű dicsőséglistáját tárolja. A 10 ugyan fix, de akár változhatna is. A fájlkezelés saját programkódon kell alapuljon, pl. grafikus könyvtár által betöltött kép nem számít saját fájlkezelésnek.

A nagy házi egyéni feladat. A plágium minden formája bukást eredményez, és nincs második lehetőség. Különösen érvényes ez a más kódjának beadására, illetve az interneten talált forráskódokra is. Ezzel kapcsolatban lásd a követelmények oldalát.

Grafikus megjelenítés nem követelménye a nagy házinak. Nem is tanulunk róla a félév során. Ha grafikus megjelenítést igénylő feladatot választottál, azzal a házi feladat egyéb követelményeit nem lehet kiváltani. Olvasd el a megjelenítésről szóló írást!

2. A nagy házi részfeladatai

A hetek során az alábbi részfeladatokat kell megoldani. Az egyes részfeladatok megoldásához példákat mutat a minta nagy házi oldal.

A konkrét tárgykövetelmény az NHF 4-es (vagy pótlás esetén az 5-ös) megléte, annak elfogadása, és az elégséges pontszám elérése. A többi részfeladat ezen belül pontot ér, az időre vagy elfogadható minőségben nem teljesítésük esetén még lehet sikeres a nagy házi. Az 1–3. részfeladatoknak határidőig kell elkészülniük, utána már nem javíthatóak, nem pótolhatóak.

NHF 1. – választás

Ez a részfeladat a feladat kiválasztását jelenti. A listában szereplő feladatok közül is lehet választani, vagy saját, hasonló nehézségű feladatot is lehet hozni. A kiválasztott feladat utólag már nem módosítható. A feladatválasztás kötelező; ha írásban nem történik meg, a laborvezetők személyesen fogják kérni.

Saját, előző évben elkezdett házi feladat is választható. Akár változatlanul is beadható, de újra lesz pontozva. Mindenesetre ezt nem javasoljuk; a házi feladat elkészítése a gyakorlás fontos része.

NHF 2. – specifikáció

A nagy házi választása után kell tölteni a házi feladat specifikációját. Ez a kiadott feladat részletekbe menő pontosítása. A pontosítás célja az, hogy a program megrendelője, és a programot elkészítő programozó ugyanarra gondoljon, és ne a munka végén derüljön fény a félreértésekre. Ide tartozik a program feladatának leírása, a bemenetek és a várt kimenetek rögzítése, a program használatának leírása is. A specifikációban még nem kell a program belső felépítésével, működésével kapcsolatos részleteket megadni.

A pontosított specifikáció részletességére jellemző, hogy ha két külön programozó elkészíti a programot ugyanabból a specifikációból, de egymástól függetlenül dolgozva, akkor kívülről nézve nagyon hasonló programoknak kell keletkezniük. Amennyiben az eredeti, rövid specifikáció bármelyik része nem egyértelmű, akkor a pontosítás során egy lehetőség mellett dönteni kell. Ebben segítenek a laborvezetők is.

A specifikációtól később csak apró részletekben, és csak a laborvezetővel egyeztetve lehet eltérni.

NHF 3. – félkész megoldás

A félkész megoldás lényege az, hogy a készülő program funkcionalitásának egy részét már meg kell valósítsa: már látszania kell rajta akár felhasználói, akár programozói szemmel, hogy mi készül. Nem elegendő egy „hellóvilág” programot, vagy egy menüt feltölteni. A félkész változat még nem kell hibamentes legyen, nem kell tartalmaznia az összes funkciót, nem kell felépítésében és használt adatszerkezeteiben a végleges programmal megegyezzen. A félkész házinak kezdetleges dokumentációt már tartalmaznia kell: legalább egy rövid, fél-egy oldalas leírást arról, hogy mi az, ami már működik, és hogy az egyes feltöltött fájloknak, függvényeknek mi a szerepe.

Néhány példa. Kukacos játék esetén félkész házi lehet egy olyan program, amelyikben a kukac feje már mozog a képernyőn, és az étkeket össze lehet gyűjteni, de a kukacnak még nincsen farka, és nem nő. Telefonkönyves házi esetén félkész változat lehet az, ahol az adatokat már be tudja kérni a program, és el tudja tárolni egy tömbben; de dinamikus adatszerkezetet még nem használ, kereséseket még nem tud végezni, vagy képernyőre írja azt, amit amúgy fájlba mentene.

NHF 4. – végleges program
Ez az elkészült, végleges program beadása, forráskódokkal és dokumentációkkal.
NHF 5. – javítás vagy pótlás
Akinek a házi feladata nem készült el időben vagy nem elfogadható, az utolsó oktatási hét végéig pótolhatja azt. Ebben az esetben kevesebb pont jár a megoldásra. Javítás esetén (ha az NHF 4-es részfeladat elfogadott) a teljes pontszám megkapható, és különeljárási díj sincsen.

3. A házi feladat beadása

Az összes részfeladatot elektronikusan kell beadni, az adminisztrációs portálon. Semmilyen más módon nem adható be megoldás.

NHF 1. – választás

A listából választott feladatok esetén a cím vagy a feladatkiírás bemásolásával választható ki a feladat. (Cím esetén is egyértelmű, hogy listából vett feladatról van szó, az ottani feladatkiírással.) Saját feladat esetén röviden el kell magyarázni a program lényegét.

A feltöltés módja lehet bemásolt szöveg, vagy PDF is, ez teljesen lényegtelen ennél a részfeladatnál.

NHF 2–3–4. – programkódok és dokumentációk

Ehhez a dokumentációkat és a forráskódot kell feltölteni egy ZIP fájlban. A feltöltés formátumára az alábbi megkötések vonatkoznak:

  • A csomag ZIP formátumú, maximális mérete 1 MB forráskóddal és dokumentációval együtt.
  • A megoldás forrásfájljait *.c, *.h nevű szöveges fájlként kell beadni.
  • A specifikációt és a dokumentációt PDF formátumban kell beadni.
  • A feltöltésnek ezeket a fájlokat tartalmaznia kell, emailben küldés, illetve link semmiképp nem elfogadható. Ha vannak egyéb, nagy adatfájlok, azokra lehet link.

A nagy házit a 13. vagy 14. heti laborgyakorlaton személyesen is be kell mutatni a laborvezetőnek. A laborvezető a megoldás saját elkészítését ellenőrzi: a program forráskódjával kapcsolatban kérdéseket tesz fel, esetleg annak módosítását kéri. A bemutatás után a laborvezető a feltöltött programot is megnézi és pontozza. Ez jelenti a házi feladat tényleges elfogadását, aminek szükséges, de nem elégséges feltétele a bemutatás. Rendszeres konzultációval a bemutatás kiváltható; ehhez a laborvezető hozzájárulása szükséges.

A javasolt PDF készítő letölthető innen: CutePDF. Telepítés után megjelenik egy fiktív nyomtató; arra nyomtatva készül a PDF fájl.

A viták elkerülése végett

  • Feltöltött fájlnak a megoldást közvetlenül tartalmaznia kell. PDF-ben feltöltött forráskódok nem elfogadhatóak. Internetes linkek, „emailben elküldve” megjegyzések nem elfogadhatóak, sem a beadandó szövegekre (specifikáció, dokumentáció), sem a forráskódra. A laborvezetők csak olyan fájlt fogadhatnak el, amely megoldásként lett beküldve, nem pedig üzenetként vagy e-mailben.
  • A feltöltött csomag felesleges, különösen a fordítással automatikusan előállítható fájlokat (*.obj, *.exe stb.) nem tartalmazhat. Az ilyen feltöltéseket a portál automatikusan vissza fogja utasítani, és nem elfogadottnak minősülnek.
  • A rossz formátumban vagy hiányosan feltöltött, feltölteni próbált megoldások szintén nem elfogadhatóak. Amit a portál nem enged feltölteni, vagy feltöltés után automatikusan visszautasít, az biztosan nem elfogadható házi. Az automatikus visszautasítás okkal történik, formai hibák miatt. Ezt az oktatók sem bírálják felül.
  • Ha túl nagyok a PDF-ek, akkor javasolt: a) egy PDF fájlban beadni a programozói és a felhasználói dokumentációt, b) kitörölni a felesleges, túlméretezett, vágatlan képeket, c) nem használni rengetegféle betűtípust. A tartalmat pontozzuk, nem a díszítéseket!
  • Ha a feltöltött csomag hiányos, vagy a programban alapvető technikai hiányosságok vannak, akkor a laborvezető utólag is megtagadhatja az elfogadást. A hibás feltöltés, követelményeknek nem megfelelés nem a laborvezető hibája, akkor sem, ha nem jelezte azonnal!
  • Gyakran visszatérő fordulat a „nem azt töltöttem fel, amit szerettem volna”. Ilyen indokkal sem fogadunk el késést. A feltöltött fájlt le is lehet tölteni; mindenki maga ellenőrizheti az összeállított és feltöltött fájlt.
  • A házi feladat fájljaiért, mint adatvagyonért mindenki saját maga felelős. Rendszeres biztonsági mentést kell készíteni róla a félév közben. „Meghalt a vinyóm, vírusos lett a gépem”, és ezekhez hasonló indokokkal sem fogadunk el késést. Javasolt felhő tárhely szolgáltatások használata.

4. A végleges megoldás értékelése, pontozása

Általános követelmény a programmal szemben az, hogy a józan ész elvárásai szerint működjön. A programnak olyan magától értetődő képességekkel is kellhet rendelkeznie, amelyek a specifikációban külön nincsenek rögzítve. Például ha a specifikáció annyit mond, hogy a program egy nevet megjegyez, akkor elvárható az is, hogy a névben lehessen szóköz karakter. Vagy ha a specifikáció azt mondja, hogy a program bizonyos adatokat fájlba tud menteni, akkor elvárás az is, hogy vissza is tudja tölteni azokat.

Automatikusan elutasításra kerül

Vannak olyan elvi hibák és alapvető hiányosságok, amelyek esetén a beadás egyáltalán nem elfogadható. Érdemes a következő ellenőrzési listán végigmenni beadás előtt:

  • Nincs feltöltve a forráskód megfelelő formátumban. Esetleg csak link, megjegyzés van a forráskód helyett, vagy csak a fejlesztőkörnyezet projektfájlja.
  • Hiányzik a feladatban megkívánt dokumentáció. Ha a felhasználói dokumentáció lényegében megegyezik a specifikációval, akkor is át kell szerkeszteni és fel kell tölteni.
  • A program alapvető funkciói nem működnek.
  • Az egész program egy forrásfájlban van, nincsen több modulra bontva. A programot logikusan több modulra kell bontani, tehát több *.c és *.h forrásfájlnak kell lennie.
  • A program nem használ fájlkezelést.
  • A program nem használ kellően összetett dinamikus memóriakezelést a lényegi funkcionalitásának megvalósításához. A programban megfelelő adatszerkezetet, pl. dinamikus tömböt (legalább két dimenziósat), láncolt listát vagy bináris fát kell használni, a feladat jellege által megkívánt módon.
  • A program nem használja vagy helytelenül használja a debugmalloc memóriakezelést ellenőrző modult. Nem elég csak beépíteni; a jelzett hibákat javítani is kell. (Ha technikai akadály miatt a debugmalloc használata nem lehetséges, a laborvezetővel ezt a beadást megelőzően egyeztetni kell. Ha más eszközt használ a program, azt a programozói dokumentációban tárgyalni kell.)
  • A program a fő adatszerkezeteihez (telefonkönyvnél a nevek, kukacos játéknál a játék állapota és a kukac stb.) globális változót vagy fájlokat használ. A globális változók sokszor indokoltak lehetnek, de nem arra valók, hogy a megfelelő függvényparaméterezést vagy a cím szerinti paraméterátadást kiváltsák.
  • A program a függvényhívást ciklusként használja: pl. a menu() meghívja az adatbevitel()-t, az pedig visszatérés nélkül meghívja a menu()-t, hogy az meghívhassa a keres()-t, ami megint meghívja a menu()-t... stb. (Gyanús, ha túl sok helyen szerepel sys.exit() hívás a programban, másképp nem oldható meg a leállítása!)

Az elfogadott megoldás pontozása az alábbiak szerint történik. Minden felsorolásjellel jelölt elem 1 pontos.

Pontozás

Határidők betartása

  • időben kiválasztva (NHF1 elfogadva és NHF4 elfogadva)
  • specifikáció időben elkészült (NHF2 elfogadva és NHF4 elfogadva)
  • félkész házi időben elkészült (NHF3 elfogadva és NHF4 elfogadva)
  • végleges házi időben elkészült (NHF4 elfogadva)

    A fenti pontok nem javíthatók és pótláskor sem adhatók meg. Vagyis ha pl. a specifikáció nem készült el időben, akkor már nem szerezhető pont utólagos beadással; illetve ha NHF4 nem volt elfogadva, akkor ezek mind elvesznek.

Programkód minősége

  • helyes forrásfájl/fejlécfájl használat (pl. nincs include-olt .c fájl, nincs függvénydefiníció hibásan .h fájlban)
  • modulokra bontás minősége (tipikusan a main.c+fuggvenyek.c nem elég; pl. lehet láncolt lista kezelő modul, grafika modul, különféle menüket megjelenítő modul stb.)
  • funkcionális dekompozíció minősége (ne legyenek túl nagy függvények, és ne hívják egymást következetlen módon, pl. beolvasás a menüt)
  • adatszerkezetek, típusok használata (tipikusan: struktúrákba bekerültek, amik összetartoznak; nem int szamlalo, nevezo, hanem struct Tort; nem rajzol(char **p, int sz, int m), hanem rajzol(struct Palya *p); általában a túl sok paraméterű függvényekből látszik, hogy baj van)
  • nyelvi elemek helyes használata (ne legyen felsorolt típus helyett egész vagy sztring, helyes vezérlési szerkezetek, ne legyen fölösleges dinamikus memóriakezelés stb.)
  • fájlkezelés helyessége, minősége (fájlok legyenek bezárva; legyen alapvető hibakezelés; ne legyenek a fájlműveletek túlbonyolítva)
  • nincsenek indokolatlanul újraimplementált szabványos függvények
  • szerep szerinti változónevek, függvénynevek (nem a betűk száma a lényeg, lehetnek 1 betűsek; int vmi, bool logikai – ezek nem)
  • következetesen indentált forráskód (0-nál nagyobb indentálás, a stílus tetszőleges)
  • 1. feladatfüggő pont, a feladat jellege alapján, laborvezető indokolja
  • 2. feladatfüggő pont, mint a fenti

Dokumentációk általában

  • a dokumentációk bekezdésekre és fejezetekre vannak tagolva, elfogadható a helyesírásuk, nincsenek bennük képként forráskódok, nincsenek felfújva (16-os betűméret, 4 cm margó, dupla sorköz, egyéb terjedelemnövelő technikák).

Programozói dokumentáció

  • a projekt felépítése (melyik fájl mit tartalmaz) és a szükséges környezet, külső könyvtárak leírása, továbbá a fordításhoz szükséges lépések leírása (pl. grafikus könyvtár; ha nem igényel szabványos könyvtárakon kívül semmit, akkor ez a tény)
  • adatszerkezetek dokumentációja, tervezési megfontolások leírása (melyik adatszerkezet és típus mire való, mit tárol, miért arra esett a választás)
  • a függvények dokumentációja (feladat, paraméterek, visszatérés, esetleg körülmények, pl. xy nem lehet NULL)

Felhasználói dokumentáció

  • program feladata, célja; milyen bemenetek, kimenetek vannak, játéknál hogyan kell irányítani