Bevezetés a programozásba előadás: Alapvető programtervezési elvek

Átírás

1 Bevezetés a programozásba előadás: Alapvető programtervezési elvek

2 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

3 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

4 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

5 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 )

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

7 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

8 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?

9 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

10 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

11 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

12 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

13 Eszközök, elvek, módszerek Refactoring Felület és motor szétválasztása Vízesés modell Agile programming Design patterns

14 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)

15 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

16 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

17 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

18 Vízesés modell Specifikáció Project terv Implementáció Tesztelés Nagy rendszerekhez jó

19 Agile programming Specifikáció Verzió váltás Project terv Teszt Implementáció Inkrementális programozás Kis és közepes projecteknél jó

20 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

21 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