PROGRAMKÉSZÍTÉS LÉPÉSEI, PROGRAMOZÁSI ELVEK

Átírás

1 PROGRAMKÉSZÍTÉS LÉPÉSEI, PROGRAMOZÁSI ELVEK 1. A PROGRAMKÉSZÍTÉS LÉPÉSEI A programozási feladat kitűzése, első megfogalmazás A feladat specifikációja, pontos megfogalmazás A program megtervezése, a feladatot megoldó algoritmus elkészítése Kódolás, a forrásnyelvű program elkészítése Tesztelés, hibakeresés, javítás Hatékonyságvizsgálat Dokumentáció készítés Ezeket a lépéseket alapvetően a leírás sorrendjében végezzük el, de előfordulhat, hogy (pl. a kódolás nehézségei miatt) vissza kell lépnünk, és át kell írnunk az algoritmust, vagy a tesztelés során kiderült hiba miatt esetleg újra kell kódolnunk bizonyos részleteket. 1.1 A feladat kitűzése, első megfogalmazása A feladat kitűzése a program legfontosabb funkcióinak és képességeinek pontos és szabatos leírását jelenti. A megfogalmazás a felhasználó szemszögéből, hétköznapi nyelven történik. Egyszerűbb programok esetében a feladatkitűzés legtöbbször csak egyetlen mondatot jelent: Írjunk programot, amely egy háromszög oldalainak ismeretében meghatározza annak területét! Persze ezt is lehet pontatlanul megfogalmazni: Írjunk programot, amely kiszámolja egy háromszög területét! Ebből a megfogalmazásból nem nyilvánvaló, hogy milyen adatokból szeretnénk számolni. Terjedelmesebb programok esetén általában nem lehet egy mondattal elintézni a feladat kitűzését. Hibás lenne pl. egy ilyesfajta megfogalmazás: Írjunk professzionális szövegszerkesztő programot! A teljesség igénye nélkül felsorolunk néhány szempontot, amelyet nem szabad kihagynunk az említett feladat kitűzéséből: - Képes legyen-e több dokumentum egyidejű szerkesztésére? - Milyen terjedelmű állományokat és milyen szövegformátumokat kezeljen? - Tudjon-e képeket és egyéb objektumokat kezelni? 1

2 - Legyenek-e speciális funkciói, pl. Web-lap készítés, Pascal kód készítés támogatása? - Milyen legyen a felhasználói felülete? A professzionális programok kitűzését rendszerint nem egyedül a programtervező végzi el, hanem a program megrendelője és készítője együtt. 1.2 A feladatok pontos megfogalmazása Feladatspecifikáció Miután megtörtént a feladat kitűzése, a program tervezője a saját szemszögéből fogalmazza meg a feladatot, ami stílusát tekintve gyökeresen különbözik a hétköznapi nyelven történő megfogalmazástól. A feladatspecifikáció során rögzíteni kell a bemenő és kimenő adatok típusát, illetve azt, hogy ezekkel kapcsolatban van-e valamilyen feltételünk, elvárásunk. A bemenő adatokra ún. előfeltételeket, a kimenő adatokra pedig ún. utófeltételeket fogalmazunk meg. A feladatspecifikáció történhet szövegesen, illetve matematikai és logikai szimbólumok alkalmazásával. Mindkét esetben maximális pontosságra és egyértelműségre kell törekednünk. Az előbbi (háromszög területét meghatározó) feladat pontos megfogalmazása: Bemenő adatok: a,b,c : valós számok a háromszög oldalai Kimenő adatok: T : valós szám a háromszög területe Előfeltételek: a>0 b>0 c>0 (minden oldal mérőszáma pozitív) a+b>c a+c>b b+c>a (az oldalakra teljesül a háromszög-egyenlőtlenség) Utófeltétel: s=(a+b+c)/2 T s(s a)(s b)(s c) Héron-féle területképlet Programunknak gondoskodnia kell arról, hogy csak olyan adatokat adhasson meg a program felhasználója, amelyek teljesítik az előfeltételeket, illetve arról, hogy a kimenő adatok teljesítsék a specifikációban leírt utófeltételeket. Példánkban az is látható, hogy egy feladatnak nem csak bemenő és kimenő, hanem fontos köztes adatai is lehetnek, ebben az esetben az s, amely a három oldal alapján számolható valós érték. Lényeges szerepe miatt ezt is rögzítettük az utófeltétel megfogalmazása során A specifikáció során használható szimbólumok A feladatok specifikálásakor gyakran alkalmazunk logikai műveleteket, valamint a matematikai logika egyéb szimbólumait. A legtöbbször használt jelek a következők: : ÉS logikai művelet 2

3 : VAGY logikai művelet : AKKOR logikai művelet (implikáció) : AKKOR és CSAK AKKOR logikai művelet (ekvivalencia) : minden logikai kvantor : létezik logikai kvantor Példaként tekintsünk egy rövid részletet egy feladatspecifikációból, amely az előbbi szimbólumokat használja: Jelekkel: i (1<= i <=N) : (A[i]>0 B[i]<0) C[i]<0 Szöveggel: minden 1 és N közé eső i értékre, amennyiben az A tömb i. eleme pozitív, a B tömb i. eleme pedig negatív, akkor a C tömb i. eleme negatív. Megfigyelhető, hogy a jelekkel felírt specifikáció sokkal tömörebb Összetett programozási feladatok specifikációja Felmerül a kérdés, hogy mi a helyzet a nagy programok specifikálásával? Ha egy kis feladat pontos megfogalmazása ennyi problémát vet fel, akkor hogyan tudjuk egy igazi program specifikációját átlátni? A válasz egyszerű: a nagy feladatokat osszuk fel részfeladatokra, azokat már valószínűleg könnyebb lesz specifikálnunk. Ha a részekre bontás után még mindig összetettek a feladatok, alkalmazzuk újabb felosztást, egészen addig, amíg elemi, könnyen megfogalmazható feladatot nem kapunk. Ez a kérdés már továbbvezet minket az algoritmuskészítés lépése felé, amelynek alapvető technikája a feladatok részekre bontása. 2. PROGRAMTERVEZÉSI ESZKÖZÖK A programtervezési eszközök közé sorolhatjuk mindazokat az eszközöket, módszereket, amelyek lehetővé teszik a programok specifikálását és tervezését. - Az adatleírást, specifikációt segítő eszközök: o Matematikai és logikai szimbólumrendszer Függvények (sorozatok, tulajdonságok definiálására) Állítások, logikai műveletek, kvantorok (elő és utófeltételek pontos leírására) o Típusleíró eszközök Matematikai jellegű típusleírás (pl. vektor ill. rekord direkt szorzatként történő felírása, pl. R N : N dimenziós, valós elemű vektor) Pszeudo-nyelv típusleíró része (hasonló, mint a programozási nyelvek típusdefiníciós része, de nyelvfüggetlen) 3

4 o Adatmodell-leíró eszközök: Bachman diagram, relációs adatbázis esetén alkalmazzuk, tartalmazza az egyes adattáblák szerkezetét, és az adattáblák közötti kapcsolatokat UML osztálydiagram. - Algoritmusleíró eszközök: pl. folyamatábra, stuktogram, Jackson-diagram, pszeudo-kód (mondatszerű leírás), UML aktivitás-diagram - OOP tervezést segítő eszközök o OOP rendszertervező eszköz: UML (Egyesített Modellező Nyelv): o Nagyon sokféle diagramtípust tartalmaz, amelyek a szoftverfejlesztés valamennyi fázisát segítik. o UML diagramtípusok pl. Használati eset diagram: a feladatspecifikáció elkészítéséhez. Osztálydiagram: a tervezéshez, tartalmazza a rendszerben található összes osztályt, és azok kapcsolatait, számosságukat Objektum-diagram: demonstrálja az egyes objektum-példányokat o CASE eszközök: Beépített OOP rendszertervezés (pl. UML) Beépített kódgenerálás egy, vagy többféle objektum-orientált forrásnyelven. Automatikus tesztelés és dokumentálás 3. PROGRAMOZÁSI ELVEK A programozási feladatok általában nem olyan egyszerűek, mint az előző mintaprogramunk. Sőt, a feladatok többsége szinte áttekinthetetlenül bonyolultnak tűnik. Ezért a programozók számos programtervezési elvet dolgoztak ki, melyeket következetesen alkalmazva úrrá lehetünk a feladatok bonyolultságából adódó nehézségeken. A., STRATÉGIAI ALAPELV - Oszd meg és uralkodj! elve: A programot több, kisebb részre bontjuk, amelyek önmagukban már sokkal kevésbé bonyolultak, mit az eredeti feladat. Szükség esetén az egyes részeket még tovább bonthatjuk. Ezt a programozási módszert moduláris programozásnak is nevezik. Kezdetben a modularitást kizárólag az eljárások és függvények alkalmazása jelentette, később megjelentek az egységek (eljárásgyűjtemények, unitok), majd pedig az objektumok. B. TAKTIKAI ELVEK A moduláris programtervezés megvalósítását segítő taktikai elvek a következők: - A modulok függetlenségének az elve: Minden modul csak a saját feladatával foglalkozzon, és azt tökéletesen hajtsa végre. 4

5 - Az adatok elszigetelésének az elve: A modulok csak a saját adataikon dolgozzanak, ne legyenek több modul által közösen, egyszerre használt adatok. Egy modul csak kész, már feldolgozott adatokat adhat át egy másiknak. A moduláris programozás többféleképpen is megvalósítható. A leginkább elterjedt moduláris programtervezési technikák Felülről lefelé történő (TOP-DOWN) programozás. A programot először néhány nagy modulra bontjuk, majd szükség esetén ezeket további, kisebb részekre osztjuk, és így tovább, egészen addig, amíg elemi, azaz rutinszerűen megoldható részfeladatokat kapunk. Ehhez a módszerhez kapcsolódnak a következő elvek: - Párhuzamos finomítás elve: Lehetőleg párhuzamosan dolgozzuk ki valamennyi modult, ne szaladjunk előre valamelyik ágon. - A döntések elhalasztásának az elve: Az algoritmus finomítása során egyszerre csak kevés dologról döntsünk. Ha egy problémát elég valamely alacsonyabb szintű modulban megoldani, akkor azt csak ott tegyük meg. - Vissza az ősökhöz elv: Ha egy ponton kiderül, hogy zsákutcába jutottunk, akkor merjünk visszalépni, gondoljuk át újra magasabb szinten a feladatot, esetleg bontsuk fel másképp az adott szintet. Ne erőltessünk nyilvánvalóan rossz utat! - A döntések kimondásának az elve: Ha valamiben döntést hoztunk, akkor azt rögzítsük, ne programozzunk hallgatólagos döntések alapján. Alulról felfelé történő (BUTTOM-UP) programozás. E módszer lényege, hogy programunkat már elkészített modulokból, építőkövekből rakjuk össze. Alkalmazásához szükséges, hogy előrelátóan dolgozzunk, és lehetőleg mindig olyan rutingyűjteményeket, modulokat készítsünk, amelyeket később írt programjainkban is fel tudunk használni. Itt említjük meg az ehhez a módszerhez legszorosabban kapcsolódó, de általánosan is alkalmazott elvet: - A nyílt rendszerű felépítés elve: Programjaink írása során lehetőleg ne csak az adott feladatra, hanem az azt magába foglaló problémakörre készítsünk megoldást. Az előző két módszer ötvözete. A gyakorlatban ritkán fordul elő, hogy az előbb említett két módszer valamelyikét tisztán alkalmazzuk. Gyakoribb, hogy a tervezést TOP- DOWN módszerrel végezzük, de felhasználunk előre elkészített, vagy a fejlesztés céljából vásárolt modulokat. Objektum-orientált programozás. - A jelenleg legkorszerűbbnek tekintett programozási technika. - Legfontosabb jellemzője, hogy az adatok és a hozzájuk kapcsolódó műveletek, eljárások egységbe foglalása révén magas szinten és az eddigi módszereknél biztonságosabban valósítja meg a moduláris programozás fent említett alapelveit. - E programozási technika a korábbi módszereknél sokkal erőteljesebben támogatja a modulok újrafelhasználhatóságát. Megjegyzések: A fent említett programozási módszerek és elvek természetesen csak sok gyakorlással sajátíthatók el. 5

6 A gyakorlatban sajnos még a legegyszerűbbnek tűnő elvek (pl. párhuzamos finomítás, vagy nyílt rendszerű felépítés) következetes alkalmazásához is nagy önfegyelemre van szükség. A legjobb, ha már a kisebb feladatok megoldása során is törekszünk a fent leírt elvek alkalmazására. Példa az említett programozási elvek alkalmazására: Tekintsük át az előzőekben specifikált feladat megoldását: Feladat: Háromszög területe 1. szint Program HaromszogTerulete: OldalakBekerese(a,b,c) T:=HaromszogTerulet(a,b,c) Kiiras(T) Program vége. 2. szint: Eljárás OldalakBekerese(a,b,c:valós) Ciklus OldalBeker(a) OldalBeker(b) OldalBeker(c) Ha (a+b<=c) vagy (a+c<=b) vagy (a+c<=b) Akkor Hiba( Nem teljesül a háromszög-egyenlőtlenség! ) amíg nem ( a+b>c és a+c>b és a+c >b) Eljárás vége Függvény HaromszogTerulet(a,b,c:valós):valós s:=(a+b+c)/2 HaromszogTerulet : Függvény vége Eljárás Kiir(T:valós) Ki: T Eljárás vége 3. szint: s(s a)(s b)(s c) Eljárás OldalBeker(Oldal:valós) Ciklus Be: Oldal Ha (Oldal<=0) akkor Hiba( Az oldalhossz nem pozitív! ) amíg nem ( Oldal > 0 ) Eljárás vége 6

7 Ebben az egyszerű feladatmegoldásban is megfigyelhető az előbb említett elvek többségének az alkalmazása. - A döntések elhalasztásának az elve már a főprogramban megjelenik, hiszen ezen a szinten az algoritmusból a feladat tagolásán kívül semmi lényegeset nem írunk le. Ugyanez az elv az OldalakBekerese eljárásban is megfigyelhető, az ellenőrzött adatbekérés tényleges megfogalmazását a 3. szintre halasztjuk. - A modulok függetlenségének az elvét is alkalmazzuk, minden eljárásnak megvan a pontos, jól meghatározott szerepe a programon belül. - A párhuzamos finomítás elve is jól megfigyelhető, csak a 2. szint minden eljárásának kifejtése után lépünk tovább az oldalbekérés ténylegesen megírására. - Az adatok elszigetelése a paraméteres eljárások révén valósul meg. Bár az a, b, c és T adatokat több eljárás is használja, ezek értékét az egyes eljárások paraméterek segítségével adják át egymásnak. Megemlítjük, hogy a HaromszogTerulet függvény s adata csak a függvény által használt, ún. lokális változó. - A nyílt rendszerű felépítés elvét az egyszerűség kedvéért ezúttal nem alkalmaztuk, de megemlítjük, hogy ezen elv jegyében az OldalBeker eljárás helyett írhattunk volna pl. egy ValosBeker eljárást, amely tetszőleges intervallumba eső valós szám bekérését valósítja meg. C. TECHNOLÓGIAI ELVEK Az algoritmusleírás módszereit határozzák meg. - Kevés szabályt alkalmazzunk, korlátozzuk a leíró nyelvekben használható utasításokat - Összetett utasításokat mindig zárójelezzünk, azaz egyértelműen jelöljük az elejét, ill. a végét. (Pl. Ciklus ciklus vége) - Alkalmazzuk a bekezdéses leírást! (Áttekinthetőség) - Alkalmazzunk beszédes azonosítókat! D. TECHNIKAI ELVEK A programkód minőségét biztosító elvek. - Barátságos program. Mindenről tájékoztat, soha nem hagyja a felhasználót bizonytalanságban. Legalkalmasabb eszközei: jól felépített menürendszer, ill. Súgó; valamint a felhasználó nyelvén megfogalmazott, valódi segítséget nyújtó üzenetek. - Bolondbiztos program. Semmiféle hibás felhasználói beavatkozás ne tudja a program működését megzavarni, a programfutást megállítani. - Jól olvasható programkód. o Szabályos struktúrák használata o Tagolás, eljárások, függvények, modulok o Beszédes azonosítók o Megjegyzések - Ergonómiai elvek. o Menütechnika, szokásos megoldások alkalmazása. 7

8 o Hagyjunk időt a felhasználónak mindenre. A felhasználó döntse el, hogy mikor lép tovább. o Ne legyen túlzsúfolt a képernyő, kerüljük a túl sok menüpont alkalmazását. o A színek, hangok ne legyenek zavaróak, lehessen beállítani, ill. kikapcsolni. 8