Nagy házi feladat – követelmények

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.

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

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 csak személyesen történhet.
• A nyelv lehetőségeinek kihasználása: strukturált felépítés, több modulra bontás, fájlkezelés, osztályok és adatszerkezetek.
• A program mellé el kell készüljön a programozói és a felhasználói dokumentáció.
• Külső könyvtárak használata (minden, amit pip-pel telepíteni lehet) a PyGame és az ezen az oldalon találhat PyConio kivételéve nem megengedett. (Magyarázat: a valóságban pont ellentétesen kell viselkedni, ami már kész van, lehetőség szerint azt kell használni. De ez egy egyetemi alapozó tárgy. Itt azt kell bizonyítani, hogy az adatszerkezetek, algoritmusok használatát sikeresen elsajátítottátok, nem pedig azt, hogy ügyesen és gyorsan oldotok meg problémákat külső könyvtárak és a Stack Overflow használatával.)
• A PyGame grafikus könyvtár használata az értékelést nem befolyásolja semmilyen irányban sem.

Az osztályok és adatszerkezetek tekintetében: a programnak összetett adatszerkezetet kell építenie, pl. objektumok listáját vagy listák listáját. Ez nem helyettesíthető fájlműveletekkel, nem váltható ki egyéb nyelvi elemekkel. Nem tárolhatóak egy entitás adatai listában (pl. lista[0] egy ember neve, lista[1] a születési dátuma, lista[2] a lakcíme, ...) saját osztályok definiálása helyett. Ezeket az adatszerkezeteket a függvények közt paraméterátadással és visszatérési értékekkel kell átadnia a programnak, nem használhat indokolatlanul globális változókat.

A programnak érdemben adatfeldolgozást kell végeznie az így felépített adatszerkezeten. Ez azt jelenti, hogy a program lényegi funkcióját saját Python kóddal kell megvalósítani. (Nem alkalmas nagy házi feladatnak pl. egy képnézegető program, amely nem saját Python modullal jeleníti meg vagy dolgozza fel a képeket. Alkalmas viszont egy aknakereső, amely ugyan maga is megnyit képeket a pálya megjelenítéséhez, de ez csak mellékes része a programnak.)

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 fentiek között logikai és kapcsolat értendő: ha bármelyik hiányzik, a házi feladat nem elfogadható.

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.

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, a nem teljesítésük esetén még lehet sikeres a nagy házi.

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 leadható, 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 a portálon meghirdetett időpontig fel 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.

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 bemutassa: 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áltozatnak valamennyire már működnie kell. Még nem kell hibamentes legyen, nem kell tartalmaznia az összes funkciót, sem felépítésében és használt adatszerkezeteiben nem kell 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, de nem tudja eltárolni, 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 leadá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ó.

NHF 1. – választás

A listából választott feladatok esetén a feladatkiírás vagy a cím bemásolásával választható ki a feladat. Saját feladat esetén röviden el kell magyarázni a program lényegét.

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

A dokumentációkat és a forráskódot elektronikusan kell leadni, az adminisztrációs portálon. A megoldás forrásfájljait és dokumentációit 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 *.py nevű szöveges fájlként kell leadni.
• A specifikációt (NHF 2.) és a dokumentációt (NHF 3-4.) PDF formátumban kell leadni.
• 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.

PDF-et Microsoft Word programból a legegyszerűbben a File/Export menüpontból lehet készíteni.

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

• Feltöltött fájlnak a megoldást tartalmaznia kell. 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. PDF-ben feltöltött forráskódok sem elfogadhatóak, az csak a dokumentáció lehet.
• 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.
• 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.
• Ha túl nagyok a PDF-ek, akkor javasolt:
  1. kitörölni a felesleges, túlméretezett, vágatlan képeket,
  2. nem használni rengetegféle betűtípust (a tartalmat pontozzuk, nem a díszítéseket)
  3. egy PDF fájlban beadni a programozói és a felhasználói dokumentációt.
• 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.
• 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. „Meghalt a vinyóm, vírusos lett a gépem”, és ezekhez hasonló indokokkal sem fogadunk el késést. Javasolt a OneDrive, Google Drive, Dropbox vagy hasonló szolgáltatások használata. Ha valaki tudja mi az a verziókezelő, használja bátran, de nagyon figyeljen arra, hogy a repository privát legyen!
• 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 magad is le tudod tölteni; ellenőrizd, mit adsz be!

Á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.

A megoldásokat a laborvezetők pontozzák. A pontozást minőségbiztosítási okokból szúrópróbaszerűen központilag is ellenőrizzük; ugyanez reklamációra is ad lehetőséget.

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 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 leglényegesebb funkciói nem működnek, nem valósítja meg a specifikációját.
• Az egész program egy forrásfájlban van, nincsen több modulra bontva.
• A program nem használ fájlkezelést.
• A program nem definiál saját osztályokat a tárolandó adatok modellezéséhez.
• A program nem épít adatszerkezeteket, esetleg fájlműveletekkel próbálja kiváltani azokat.
• A program indokolatlanul, túlzóan használ globális változókat a függvényparaméterek és visszatérési értékek helyes használata helyett.
• 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!)
• A programkód minőségére adott pontokból össze kell gyűlnie 8-nak.

Az elfogadott megoldás pontozása az alábbiak szerint történik.

Programkód minősége

• modulokra bontás minősége (tipikusan a main.py+fuggvenyek.py nem elég; pl. adatszerkezeteket 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: osztály bekerültek, amik összetartoznak; nem szamlalo, nevezo, hanem class Tort; nem rajzol(palya, szelesseg, magassag), hanem rajzol(palya), ahol az egy osztály; általában a túl sok paraméterű függvényekből látszik, hogy baj van)
• helyes erőforráskezelés (fájlok bezárása, kivételek kezelésével vagy with blokkokkal)
• nyelvi elemek helyes használata (ne legyen sok mágikus szám vagy sztring, helyes vezérlési szerkezetek, nincs from module import *)
• a tárgyban elvárt kódolási stílust követi (van main() függvény, osztályok adattagjai már a konstruktorban létre vannak hozva)
• nincsen telis-tele indokolatlanul újraimplementált szabványos függvénnyel
• szerep szerinti változónevek, függvénynevek (nem a betűk száma a lényeg, lehetnek 1 betűsek; vmi, logikai – ezek nem)
• 1. feladatfüggő pont, a feladat jellege alapján (tipikusan egyéb hibáért, hatékonytalanságért levonható, főleg ha az adott problémának van tanult megoldása; laborvezető indokolja)
• 2. feladatfüggő pont, mint a fenti
• 3. feladatfüggő pont, mint a fenti

Dokumentáció á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, telepítéshez 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 típus és adatszerkezet 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 None)

Felhasználói dokumentáció

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

Ezen felül pedig, pontok járnak a határidők betartására. A lenti 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 az NHF4 nem volt elfogadva, akkor ezek mind elvesznek:

Határidők betartása

• Házi 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)