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

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 –

●

Túl bonyolult rendszer –

●

A feladatot nem lehet megoldani a rendelkezésre álló eszközökkel, és a bővítés nehéz 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ó ● ●

–

Fejlesztői dokumentáció ● ● ●

●

Hogyan kell telepíteni, használni a programot Gyakori problémák, esetleges hibaüzenetek magyarázata 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

PályaWidget JátékMester

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