Vissza az előzőleg látogatott oldalra (nem elérhető funkció)Vissza a modul kezdőlapjáraUgrás a tananyag előző oldalára (23)Ugrás a tananyag következő oldalára (25)Fogalom megjelenítés (nem elérhető funckió)Fogalmak listája (nem elérhető funkció)Oldal nyomtatása (nem elérhető funkció)Oldaltérkép megtekintéseSúgó megtekintése

Tanulási útmutató

Összefoglalás

Ebben a leckében a programozással kapcsolatos, az eddigi lépéseknél kevésbé „kreatív”, ámde nem nélkülözhető gyakorlati ismeretek közül az algoritmizálást és a kódolást „szabályozó” elvekkel ismerkedünk meg.

Követelmény

Önállóan megoldható feladatok

Programkészítési elvek

1. Stratégiai elv

Egyik legfontosabb, sokféleképpen alkalmazható elvünk az ókori latin kultúrából ránk maradt oszd meg és uralkodj elve alapján fogalmazható meg: oszd részekre, majd a részek független megoldásával az egész feladatot könnyebben oldhatod meg. Így programod könnyen kézben tarthatod, vagyis uralkodhatsz felette.

Ezt a stratégiai elvet tartjuk szem előtt akkor, amikor gondolkodásmódunkat kívánjuk helyes mederbe terelni. Lépésenkénti finomításnak nevezik ezt az elvet a feladatmegoldás filozófiájában. A feladat megoldását először átfogóan végezzük el, nem törődve a részletekkel, amelyekről érdemben amúgy sem tudnánk helyesen dönteni az adott pillanatban sok, még pontosan előre nem látható probléma miatt. Tehát a feladatot néhány (nem túl sok!) részfeladatra bontjuk. Úgy is mondhatnánk: a feladatot megoldjuk a legfelső szinten. Ha volna olyan gép, amelyen léteznének azok az utasítások, amelyeket mi részfeladatokként megadunk, akkor máris futtatható lenne a program. (Ez a Dijkstra-féle gyöngysormodell.) Ezt az eljárást fogjuk követni az egyes részfeladatok megoldásakor is (a részek feletti uralkodás érdekében) mindaddig, amíg olyan utasítások szintjéig nem érünk, amelyeket gépünk (kódolás után) már végre tud hajtani.

A kép a feladat hierarchikus részekre bontását mutatja be egy piramisra emlékeztető ábrával.A 'Piramis elv'.

A részfeladatokra bontás a következőket foglalja magában: pontosan ki kell jelölni, hogy az adott részművelet milyen adatokat kezel, milyeneket állít elő, és ezeket miként kell egymáshoz rendelni; vagyis ha ez az adat jött a részművelethez, akkor azt az adatot kell kapjuk eredményként. A hogyanról most nem elmélkedünk.

Nyilvánvaló, hogy két azonos szinten definiált részfeladat között biztosítani kell a harmóniát úgy, hogy a végrehajtásban előbb következő az utána következő adatait szolgáltassa

A feladat egy adott szintjén egymást követő részfeladatok érintkezését ábrázolja a kép.Részfeladatokra bontás: a piramis egy szintje

A részfeladatokra bontáskor persze felmerülhetnek illesztési problémák.

Az elmondottakból már körvonalazódik a lépésenként elnevezés értelme. Óvatosan, megfontoltan haladunk az ismeretlenbe; vigyázunk, hogy minden lépésnél megtartsuk uralmunkat az éppen megoldandó részfeladat felett. A finomítás pedig e lépésenkénti megközelítés mikéntjére utal. A lépés során kirajzolódott elemibb, egymástól már jól elhatárolható, s ezért egymástól függetlenül kezelhető tevékenységek még elemibbekre bontását jelenti.

Ez a módszer tehát a program felülről lefelé való kifejtése (top-down programozás), amely a problémaanalizáláson, dekomponáláson, részekre osztáson alapul.

Elképzelhető egy másik módszer is, amelyben a piramist alulról kezdve építjük fel. Itt azonban nagy gyakorlat szükséges ahhoz, hogy a csúcsra érve tényleg a kitűzött feladatot oldjuk meg.

Ez utóbbi módszer a program alulról felfelé való felépítése (bottom-up programozás), amely szintetizáláson alapul.

Valójában nem is két alternatívan alkalmazható módszerről van szó. Az alulról felfelé tervezés akkor jut szóhoz, amikor egy eszközkészlet (például egy típus a hozzá tartozó műveletekkel együtt) elkészítése a feladat. Ekkor valóban egy majdani program legalacsonyabb szintjén lévő elemeit kell elkészíteni. Persze egy-egy ilyen eszköz is lehet annyira bonyodalmas, hogy a „legyártásához” a felülről lefelé tervezés módszeréhez kell folyamodnunk.

Vissza a tartalomjegyzékhez

2. Taktikai elvek

Milyen taktikai elveket – vagy kissé szerényebben szólva, jó tanácsokat – adhatunk a lépésenkénti finomítás elvének megvalósításához?

2.1. A párhuzamos finomítás elve

A szint összes részfeladatára kell elvégezni a finomítást. Nem szabad előre sietni valamelyik könnyebbnek vélt ágon, mert előfordulhat, hogy munkánk kárba vész (egy esetleges visszalépés miatt, és kár lenne ilyen lélektani terhet nyakunkba venni).

Egy-egy szinthez szervesen hozzátartoznak a részfeladatok adatai is. Így világos, hogy az adatok finomítása során sem szaladhatunk előbbre, mint amit a szint eljárásai megkívánnak.

A szint eljárásai – mint a piramiselvből nyilvánvaló – a feladat teljes megoldását adják. Ha lenne olyan gép, amely ezeket az utasításokat végre tudná hajtani, akkor készen is lennénk. Ha nincs ilyen gép, akkor – legalább– egy szinttel lejjebb kell lépnünk.

2.2. A döntések elhalasztásának elve

Egyszerre csak kevés dologról, de következetesen kell rendelkezni. A problémát kevés, de jól körülhatárolt részproblémára kell bontani. Ám óvakodni kell a másik véglettől is, hiszen a túl kevés részre bontás általában nem vezet optimális döntésekhez, mert nem azonos nehézségű, súlyú részproblémákkal szembesülünk.

A részfeladatok pontos körvonalazásához eleinte még nincs elegendő ismeret a birtokunkban, és ha döntésünket később felül kell bíráljuk, még visszalépések is adódhatnak. Az a jó döntés, amely a későbbiek során a legkevésbé köti meg kezünket.

Célszerű az adatok és eljárások finomításánál minél későbbre halasztani azokat a döntéseket, amelyek kihasználják a gép, illetve a programozási nyelv konkrét sajátosságait. Annál jobb a programunk, minél többet tartalmaz a feladat lényegi felépítéséből és minél kevesebbet a gép, illetve a nyelv kötöttségeiből.

Ugyanezen elv alapján célszerű a bonyolult döntéseket későbbre hagyni, az algoritmus finomítása során ugyanis nagy valószínűséggel ezek egyszerűbbé válnak.

2.3. Vissza az ősökhöz elv

Erre akkor van szükségünk, amikor körültekintő megfontolásaink ellenére zsákutcába kerülünk. Ekkor vissza kell lépni az előző szinthez (az őshöz), és újra végig kell gondolni a részfeladatokra bontást, a keserű tapasztalatok figyelembevételével.

Vegyük példának az alábbi ábrán mutatott szituációt! Bármennyire is csábító lenne a zsákutcából a 2. részfeladat újra átgondolásával, feladatának újra meghatározásával kijutni, elkerülhetetlen a 2.-at tartalmazó minden részfeladatát (az 1.-t és a 3.-at … is) újra megfontolni, hogy a beépített elem hézagmentesen illeszkedjen.

A visszalépés nem hiba, csupán egy előre nem látható hatású döntés következménye. A visszalépések e programkészítési folyamatban természetesek.

A képen egy „pillanatfelvétel” látható, amelyben a feladatok részfeladatokra bontása során a programozó megakad.'Vissza az ősökhöz' elv alkalmazása.

2.4. A „nyílt rendszer” felépítés elve

Nemcsak a feladatra, hanem a feladatot is tartalmazó feladatkörre alkalmazható programot érdemes definiálni. Ezzel elkerülhetjük a későbbi kényszerű feladat- vagy programidomítási gondokat, azaz nem egy „nyárra” hozunk létre programot. (Szokás ezt még a feladatáltalánosítás elveként is emlegetni.)

Itt tehát nagyobb szabadságot kell adnunk az előfeltételben, több lehetséges eredményt az utófeltételben, csak az a kérdés, hogy meddig érdemes elmenni?

Az általánosításnak nyilvánvalóan vannak hatékonyságrontó vonatkozásai, valamint a programozási munkát növelők is. Az előbbi kérdésre a válasz nyilvánvalóan az, hogy addig, amíg a befektetett munka nem növekszik meg túlságosan, és a kapott eredmény még megfelelő hatékonyságú lesz.

2.5. A döntések kinyilvánításának elve

A ki nem mondott, de hallgatólagosan meghozott döntések rugalmatlanná és „álnokká” teszik a programot. Szorosan összefügg azzal, hogy a fejlesztői dokumentációt a program tervezésével, írásával párhuzamosan kell készíteni. (Ebben úgy írjuk le a programot, hogy működését más is megértse, szükség esetén módosítsa.)

2.6. Az adatok elszigetelésének elve

Ez az elv azt mondja ki, hogy a programot biztos mederben csak úgy lehet tartani, ha az egyes programegységek a megtervezett illesztéseken, kapcsolatokon kívül egymással nem beszélhetnek. Ezért tehát a programegységekhez tartozó adatokat ki kell jelölni, és el kell szigetelni más programegységektől.

Az adatok kijelölését legcélszerűbb a programegységben betöltött szerepük alapján csoportosítani: közös (pontosabban fogalmazva: globális), ezen belül bemeneti (input) és kimeneti (output) adatok.

A programegységhez és csak hozzá tartozó, saját (pontosabban fogalmazva: lokális) adatok, melyektől mint később látni fogjuk a jó helykihasználás miatt hasznos elválasztani az ún. munkaadatokat (igazából ezeket nevezik a programozók saját adatoknak). Ez utóbbiak a programegységnek csak egyszeri működéséhez, időlegesen felhasznált segédadatok.

Így a következő ábrához hasonló táblázatot (az ún „kereszthivatkozás-” vagy „keresztreferencia-táblát”) építhetünk föl a program létrehozása közben. A táblázat tartalmazza az adat nevét, azt a szintszámot vagy eljárásnevet, amelyben létrehoztuk, és a hatáskörét (az egész szinthez vagy csak a szint egy eljárásához tartozik).

Adat

Szint

Hatáskör

sor_számláló

lapozás

munka

lap_számláló

lapozás

be-kimenet

Megjegyzés

E táblázatot praktikusan még további oszlopokkal bővíthetjük, úgy fogja igazán jól betölteni a szerepét. Vegyük észre, hogy nem nehéz olyan programot készíteni, amellyel ez a tábla automatikusan generálható (az érintett program forráskódjából).

2.7. A párhuzamos ágak függetlenségének elve

Szintenként az egyes részfeladatok között semmilyen vezérlési, illetve adatforgalom nem lehetséges, mindezt az eggyel magasabb szint feladata megoldani. Tehát egy szinten sőt különböző szinteken, de független kifejtési ágakon levő eljárások egymást nem hívhatják, egymás változóit nem is láthatják.

2.8. A szintenkénti teljes kifejtés elve

Minden szint a probléma teljes megoldását adja egy olyan absztrakt gépen, amelynek utasításai a szinten nem definiált, primitív eljárások, valamint elemi tevékenységek. Emiatt a szint leírásának már tartalmaznia kell a majdani alatta levő szint eljárásainak specifikációját is.

A résztevékenységek interfészeinek illeszkedniük kell egymáshoz: Kimeneti + Előfeltételi Bemeneti+1 + Utófeltételi+1!

Vissza a tartalomjegyzékhez

3. Technológiai elvek

A programírás már ecsetelt didaktikai elveitől a technológiai elvek vezetnek el bennünket a kóddal kapcsolatos technikai elvek birodalmához. Ezek az elvek az algoritmus (és a kód) írására, annak szabályaira vonatkoznak.

3.1. Algoritmusleírási szabályok

Kevés, de egyértelmű szabályt kell kialakítani az algoritmusok leírására. Ez legyen számunkra kellően kényelmes gondolataink szárnyalásához, de a kényelem nem mehet a precizitás, az egyértelműség rovására! Ebben a legfontosabb algoritmikus szerkezeteknek helyet kell kapniuk.

Melyek is ezek a nevezetes szerkezetek?

Az adatokat beolvasó és kiíró utasítások az „ablak” szerepét játsszák a külvilág felől, illetve a program felhasználója felé.

A program változóinak értékkel való ellátását az értékadó utasítások végzik.

A feltételektől függő végrehajtást teszik lehetővé az ún. feltételes utasítások, elágazások.

A számítógépre szánt feladatok mindegyike feltételezi bizonyos részfeladatok ismételt elvégzését. A számítógép erősségét, a gyorsaságot éppen a „mechanikus” ismétlések használják ki a legjobban! Ezek ciklusutasítások segítségével valósulnak meg.

A program adott szintjén elemi utasításként felhasznált, meghatározott, de nem finomított részprogramok (eljárások, függvények, operátorok) beépítését (az ún. eljáráshívást) is meg kell oldanunk nyelvünkben.

Természetesen a felhasznált és még hiányzó eljárások finomítása (másként szólva: az eljárás kifejtése) sem hiányozhat.

Az algoritmusleírás mellett e nyelvek rendelkeznie kell az adatok (konstansok, változók) és típusok leírására szolgáló eszközökkel is.

3.2. Értelmes sorokra tördelés – világos tagolás

Kérdés, hogy mit írjunk egy sorba, mit több sorba. Alapelképzelésünk lehetne például az, hogy minden utasítást külön sorba kell tenni. Ezt a következőképpen módosítjuk: kerüljenek egy sorba azok az utasítások, amelyek szervesen összekapcsolhatók, és egy sorba írásukkal a program még áttekinthető marad.

3.3. Bekezdéses leírás

Ahogy az író is főbb gondolatait, a történés főbb eseményeit fejezetekbe tömöríti, ahogy az egyes epizódok külön-külön bekezdéseket alkotnak a fejezeten belül, valahogy úgy kell algoritmikus gondolatainkat, az algoritmus főbb eseményeit, epizódjait is jól láthatóan elkülöníteni a programban. A program teljes levezetése (finomítása) után a program szerkezetének vissza kell tükröznie a szintekre tagozódást: egy szint elemi utasításai a bekezdések azonos szintjeit alkossák!

Egyes nyelvi szövegszerkesztők automatikusan a bekezdéses leírásnak megfelelően tördelik programunkat.

3.4. Összetett struktúrák zárójelezése

Az algoritmusokban szereplő elágazások, ciklusok, eljárások, valamint az összetett adatstruktúrák úgy ismerhetők fel könnyen, ha nemcsak az elejüket jelzi valamilyen nyelvi elem, hanem a végüket is egyértelműen rögzítjük.

3.5. A „beszédes” azonosítók elve

A konstansoknak, változóknak, típusoknak, eljárásoknak, függvényeknek, operátoroknak olyan nevet érdemes adni, ami utal arra, hogy mire használjuk. Ez kizárja az azonosítók keveredését: hiszen a név sugallja funkciót, az algoritmusban betöltött szerepet. Nagy segítséget nyújt a kódoláskor is, például lehetővé teszi, hogy minimális számú változót rendeljünk az adatokhoz, hiszen a munkaváltozókhoz azonos neveket is rendelhetünk.

Nem minden esetben a hosszú azonosítók a beszédesek, például ha egy fizikai képlettel (E=m*g*h) dolgozunk, akkor éppen ezek az egybetűs jelölések a beszédesek, ha pedig mátrixösszeadásra definiálunk egy operátort, akkor azt célszerű a + jellel jelölni.

Vissza a tartalomjegyzékhez

4. Technikai elvek

A továbbiakban technikai jellegű ismérveket sorolunk fel, amelyek a program kódjával kapcsolatosak. Inkább úgy mondhatjuk, hogy az előzőek a program megírásához szükségesek, ez utóbbiak pedig a program használhatóságához elengedhetetlenek. Ilyen értelemben beszélhetünk a „csak” helyes programról, amely a feladat logikája szempontjából tökéletes, és a programról, amely ezen túl elő is segíti saját felhasználását.

4.1. Barátságosság, udvariasság

Az udvarias program bemutatkozással kezdi ténykedését (tájékoztató), és ezzel tudatja a felhasználójával képességeit, szolgáltatásait, használatának mikéntjét. Az udvariasság másik fontos megnyilvánulása, hogy a program futása során megjelenő kérdések bárki számára – azaz a nem informatikus szakemberek számára is – érthetők, és a válaszok a lehető legegyszerűbben megadhatók legyenek. Így például nem rabolja feleslegesen a felhasználó türelmét azzal, hogy a már megadott adatokból kiszámítható, származtatható adatokat kér.

4.2. Biztonságosság

A „bolondbiztos” program az, amit a kísérletezni vágyó vagy éppen balszerencsés felhasználó sem képes ellenőrizetlen vágányokra terelni azáltal, hogy nem a megfelelő módon, vagy nem a megfelelő pillanatban válaszol a feltett kérdésére. Ennek érdekében a program kritikus pontjait, azaz ahol a felhasználó közvetlenül avatkozik be a program további menetébe, nagy odafigyeléssel kell megírni. Az esetleges hibalehetőségekre fel kell készíteni a programot úgy, hogy a felhasználónak lehetősége legyen a helyesbítésre is. (Itt használjuk ki a specifikáció előfeltétel részében leírtakat.)

Nem támaszkodhatunk a számítógép, illetve az értelmező vagy fordítóprogram eleve meglévő hibajelzéseire. Ezek ugyanis arra valók, hogy segítségükkel felderíthessük és kijavíthassuk az esetleges programhibákat, tehát a program írója, nem pedig a használója számára készültek. A felhasználónak végeredményben semmi köze sincs ahhoz, hogy a program nem közvetlenül, hanem valamilyen programozási nyelv közvetítésével, bábáskodásával mozgatja a számítógépet.

A „bolondbiztos” tulajdonság egyébként nemcsak e technikai elv, hanem a piramiselv közvetlen folyománya is, mert ahogy megadtuk az egyes eljárások közötti elvárásainkat (ti. egy eljárás végső feltételei nem lehetnek bővebbek, mint az azt követő eljárás bemeneti feltételei), pontosan ugyanúgy kell rögzíteni a „külvilág” és a beolvasó eljárás kapcsolatára vonatkozó kívánalmakat is. A külvilág azonban a programnak nem része, és így nem is programozható, ezért a bemeneti eljárások kezdőfeltételeinek körét megfelelően ki kell szélesíteni. Ez azt jelenti, hogy a bemenő adatok értéktartományát, összeférhetőségét ellenőrizni kell. Ha ezek az eredeti feltételeket nem teljesítik, akkor jelezni kell, majd új adatbevitelt kell kezdeményezni.

4.3. Jól olvasható program

A program módosításakor, továbbfejlesztésekor óriási előnyt jelent, ha nem kell a programunk minden mellékes vonását újra feltérképezni a megértéshez, hanem a lényeges tulajdonságai a program megfelelő helyén könnyen kiolvasható formában megtalálhatók, és így a sebész magabiztos mozdulatával nyúlhatunk bele a program legérzékenyebb részeibe is.

Már két idevágó elvet is említettünk: a bekezdésesleírás és az összetett utasítások zárójelezése elveket. Ezt egészíthetjük ki a kódoláskor különösen nagy jelentőségűvé váló „jó magyarázatok (kommentek)” elvével. A programozási nyelvre való áttéréskor ugyanis a programozási nyelv kötöttségei miatt sok, az algoritmust nagyban jellemző tulajdonság elveszne, ha ezeket az információkat nem őriznénk meg egy-egy jól megfogalmazott megjegyzés formájában.

4.4. A (jól) dokumentált program

Sokszor nincs lehetőség – a program méretére rótt korlátozások miatt – arra, hogy az előző elvet maradéktalanul megvalósíthassuk; ekkor le kell írni a program fontos vonásait: az algoritmusát (felépítését), a változóit és ezek szerepét, értelmezését, értéktartományát, hatáskörét stb., a kódolásnál követett szabályokat (a leíró és a programozási nyelv utasításainak, illetve változóinak megfeleltetését). Ezeket a dokumentációban is rögzíteni kell, amelyben ezen kívül még foglalkozni kell a használat mikéntjével és az esetleges, előre látható fejlesztési lehetőségekkel is.

Vissza a tartalomjegyzékhez

5. Esztétikai-ergonómiai elvek

A következőkben a már ismertetett udvariasságra és bolondbiztosságra vonatkozó elv finomításairól, a program emberközelségéről lesz szó. Ezek a használatot befolyásoló tényezőkre hívják fel a figyelmet. Legfőbb mondanivalójuk, hogy nagy gondot kell fordítani a program által megjelenített információk külalakjára. Ide nemcsak az eredmény jellegű kiírandók tartoznak, hanem például a tájékoztató, a felhasználóval való párbeszéd módja is.

5.1. Lapkezelési technika

A kiírandó szövegek, adatok logikai egységekre bontva jól különüljenek el, egyszerre csak annyi és olyan ütemezésben, amennyit és ahogy a felhasználó be tud fogadni. Ennek megvalósítására alkalmazzák a lapkezelés technikáját.

Mit is jelent a lapkezelés? Egyszerre egy képernyőlapnyi információt jelenítünk meg, és a felhasználónak lehetősége van lapozásra, például egy adott billentyű lenyomásával jelzi a gépnek: „Elolvastam! Lapozhatsz!” (Többek között ennek megvalósítására használható a „Várj, amíg szükséges” utasítás.) Nem szerencsés ez esetben az adott ideig történő várakozás – gondoljunk a különböző olvasási sebességű felhasználókra!

Nyomtató esetén e várakozásra nincs szükség, viszont újdonságként felmerülhet a lapszámozás, illetve a fejléc vagy lábléc írása.

Képernyőkezelés esetén is lehetőséget kell teremtenünk arra, hogy az aktuális képernyőtartalmat kinyomtathassuk.

Mit kell még figyelembe venni egy lap összeállításánál? Ügyelni kell a képernyőlap arányos kitöltésére, és jó, ha az egy lapon belül szereplő, logikailag szorosan össze nem tartozó információk egymástól elkülönülnek. Az elkülönítés megoldható üres sorok beiktatásával, az egyes részek szakaszokkal való elkülönítésével, illetve bekeretezésével.

A mondanivalónk legfontosabb elemeit – a gép adta lehetőségek figyelembevételével – kiemeljük (inverz betűkkel, vagy bekeretezve, vagy más színű háttérrel, illetve betűkkel stb.).

5.2. Menütechnika

A lapkezeléssel szorosan összefüggő módszer, amely a felhasználóval való párbeszéd elegáns megszervezésére alkalmas. Általában bonyolult szolgáltatásokkal rendelkező programoknál használatos, amelyből a felhasználó – akár egy menüből – kiválaszthatja a számára szükséges lehetőséget.

Minden egyes válaszával (válaszcsoporttal) a kérdések egy nagy hányadát kizárja, ezeket a számítógépnek fel sem kell tennie, megkímélve a felhasználót a fölösleges válaszadásoktól (hierarchikus menürendszer).

A menü egy lap (vagy ablaka), amelyen megjelennek a választási lehetőségek; közülük sorszámmal (vagy kezdőbetűvel), illetve rámutatással (kurzormozgató billentyűk vagy egér segítségével) választhatunk.

A program főmenüjében célszerűen szerepel egy Munka befejezése menüpont, a többi menüpont végrehajtása után pedig újra e főmenü jelenik meg. Az egyes almenük hasonló elven épülhetnek fel, de ezekben a befejezés helyett a Vissza az előző menühöz pont választható.

5.3. Ikontechnika

A szöveges menüknél esetenként gyorsabban felismerhetők az egyes választási lehetőségek, ha azokat kicsi jellemző ábrával, ún. ikonnal jelenítjük meg; közülük rámutatással (kurzormozgató billentyűk vagy egér segítségével) választhatunk.

Ez a technika azonban könnyen veszélyessé válhat: a túl sok és túl kicsi ikon a képet áttekinthetetlenné teheti.

5.4. Értelmezési tartomány kijelzése

A kérdéseknél nagyon sokszor épp az okoz bizonytalanságot, hogy a felhasználónak fogalma sincs arról, hogy az adatot milyen mértékegységben kell megadni. Ezért a kérdés szövege mellett célszerű közölni az adat mértékegységét, sőt – ha nem magától értetődő, akkor – még az értéktartományt is.

Így elkerülhető, hogy például a program egy szöget radiánban vár, a gyanútlan felhasználó pedig a legnagyobb természetességgel fokban adja meg az értéket. Az ilyesmiből származó hibát nyilván nem kell ecsetelnünk.

5.5. A fontos adatok kiemelése

Nemcsak az információk könnyebb megértése szempontjából van jelentősége – amint ezt már a laptechnikánál taglaltuk –, hanem hasznos a program állapotának, meghatározó paramétereinek azonnali visszajelzésekor is.

Például amikor a számítógép egy hosszadalmas számítást végez, vagy bármilyen időigényes tevékenységbe fog – a hangsúly a hosszadalmasságon, időigényességen van! –, akkor ne maradjon el időnként egy-egy kiírás, ami értesíti a felhasználót, hogy mely tevékenységgel bíbelődik éppen a program, és hogy még kis türelmet kér. Látványos lehet ilyen esetekben közölni azt – esetleg grafikus formában is –, hogy a feldolgozás hány százalékánál tart éppen a program.

5.6. Tördelés

A legelemibb elvárás a képernyőn megjelenő szövegekkel szemben, hogy a sorok/szavak tördelése a helyesírás szabályainak megfeleljen. Ne sajnálja a programozó a fáradságot mondanivalójának gördülékeny megfogalmazására, szép elhelyezésére, hiszen csak ily módon kaphat mindenki számára kellemes programot!

5.7. Következetesség

A következetes beolvasási és kiírási szokások is fontosak. Tartsunk mértékletességet a beolvasási módszerek változatosságában. Nem díjazzák a felhasználók kiterjedt programozási ismereteinket, ha a választ hol <ENTER>-rel lezárva, hol anélkül várja a program.

Hasonló probléma az IGEN-NEM választ igénylő kérdések sokféle feldolgozási lehetősége, válasszunk egyfajtát, és ahhoz ragaszkodjunk.

Ha lehetőségünk van rá, akkor a lapkezelési technikához kapcsolódva az azonos jellegű kérdések, illetve eredményadatok a lapok azonos helyein jelenjenek meg.

5.8. A hibajelzés követelményei

A hibák kézben tartásának szükségességéről már volt szó, de a hibák jelzésének mikéntje is jellemzi a programot. Igyekezni kell a hibajelzés legmegfelelőbb módjának kiválasztására. Ehhez a következő szempontokat érdemes megfontolni:

Felesleges azonban abban az esetben külön hibajelzés szöveget kiírni, amikor a kérdés szövegéből egyértelmű, hogy a felhasználó mit rontott el. Ekkor elég például egy hangjelzés, majd a kérdés újra feltevése.

5.9. Naplózás

A program futása során több olyan esemény következhet be, amelyeket jó feljegyezni a későbbi esetleges feldolgozás érdekében. A felhasználó – ha ott ül is a számítógép mellett – nem biztos, hogy megteszi ezeket. Ennek megoldására szolgál az ilyen események automatikus fájlba írása, a naplózás. Ez többnyire egy egyszerű szerkezetű szöveges fájl, amit a használó könnyen (egy „igénytelen” szövegszerkesztővel is) képes megjeleníteni, nyomtatni.

5.10. Makrók, funkcióbillentyűk

Érdemes lehet egyes funkciókhoz, funkciócsoportokhoz egy-egy billentyűt hozzárendelni, és annak bármikori lenyomása a megfelelő funkciók végrehajtását jelenti.

Például szimulációs programokban gyakran találkozunk olyan funkcióbillentyűkkel, amelyek a szimuláció leállítására, újra paraméterezésére, megjelenítési módjának változtatására, részleges összesítések elkészítésére stb. vonatkoznak.

5.11. Segítség

Egy tipikus funkcióbillentyű a segítség (HELP=SÚGÓ) billentyű. Ennek lenyomása a futás bármely pillanatában a program aktuális állapotáról szükséges tudnivalók kiírását eredményezi.

Ennek egy hasznos formája a menüben mozgás alatti segítség, amely az aktuális menüpont részletes leírását adja a felhasználó kívánságára.

5.12. Ablaktechnika

A homogén képernyő helyett célszerű olyan lapokat, ún. ablakokat használni, amelyek a képernyő elkülönített részein jelennek meg.

Egy ablak mindig egy keret, és egy a belsejében levő tartalom. Az ablak kiírásakor a képernyőn alatta lévő részt eltakarja, és levételekor újra megjelenik az eltakart rész.

Ablakokat használhatunk a segítségszöveg megjelenítésére, hibajelzésre, menük kezelésére, a program állapotának kijelzésére stb.

Az animáció bemutatja a programkészítési elveket:

Az animáció bemutatja a különböző programkészítési elveket.

Flash lejátszó letöltése

Programkészítési elvek

Vissza a tartalomjegyzékhez

Fel a lap tetejére
Új Széchenyi terv
A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszirozásával valósul meg.