Programozás alapjai, programtervezés

Programozás alapjai, programtervezés

Mûszertechnika Oktatás Kft. Összállította: Kertész György tanfolyami jegyzete alapján Kovalcsik Géza 1107 Budapest Szállás u. 21 Telefon: 260-87-14 Tel/Fax: 260-43-48 Levélcím: 1475 Budapest Pf. 167 Tartalomjegyzékre ugrás E:\Dokumentumok\Excel makro\Ventura\Jackson screen2.vp 1999.januÆr.26. 13:01:26

Ezúton is szeretném megköszönni Kertész Györgynek a segítségét, melyben hozzájárult ahhoz, hogy az Excel programozása könyv CD mellékletében közreadjam az általa készített Programozás alapjai, programtervezés címû jegyzet kivonatát. Ugyanitt szeretném köszönetemet nyilvánítani a Mûszertechnika Oktatás Kft-nek is. A jegyzet a Mûszertechnika Oktatás Kft tulajdona. Ennek megfelelõen bármilyen módon felhasználni akár az egészet, akár egyes részleteit csak az Õ hozzájárulásukkal lehet.

E:\Dokumentumok\Excel makro\Ventura\Jackson screen2.vp 1999.januÆr.26. 13:01:26

Bevezetés Elsõként gondoljuk át, hogy mi is valójában egy program? Egyáltalán mit jelent a program szó? Használjuk ezt a szót a napi társalgásban is. Például így: ez, vagy az a rendezvény egy jó program volt. Vagy máskor így: mi lesz a vasárnapi program? Mi volt a közös ebben a két mondatban? Az, hogy az esemény, ami adott helyen történik és meghatározott ideig tart, programnak neveztünk. Persze ez még nem elegendõ ahhoz, hogy valamit programnak tekintsünk. Mindkét esetben sok külsõ tényezõtõl függött az, hogy a „program” hogyan zajlott. Nevezzük tehát programnak azt az adott helyen és idõben meghatározott eseményt vagy eseménysorozatot, ami a külsõ tényezõket figyelembe véve, esetenként más-más módon folyhat le. A számítógép egy programozható eszköz, ami a megfelelõ programok nélkül nem képes mûködni. A számítógép programja is egy adott helyen – a számítógépünkön –, adott idõben – a program indításától kezdve –, a környezeti változásokat a megfelelõ pillanatban kiértékelve – a körülmények figyelembevételével –, alkalmanként máshogy folyik. A számítógép programok a számítógépet, annak központi egységét vezérlik. A vezérlés eszközei csak olyanok lehetnek, amiket a számítógép ki tud értékelni. A körülmények kiértékelésének, bár más-más programnyelvrõl legyen is szó, azonos módjai vannak, hiszen a kiértékelést minden esetben a számítógép végzi. Ez teszi lehetõvé azt,


hogy egy programot úgy tervezhessünk meg, hogy elõbb elkészítjük a program tervét, és utána választunk programnyelvet. Egy jó tervnek bármelyik programnyelven megvalósíthatónak kell lennie. Az egyes programnyelveket egy-egy feladatkör megoldására tervezték. A nyelv megválasztása így nem teljesen mindegy. Ez a gondolat nem az elõzõ állítás tagadása, csak egyszerûen azt jelenti, hogy a szerszámokat arra használjuk, amire kitalálták. Olyan ez, mint amikor egy szöget a csavarhúzó fejével szeretnénk a falba verni. Ha elég nagy a csavarhúzó, akkor a mûvelet valószínûleg sikerülni fog, de gondolom mindenki inkább kalapácsot fog használni. A mi esetünkben nem kérdés a nyelv megválasztása – Visual Basic for Application –, de a tervezés során nem a nyelv ismerete lesz a legfontosabb tudnivalónk. A könyvben már láttunk egy lehetséges utat a program megtervezésére és megvalósítására. Ha komolyan foglalkozunk programok készítésével, akkor minden esetben a feladat megfogalmazása és megtervezése fogja meghatározni munkánk eredményét. Ez a melléklet elsõsorban azoknak szól, akiknek még nincs gyakorlatuk összetett programok készítésében, de a könyv olvasása felkeltette érdeklõdésüket ez iránt a szép alkotó munka iránt.


Feladatmegoldás A megvalósításra szánt programozási feladatok során találkozunk gyorsan, egyszerûen átlátható feladatokkal, és olyanokkal, melyeknél már a megoldandó probléma megértése is nehéz. Az elsõ esetben csak akkor gondolunk programozásra, ha valamilyen mûveletsort gyakran hajtunk végre. Ilyenek a statisztikai feldolgozások és az adminisztratív feladatok többsége. A második esetben a feladat bonyolultabb, megoldása sok külsõ feltételtõl függhet. E körbe tartoznak a tudományos, az ipari tervezési és irányítási feladatok. A valóságban elõforduló esetek mindegyikére nem lehet példát adni. Mit kezdhetünk az egyszerû adatokkal dolgozó, de sok és sokféle eredményt adó alkalmazásokkal, melyek adminisztratív területen is sûrûn elõfordulnak, vagy a másik oldalról azokkal, melyek bonyolult adathalmazokból egyszerû következtetéseket vonnak le? Be kell látnunk, hogy a feladatokat nem válogathatjuk a fenti egyszerûséggel. Észrevehetünk azonban egy fontos szempontot: minden esetben adatokról és eredményekrõl beszéltünk. Szerencsésebb megközelítés, ha ezek alapján gondolkodunk. Egy program tervezése során a feladatot két kérdéssel közelítjük meg: „Mit szeretnék eredményként kapni?” és „Milyen adatokból állítható elõ a kívánt eredmény?” A számítástechnika fogalmaival: a program a bemeneti (input) adatokból egy meghatározott utasítássor végrehajtásával (procedure) létrehozza a kimeneti (output) adatokat. Az adatok beadásától az eredmény megjelenéséig nekünk kell meghatároznunk a megfelelõ lépéseket.


Azt a lépéssorozatot, ami a bemeneti adatokból létrehozza az eredményt, algoritmusnak nevezzük. A programozási feladatokat minden esetben felbonthatjuk az adatbeolvasás, feldolgozás és eredmény megjelenítése részekre. Erre a felbontásra gyakorlatilag mindig lehetõségünk van. Még olyan elsõ látásra nehezen ide sorolható esetekben is, mint például egy ébresztõóra program, melyben a bemeneti adat egyrészt az idõ múlása, másrészt a beállított ébresztési idõ, s ahol a kimenet az eltelt idõ jelzése, és az ébresztés. Arra a kérdésre, hogy mitõl lesz egy feladat egyszerû, vagy bonyolult, szintén nem lehet rávágni a nyilvánvalónak tûnõ választ. Sok rosszálmú programozó köszönheti kínjait a tervezéskori hibás megközelítésnek. Az egyszerû feladat (ahol a bemenetbõl egyszerûen alakítható ki a kimenet) is lehet nehezen megoldható, ha akár a „kapok”; akár az „adok” kérdésre nem tudjuk a megfelelõ választ meghatározni. Régi tapasztalat, hogy a számítógépes programtól várt kimeneti eredménynél csak a bemeneten rendelkezésre álló adatokról tudunk nehezebben információt szerezni. Nem is az a baj, hogy a majdani felhasználó ne mondaná el készségesen a válaszokat, hanem az, hogy nehéz kiválogatni a kívánt kimenethez szükséges bemeneti adatokat. Sokféle bemeneti adat állhat rendelkezésre, de nem feltétlenül szükséges mindegyik, illetve egyik származhat a másikból. Nagyon fontos, hogy meg tudjuk határozni a szükséges és elégséges bemeneti adatok körét. Erre csak a kimeneti igények ismeretében van lehetõségünk. Tudnunk kell jól megfogalmazni a kérdéseket, és jól kiértékelni a válaszokat. A fenti probléma megoldása általában – papíron – a szervezõ gondja. Az életben persze ez sem ilyen egyszerû. Mindenképpen ismernünk kell a feladatmegoldás ilyen értel-


mû elõkészítését, hiszen másképp nem tudnánk értelmezni a szervezõ által megadott adatokat. Nem is beszélve azokról az esetekrõl, amikor a szervezési feladatok is a programozóra hárulnak. Foglaljuk össze, a fentiek alapján mit is nevezhetünk feladatmegoldásnak: a szükséges kimeneti adatok megfogalmazása után meghatározzuk az ezek elõállításához szükséges bemeneti adatokat, majd ezek alapján leírjuk, hogy a bemenetbõl milyen átalakítással kapjuk meg a kimenetet. Ezt a tervezési módszert az angol nyelvû szakirodalom az Input, Procedure és a Output szavak kezdõbetûinek az összeolvasásával IPO módszernek nevezi.

A programkészítés lépései A feladat meghatározása, specifikáció A specifikáció egy olyan leírás, amely rögzíti a feladattal szemben támasztott igényeket, követelményeket. Ebben meg kell határozni azt, hogy mi a feladat, azt milyen környezetben kell megvalósítani, milyen bemenettel rendelkezünk és milyen kimenetet, eredményt várunk el a programtól. A specifikáció minõsége, korrektsége alapvetõen meghatározza a további munka sikerét. A hiányos feladat-meghatározás alapján készített


programról általában csak a program tesztelése során – az ellenõrzéskor –, vagy a program használatbavételekor derül ki, hogy nem azt teszi, amit vártunk tõle. A feladat meghatározását a programozó általában készen kapja. Ez elsõ hallásra azt jelenthetné, hogy a programozó nem felelõs annak hibáiért. Lehet így gondolkozni, de nem célravezetõ. A programozónak rendelkeznie kell annyi rálátással az adott területre, hogy a nem kellõen pontos, vagy feltételezhetõen hiányos részekre, rá tudjon kérdezni. Sokszor arra is szükség lehet, hogy egyes részleteket önállóan dolgozzon ki. Vagyis a feladat meghatározásának egy párbeszédnek kell lennie a megrendelõ és a program írója között. A feladat meghatározása w A feladatok meghatározása során körültekintõen kell eljárnunk. Fel kell becsülni a célokat és lehetõségeket. Itt még azt is el kell döntenünk, hogy a feladat egyáltalán megvalósítható vagy nem. A feladatot a következõ szempontok szerint fogalmazzuk meg: A megfogalmazás legyen – teljes, – érthetõ, – egyértelmû, – pontos, – tömör, – szemléletes,


– elõrelátó, – jól felépített, tagolt. Ha az input, procedure, output tervezési módszert követjük, akkor a bemeneti és kimeneti adatokkal kapcsolatban a következõ szempontokat vegyük figyelembe: Input adatok: – Mik az input adatok? – Milyen a beviteli formájuk (adattípus) ? – Mik a bevihetõ értékek? – Az adatbevitelt hogyan kell befejezni? – Milyen speciális megszorítások vannak? – Milyen kapcsolatok állnak fenn a beviendõ adatok között? Output adatok: – Milyen adatokat kell megõrizni? – Milyen formában kell megõrizni az adatokat? – Mennyi adatról van szó? – Melyik adatokat kell megjeleníteni? – Hogyan állíthatjuk elõ ezeket az adatokat?


Tervezés A program egy idõben zajló folyamat leírása. Azt várjuk el tõle, hogy a feladatot oldja meg, illetve a feladatban kitûzött célokat valósítsa meg. A specifikációból, vagy más szóval a feladat-meghatározásából, a forrásprogram, mint a fordítás alapjául szolgáló szöveg, nem egyszerû begépeléssel jön létre. A feladatot meg kell értenünk, el kell képzelnünk a megoldás menetét, majd részletesen ki kell dolgoznunk. E folyamatban helyezkedik el a tervezés, mint olyan lépés, mely leegyszerûsíti és pontossá, hatékonnyá teszi a programkészítés folyamatát. A tervezés során arra törekszünk, hogy az emberi gondolkodással, emberi nyelven elképzelt megoldást olyan világos egyszerû szerkezetekkel fogalmazzuk meg melyek könnyen megfeleltethetõk lesznek a majdani programlépéseknek. A jó programterv nem kötõdik programnyelvhez, számítógéptípushoz, általános fogalmakkal dolgozik. Az egyes feladatok megoldásához meg kell határoznunk a megfelelõ algoritmust. A megoldandó feladatot bontsuk kisebb részekre. Kevés ember van, aki egy nagyobb feladatot egy lépésben meg tud oldani. Egy almát sem eszünk meg egyetlen harapással. A feladat megoldása szempontjából így kisebb jobban áttekinthetõ részekkel kell dolgoznunk. Hogyan bontsuk részekre a programozási feladatainkat? Arra kell törekednünk, hogy a részek minél kevésbé függjenek egymástól. Tehát az egyes részek önállóan is hasz-


nálhatóak legyenek. Ez a fejlesztési szemlélet nem csak a tervezés során teszi érthetõvé a programot, hanem késõbb könnyebb lesz a programot karbantartani is.

Kódolás A kódolás az a lépés, melyet a kívülálló általában programozási tevékenységnek tart, hiszen azt látja, hogy megszállott emberek püfölik a számítógép billentyûzetét és nem figyelnek a külvilágra. Itt készül el a terv alapján a forrásprogram, az adott nyelv szabályai szerinti és annak eszközkészletére hivatkozó kód, melyet lefordítva jutunk a gépi kódú programhoz. Abban, hogy ez a fázis milyen sokáig tart, mennyire hatékony, nagy szerepe van az elõzõ lépések jó megoldásának. A rossz tervbõl szinte soha nem lesz jó program, míg a jó terv alapján hibátlan, jószerével csak elírásokat tartalmazó program készülhet. Sikerélményt nem az okoz, ha több napi fúrás-faragás után rájövünk a hibára, hanem az, amikor a kódolás gyors, egyszerû, a begépelt program a fordítás után úgy mûködik, ahogy elképzeltük. Régi mondás, hogy csak az lehet jó, ami szép is. Ha ezt gondolatmenetünk tisztaságára, megoldásaink egyszerûségére, követhetõségére, átláthatóságára értjük, elhihetjük: minél többet fúrjuk-faragjuk a programot, annál több rejtett hibát fog tartalmazni, annál nehezebb lesz igazán kijavítani. Murphy szerint: az elsõ hibátlan programot még írják. A kódolás eredménye a program maga. Ezt forráslistának nevezzük.


A forráslista akkor jó, ha: – pontosan a programterv alapján készült, – áttekinthetõ, olvasható, – tömör és egyértelmû magyarázó megjegyzéseket tartalmaz.

Tesztelés A munka során rendszeresen ellenõrizzük megoldásaink helyességét. Ilyen ellenõrzéseket nemcsak a kódolás során végzünk, hanem már a terv lépéseit is tesztelhetjük. Nyilvánvaló, hogy a terv elolvasásával is megállapítható, mi fog történni. Az ilyen ellenõrzéseket asztali- vagy száraztesztnek nevezzük. A programot természetesen mûködés közben is ki kell próbálnunk. Az ellenõrzés körülményeit gondosan meg kell határoznunk. Nem elég a mûködésnek megfelelõ (rendeltetésszerû) használatnak kitennünk. Gyakori hiba, például, ha a program egy számra vár, de a programban nem ellenõrizzük, hogy a felhasználó valóban számot írt-e be? A programozónak nem szabad csak azt ellenõrizni, hogy programja a számokra hogyan reagál, hiszen a felhasználó szöveget is beírhat, amitõl a programnak nem szabad „megbolondulnia”. Különös gondosságot igényel, hogy a programban elõforduló döntéseket minden szélsõ helyzetre megvizsgáljuk.


A fejlesztés lezáró ellenõrzése lehet az úgynevezett béta-teszt, ami azt jelenti, hogy a kész programot kipróbálásra átadjuk egy vagy több majdani felhasználónak, akik tapasztalataikat, a felfedezett hiányosságokat elmondják nekünk. Ilyen teszt csak a nagyobb méretû és felhasználói körû programoknál szokásos. A tesztelés eszköze a nyomkövetés. A korszerû fejlesztõrendszerek, – így a Visual Basic for Application is –, lehetõvé teszik a program speciális, lépésenkénti futtatását, és közben az egyes adatok, változók értékeinek a figyelését. A figyelmetlenségbõl, átgondolatlanságból eredõ hibák nagy része kiszûrhetõ így. Gyakran használjuk e lépés megnevezésére az angol „debugging“ szót, ami szó szerint „poloskátlanítást“ jelent. A tesztelés tulajdonképpen nem más, mint egy próbafuttatás. A próbafuttatás alatt sok hibáját fedezhetjük fel a megírt programnak. A tesztadatokat úgy kell összeállítani, hogy minden lehetséges értéket felvegyenek. A program tesztelésekor a következõkre kell figyelemmel lennünk: – A program pontosan úgy mûködik-e mint azt a feladat meghatározásában leírtuk? – Ne lehessen a programot elrontani. – Elég hatékony-e? – Biztonságos-e a használata? – Felhasználóbarát-e? – Mennyire szolgálja ki a felhasználó igényeit? – A külsõ megjelenése elég esztétikus?


– Sehol nem idegesítõ? – Mennyire illeszkedik a szabványokhoz, szokásokhoz?

Dokumentáció A program dokumentációja több részbõl áll. Egyik részét képezi a fejlesztéskor létrehozott írásos anyag: a specifikáció, a terv, a programkód, az abba beírt megjegyzések és a tesztek kiinduló adatai, eredményei. Másik része a felhasználáshoz szükséges segédanyag: installációs leírás, kezelési utasítás, technikai referencia. A fejlesztési dokumentáció minõsége (érthetõség, olvashatóság) fontos a kivitel, a hibakeresés és a késõbbi fejleszthetõség szempontjából is. Célszerû a program forráskódját is öndokumentáló módon elkészíteni. Ez azt jelenti, hogy a szöveget ellátjuk magyarázó megjegyzésekkel, illetve a befoglalt részeket beljebb tabuláljuk, az egyes részeket világosan elhatároljuk stb. Összefoglalóan: betartunk olyan szerkesztési konvenciókat, amelyek lehetõvé teszik, hogy a programkód szövegét bárki elolvasva megérthesse azt (akár magunk is egy késõbbi alkalommal).


A fejlesztõi dokumentációnak a következõket kell tartalmaznia: – A feladat meghatározása. – A programterv. – A forrásprogram. – A kész program forrás kódú listája. – Tesztadatok listája. A felhasználói dokumentációnak más feladatokat kell kielégítenie, mint a fejlesztõi dokumentációnak. A felhasználói dokumentációnak a következõ részekbõl kell állnia: – A feladat leírása, vagyis mire használható a program. – Milyen legkisebb hardver konfiguráción használható. – Milyen legkisebb szoftver környezetben használható. – Hogyan lehet használatba venni. Telepítés. – Hogy lehet elindítani a programot? – A program használatának részletes leírása. – Hibalehetõségek, hibaüzenetek magyarázata, útmutatás, teendõk leírása.


A programnyelvek elemei A számítógépes programok adatokkal, vezérlésekkel dolgoznak, így fontos ismernünk ezek típusait. Az adat fogalmáról megállapítottuk, hogy a körülöttünk lévõ dolgok bármely mérhetõ és nem mérhetõ jellemzõjét így nevezhetjük, ha azt egyértelmûen le tudjuk írni. Az információ fogalmával is találkoztunk: az adatokból levont következtetések eredménye. Ez utóbbi a számítógép számára ugyanúgy jelenik meg, mint az eredeti adat, ezért most nem fogunk közöttük különbséget tenni, egyszerûen mindkettõt adatnak nevezzük. A számítógépeken, függetlenül a programnyelvtõl, az adatokat különbözõ formában tároljuk. Ahhoz, hogy egy programot megvalósítsunk, ezeket az adatformákat ismernünk kell.

Adattípusok Az adatokat a program futása alatt változókban õrizzük meg az éppen futó program számára. A változó nem más mint a számítógép operatív memóriájában egy névvel ellátott hely, ami alkalmas az adatok tárolására. Az egyes helyfoglalásokat deklarálással valósíthatjuk meg. Az egyes helyfoglalások, deklarálások alkalmával azt is meghatározhat-


juk, hogy az adatot milyen formában kívánjuk megõrizni. Ezzel annyi helyet fogunk lefoglalni az adataink számára, amennyire szükség van. A jegyzetben a Visual Basic for Application nyelvben használható változótípusokat mutatjuk be, de a felsorolt típusokat más programnyelvekben is meg fogjuk találni.

Numerikus típusok Számszerû értékek ábrázolására szolgálnak. Megkülönböztetünk egész és valós típusokat. Az egész típusok nevükbõl adódóan egész számokat ábrázolhatnak, míg a valós típusok valós, azaz egész és tört számokat. Mindkét esetben beszélhetünk az ábrázolható számok intervallumáról (a legkisebb és a legnagyobb érték között). Az egész típusoknál a pontosság kérdése nem vetõdik fel, annál inkább érdekes a valós típusoknál. Az egész típusokat tárolási módjuk és méretük alapján osztályozhatjuk.


Egészszámok: adattípus

hossza

intervallum

Byte

1 byte

0-tól 255-ig

Integer

2 byte

-32 768-tól 32 767-ig

Long

4 byte

-2 147 483 648-tól 2 147 483 647-ig

Valós számok: Single

4 byte

Negatív számok: -3,402823E38-tól 1,401298E-45 Nulla Pozitív számok: 1,401298E-45-tõl 3,402823E38-ig

Double

8 byte

Negatív számok: -1,79769313486231E308-tól -4,9406564584124E-324-ig Nulla Pozitív számok: 4,9406564584124E-324-tól 1,79769313486231E308-ig


Currency

8 byte

-922 337 203 685 477,5808-tól 922 337 203 685 477,5807-ig

Date

8 byte

100-január 1-tõl 9999-december 31-ig

Szöveges típusok A program a szöveges adatokat éppúgy képes feldolgozni, azokkal mûveleteket végezni, mint a számértékekkel. A Visual Basic for Application programnyelvben kétféle String típusú változót deklarálhatunk. Fix hosszúságút és változó hosszúságút. A változó hosszúságú szöveges változó hossza körülbelül 2 milliárd karakter tárolását teszi lehetõvé. A fix hosszúságú szöveges változók hossza maximum 64 kbyte lehet. Egy tíz karakter hosszúságú szöveg befogadására alkalmas változót a következõ módon kell deklarálnunk: Dim Szoveges As String *10


Logikai típus A számítástechnika szinte legfontosabb adattípusa, bár ezt elsõ látásra nem is gondolnánk. Logikai típusú adat, kell minden döntéshez, ami a program mûködését befolyásolja. A logikai típus tárolásához 1 bit szükséges, hiszen értéke csak kétféle (hamis és igaz) lehet. A kényelem (sebesség, egyszerû programozás) érdekében az IBM PC-re írt programnyelvek általában egy egész byte-ot elhasználnak egy bit helyett. A VBA két byte-ot foglal le a Boolean típusú változóknak. Az érték True vagy False lehet.

Mutató típus A mutató típus a memória egy címét tárolja, azaz egy címre mutat, ahol adat, objektum vagy alprogram található. A VBA nyelvben objektumokra hivatkozhatunk mutató típusú változóval. Az adattípus deklarálása során az Object kulcsszót használjuk. Mutató típusú változónak a Set paranccsal adhatunk értéket. Erre példa a következõ programrészlet: Dim Lap As Object Set Lap = Worksheets(1)


A Set utasítás segítségével a Worksheets(1) munkalapot elneveztük Lap névvel. A program további részeiben a Lap változóval hivatkozhatunk – rámutathatunk – a Worksheets(1) munkalapra.

Általános adattípus Ha a program futása során egy változónak úgy adunk értéket, hogy elõre nem tudjuk annak az adattípusát, akkor a Variant változótípust használhatjuk.

Adatszerkezetek Az egyedi tárolású adatok nem elégítenek ki minden igényt, hiszen sokszor fordul elõ, hogy több önálló, esetleg eltérõ típusú adat képez olyan egységet, amit a gépi feldolgozás során is szeretnénk megõrizni. Az adattípusok adatszerkezetekbe szervezhetõk, s azok újabb szerkezetekbe ágyazódhatnak. Mindig a program igényeihez legjobban alkalmazkodó szerkezeteket alakítsunk ki. A legalapvetõbb esetekre a programnyelvek általában kínálnak megoldást:


A tömb azonos típusú, méretû adatok ismétlõdése a memóriában, index-szel, az adat tömbön belüli sorszámával hivatkozhatunk a egy-egy elemére. Erre a könyvben a változókról szóló részben találunk példákat. Rekord típusú változóban eltérõ típusú, méretû adatok együttesét tárolhatjuk. Ezeket a változótípusokat nekünk kell meghatároznunk. A VBA nyelvben erre a TYPE utasítást használjuk. Az így meghatározott változók a felhasználó típusú változók. Type felhaszntípus elemnév As típusnév [ elemnév As típusnév]... ... változók felsorolása ... End Type A Type utasítás argumentumai a következõk: felhaszntípus A felhasználó által definiált típus neve. Erre az általános változó elnevezés szabályai érvényesek. elemnév

A felhasználó által definiált típus elemének neve. Erre az általános változó elnevezés szabályok érvényesek


típusnév

Az elõbb felsorolt típusok egyike lehet (típusnév nem lehet objektum adattípus).

Felhasználói változótípust a következõ leírás szerint határozhatunk meg: Type HelysegAdat HelysegKod (1 To 100) As Integer Orszag As String * 30 End Type A felhasználó által meghatározott változótípust a továbbiakban ugyanúgy használhatjuk egy-egy változó típusának a megjelölésére, mintha a VBA beépített adattípusa lenne: Dim Ibafa As Helysegadat Az elõzõ példában a HelysegAdat tartalmazza a Helysegod statikus tömböt, és az Orszag stringet. Az Ibafa rekordnak ugyanaz a szerkezete, mint a HelysegAdatnak. A következõ példában a Type utasítással egy 3 elemû, a felhasználó által definiált típust hozunk létre, ennek segítségével megadunk egy ilyen típusú változót, és minden elemhez hozzárendelünk adatokat.


Type TesztRekord VevoSzam As Long VevoNev As String * 36 Hitel As String * 24 End Type Dim Vevo As TesztRekord Vevo.VevoSzám = Val(InputBox$(„Írja be a vevõ számát: “)) Vevo.VevoNév = InputBox$(„Írja be a vevõ nevét: “) Vevõ.Hitel= InputBox$(„Írjon be hitelezési információt: “)

Utasítások típusai A programokban használt utasításokat az adott nyelvtõl függetlenül csoportosíthatjuk: – értékadás – vezérlésátadás – direkt: ugrás, alprogramhívás, visszatérés – feltételes: elágazás, ciklus – egyéb


Vezérlõszerkezetek A program mûködését, az utasítások végrehajtási sorrendjét befolyásoló utasításokat összefoglalóan vezérlésátadó utasításoknak nevezzük. Magyarázzuk meg a kifejezést: Az utasítások azt mondják meg a processzornak, hogy milyen adatokkal, mit kell tennie, azaz vezénylik, vezérlik a processzor mûködését. A processzor az utasításokat sorban, egymás után hajtja végre. Vezérlésátadásról akkor beszélünk, amikor ettõl az automatizmustól eltérünk. A vezérlésátadó utasítások azt határozzák meg, melyik programrészlet utasításai vezérlik ezentúl a processzort. Feltételes vezérlésátadó utasításnak azokat az utasításokat nevezzük, melyek valamilyen feltétel teljesülésétõl függõen hajtják végre a program egyik vagy másik utasítássorozatát. A feltétel vizsgálata során egy vagy több változó vagy objektum állapotának pillanatnyi értékét vizsgáljuk. A vizsgálat eredménye minden esetben egy logikai érték. A modern – struktúrált – programozásban a feltételes vezérlésátadó utasítás és az általa végrehajtott, vagy éppen kikerült utasítások egymástól elválaszthatatlanok, egy vezérlõszerkezetet alkotnak. A vezérlõszerkezeteket két fõ és több alcsoportba oszthatjuk:


Elágazások w Szelekciók – egyágú: a vizsgált feltétel igaz értéke esetén a befoglalt utasítás végrehajtódik, egyébként nem – kétágú: a feltétel igaz és hamis értéke esetén más-más ág hajtódik végre – többágú: egy kifejezés értékétõl függ, hogy melyik ág hajtódik végre, vagy az ágak külön feltétellel rendelkeznek, közülük csak egy hajtódhat végre Ciklusok w Iterációk – elõl tesztelõ: a ciklus elején megvizsgálja a meghatározott feltétel teljesülését. Ha a feltétel igaz, akkor végrehajtja a ciklustestbe írt utasításokat, majd újra a feltételt vizsgálja. Mindaddig ismétli a ciklustestbe írt utasításokat, amíg a feltétel igaznak bizonyul. – hátul tesztelõ: A ciklustestbe írt utasításokat legalább egyszer végrehajtja, mert a ciklustest végén vizsgálja a kilépés feltételét. A ciklustestbe írt utasítások végrehajtását, akkor hagyja abba, ha feltétel igaz.


Összegezve A programnyelvek ugyanazokkal az eszközökkel dolgoznak, csak az egyes utasítások szintaktikája, nyelvi megvalósítása más. Vagyis más szabályok szerint kell leírni a különbözõ programnyelvek utasításait, de az építõkövek megegyeznek. Ez teszi lehetõvé a nyelvtõl független programtervezést.


feltétel 1 Igaz

Hamis

A program építõelemei

utasítás(ok)

feltétel 2 Igaz

Hamis

utasítás(ok)

A program tervezése során hasznos az egyes eljárásokat valamilyen grafikus módszer segítségével ábrázolni. Ennek egy korai változata a folyamatábra. Jegyzetünkben nem ennek a megtanulása a cél, de most az egyes vezérlõszerkezetek szemléltetésére ezt használjuk. A program tevékenységeit, szerkezetét ezzel a módszerrel mindenki számára olvashatóvá tehetjük. Ezzel a módszerrel a programnyelvtõl függetlenül írjuk le a program folyamatait.

A folyamatábra elemei feltétel n Igaz

Hamis

utasítás(ok)

utasítás(ok)


Folyamatábra rajzolásakor két síkidomot és összekötõ vonalakat használunk: A folyamatábrát felülrõl lefelé kell olvasni, az utasítások, feltételek felülrõl lefelé követik egymást. Ha az elágazás miatt nem a következõ utasításnál folytatódik a

program, akkor a vonal végére rajzolt nyílhegy után kell haladnunk, ez megkönnyíti az értelmezést. Ugyancsak kitesszük a nyílhegyeket a csomópontokba befutó vonalak végén is. Szokás jelezni az ábrázolt program vagy eljárás elejét és végét külön, lekerekített sarkú négyszögbe írt „start“ és „stop“, vagy „begin“ és „end“ szavakkal. A „start“ illetve „begin“ szavakat célszerû helyettesíteni a program vagy eljárás nevével. A rajztechnika a hosszabb, bonyolultabb eljárások ábrázolására is alkalmas. Elõfordulhat, hogy a rajz méretei miatt, átláthatóságának érdekében a nagyon távoli csomópontokat összekötõ vonalakat nem rajzoljuk le, hanem végeiket kis körökbe írt számokkal jelöljük meg.


Vezérlõszerkezetek Ebben a fejezetben részletesen megvizsgáljuk a vezérlõszerkezetek fajtáit, azok mûködését. A folyamatábra mellett VBA nyelvû példát is láthatunk.

Szelekciók

feltétel Igaz

Hamis

Egyágú szelekció w A feltétel igaz – True – értéke esetén az „igaz“ ág (Then ág) utasítását vagy utasításait hajtja végre a program, egyébként ezt kihagyva a program a csomópontot követõ utasításnál folytatódik.

Kétágú szelekció w A feltétel igaz értéke esetén az „igaz“ ág (Then ág) utasítása, utasításai, egyébként a „hamis“ ág (Else ág) utasítása, utasításai hajtódik végre, majd a program a csomópontot követõ utasításnál folytatódik. utasítás(ok)


feltétel igaz

hamis

utasítás(ok)

utasítás(ok)

feltétel 1 Igaz

Hamis

utasítás(ok)

feltétel 2 Igaz

Hamis

utasítás(ok)

feltétel n Igaz

Hamis

utasítás(ok)

utasítás(ok)


Többágú szelekció w A többágú szelekció kétágú elágazások egymásba-ágyazásából épül fel. A vizsgálat az 1. feltétel vizsgálatával indul. Ha ez igaz, akkor a hozzátartozó utasításokat hajtja végre és a program az egész szelekciós szerkezet után folytatódik. Ha az elsõ feltétel eredménye hamis, akkor a következõ feltétel vizsgálatára kerül sor, ha ez igaz, úgy az ehhez tartozó utasítás hajtódik végre, s így tovább. Bármely feltétel igaz értéke esetén a többit már nem vizsgálja. Ha egyik feltétel sem volt igaz értékû, akkor a vezérlés az utolsó feltétel hamis ágában álló utasításhoz (n+1) kerül. Az ebben az ágban álló utasítás el is maradhat, vagyis az utolsó feltétel lehet egyágú is.

Elöltesztelõ iterációk a vezérlõváltozó kezdeti értékének a beállítása

feltétel Igaz

Hamis

utasítás(ok)

vezérlõváltozó növelése


For... Next típus w A For... Next típusú ciklus egy vezérlõváltozó értékét rendre megnöveli, s a ciklustestben található utasításokat minden növelés után végrehajtja. A folyamat addig tart, míg a vezérlõváltozó értéke meg nem haladja a ciklus elsõ sorában meghatározott végértéket. A vezérlõváltozó értékének vizsgálata a ciklustestbe írt utasításokat megelõzi, így abban az esetben, ha a kezdõérték eleve nagyobb a végértéknél, akkor a ciklusba zárt utasítások egyszer sem kerülnek végrehajtásra. A vezérlõváltozó növelése akkor következik be, amikor a program a Next utasításra lép. Ezután visszaadja a vezérlést a For utasítást tartalmazó sornak. Itt ismét a vezérlõváltozó ellenõrzésére kerül sor. A VBA nyelvben két For Next típusú vezérlést is találunk. Az egyik vezérlõváltozója egy számértéket tartalmazó kifejezés, a másik pedig egy objektum. Az objektum típusú For Each... Next ciklus egy gyûjtemény elemeit

veszi sorra. Ebben az esetben a ciklust egy gyûjtemény hivatkozással határozhatjuk meg. A For Each ciklus addig ismétlõdik, amíg a gyûjtemény minden objektumát sorra nem veszi. A For... Next típusú ciklusszervezés esetén az ismétlések számát elõre meghatározzuk. Do... Loop típus w A Do... Loop típusú iterációt felhasználhatjuk mind elöltesztelõ, mind pedig hátultesztelõ ciklusként. Ez csak az írás módjától függ. Ha ugyanis a Do utasítássorba írjuk a feltétel vizsgálatát, akkor elõltesztelõ cikfeltétel lust – iterációt – alakíthatunk ki, ha pedig a Loop utasítás mellé, akkor hátultesztelõt. Ebben az esetben egy külsõ változó értékének megváltozásával vezérelhetjük a ciklusok Igaz Hamis végrehajtási számát. Természetesen a vizsgált változónak változnia kell a ciklustesten belül, különben a ciklus végteutasítás(ok) lenszer ismétlõdik meg. Az iteráció elsõ sorában a feltétel teljesülését vizsgálhatjuk úgy is, hogy akkor lépünk a ciklusba, ha a feltétel igaz (While), és úgy is hogy amíg a feltétel nem igaz (Until). Mindkét vizsgálatot a ciklus elején hajtjuk végre, így az iterációnk elõl-tesztelõ lesz.


Hátul-tesztelõ iteráció Erre a vezérlésszerkezetre szintén a Do... Loop utasításpárt használjuk. Az elõzõ vezérlésszerkezet megvalósításától csak annyiban térünk el, hogy a ciklus végrehajtását vezérlõ vizsgálatot a Loop utasítás mellé írjuk, így a ciklus egyszer mindenképpen végrehajtódik.

Összefoglalva

utasítás(ok)

feltétel Igaz

Hamis

A fejezetben felsorolt vezérléseket felhasználhatjuk bármilyen programszerkezet felépítésére. Ez a gondolat másként megfogalmazva: minden programot megvalósíthatunk három elem megfelelõ kombinálásával. Ez a három elem a: – szekvencia, egyszerû utasítások – szelekció, elágazás vezérlésátadások – iteráció ismétlés, ciklus vezérlések. Ezek a szerkezeti elemek olyanok, mint egy autóban a csavarok, alkatrészek. A tervezéskor az algoritmus megfogalmazása során ezeket az alkatrészeket használjuk a teljes program felépítésére.


Struktúrált programtervezés A programfejlesztés módszerei a számítástechnika hõskorában korántsem fejlõdtek olyan iramban, mint a hardware eszközök. A hatvanas évek végén a programok írására, kijavítására fordított idõ aránytalanul nagy lett a végrehajtási idõhöz és a megnövekedett feldolgozási igényekhez képest. Gazdasági szükségszerûséggé vált hatékony tervezési, programozási módszerek kifejlesztése, hiszen a nagy létszámú, de kevéssé hatékony fejlesztõ csoportok munkája túlságosan drágává vált. A nagy számítástechnikai cégek szakemberei és az egyetemi kutatók sok alapvetõ elméleti fejlesztést végeztek a tervezési, programozás-elméleti szakterületeken. E kutatások eredményei minden más tudományterületnél gyorsabban kerültek át a mindennapi gyakorlatba. Ebben az idõben, egészen a hetvenes évek végéig számos új módszer és programnyelv jelent meg, köztük a moduláris és struktúrált programozás. Próbáljuk meg összegyûjteni és értelmezni a programok hatékonyságát, minõségét biztosító szempontokat: −Korrektség:

a program a kitûzött célt valósítsa meg

−Megbízhatóság:

hibátlan mûködés, illetve a hibák behatárolhatósága, kiszûrhetõsége


−Áttekinthetõség:

világos, érthetõ szerkezet, jól olvasható terv és program

−Személytõl val ófüggetlenség:

megállapodásos módszerek alkalmazásával biztosítható, hogy a munkán párhuzamosan többen dolgozzanak, vagy más személy vegye át a fejlesztést

−Karbantarthatóság, továbbfejleszthetõség:

a késõbb felmerülõ igényekhez könnyen lehessen alakítani, legyen kiegészíthetõ

−Olcsó, gyors fejlesztés:

az elõbbi szempontok figyelembevételével a fejlesztés költségei csökkenthetõk, a tévutak, javítgatások kiküszöbölhetõk

Elsõ pillantásra (és a programok minõségérõl szerzett tapasztalataink szerint) a fentiek vágyálomnak tûnhetnek. Fordítsuk meg a dolgot: ki mer és akar megbízhatatlanul fejleszteni? Ki akar állandóan fúrni-faragni anélkül, hogy átlátná amit csinál? Az ilyen munkára mondja Murphy: A számítógépes fejlesztés határidõ-túllépése emberi élõmunka hozzáadásával csak fokozódik. Meg kell találnunk a feladatok megoldásának olyan módját, amivel az említett szempontok megvalósíthatók.


A moduláris programozás A moduláris programozás kezdetben a nagy méretû programok fizikai tördelését jelentette, hiszen sok esetben az egész be sem fért volna egyszerre az operatív tárba, vagy a feladat nagyon áttekinthetetlen volt. A feladat szétbontása modulokra akkor lehet igazán hasznos, ha az egyes részek függetleníthetõségének határait jól felismerjük. Biztosítanunk kell azt, hogy a modulok jól körülhatárolt, korrekten definiálható feladatokat valósítsanak meg, így az egyes modulok külön tervezhetõk, kódolhatók, tesztelhetõk. Ügyelnünk kell arra, hogy az egymással majdan kommunikáló, adatcserét végzõ modulok értsék egymást. A modulok elkészítése után össze kell õket fûznünk egy programmá. A moduláris programfejlesztés elsõ lépése a modulok kialakítása. Az egyes modulok természetesen további modulokra is oszthatók olyan mélységben, ami az egyszerû fejlesztés érdekében megfelelõ. Kezdetben az egész feladatot egy egységnek tekintjük, s ezt bontjuk részekre. Ezután az egyes modulokat külön-külön vizsgáljuk, s ha szükséges, tovább bontjuk õket. E folyamatot ismételjük addig, míg minden szükséges bontást elvégeztünk. A felbontás tehát felülrõl (az egésztõl) lefelé (az egyre kisebb részekhez) tart, angol kifejezéssel: top-down irányú.


A kódolás – vagy más szóval a program írása – a legalacsonyabb szintû modulokkal kezdõdik, s ezeket fûzzük össze egyre bonyolultabb egységekké. A kódolás tehát alulról felfelé tart, angol kifejezéssel: bottom-up irányú. A moduláris programozás hiányossága az, hogy a modulok kialakításának mikéntjére nem ad módszert. A modulok rossz elhatárolása növeli a bonyolultságot, rontja az áttekinthetõséget, és ha a kapcsolódások rosszak, akkor sok utólagos, „favágó“ módosításra van szükség. Romlik a megbízhatóság és hatékonyság is.

A struktúrált programozás A moduláris programozás fejlõdése nyújtott alapot a struktúrált programozás tervezési és kódolási módszereinek kifejlesztéséhez. A struktúrált programozás a moduláris programozás szigorúbb formája, melynek alapkérdése a modulok elhatárolása. E módszerben a részfeladatok hierarchikus rendszerben kapcsolódnak egymáshoz, melyben csak alá- és mellérendeltségi viszonyok szerepelnek. Böhm és Jacopini tétele w 1966-ban Böhm és Jacopini egy cikkben fogalmazta meg tételét: Bármely egy bemenetû és egy kimenetû program megfeleltethetõ egy olyan programnak, ami csak három vezérlési struktúrát tartalmaz. Visszafelé olvasva: a három vezérlési struktúrából minden egy bemenetû és egy kimenetû program felépíthetõ.


Fontos értenünk az egy bemenet és egy kimenet fogalmát. Bemenet alatt itt azt a pontot értjük, ahol a program elkezdõdik, kimenet alatt pedig azt, ahol véget ér. Szerencsésebb ezeket bejáratnak (Entry) és kijáratnak (Exit) nevezni. A késõbbiekben inkább e kifejezéseket használjuk. A három alapvetõ struktúra: – Egyszerû utasítássorozat (szekvencia) – Elágazás (szelekció) – Ciklus (iteráció) A fenti struktúrák felépítésével tulajdonképpen már foglalkoztunk a vezérlõszerkezetekrõl szóló fejezetben. A tétel szerint ezek mindig ábrázolhatók egy olyan egyszerû szekvenciával, melynek hatása ugyanaz, illetve a tevékenységek (szekvenciák) is felbonthatók a három alapstruktúra valamelyikére. Ez egyrészt azt jelenti, hogy bonyolult részfolyamatok is ábrázolhatók egy tevékenységként ott, ahol részletezésük felesleges, másrészt azt, hogy minden tevékenységként ábrázolt részfolyamat tovább bontható addig, míg az elemi, triviális szintet el nem érjük. A következõ oldalon a lépésenkénti finomítást igyekszik ábrázolni egy egyszerû példa: A program számítsa ki a beírt számok átlagát! Ha nem írtunk be adatot, akkor jelezzen hibát! Az összegzés akkor ér véget, ha 0-t írunk be.


Elsõ lépésben ábrázoljuk azt, hogy a feladat elõkészítéssel kezdõdik, majd folytatódik az adatok gyûjtésével, végül az eredmény képzésével fejezõdik be:

elõkészítés

adatok gyûjtése

eredmény képzése


Második lépésben az elõkészítést bontsuk fel a gyûjtõ nullázása és a számláló nullázása tevékenységekre, az adatok gyûjtését az elsõ adat beolvasása és ciklikus gyûjtés tevékenységekre, az eredményképzést pedig egy szelekcióra, melynek egyik ágában az osztás és kiírás, másik ágában hibajelzés található aszerint, hogy van-e beolvasott adat, vagy nincs. Elõfordulhat ugyanis, hogy már az elsõ esetben 0 értéket ír be a felhasználó, ami 0-val való osztást eredményezne, ha erre nem figyelnénk: gyûjtõ = 0 elõkészítés számláló = 0 elsõ adat beolvasása adatok gyûjtése ciklikus gyûjtés

számláló > 0 eredmény képzése


Igaz

Hamis

osztás és kiírás

hibajelzés

Harmadik lépésben a ciklikus gyûjtést bontsuk egy iterációra, melynek feltétele az, hogy a beírt adat nem 0, magjában pedig növeljük a számlálót és a gyûjtõhöz hozzáadjuk a beolvasott értéket, majd újabb számot olvasunk, az osztást és kiírást pedig bontsuk az osztás elvégzésére és az eredmény kiírására:

adat <> 0 elsõ adat beolvasása

Igaz

ciklikus gyûjtés

gyûjtõ = gyûjtõ + adat számláló növelése

számláló > 0


adat beolvasása

Hamis

Mills szabályai w –

A legkisebb programozási egység a tevékenység. A legkisebb itt azt jelenti, hogy tovább nem bontható, vagy nincs értelme tovább bontani – Minden tevékenységnek csak egy bejárata és egy kijárata lehet ezt nevezzük Mills féle kritériumnak. – A tevékenységek (utak) elágazása csak predikátumokon – feltételeken – keresztül történhet, aminek csak két értéke lehet: hamis és igaz – Több tevékenység (út) csak csomópontokban találkozhat. A fenti szabályoknak megfelelõ programok felépítéséhez három objektum szükséges: tevékenység, predikátum, csomópont. Ezek ábrázolásához a folyamatábránál megismert rajztechnikai jeleket fogjuk felhasználni. Ha visszalapozunk a vezérlõszerkezetekrõl szóló fejezethez, akkor felismerhetjük: az ott ábrázolt alapszerkezetek mindegyike felépíthetõ ezekbõl, s mindegyikre érvényesek Mills szabályai. A programozó egyik feladata az, hogy a fenti szerkezeteket alkalmazva el tudja végezni a részletes felbontást azokon a pontokon, ahol a szervezéskor nem történt bontás, de technikailag szükséges, és az adott programnyelvben megvalósítsa ezeket. A fejlett programnyelvek jól alkalmazkodnak a fentiekhez, hiszen definiálásukkor ezek már ismertek voltak. Van azonban néhány olyan utasítás, amitõl tartózkodnunk kell e té-


teleket alkalmazva. Szinte minden nyelv tartalmaz olyan utasításokat, melyekkel az egy bejárat egy kijáratát elve megtörhetõ. Ilyen a VBA-ban a GOTO (direkt ugrás), vagy az iterációkban az EXIT utasítások. Az ilyen utasítások alkalmazása elsõ pillantásra nagyon kényelmesnek tûnik, de kis gyakorlattal is belátható, hogy nagyon nehezen követhetõ, s nehezen módosítható, javítható programok megírásához vezetnek. Ha a Mills kritériumot betartjuk, egyre bonyolultabb eljárások építhetõk fel anélkül, hogy az egy kijárat egy bejárat elvét megsértenénk. Az általunk vizsgált nyelvre jellemzõ, hogy eljárások, függvények (egyszóval szubrutinok) deklarálásánál sem térhetünk el a Mills kritériumtól.

Struktúrált problémalebontás A korszerû programtervezési eljárások alapja a probléma lebontása, dekompozí- ciója. A lebontás szisztematikusan felülrõl lefelé (top-down) haladó módszer, mely lépésrõl lépésre meghatározza az eljárást. A kiindulásnál a specifikáció szerint megoldandó problémát tekintsük egyetlen funkciót tartalmazó egységnek, majd hajtsuk végre az alábbi mûveletsort: – Döntsük el, hogy a vizsgált funkció az adott programnyelven közvetlenül megoldható vagy sem.


– Ha megoldható, akkor kódoljuk, majd ellenõrizzük, hogy a kód valóban megfelel-e a funkciónak (ugyanazt az eredményt adja-e). – Ha nem oldható meg közvetlenül, akkor bontsuk fel vezérlõfunkciókra a három alapstruktúra (Böhm-Jacopini) segítségével. Azokat használjuk fel, melyek a legjobban leírják a funkciót. – Ellenõrizzük a felbontás helyességét, s ha megfelelõnek találjuk, akkor a funkciót váltsuk ki az elõzõ lépésben kialakított részfunkciókkal. A fenti lépéseket addig ismételjük, míg van a struktúrának olyan pontja (tevékenysége), melyet tovább lehet bontani. A felbontás végeztével eljutunk a triviális szintig, mely csak feltételeket és az adott nyelven eleminek tekinthetõ tevékenységeket tartalmaz. A felbontás során az egésztõl az egyre részletesebb, egyre finomabb felbontás felé haladunk, s minden szinten csak az ott felmerülõ kérdéseket vesszük figyelembe. Ez azt jelenti, hogy a problémát egyre finomabban körülhatároljuk, mégsem kell – elveszve a részletekben – egyszerre minden szintet látnunk. A lépésenkénti finomítás elvét alkalmazzuk (angolul: Stepwise Refine- ment), vagyis a funkciót részekre bontjuk, majd minden részt egy lépéssel tovább bontunk, csak ezután megyünk mélyebbre. A struktúrát emeletenként (szintenként) elemezzük.


Összegezve A programozási feladatok megoldását a nagyobb egységektõl a kisebbek felé haladva oldjuk meg. A nagyobb lépéseket addig bontsuk kisebb részekre, amíg az adott programnyelvben egy utasítással megoldható lépések szintjéig el nem jutunk. A kódolást a kisebb részek, eljárások megírásával kezdjük. A kisebb egységek elkészítése után azokat fogjuk össze egy eljárásban.


Jackson módszere Michael Jackson, amerikai szakember 1975-ben publikálta módszerét, melyet sokéves ipari, kereskedelmi és számítástechnikai munkájának tapasztalatai alapoztak meg. A Jackson módszer az adatszerkezetek vizsgálatából indul ki, a program vezérlõszerkezeteit az adatok szerkezetébõl vezeti le. Ez az elv magától értetõdõ lehet minden adatfeldolgozási környezetben, hiszen a kimeneten elvárt eredmény és a bemeneten rendelkezésre álló adat egyértelmûen meghatározza a feldolgozó folyamatot. A korábban megbeszéltek alapján ez nem más, mint egy átalakítás: bemenet Ø transzformáció Ø kimenet.

Alapvetõ tervezési lépések A feladat specifikációjának alapján ábrázolhatjuk a bemenõ és kimenõ adatok struktúráját. Itt a már ismert három alapszerkezetet használjuk fel (szekvencia, szelekció, iteráció). Az ábrázolt szerkezet nem fizikai, hanem logikai értelmû: az adatok egymáshoz való viszonyát, megjelenésük, ismétlõdésük feltételeit jelenti a feladat tükrében.


Az adatszerkezetek képe a feladat környezetét jelenti, általuk készíthetõ el a program szerkezetének terve. Az így kialakuló struktúra megfelelõ pontjain elhelyezhetjük a programban elõforduló tevékenységeket, melyeket elõbb összegyûjtünk. A tevékenységek céljuk, hatásuk szerint csoportokba sorolhatók: bemeneti (beolvasó), kimeneti (kiíró) utasítások, számítások, döntéselõkésztések, alprogramhívások. A programban használt utasításokat jegyzékbe szedjük, ami egyrészt az ismétlések elkerülését biztosítja, másrészt a programszerkezet ábráján elég a jegyzékbeli számokkal jeleznünk õket. Hasonlóan járunk el a szerkezetben szereplõ feltételekkel is, azaz megszámozzuk õket, s az ábrán csak számaikat tüntetjük fel (lásd késõbb a rajztechnikai ismertetésnél). Az ábrázolt programszerkezetet a funkcionális leírásban metanyelven is megadjuk. A funkcionális leírás a programozási nyelvtõl független, mégis közelebb visz a kódoláshoz azzal, hogy a majdani kódhoz hasonlóan sorokból áll és tabulációk segítségével tükrözi a struktúrák egymásba-ágyazását. Foglaljuk össze a módszer tervezési lépéseit: – a specifikáció megértése – az adatszerkezetek ábrázolása – a programszerkezet elkészítése az adatszerkezetek alapján – a tevékenységek elhelyezése a programszerkezetben – funkcionális leírás készítése


Jelölésrendszer A Jackson módszer a folyamatábrától eltérõ, rajztechnikailag nagyon egyszerû jelölésrendszert alkalmaz, ami képes az alapszerkezetek ábrázolására. Elõnye a folyamatábrával szemben az, hogy a top-down elv szerinti felbontás minden fázisát egy ábrán tükrözi, így a különbözõ szinteken álló tevékenységek alatt láthatjuk részletes tartalmukat is. Az ábrákban egyszerû dobozokat látunk, melyeket vonalak kötnek össze egymással. A dobozokban látható jelek határozzák meg, hogy ott melyik alapszerkezetrõl van szó, s a funkciók, tevékenységek nevei is beírhatók. Az alapszerkezetek ábrái w Az ábrák bal oldalán látható a folyamatábra szerinti megvalósítás is elõbb csak tevékenységként, majd részletezve. Középen látjuk a Jackson módszer szerinti ábrázolást, ami a két szintet egyszerre jelzi, mellette, a jobb oldalon pedig a funkcionális leírást.


Szekvencia w Jelentése: az A jelû szekvencia tartalma az Al, A2, A3 tevékenységek egymást követõ végrehajtása. A-t azért nevezzük szekvenciának, mert tartalma szekvenciálisan (egymás után) elvégzendõ tevékenységeket jelez. A Jackson ábra fentrõl lefelé, azon belül balról jobbra olvasható: az A szekvenciában az A1 tevékenység végrehajtását követi az A2, majd ezután az A3 tevékenység.

Folyamatábra A1 A

Jackson ábra

Metanyelv

A

A seq A1 A2 A3 A end

A2 A3


A1

A2

A3

Szelekció w Jelentése: a B jelû szelekcióban az F feltétel igaz értéke esetén a B1 tevékenység, hamis értékénél a B2 tevékenység hajtódik végre. A feltételes ágakat egy-egy körrel jelöljük; az igaz ághoz írjuk a feltételt.

Folyamatábra

F B

Jackson ábra

Hamis

Metanyelv

B

Igaz B1


B2

B1

F

B2

B select felt. F B1 B or B2 B end

Iteráció w Jelentése: a C struktúra tartalma, a C1 mag mindaddig ismétlõdik, míg az F feltétel igaz. Ez tehát, elõltesztelõ ciklus. Az iteráció magját egy csillaggal jelezzük; s kívülrõl mellé írjuk a feltételt. (A Jackson módszer hátultesztelõ ciklust nem ismer.)

Folyamatábra

F C

Jackson ábra

Hamis

C iter felt. F C1 C end

C

Igaz C1


C1

Metanyelv

* F

Egyágú szelekció w A struktúrában állhatnak olyan ágak, melyeknek igazi tartalma nincsen, ezeket el lehet hagyni. Ilyen eset az is, amikor egy szelekció egyágú. Itt a hamis ág létezik ugyan, de tevékenységet nem tartalmaz: az ábrát egyszerûsíthetjük. Jelentése: a D jelû szelekcióban az F feltétel igaz értéke esetén a D, tevékenység hajtódik végre, míg hamis értéknél nem történik semmi.

Folyamatábra

F D

Jackson ábra

Hamis

D select felt. F D1 D end

D

Igaz D1


D1

Metanyelv

F

Folyamatábra

Többágú szelekció w A többágú szelekciónál korábban is abból indultunk ki, hogy kétágú szelekciók egymásba-ágyazásából jön létre. Akkor beszélhetünk többágú szelekcióról, ha minden benne szereplõ szelekció igaz ágában egy tevékenységet, hamis ágában egy újabb szelekciót találunk, egészen az utolsóig, melynek már mindkét ága tevékenység. Az ilyen struktúrára igaz az, hogy a benne szereplõ feltételek egymás után értékelõdnek ki, s közülük az elsõ igaz eredményû feltételhez tartozó tevékenység végrehajtódik, majd a szelekció véget ér. Ennek a rajzát láthatjuk a folyamatábrán és a Jackson ábrán, ahol az elsõ a teljes a második az egyszerûsített jelzésû.


elsõ Jackson ábra

F1 Igaz

S

Hamis

S1

S1

S2

F2 Igaz

F1

S1

F2 S2 S3

Hamis

S2

F3

S3

S4

F4

S4

F3 Igaz

Hamis

második Jackson ábra

S3

S

S1

F4 Igaz

Hamis

S4

S5

F1

S2

F2

S3

F3

S4

F4

S5

Elemi tevékenységek elhelyezése w A további felbontást nem igénylõ (célszerûen nem bontható) tevékenységeket T betûvel és a jegyzékben feltüntetett számukkal szerepeltetjük az ábrán. Tevékenységjegyzék: 1. n beolvasása 2. szám beolvasása

beolvasások

3. számláló = 0 4. összeg = 0

számítás-elõkészítés

5. összeg = összeg + szám 6. átlag = összeg / számláló 7. számláló növelése

számítások

8. összeg kiírása 9. átlag kiírása

kiírások Program

halmozás

n 1

3

F: számláló <= 1


4

2

szám 5

8

7

átlag

¶ F 2

6

9

A Jackson módszer jelölésrendszerérõl összefoglalóan elmondhatjuk, hogy: – Az ábra egyszerre tükrözi a feladat felbontásának összes szintjét – Olvasása balról jobbra, azon belül fentrõl lefelé történik – A tevékenységeket „dobozok“ segítségével ábrázoljuk, melyeket vonalak kötnek össze – A szekvenciát ábrázoló doboz nincs külön jellel ellátva, a szelekciós ágakat körrel, az iterációk magját csillaggal jelöljük

Adatszerkezetek ábrázolása Az alábbiakban értelmezni fogjuk az adatszerkezetek ábrázolását. Amint azt korábban megállapítottuk: itt a feladat kimenetét és bemenetét alkotó adatok logikai szerkezete érdekel minket. Vizsgáljuk meg ezt egy egyszerû példán: A feladat arra kíván választ adni, hogy egy banknak hány betétes ügyfele van. A kimeneten itt egyetlen számot várunk, míg a bemeneten megjelenik az összes betétes adata, melyeket meg kell majd számolnunk. A kimenetet szekvenciaként ábrázolhatjuk, hiszen ott feltétel nélkül áll egy számadat. A bemeneten a betétesek adatai követik egymást, azaz addig ismétlõdnek, míg van adat. Az egyes bemeneti adatok között ebben a feladatban semmi különbség nincs, így csak ismétlõdésüket kell ábrázolnunk:


Bemenet

betétes

Kimenet

* F

ügyfélszám

F: Van még adat Változtassuk meg a feladatot úgy, hogy a pozitív és negatív betéttel rendelkezõ ügyfelek számát külön mondjuk meg (a 0 betétet is pozitívként értékeljük). A kimeneten most két szám áll majd, de továbbra is feltétel nélkül, szekvenciaként. A bemeneten most is minden betétes adata rendre megjelenik, de azt is meg kell állapítanunk róluk, hogy mely csoportba esnek (tartoznak, vagy követelnek). A bemeneten azt tudjuk ábrázolni, hogy a betétesek között van pozitív betétû és negatív betétû is. A választás feltétele is megadható: a tartozók közé kell sorolnunk az ügyfelet, ha betétje kisebb 0-nál illetve a pozitív betétesek közé, ha betétje >= 0.


Bemenet

betétes

pozitív

F2

Kimenet

* F1

követel

tartozik

negatív

F1: Van még adat F2: Betét >=0 A fenti két példából láthatóan a kimeneten és bemeneten azt ábrázoljuk, hogy az adatok milyen viszonyban állnak egymással, ciklikusan követik egymást, vagy eltérnek egymástól valamely feltételnek megfelelõen. A betétesekrõl szóló adat az ábrázoltnál részletesebb, hiszen egy ügyfélrõl számos információt kell rögzíteni (név, cím, számlaszám, stb.) de itt, ebben a feladatban ezek minket nem érdekelnek.


Alapvetõ adatstruktúrák ábrázolása A Jackson ábrán strukturált adatszerkezeteket is megjeleníthetünk. A programnyelvekben használható strukturált adattípusokról korábban már olvashattunk. A programozási feladatok bemenetének, kimenetének ábrázolásakor gyakran kell a feldolgozásra váró adatokat ábrázolnunk. A tömböt és az állományt iterációs szerkezettel, míg a rekordot szekvenciával ábrázoljuk. A tömb egyforma felépítésû elemek iterációját jelenti. Az elemek addig követik egymást, míg el nem érjük a tömb utolsó elemét. Az egy dimenziós tömb vagy vektor ábrázolására a következõ Jackson ábrát használjuk.

Tömb (1d)

elem


* F

A két dimenziós tömböt olyan egydimenziós tömbnek kell tekintenünk, melynek elemei tömbök, így ez két iterációból épül fel, és a következõképpen ábrázoljuk:

Tömb (2d)

elem (1d)

* F1

elem

* F2

Vonjuk le tehát azt a következtetést, hogy az egyes tömbök dimenziószáma meghatározza az egymásba ágyazott iterációk számát. Az iterációk feltételei az adott dimenzió elemszámára vonatkoznak.


A rekord adattípus eltérõ (nem feltétlenül azonos) típusú elemeket, más szóval mezõket fog össze egy szerkezetbe. A mezõk viszonyát nem befolyásolják feltételek, egyszerûen felsoroljuk õket, így leírásukra szekvenciát használunk:

Rekord

mezõ 1

mezõ 2

mezõ 3

Az adatszerkezetek egymásba is ágyazhatók. Tipikus példa erre a rekordokból álló állomány: Fájl

Rekord

mezõ 1


mezõ 2

* F

mezõ 3

A programszerkezet elkészítése A Jackson módszer a program struktúráját a bemeneti és kimeneti adatszerkezetbõl vezeti le a struktúrák összefésülésével. Az összefésülés során megpróbáljuk azonosítani a két adatszerkezet azonos részleteit. Az azonosítás során három alapvetõ eset fordulhat elõ:

Program

Eredmény

Számlálás

betétek

pozitív

F2


*

F1

negatív

követel

F1 : Van még adat F2 : Betét >=0

tartozik

– nincs azonos részlet – van azonos részlet – van azonos részlet, de az egyik struktúra teljes egészében tartalmazza a másikat Az elsõ esetben egyszerû dolgunk van: a bemeneti és a kimeneti szerkezetet egymás mellé helyezve áll elõ a programszerkezet. A bemenettõl örökölt „számlálás” ág után a kimenettõl származó „eredmény” ág végrehajtása következik. Tehát ebben az esetben nem találtunk összevonható szerkezetet. Nézzünk egy olyan példát, amikor van azonosítható rész a két struktúra között. Ilyen esetben úgy járunk el, hogy az azonos adatszerkezeteknél fogva „összefésüljük” õket. Oldjuk meg a következõ feladatot: Olvassunk be n számot, majd számítsuk ki ezek átlagát! Minden újabb szám beírása után írjuk ki az addigi halmozott összeget, végül jelenítsük meg az átlag értékét is! A megoldás során válasszuk szét a bemeneti és a kimeneti adatszerkezetet.


Bemenet

n

F: számláló <= n

Kimenet

összeg

számok szám

¶ F

szám

átlag

¶ F

A két szerkezetben jól láthatóan ugyanolyan feltételû iteráció szerepel. A programstruktúrában ezeket összefogjuk „halmozás” néven:


Program

n

F: számláló <= n

halmozás szám

átlag

¶ F

A harmadik esetben az egyik adatstruktúra bõvebb, mint a másik. Ilyenkor a programstruktúrát a bõvebb adatszerkezet határozza meg. Oldjunk meg egy ilyen példát is. A billentyûzetrõl beírt számok gyökét írjuk ki! Csak pozitív számokat fogadjunk el! A program véget ér, ha 0-t írunk be.


A bemeneten a beolvasott számok ismétlõdnek. Az iteráción belül egy szelekció áll, amelyik azt vizsgálja, hogy a szám elõjele milyen. Mivel minket csak a pozitív számok érdekelnek ez a szelekció egyágú. A kimeneten a beolvasott számok gyöke rendre megjelenik, így ez is egy iteráció, melynek feltétele ugyanaz, mint a bemenetié: a szám <> 0.

Bemenet

szám

pozitív


Kimenet

¶ F 1 m

F2

szám

¶ F 1

F1: szám <> 0 F2: szám > 0

A bõvebb struktúra ez esetben a bemeneti, így a programszerkezetet ez adja:

Program

szám

pozitív

¶ F 1 m

F1: szám <> 0 F2: szám > 0

F2

Tevékenységek elhelyezése a programszerkezetben A programszerkezet ábrájának elkészítése után összegyûjtjük, jegyzékbe foglaljuk mindazokat az elemi tevékenységeket, melyeket a program a mûködése során végrehajt. Ezt követõen jegyzékbeli számuk segítségével jelezzük helyüket az ábrán. A korábbi példák közül válasszuk most az átlagszámítást:


Tevékenységjegyzék: 1. n beolvasása 2. szám beolvasása

beolvasások

3. számláló = 0 4. összeg = 0

számítás-elõkészítés

5. összeg = összeg + szám 6. átlag = összeg / számláló 7. számláló növelése

számítások

8. összeg kiírása 9. átlag kiírása

kiírások Program

halmozás

n 1

3

F: számláló <= 1

4

2

szám 5

8

7

átlag

¶ F

6

9

2

Az ábrán észrevehetjük, hogy „elõkészítés” nevet adtunk a korábban (elõzõ oldali ábra) „n” névvel jelzett ágnak, hiszen itt nem csak az n szám beolvasása, hanem más elõkészítõ tevékenységek is végrehajtódnak. A programszerkezet ábráján nem mindig találunk olyan ágat, mely az elõkészítõ jellegû tevékenységek elhelyezésére alkalmas. Ilyenkor az ábrát szabadon kiegészíthetjük az „elõkészítés” szekvenciával.


Struktúrák ütközése, homogenizálás A programszerkezet ábrájának elkészítésekor vagy a tevékenységek elhelyezésénél elõfordulhat az, hogy különbözõ típusú ágak kerülnek egymás mellé. Ilyenkor nem tudjuk menü

1

a

m

b

1: gomb beolvasása


m

c

m

d

m

e

m

menü

H

1

a

m

b

m

c

m

d

m

e

m

megállapítani a befoglaló szerkezet típusát, ezért ezt fel kell oldanunk, az ütközést homogenizálnunk kell. Vizsgáljuk ezt meg néhány példán: A „gomb beolvasása” tevékenység elhelyezése miatt a „menü” szelekció egy szekvenciát is tartalmaz, nemcsak szelekciós ágakat. Feloldásához a struktúrában elhelyezünk egy további szekvenciát, amit itt „H” betûvel jelölünk: A homogenizálás elõtt a „menü” típusa nem volt megadható, hiszen egyaránt tartalmazott szekvenciát és feltételesen végrehajtódó ágakat. A javítás után a „menü” szekvencia tartalma az 1 számú tevékenység és a „H” jelû többágú szelekció. A homogenizálás során mindig csak szekvenciákat illesztünk be, hiszen ezek nem befolyásolják érdemben a szerkezetet (sem a végrehajtás sorrendjét, sem annak feltételeit).


Tartalomjegzék Bevezetés Feladatmegoldás A programkészítés lépései A feladat meghatározása, specifikáció Tervezés Kódolás Tesztelés Dokumentáció A programnyelvek elemei Adattípusok Numerikus típusok Szöveges típusok Logikai típus Mutató típus Általános adattípus Adatszerkezetek


Utasítások típusai Vezérlõszerkezetek Összegezve A program építõelemei A folyamatábra elemei Vezérlõszerkezetek Szelekciók Elöltesztelõ iterációk Hátul-tesztelõ iteráció Összefoglalva Struktúrált programtervezés A moduláris programozás A struktúrált programozás Struktúrált problémalebontás Összegezve Jackson módszere Alapvetõ tervezési lépések


Jelölésrendszer Adatszerkezetek ábrázolása Alapvetõ adatstruktúrák ábrázolása A programszerkezet elkészítése Tevékenységek elhelyezése a programszerkezetben Struktúrák ütközése, homogenizálás


Programozás alapjai, programtervezés

Recommend Documents