Bevezetés a programozásba 2 12. előadás: Alapvető programtervezési elvek
Miről lesz szó A félév célja a nagyobb programrendszerek felépítésében való részvétel képességét megszerezni Mindenki a saját widgetkészletének gondozása közben többféle problémával kellett találkozzon váratlan feladatok, amikhez változtatásokra van szükség váratlan hangsúlybeli eltolódások, nem azt egyszerű megoldani, amit gyakran kell használni stb stb
Időrendben 1968: strukturált programozás (Dijkstra) 1972: moduláris programozás, OOP gyökerek 1975: The Mythical Man-Month 1987: Statechart -> UML 1994: Design Patterns
A programtervezés általános lépései Fontossági és időbeli sorrendtől függetlenül: Specifikáció Project terv Implementálás Hibakeresés és tesztelés Dokumentáció A program létrehozása közben felmerülő problémák általában visszavezethetőek ezek hibáira vagy hiányosságaira
Specifikáció A feladat pontos megfogalmazása Nehéz és fontos lépés Elsődleges szempont a lehetséges feladatok teljes körét lefedni. A widgetkészlet tervezésénél ez a lehetséges widgetes programok által megkívánt funkciókat jelenti, ezekre képesnek kell lenni. Egy titkársági segédprogramot a titkár összes lehetséges feladatára fel kell készíteni. Vita tárgya, hogy érdemes-e végiggondolni az implementációt ( fejben programozni )
Specifikáció hiányából származó problémák Koncepció nélküli rendszer Nincs következetesség az alkotóelemek között Nehéz használni, mindennek utána kell nézni Túl egyszerű rendszer A feladatot nem lehet megoldani a rendelkezésre álló eszközökkel, és a bővítés nehéz Túl bonyolult rendszer Sok olyan feladatra van felkészítve, amire végül nincs szükség, és a sok lehetőség miatt nehéz használni Stb..
Project terv Implementációs és megvalósíthatósági tanulmány A widgetkészlet esetében ez lényegében az osztályok és kapcsolataik (tartalmazás, öröklés, tagfüggvényhívás) felépítése Szempontok: Takarékosság: kód ismétlések elkerülése Modularitás garantálása Következetesség, konvenciók
Project terv hibájából/hiányából eredő problémák: Az a feladat, amit eredetileg meg kellett oldani, az működik, de a feladatban történő kis változás a kódban nagy változást is igényelhet A szerzőn kívül nem igazodik el a programon senki A géptermi ZH nagyrészt ezt fogja mérni: mennyire alkalmas a program szerkezete egy váratlan feladat megoldására?
Implementálás Ez az eddigi programozásoktatás tárgya, az effektív programkód előállítás Szempontok: Biztonságosság Hatékonyság Tömörség Érthetőség ilities
Tesztelés Az implementáció hiányosságainak felderítése Futásidejű hibák összegyűjtése, okainak felderítése, javítása Memóriakezelés (folyik a memória) Felhasználói felület, ergonómia, bolondbiztosság Zavaróan lassú működés okainak felderítése, optimalizálás megfontolása
Tesztelés hiányából származó problémák A program fagy, lassú, kezelhetetlen Bármilyen korábban említett problémára igaz: nem derül ki Váratlan helyzetek (például az amőbaprogram nem készült fel arra, hogy betelik a mátrix) Bedrótozott elemek miatt más adatokon rossz működés
Dokumentáció Kétféle dokumentációt kell készíteni Felhasználói dokumentáció Hogyan kell telepíteni, használni a programot Gyakori problémák, esetleges hibaüzenetek magyarázata Fejlesztői dokumentáció A modulok felsorolása, szerepeinek tisztázása Felületek gondos leírása, akár specifikáció szinten Implementáció magyarázata, ahol szükséges Szoftverkomponens esetében (mint a widgetkészlet lib része) ezek a szerepek összemosódnak
Eszközök, elvek, módszerek Refactoring Felület és motor szétválasztása Vízesés modell Agile programming Design patterns
Refactoring A jelentése: újragyártás, újragondolás Előfordul, hogy egy rendszer már a kezdet kezdetén elkezd túlbonyolódni, ami a feltételek rossz megítéléséből fakad Képesnek kell lenni meghozni a döntést, hogy a kódot (egy részét, vagy akár az egészet) kidobjuk, és újraírjuk okosabban Minél hamarabb, annál jobb (dollárárverés) Gyakran jelent újraspecifikálást (rosszabb esetben az első specifikálást)
Változtatás vs refactoring Amikor a feladat változása miatt változik a kód, az nem refactoring. A refactoring lényegében megtartott működés mellett hatékonyabb, elegánsabban felépített kódot jelent. Például egy nagy main() felbontása függvényekre, a működés megtartása mellett
Refactoring: intő jelek Az egyszerűnek tűnő feladatokat is csak bonyolultan lehet megfogalmazni A használt fogalmak, osztályok rendszere elveszik a sok futtában hozzáadott újdonságtól Túl hosszúak az egyes komponensek implementációi: részekre kell bontani
Felület és motor szétválasztása Általánosabb elv konkrét megfogalmazásáról van szó, a modularitás hierarchikusságáról. Elv: a motor / logika elválasztása annak felhasználásától Mindkét rész több komponensből állhat, de a két oldal kapcsolatait minimalizálni kell Logika Felület Mező Pálya JátékMester PályaWidget Application
Vízesés modell Specifikáció Project terv Implementáció Tesztelés Nagy rendszerekhez jó
Agile programming Specifikáció Verzió váltás Project terv Teszt Implementáció Inkrementális programozás Kis és közepes projecteknél jó
Design patterns OOP tervezésnél megfigyelt visszatérő feladatokra objektumlétrehozás, vezérléselosztás, perzisztencia, stb... Bevált megoldások Azoknak, akik már képesek végiggondolni az implementáció problémáit
Időrend ismét 1968: strukturált programozás (Dijkstra) 1972: moduláris programozás, OOP gyökerek 1975: The Mythical Man-Month 1987: Statechart -> UML 1994: Design Patterns