OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK

OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK Dr. Gyurkó György 2011.

Szerzı: Dr. Gyurkó György

Lektorálta:

Elıszó A szoftvertechnológia (benne az objektumorientált technológia) nem olyan tudás, amely csupán elméleti képzés útján átadható vagy nem túl nagy számú feladat megoldásának betanulásával elsajátítható lenne. Az OO technológiában ugyan léteznek széles körben alkalmazható és nagyon hasznos tervezési minták, de ezek megértése vagy adott problémára való alkalmazhatóságuk és konkrét esetben való hasznosságuk felismerése maga is biztos elméleti alapokat és jelentıs gyakorlatot feltételez. További sajátos körülmény, hogy a szoftvertechnológia tárgyát képezı problémák általában nem abba a kategóriába tartoznak, amelyekre csak egyetlen lehetséges jó megoldás létezik. A kicsit is összetettebb rendszerek terve pedig általában nem mindjárt egy tökéletes változatban pattan ki a tervezı(k) fejébıl, hanem valamilyen fejlıdési fokozatokat jár be, mire a kivitelezésnek átadható változat lesz belıle. Tehát a kezdeti változatok minıségének mércéje értelemszerően nem a tökéletesség (és fıleg nem a teljesség), hanem az, hogy könnyen bıvíthetık úgy, hogy a bıvítmények szervesen tudnak illeszkedni a bıvítés elıtt létrejött elemekhez. Az említett körülményeket figyelembe véve az egyes esettanulmányoknak nem az a célja, hogy adott feladatok egy adott megoldását súlykolják, hanem az, hogy az Olvasó a késıbb felmerülı (ma még ismeretlen) problémákra is képes legyen önállóan megoldást találni. Ezért az esettanulmányok tárgyalása a hangsúlyt nem a végeredményként kapott megoldásra, hanem az ahhoz vezetı útra helyezi, és nem is csak egyetlen útra terjed ki, hanem az elágazásokban szóba jöhetı alternatív ágakra, és az egyes ágak választásának a megoldásra, illetve a rendszer késıbbi bıvíthetıségére kiható következményeire is. A tárgyalt problémák mindegyike elıfordult már korábbi szoftvertechnológia kurzusok gyakorlati foglalkozásain, így azok tapasztalatai beépülhettek az esettanulmányokba, azokon belül is legerısebben az ellenırzı / magyarázó kérdésekbe és a rájuk adott válaszokba. Az Olvasó jól teszi, ha nem hagyja ki ezeket a kérdés-válasz dialógusokat, még akkor is, ha azok eleinte esetleg olyan kellemetlen felismerésekre vezetik rá, hogy amirıl úgy vélte, már érti, azt is rosszul értette. Elıbb-utóbb rá fog jönni, hogy ezek a dialógusok mind a tervezıi gondolkodás mozzanatainak, mind a modellek értelmezésének lényeges elemeirıl szolgálnak nagyon hasznos ismeretekkel. A szerzı számára nem ismeretlen az a szituáció, amikor egy hallgató az érdeklıdés teljes hiányában csupán valamilyen kényszerbıl veszi fel a szoftvertechnológia (OO tervezés) kurzust. Korábbi ilyen hallgatóim közül néhány, immár valamilyen munkakörben elhelyezkedve fontosnak tartotta visszajelezni, utólag rájött, miért lett volna hasznos a tanított témákra odafigyelni, és azokat az elıkeresett régi jegyzeteibıl próbálja éppen pótolni; vagy már pótolta is, és egy külföldi fejlesztési projektben ı tanítja az OO tervezés fogásaira a team más tagjait. – Ezt (az elégtétel érzésén túl) azzal a „hátsó” szándékkal említettem meg, hogy még idıben kedvezı felismerésre bírjam a téma irányában kevésbé motivált olvasókat is. Budapest, 2011. augusztus 2. A szerzı Az Olvasó észrevételeit a következı címre küldheti: [email protected]

TARTALOMJEGYZÉK

1.

Bevezetés (Elızetes tudnivalók az esettanulmányokról) ........................... 9

1.1 1.2 1.3 1.4 1.4.1 1.4.2

Az esettanulmánykötet célja..................................................................................... 10 Az esettanulmányok témáinak kiválasztása ........................................................... 11 Az esettanulmányok szerkezete................................................................................ 13 Technikai jellegő tudnivalók .................................................................................... 15 A diagramok szerkesztése ........................................................................................... 15 A pszeudokód értelmezése .......................................................................................... 15

2.

Digitális óra............................................................................................. 27

2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.5

A feladat ..................................................................................................................... 28 A probléma használati eset modellje ....................................................................... 29 A probléma statikus modellje................................................................................... 32 A statikus modell elsı változata.................................................................................. 32 A statikus modell második változata – Újrafelhasználás I.......................................... 38 A statikus modell harmadik változata – Újrafelhasználás II....................................... 41 Amit a tervezı elhanyagolt ......................................................................................... 45 A probléma dinamikus modellje.............................................................................. 47 A digitális óra létrehozása, kezdeti teendık................................................................ 47 A DigitálisÓra osztály állapotdiagramja ..................................................................... 50 Az állapotdiagram alapján levonható következtetések ............................................... 55 Az állapotdiagram szerepe a programkód kialakításában ........................................... 57 Szekvenciadiagram az óra normál mőködése alatti egyik folyamatról....................... 64 Szekvenciadiagram az óra beállítása alatti egyik folyamatról .................................... 67 Vezet-e út a digitális óra problémától a vállalatirányítási alkalmazások fejlesztéséig?............................................................................................................... 70

3.

Zsebszámológép...................................................................................... 71

3.1 3.2 3.2.1 3.2.2 3.2.3 3.3 3.4 3.4.1 3.4.2 3.4.3 3.4.4

A feladat ..................................................................................................................... 72 A követelmények részletesebb meghatározása ....................................................... 73 A Calculator alkalmazás viselkedésének megfigyelése .............................................. 73 A zsebszámológép mőködésére vonatkozó követelmények ....................................... 80 A zsebszámológép használati eset modellje................................................................ 82 A probléma statikus modellje................................................................................... 85 A probléma dinamikus modellje.............................................................................. 91 A ZsebSzámolóGép osztály állapotdiagramjának elsı változata................................ 91 A ZsebSzámolóGép osztály állapotdiagramjának második változata......................... 96 A ZsebSzámolóGép osztály állapotdiagramjának harmadik változata ....................... 97 A statikus modell finomítása a ZsebSzámolóGép osztály állapotdiagramjával összefüggésben tett megfontolások alapján ................................................................ 98 A ZsebSzámolóGép osztály állapotdiagramjának negyedik változata ..................... 102 A számJegyFd(számJegy) mővelet megvalósítása ................................................... 104 Az alapMőveletFd(mővelet) metódus megvalósítása ............................................... 108 A zsebszámológép létrehozása, kezdeti teendıi ....................................................... 112 Szekvenciadiagram egy adabeviteli folyamatról....................................................... 114

3.4.5 3.4.6 3.4.7 3.4.8 3.4.9

3.4.10 Szekvenciadiagram számítási mőveleteket tartalmazó folyamatról.......................... 116

4.

Egy lakás biztonsági rendszere........................................................... 119

4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.3.10 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.5

A feladat ................................................................................................................... 120 A probléma használati eset modellje ..................................................................... 123 A használati eset diagram kétféle élesítés paranccsal ............................................... 123 A használati eset diagram élesítési mód paranccsal.................................................. 125 A probléma statikus modellje................................................................................. 126 A konkrét rendszer objektumdiagramja .................................................................... 126 Az objektumdiagramból elvonatkoztatott osztálydiagram........................................ 128 A MozgásÉrzékelı és a NyilásZáróÉrzékelı specializációk .................................... 131 Az érzékelık üzemképesség-nyugtázási módjának figyelembe vétele..................... 135 Az érzékelık specializációja csupán az érzékelt változás típusa szerint .................. 141 Az érzékelık specializációja csupán a nyugtázási mód szerint ................................ 143 Az érzékelık többszintő hierarchikus specializációja............................................... 145 Az érzékelık hálós specializációja (csak elvi lehetıség).......................................... 146 Specializáció kombinálása kompozícióval................................................................ 147 A statikus modell (az áttekintı osztálydiagram) második változata ......................... 152 A probléma dinamikus modellje............................................................................ 156 A Zóna osztály állapotdiagramjának elsı változata.................................................. 156 A Zóna osztály állapotdiagramjának második változata........................................... 158 A Zóna osztály állapotdiagramjának harmadik változata ......................................... 160 A Vezérlés osztály állapotdiagramja......................................................................... 164 Szekvenciadiagram egy kiiktatott zóna kezelésérıl.................................................. 166 A zónák, a vezérlés és a kapcsolótáblák együttmőködése ........................................ 168 A Vezérlés és a KapcsolóTábla osztályok specifikációjának kiegészítése ............... 170 Folytassa az Olvasó! ................................................................................................ 172

5.

Egy szupermarket parkolási rendszere ............................................. 173

5.1 5.1.1 5.1.2 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.4 5.4.1 5.4.2 5.4.3 5.5 5.5.1 5.5.2 5.5.3 5.5.4

A feladat ................................................................................................................... 174 A megtervezendı parkolási rendszer ........................................................................ 174 Adatbázishasználat, konkurens események kezelése ................................................ 175 A probléma használati eset modellje ..................................................................... 177 A probléma statikus modellje................................................................................. 179 A konkrét rendszer objektumdiagramja .................................................................... 179 Az objektumdiagramból elvonatkoztatott osztálydiagram........................................ 180 A szálak figyelembe vétele a statikus modellben...................................................... 184 További variációk a szálakat figyelembe vevı modellre .......................................... 187 A probléma dinamikus modellje............................................................................ 189 Az autó egyedek állapotdiagramjának elsı változata ............................................... 189 Az autó egyedek állapotdiagramjának második változata ........................................ 195 A szálakon futó folyamatok ábrázolása tevékenységdiagramokkal.......................... 199 Folytassa az Olvasó! ................................................................................................ 205 Elveszett parkolócédula esetének kezelése ............................................................... 205 Ha a díjmentes parkolás nem akármeddig díjmentes ................................................ 206 A fizetıautomata nem autó egyedet érintı eseményeinek kezelése ......................... 206 Az operátori pult nem autó egyedet érintı eseményeinek kezelése.......................... 207

6.

Termékszerkezettel kapcsolatos feladatok ........................................ 209

6.1

A feladat ................................................................................................................... 210

6.1.1 6.1.2 6.1.3 6.2 6.2.1

A termékszerkezeti háló ............................................................................................ 210 Adott termék szerkezetének és közvetlen anyagszügségletének megjelenítése........ 211 Adott termék teljes anyagszükségletének meghatározása......................................... 212 A probléma statikus modellje................................................................................. 213 A cikkek hálós kapcsolatainak modellje kapcsolatvektorokkal és kétirányú navigációval .............................................................................................................. 213 6.2.2 A termékszerkezeti háló modellje kapcsolatvektorral és egyirányú navigációval.... 215 6.2.3 A termékszerkezeti háló reprezentációja egy relációs adatbázisban......................... 216 6.2.4 A termékszerkezeti háló modellje a kapcsolatok listába szervezésével.................... 220 6.2.5 A termékszerkezeti háló modellje egy ListaElem osztály újrafelhasználásával ....... 223 6.3 A probléma dinamikus modellje............................................................................ 227 6.3.1 A bemeneti és a kimeneti adatszerkezetek eltérése................................................... 227 6.3.2 A közvetlen anyagszükséglet meghatározása – A termékszerkezet hierarchikus bejárásának vezérlése veremmel ............................................................................... 228 6.3.3 Adott termék teljes anyagszükségletének meghatározása......................................... 231 …Nincs befejezve!!!

1. Bevezetés (Elızetes tudnivalók az esettanulmányokról)

10

OBJEKTUMORIENTÁLT TERVEZÉS – ESETTANULMÁNYOK

1.1 Az esettanulmánykötet célja

A szoftverfejlesztés objektumorientált (továbbiakban: OO) technológiájának megismertetésébıl az OBJEKTUMORIENTÁLT ELEMZÉS ÉS TERVEZÉS c. tankönyv csak az alapelveknek, az alapvetı fogalmaknak, valamint az OO technológia által használt UML modellezési technikáknak a bemutatását vállalta magára. Adós maradt azzal, hogy a tanultakat miként kell egymással összefüggésben és módszeresen alkalmazni egy konkrét probléma megközelítıen optimális megoldásának megtervezésében. Az itt következı esettanulmányok a kereskedelmi forgalomban elérhetı más elméleti szakkönyveknek is éppen ezt a hiányosságát igyekeznek pótolni: az Olvasóban az OO technológia által megkívánt készségek kialakulásához próbálnak hozzájárulni. Az esettanulmányok tárgyalása feltételezi a fentebb említett tankönyv anyagának ismeretét, azaz nem foglalkozik a használt fogalmak megtanításával, helyette mindig valamilyen konkrét feladatra összpontosít; az alapelveknek, fogalmaknak és modellezési technikáknak egy-egy megoldandó feladat szempontjából célszerő alkamazását mutatja be.

BEVEZETÉS

11

1.2 Az esettanulmányok témáinak kiválasztása A esettanulmányok témái kiválasztásánál a következı szempontok játszottak szerepet: • A feladatok a probléma megoldásának nehézségi foka tekintetében különbözı szintőek legyenek, alkalmasak a növekvı nehézégi fok sorrendjében való „adagolásra”. • A feladatok tartalmukban változatosak legyenek, mégis fellelhetı legyen köztük annyi hasonlóság, amennyi lehetıvé teszi az absztrakciós készségnek az analógiák felismerése útján való fejlesztését, az újrafelhasználás gyakorlását, valamint a megerısítı ismétlést. A feldolgozott problémák (témák) jellemzıi: Probléma 1. Digitális óra

Jellemzık Egyszerő probléma. Az alkalmazás nem egy fizikailag létezı órát vezérel, hanem az óra szoftveres szimulációját valósítja meg.

2. Zsebszámológép

Egyszerő probléma. – Hasonló az 1. feladathoz, de a felhasználói felület és a vezérlés valamivel bonyolultabb, és alkalmat ad a követelmények megfigyelés útján való meghatározásának gyakorlására is.

3. Egy lakás biztonsági rendszere

Az elızı problémákhoz képest itt több komponens együttmőködését kell megoldani. Az alkamazás fizikai eszközöket kezel, tehát itt már nem csupán valaminek a szoftveres szimulációjáról van szó. A rendszernek a felhasználói eseményeken és az idıeseményen felül más eseményekre is reagálni kell, és felmerül benne a konkurens események kezelésének problémája is.

4. Egy szupermarket parkolási rendszere

Bizonyos elemeiben hasonlóságot mutat a 3. feladattal. Az elızıekhez képest lényeges különbség, hogy a rendszer perzisztens objektumokat is kezel, és emiatt már egy adatbázist is használ. Több felhasználó. A konkurens események kezelésére alkalmazott szálak megjelennek mind a statikus, mind a dinamikus modellben. A mőködést, a kimenetet nem egy vézérlı objektum állapotmodellje, hanem az adatbázisban tárolt egyedek állapotváltozásai határozzák meg.

5. Termékszerkezettel kapcsolatos feladatok Az adatabsztrakció tekintetében több megfon(a közvetlen, illetve a teljes anyagszükséglet tolásra van szükség, mint a megelızı esettameghatározása) nulmányoknál, és a hangsúly a bonyolultabb kimenetek elıállítására tevıdik át. A bemeneti

12

OBJEKTUMORIENTÁLT TERVEZÉS – ESETTANULMÁNYOK Probléma

Jellemzık adatszerkezet és a kimenet szerkezete olyan különbségeket mutat, hogy az utóbbit elıállító transzformáció köztes (közvetítı) adatszerkezeteket (objektumokat) is igényel.

Az egyes esettanulmányok korlátozott mértékben magukban is érthetık, illetve tetszıleges sorrendben feldolgozhatók, azonban több okból is ajánlatos a fejezetszámok sorrendjében haladni: • az OO technológiában kezdı olvasónak azért, mert a feladatok nehézségi foka a fejezetsorszámmal együtt nı; • egyébként pedig azért, mert az elıbb álló fejezetek több részletre kiterjedıen szolgálnak magyarázatokkal, mint a hátrább állóak, illetve az utóbbiak az azonos magyarázatok ismétlése helyett gyakran csak visszautalnak az elıbbiekben adott magyarázatokra.

BEVEZETÉS

13

1.3 Az esettanulmányok szerkezete Minden esettanulmány a feladat leírásával indul. Ezt általában egy használati eset modell követi, de zsebszámológép problémánál a használati eset modellt egy kis követelményelemzés is megelızi. (A termékszerkezetekkel kapcsolatos feladatokat tárgyaló esettanulmány kivételes, mert annál a hangsúly annyira a belsı összefüggésekre helyezıdik, hogy a használati esetekkel nem kellett foglalkozni.) A tulajdonképpeni tervezés a statikus modell tárgyalásával kezdıdik, amelyet a dinamikus modell követ, de ebben a statikus modell egyes részletei ismét érintıdnek, mivel a dinamikus modellek útján történı megfontolások egyik eredménye éppen a statikus modell finomítása. Akár a statikus modellen belül, akár a dinamikus modellen belül már a feladattól függ, hogy milyen diagramtechnikákat alkalmaz az esettanulmány. Könnyebb feladatnál a statikus modell mindjárt az osztálydiagrammal kezdıdhet, nehezebb feladatnál elıbb objektumdiagram(ok) készül(nek) és abból (azokból) elvonatkoztatással áll elı az osztálymodell. Az elsı három probléma dinamikus modellje mellızte a tevékenységdiagramot, de a negyedik esettanulmányban már az is megjelenik. Egy-egy modellbıl általában több változat is készül. Ezek vagy alternatív megközelítések, vagy fejlıdési fokozatban különböznek. A gyakorlatban sem mindjárt a legjobb megoldás pattan ki a tervezı fejébıl. Az esettanulmányok megpróbálják érzékeltetni azt az utat (még a vargabetőivel együtt is), amit a tervezı is bejárhat a megoldás fokozatos finomításában. A modellek megértetésének fontos eszközét képezik az ellenırzı / magyarázó kérdések, illetve az ezekre adott válaszok. Velük a szerzı a következı gondokat próbálta enyhíteni: • Egy kezdınek rengeteg olyan kérdése támadhat, amilyen egy gyakorlott tervezıben általában már fel sem merül. Az Olvasó bizonytalanságai eredhetnek a feladat félreértelmezésébıl; a fogalmak, szimbólumok jelentésének nem kellı ismeretébıl; jól ismert fogalmak és szimbólumok esetében pedig az alkalmazásukra alkalmat adó gyakorlat hiányából. – A szerzı a hiányosságokat, félreértéseket megvilágító kérdéseket részben a saját oktatási tapasztalatai alapján igyekezett kitalálni, részben a hallgatók órai megnyilvánulásaiból „plagizálta”. • A tudásnak már az is egy szintje, amikor a hallgató azt nyilatkozza: „Most, hogy a tanár úr elmagyarázta, így mindent értek, de egyedül ezt a megoldást soha nem találtam volna ki; és továbbra sem biztos, hogy egy hasonló nehézségő, másik feladatot már meg tudok oldani.” Az ellenırzı / magyarázó kérdéseknek éppen az a célja, hogy ne csak a kész megoldás megértetéséhez, hanem a hozzá vezetı út megvilágításához is hozzájáruljanak. • Ha az Olvasónak van már bátorsága belevágni a modellezésbe, de az esettanulmányban adottól különbözı megoldásra jut, akkor érthetıen szeretne bizonyosságot szerezni arról, hogy egy lehetséges alternatív megoldást talált-e, vagy ha nem, akkor mi a hiba a megoldásában. Az ellenırzı / magyarázó kérdések ebben a tekintetben is próbálnak eligazítással szolgálni. Az esettanulmányok dimakus modellt tárgyaló része egyes objektumok viselkedésébıl némely összetett mővelet megvalósítását is megadja egy – a programnyelvekhez közeli – pszeudokóddal. Ennek ellenére nincs szó arról, hogy az esettanulmánykötetnek a programozni tanítás is célja lenne. A pszeudokódú részletek alkalmazásának az a racionális magyarázata,

14


hogy a tervezésnek számolni kell a megvalósítással is. Ha a tervezınek fogalma sincs róla hogyan dolgoznak a kivitelezık – esetünkben a programozók –; akkor azt sem tudja, hogy „mire megy ki a játék”; mirıl kell szólni, hogyan kell kinézni a terveknek, hogy azok használhatók legyenek a programozók számára.

BEVEZETÉS

15

1.4 Technikai jellegő tudnivalók 1.4.1 A diagramok szerkesztése A kötetben bemutatott modellek majdnem mindegyike a Sparx Systems cég Enterprise Architect CASE eszközével készült. Ha az Olvasó hasonló modellek szerkesztését akarja gyakorolni, ajánlatos szintén valamilyen – az UML-t támogató – CASE eszközt használnia. Ugyanezeket a modelleket általános célú (butább) rajzeszközökkel szerkeszteni lényegesen nagyobb munkaráfordítással jár. 1.4.2 A pszeudokód értelmezése Ahhoz, hogy a dinamikus modellek lehetséges megvalósításairól szóló pszeudokódú részletek mondjanak valamit az Olvasónak, meg kell ismerkednie a pszeudokód kulcsszavainak és szerkezeteinek értelmezésével. Megjegyzés a pszeudokódban: A pszeudokód könnyebb megértését segítik a magyarázó megjegyzések. Ezek a // jelpártól a sor végéig tartó szövegek. Pl.: // Ez itt egy megjegyzés

Fontos!: A megjegyzés az egyetlen olyan szerkezet, amely a sor végéig tart. Minden más szerkezet (osztálydefiníció, attribútumdefiníció, mőveletdefiníció, utasítás, …) több soron keresztül folytatódhat, illetve egy sorban több is lehet belıle; tehát a végét nem a sorvége, hanem valamilyen más karakter jelöli. Így az osztálydefiníciót vagy a (megvalósítással rendelkezı) mőveletdefiníciót } (záró kapcsos zárójel) zárja le; attribútumdefiníció vagy egy elemi utasítás végét pedig ; (pontos vesszı) jelzi. Osztályt definiáló szerkezet: Egy osztályt definiáló szerkezet a legyegyszerőbb esetben így néz ki: OSZTÁLY OsztályNeve { ...// Ide jön az osztály definíciójának törzse. }

A {} kapcsos zárójelek között áll az osztály definíciójának a törzse, abban lehet megadni az osztály attribútumait és mőveleteit (az utóbbiakat definiáló szerkezeteket lásd késıbb). Egyébként a fenti alak egy olyan osztályra alkalmazható, amely példányosodik; konkrét osztály (=nem absztrakt); nem realizációja és nem is kiterjesztése egy másik osztálynak. Jegyezzük meg, hogy a különbözı szintaktikai egységekre adott mintákban az álló nagybetőkkel szedett szavak (pl. itt: OSZTÁLY) változatlan formában alkalmazandó kulcsszavak. A dılt betős egységek (pl. itt: OsztályNeve) értelemszerően helyettesítendık be (esetünkben az OsztályNeve helyén egy konkrét osztálynév állhat). Az itt definiált pszeudonyelvben is tartjuk magunkat a programozók között széles körben elfogadott azon konvencióhoz, hogy az osztályok nevét nagybetővel kezdjük.

16

OBJEKTUMORIENTÁLT TERVEZÉS – ESETTANULMÁNYOK Egy absztrakt osztályt definiáló szerkezet:

ABSZTRAKT OSZTÁLY OsztályNeve { ... }

Egy interfész osztályt (röviden: interfészt) definiáló szerkezet: INTERFÉSZ OSZTÁLY OsztályNeve { ... }

Ha egy osztály kiterjesztése egy másik osztálynak (a szülı osztálynak), akkor ezt pszeudokódunkban az osztálydefiníció fejrészében így kell jelölni: OSZTÁLY OsztályNeve SZÜLİJE SzülıOsztályNeve { ... }

Az OSZTÁLY kulcszó helyén ebben az utóbbi változatban is állhat ABSZTRAKT OSZTÁLY vagy INTERFÉSZ OSZTÁLY. Ha egy osztály realizációja egy vagy több interfész osztálynak, akkor ezt pszeudokódunkban az osztálydefiníció fejrészében így kell jelölni: OSZTÁLY OsztályNeve SZEREPE InterfészNeve1 [, InterfészNeve2] ... { ... }

Ebben a mintában és a (további mintákban is) a [] szögletes zárójelek közötti rész csak szükség esetén alkalmazandó. Így az InterfészNeve2 egységre csak akkor van szükség, ha az osztály egyszerre egynél több interfésznek képezi realizációját. A szögletes zárójeleket követı három pont ([]...) jelzi, hogy a szögletes zárójelben adott egységnek még további példányai is alkalmazhatók (esetünkben: InterfészNeve3, InterfészNeve4, …): Mivel ugyanazon osztály egyszerre lehet kiterjesztése egy másik osztálynak, és realizációja több interfésznek is, az utóbbi két szerkezet egymással így kombinálható: OSZTÁLY OsztályNeve SZÜLİJE SzülıOsztályNeve SZEREPE InterfészNeve1 [, InterfészNeve2] ... { ...

}

Nem példányosodó osztályt definiáló szerkezet: NEM PÉLDÁNYOSODÓ OSZTÁLY OsztályNeve { ... }

Megjegyzés: Az osztály további fontos tulajdonsága a láthatóság, azonban a pszeudokódban ennek jelölésével nem foglalkozunk. Emiatt az esettanulmányokban szereplı osztályokat mind publikusnak (más csomagokból is láthatónak) kell tekinteni. Attribútumot definiáló szerkezet: Skalár attribútumot definiáló szerkezet általános sémája a következı: [NYILVÁNOS] [OSZTÁLYATTRIBÚTUM] [KONSTANS] attribútumNeve: típus [:= kezdıÉrték]

BEVEZETÉS

17

Megjegyzés: A skalár elemi adatot, tehát nem vektort jelent. A fenti definícióban a [] szögletes zárójelek csak a minta részei, és azt jelzik, hogy a közöttük álló rész nem kötelezı. A NYILVÁNOS kulcsszót csak akkor kell megadni, ha az attribútumot nyilvánossá (azaz más osztályból – nem csak a leszármazott osztályokból – közvetlenül elérhetıvé) akarjuk tenni; azonban a legtöbbször elhagyható, és akkor az attribútum privát (nem nyilvános) minısítéső lesz, azaz más osztályból nem látható. (A láthatóság további lehetséges opcióival, pl. a védett láthatósággal a pszeudokódban nem foglalkozunk.) Hasonlóan az OSZTÁLYATTRIBÚTUM alkalmazása osztályattribútumot, a hiánya példányattribútumot (példáinkban ez a gyakoribb) jelez. A KONSTANS szó alkalmazása azt jelzi, hogy az attribútum értéke az objektum élete alatt nem változik, végig a kezdıértékként megadott értéket tartalmazza (ilyenkor a :=kezdıÉrték egység nem hagyható el). A KONSTANS szó hiánya esetén az attribútum értéke az objektum élete alatt változhat (példáinkban ez a gyakoribb). A típus lehet egy programnyelv valamely primitív típusa (pl. int, long, real, double, boolean, … – azaz nem objektum) vagy egy osztály neve. A := kezdıÉrték egységre csak akkor van szükség, ha jelezni akarjuk (vagy konstans esetében jelezni kell), hogy az objektum létrehozásakor az attribútum milyen értéket kap. Az itt definiált pszeudonyelvben is tartjuk magunkat a programozók között széles körben elfogadott azon konvencióhoz, hogy az attribútumok nevét kisbetővel kezdjük. – Példák: lapokSzáma: int; // Attribútum neve: lapokSzáma, típusa: int. // Egyéb jellemzık: nem nyilvános, példányattribútum, // nem konstans értékő, // a definícióban nem kap kezdıértéket OSZÁLYATTRIBÚTUM KONSTANS programNeve: String := ”PELDA”; // Attribútum neve: programNeve, típusa: String, // kezdıértéke: ”PELDA” // Egyéb jellemzık: nem nyilvános, osztályattribútum, // konstans értékő, azaz végig a // a kezdıértékül kapott PÉLDA szöveget // tartalmazza.

Megjegyzés: A pszeudokódban igyekeztünk magyar nyelvő kulcsszavakat alkamazni, ennek ellenére néhány angol kulcsszó is becsúszott a készletbe. Ennek az az oka, hogy a tervezés során ugyan valódi programnyelveket nem, de tervezı eszközöket (CASE eszközöket) már használunk, és az olyan angol kulcsszavakat, amelyek már a tervezıeszközökben is megjelennek, nem fordítottuk le magyarra. Ilyenek a fentebb említett adattípusok (int, long, real, double, boolean, …) vagy a késıbbiekben az olyan mőveletek visszatérési értéke típusának helyén alkalmazott void kulcsszó, amelyeknek nincs visszatérési értéke. Még egy ilyen kulcsszó a this, amellyel az objektum egyes esetekben önmagát hivatkozza meg, mivel már ez is elıfordulhat a tervezési modellekben pl. az állapotdiagramok szerkesztésénél. Ha az attribútum több elemő vektor (tömb), akkor az ıt definiáló szerkezet így nézhet ki: [NYILVÁNOS] [OSZTÁLYATTRIBÚTUM] [KONSTANS] attribútumNeve[elemSzám]: típus [:= kezdıÉrtékLista]

Ebben a vékonyan szedett [] szögletes zárójelek csak a minta részei, és azt jelzik, hogy a közöttük álló rész nem kötelezı. A vastagon szedett []szögletes zárójelek viszont nem azt jelzik, hogy az elemSzám egység elhagyható, hanem azt, hogy ennek az egységnek egy konkrét attribútum definíciójában is szögletes zárójelben kell állni. Az elemSzám: a vektor

18


elemeinek száma. Ha az elemSzám egy közvetlenül beírt számkonstans (pl. 40), akkor a definícióban szerepelhet egy kezdıÉrtékLista is, amely kezdıértékek vesszıvel elválasztott felsorolását jelenti. Ha viszont az elemSzám helyén pl. int típusú változó (az objektum egy másik attribútuma) áll, akkor a változó értékét (és azzal a vektor méretét) csak az objektum konstruktora tudja beállítani. – Példák: NYILVÁNOS OSZTÁLYATTRIBÚTUM KONSTANS irány[4]: String := ”ÉSZAK”, ”KELET”, ”DÉL”, ”NYUGAT”; // Attribútum neve: irány, 4 elemő vetor, az elemek típusa: String. // Egyéb jellemzık: nyilvános, osztályattribútum, konstans értékő. // A vektor elemei kezdıértéket is kapnak: irány[1] := ”ÉSZAK”, // irány[2] := ”KELET”, ... szobákSzáma: int; szoba[szobákSzáma]: Szoba; // Attribútum neve: szoba, többelemő vetor, az elemek típusa: Szoba. // A vektornak annyi eleme lesz, amennyi a szobákSzáma attribútum értéke, // amit a konstruktor állít be. // Egyéb jellemzık: nem nyilvános, példányattribútum, // nem konstans értékő, // a definícióban nem kap kezdıértéket

Mőveletet definiáló szerkezet: Az általános séma: [PRIVÁT] [OSZTÁLYMŐVELET] [ABSZTRAKT] [PROGRAM] mőveletNeve([paraméterLista]): [visszatérésiÉrtékTípusa] [{ ...// Mővelettörzs: ide jön a mővelet megvalósításának kódja. }]

A PRIVÁT minısítést csak akkor kell megadni, ha a mőveletet priváttá (azaz más osztályból nem elérhetıvé) akarjuk tenni; azonban a legtöbbször elhagyható, és akkor a mővelet nyilvános minısítéső lesz. (A láthatóság további lehetséges opcióival a pszeudokódban nem foglalkozunk.) Az OSZTÁLYMŐVELET minısítés alkalmazása osztálymőveletet; a hiánya pedig példánymőveletet (példáinkban ez a gyakoribb) vagy konstruktort jelez.. Az ABSZTRAKT minısítés csak példánymőveletre alkalmazható (tehát nem állhat sem az OSZTÁLYMŐVELET, sem a PROGRAM minısítéssel együtt, és konstruktorra sem alkalmazható). Az ABSZTRAKT minısítés feltüntetése absztrakt mőveletet; hiánya: konkrét mőveletet jelez. A PROGRAM minısítés olyan osztálymőveletet jelez, amely az osztály betöltése után automatikusan végrehajtódik. (Egy osztály definíciója legfeljebb egy PROGRAM minısítéső mőveletet tartalmazhat.) Az itt definiált pszeudonyelvben is tartjuk magunkat a programozók között széles körben elfogadott azon konvencióhoz, hogy a mőveletek nevét kisbetővel kezdjük. Kivételt képez a konstruktor mővelet neve, amely a pszeudonyelvben (a Java és a C# nyelvet utánozva) a megfelelı osztály nevével lesz azonos.A paraméterLista üres is lehet, vagy egy paraméteregységet tartalmaz, vagy több paraméteregységet vesszıvel elválasztva. Egy paraméteregység felépítése: paraméterNeve: paraméterTípusa. Konstruktor definiálása esetén a visszatérésiÉrtékTípusa egységet nem kell megadni, mert a konstruktor mindig a megfelelı osztály egy új példányát adja vissza. Más mővelet esetén visszatérési érték hiányában is jelen kell lenni a visszatérésiÉrtékTípusa egységnek, akkor ezen egység

BEVEZETÉS

19

helyén a void szót kell szerepeltetni. A mővelettörzs azért áll [] között (azért opcionális), mert az absztrakt mőveleteknek nincs mővelettörzse (másképpen nincs megvalósítása). Megjegyzés: A Java és a C# terminológiájához hasonlóan mi is használjuk a mővelet szignatúrája fogalmat. Ezen a mővelet neve és paraméterei típusának adott sorrendő listáját értjük. A Javahoz és a C#-hoz hasonlóan a pszeudokódunkban is ahhoz tartjuk magunkat, hogy a mőveletet annak neve azonosítja, de azonos mővelet azonos környezetben többféle szignatúrával specifikálható. – Az, hogy a visszatérési érték típusa nem része a szignatúrának, úgy értelmezendı, hogy egy mővelet minden szignatúrája mellett a visszatérési érték típusának azonosnak kell lenni. Példa mőveletet definiáló szerkezetre: eseményFeldolgozás(eseményKód:int): void { HA eseményKód = 1 AKKOR selectFeldolgozás() KÜLÖNBEN HA eseményKód = 2 AKKOR setFeldolgozás() KÜLÖNBEN HA eseményKód = 3 AKKOR alarmOnOffFeldolgozás() }

E példában a mővelettörzsben már olyan szerkezetek láthatók, amelyekrıl még nem volt szó. A mővelettörzs tartalmazhat: • lokális változó deklarációját, • egyszerő utasításokat, • összetett utasításokat. Megjegyzés: Az esettanulmányok a továbbiakban annak dacára a mővelettel szinoním fogalomként használják a metódus fogalmát, hogy a szerzı tisztában vele, az OO tervezés korábbi irodalmában ez a két fogalom különbözött egymástól, eredetileg a metódus a mővelet megvalósítását jelentette. – Az a helyzet, hogy mára a különbözı OO programnyelveket ismertetı könyvekben sokkal gyakoribb az, hogy az egyes osztályok definíciójának részét képezı mőveleteket metódusnak nevezik, megkülönböztetésül a hagyományos nyelvek összetett mőveleteitıl, illetve a hibrid nyelvek esetében az ugyanazon nyelv osztályfüggetlen mőveleteitıl. Lokális változót deklaráló szerkezet: A változó egyik esete az objektum (vagy osztály) attribútuma. Itt viszont lokális változóról van szó, amely abban különbözik az attribútumtól, hogy nem egy objektumot (vagy osztályt) jellemzı adat, hanem csak valamely mővelet munkaadata tárolódik benne. Az attribútum addig él, ameddig az általa jellemzett objektum; egy lokális változó viszont csak addig, ameddig az ıt tartalmazó (használó) mővelet végrehajtása tart. Lokális skalárváltozót deklaráló szerkezet mintája: [KONSTANS] LOKÁLIS ADAT változóNeve: típus [:= kezdıÉrték]

Lokális vektorváltozót (tömbváltozót) deklaráló szerkezet mintája: [KONSTANS] LOKÁLIS ADAT változóNeve[elemSzám]: típus [:= kezdıÉrtékLista]

E szerkezet egyes elemeirıl hasonlók mondhatók el, mint az attribútumot definiáló szerkezeteknél. A vékonyan szedett [] szögletes zárójelek itt is csak a minta részei, és azt jelzik, hogy a közöttük álló rész nem kötelezı. A vastagon szedett []szögletes zárójeleknek egy konkrét változó definíciójában is meg kell jelenni. Az elemSzám a vektor elemeinek száma. Vektorváltozó deklarációjában akkor szerepelhet kezdıÉrtékLista, ha az elemSzám egy közvetlenül beírt számkonstans. A kezdıÉrtékLista kezdıértékek vesszıvel elvá-

20


lasztott sorozata. Ha az elemSzám helyén pl. int típusú (másik) változó áll, akkor e skalárváltozó értékét beállító értékadó utasításnak meg kell elıznie a vektorváltozó deklarációját. Egyszerő utasítások: Formailag egyszerő utasítás alatt háromféle utasítást értünk: értékadó utasítást, mővelethívást, metódus (függvény) visszatérési értékét meghatározó utasítást. [címzett.]változóNeve := kifejezés // Értékadó utasítás [címzett.]mőveletNeve([aktuálisParaméterekListája]) // Mővelethívás VISSZATÉR kifejezés // Visszatérési értéket meghatározó utasítás

Az értékadó utasítás bal oldalán a változóNeve lehet akár lokális változó neve, akár attribútumhivatkozás; az utóbbi esetben a címzettel minısíthetı, amely az attribútum tulajdonosát képezı objektumot azonosítja, vagy osztályattribútum esetében a megfelelı osztály neve. A kifejezés lehet konstans, változó, mővelethívás (amely csak egy visszatérési értékkel rendelkezı mőveletre hivatkozhat), valamint az elıbbiekbıl mőveleti jelek alkalmazásával képezett formula. (Tehát az egyszerő utasítás fogalmába belefér a értékadó utasítás és a mővelethívás olyan kombinációja is, amelynél az értékadó utasítás jobb oldalán álló kifejezés egy mővelethívást tartalmaz.) A kifejezés kimeneti értéke kerül a bal oldalon hivatkozott változóba. – Példák értékadó utasításra. lábakSzáma := 4; // Itt a kifejezés egy konstans. fizetés := 1.2*fizetés; // 20%-os fizetésemelés ruha.méret := 50; // Itt a változó egy attribútumhivatkozás, // a ruha objektum méret nevő attribútuma. this.méret := méret; // Itt a this a vezérlést éppen birtokló objektum // és ennek egy méret nevő attribútuma kap értéket // egy méret nevő lokális változótól vagy // paramétertıl. alkatrész[5] := mütyür; // Itt a változó az alkatrész vektor 5. eleme. alkatrész[5].csereDátuma := ”2011.07.03.”; // Itt a változó egy attribútumhivatkozás, az alkatrész[5] // objektum csereDátuma nevő attribútuma. dátum := alkatrész[5].csereDátuma; // A dátum felveszi az alkatrész[5] objektum csereDátuma nevő // attribútumának értékét.

Megjegyzés: Ha egy objektum által végrehajtott példánymőveleten belül a végrehajtó objektum sajátmagára kényszerül hivatkozni, akkor azt (a Java és a C# nyelvet utánozva) a pszeudokódban is a this hivatkozással teheti meg. A this.méret:=méret példában csak azért volt szükség a this önhivatkozásra, mert a végrehajtó objektum egy attribútuma egy azonos nevő másik változótól vagy paramétertıl kap értéket. Ha egy kódkörnyezetben egy változóNeve egyértelmően csak a végrehajtó objektum egy attribútumának a neve lehet, akkor nem szükség a this hivatkozással minısíteni. A mővelethívásokban a címzett a mővelet végrehajtására felszólított objektumot hivatkozza meg vagy osztálymővelet esetén egy osztály neve. A hibrid nyelvek osztályfüggetlen mőveleteinek nincs címzettje. Nem lehet címzettje a konstruktoroknak sem. Ha egy objektum önmagát szólítja fel egy mővelet végrehajtására, akkor a címzett elhagyható, de ha mégis egyértelmővé akarjuk tenni az öndelegáció tényét, a címzett helyén (a Java és a C# nyelvet utánozva) akkor is feltüntetjük a this hivatkozást a pszeudokódban.

BEVEZETÉS

21

A mőveletNeve a hívott (végrehajtandó) mővelet neve. Az aktuálisParaméterekListája egy vagy több kifejezést tartalmazhat. A kifejezés által visszaadott érték típusának azonosnak kell lenni a mőveletdefinícióban (lásd fentebb a mőveletdefiniáló szerkezetet) szereplı paraméterLista egység megfelelı elemében adott paramétertípussal. – Példák mővelethívásokra: OSZTÁLY Mezı { // Ebben az osztályban van definiálva a setVillog(…) mővelet villog: boolean; // boolean: kétféle értéke lehet, true vagy false. ...

// Itt jön a setVillog(…) mővelet definíciója setVillog(pVillog: boolean) void { villog := pVillog // Értéket ad a villog attribútumnak. } ...

} // Itt egy mővelethívás (az óraMezı.setVillog(true); // // //

óraMezı a fenti Mezı osztály példánya): Az óraMezı objektum felszólítása a setVillog mővelet végrehajtására. A mővelet paraméterként kap egy true értéket.

// Ha egy mőveletnek van visszatérési értéke (vagy a mővelet egy // konstruktor), akkor az egy értékadó utasítás jobb oldalán szerepelhet: dátum := alkatrész[5].getCsereDátuma(); // A dátum változó felveszi az alkatrész[5] objektum getCsereDátuma() // nevő lekérdezı mővelete által visszaadott értéket.

A legutóbbi példához hasonlóan mőködik a konstruktorhívás is. Ezt egy, az óraMezı létrehozásáról szóló példába ágyazva mutatjuk meg: OSZTÁLY Mezı { érték: String; látszik: boolean; villog: boolean; ... // Itt jön a konstruktor definíciója Mezı(pÉrték: String, pLátszik: boolean, pVillog: boolean) { érték := pÉrték; látszik := pLátszik; villog := pVillog } ... } // Itt jön a Mezı osztály óraMezı nevő példányának létrehozása óraMezı: Mezı; // Az óraMezı nevő, Mezı típusú változó deklarálása óraMezı := Mezı(”00”, true, false); // A konstruktor itt hozza létre // az új óraMezı objektumot. Az óraMezı attribútumainak értékei: // érték: ”00” ( pÉrték), látszik: true ( pLátszik) és // villog: false ( pVillog)

22


Megjegyzés: A konstruktorhívás formájával jelentısen eltértünk az olyan programnyelvektıl amelyekben a konstruktorhívást speciális kulcsszó elızi meg (Javaban vagy a C# nyelvben ez a new kulcsszó), amely egyértelmően jelzi, az adott helyen új objektum jön létre. A fenti pszeudokódú részletben látható óraMezı:=Mezı(”00”,true,false) utasítás megfelelıje Java, illetve a C# nyelvben: óraMezı = new Mezı(”00”,true,false). Az metódus (függvény) visszatérési értékét meghatározó utasítás a metódus végrehajtásán belül idıben utoljára végrehajtódó utasítás. Az utasításban adott kifejezés kimeneti értéke típusának egyezni kell a metódus visszatérési értékének típusával. OSZTÁLY Alakzat { szín: int; getSzín(): int {VISSZATÉR szín} // A szín értékének visszaadása }

Hátra van még az összetett utasítások három fajtájának leírása. Ezek az utasításblokk, az elágazás és az ismétlés (vagy ciklus). Utasításblokk: Tulajdonképpen egy mővelet törzse is utasításblokk. Az utasításblokk arra való, hogy több utasításból (egy utasítássorozatból) formailag egyetlen utasítással egyenértékő egységet képezzen. Ennek jelentısége az elágazás és az ismétlés szerkezeteknél válik érthetıvé. Az utasításblokk utasításoknak {} kapcsos zárójelek között álló sorozata. { utasítás1 [[;] utasítás2] ... }

A fenti szerkezetleírás szerint a blokk extrém esetben egyetlen utasításból is állhat, de az elágazásokra adott 5. példa szerint ennek is lehet értelme. A blokkon belül akár egyszerő, akár összetett utasítások szerepelhetnek; ebbıl az is következik, hogy a blokkok egymásba skatulyázhatók. Az utasításokat elválasztó ; (pontosvesszı) azért opcionális, mert adott utasítást az elızı utasítástól csak akkor kell pontosvesszıvel elválasztani, ha az elızı utasítás nem blokk. (Ugyanis a blokkot és vele annak utolsó –nem blokk – utasítását a záró kapcsoszárójel terminálja.) – Utasításblokkok használatára késıbb, az elágazásokhoz kapcsoltan mutatunk példákat. Elágazás: Bizonyos utasításokat csak opcionálisan – bizonyos feltételek teljesülése esetén – kell végrehajtani, máskor alternatívan csak az egyik utasítást kell végrehajtani, ha bizonyos feltétel teljesül, vagy csak egy másik utasítást, ha ugyanez a feltétel nem teljesül. Ilyen szabályok megvalósítására alkalmas a következı elágazás szerkezet: HA feltétel AKKOR utasítás1 [KÜLÖNBEN utasítás2]

Mind az utasítás1, mind az utasítás2 egység maga is összetett utasítás lehet, tehát blokk, beskatulyázott elágazás vagy ismétlıdés.

23

BEVEZETÉS Példák elágazásokra: // Elágazás - 1. példa: HA a < 0 AKKOR a := -a; b := 3;

1.1. ábra: Elágazás – 1. példa

// Elágazás - 2. példa: HA a < 0 AKKOR b := -a KÜLÖNBEN b := a; c := 2*c;


// Elágazás - 3. példa: HA a < 0 AKKOR { utasítás1; utasítás2; utasítás3 } KÜLÖNBEN { utasítás4; utasítás5 } utasítás6


// Elágazás - 4. példa: HA feltétel1 AKKOR HA feltétel2 AKKOR utasítás1 KÜLÖNBEN utasítás2; utasítás3

// Elágazás - 5. példa: HA feltétel1 AKKOR { HA feltétel2 AKKOR utasítás1 } KÜLÖNBEN utasítás2; utasítás3

24




Vegyük észre, hogy az 5. példa formai szerkezetében csak abban különbözik a 4. példától, hogy a HA feltétel2 AKKOR utasítás1 részt egy blokkba zártuk (blokkzárójelek közé tettük). Ám ennek következtében az 5. példa elágazása egészen más szabályt rögzít, mint a 4. példáé. A 4. példában – blokkzárójelek hiányában – a KÜLÖNBEN utasítás2 ág a hozzá legközelebbi HA feltétel2 AKKOR utasítás1 ág párja; ezzel szemben az 5. példában a blokkzárójelen kívül esı KÜLÖNBEN utasítás2 ág már nem lehet a HA feltétel2 AKKOR utasítás1 ág párja, azt a blokkzárójelek a HA feltétel1 AKKOR ág párjává teszik.

// Elágazás - 6. példa: HA feltétel1 AKKOR utasítás1 KÜLÖNBEN HA feltétel2 AKKOR utasítás2 KÜLÖNBEN HA feltétel3 AKKOR utasítás3; utasítás4


Ismétlés (ciklus): Van úgy, hogy a cél érdekében a program adott helyén bizonyos utasítások végrehajtását többször is meg kell ismételni. Nem lenne egyszerő a programozás, ha ezeket az utasításokat a programozónak is annyiszor kellene leírni, ahányszor azokat a számítógépnek végre kell hajani. Szerencsére az ismétlés (vagy másképpen ciklus) utasítás megkíméli a programozókat ez effajta rabszolgamunkától. Ismétlés utasításból mindjárt két változatot is láthat az Olvasó. Az elöltesztelt változatnál elıbb kiértékelıdik az ismétlésiFeltétel, és az utasítás csak akkor hajtódik végre,

BEVEZETÉS

25

ha az ismétlésiFeltétel értéke igaz (true). A hátultesztelt változatnál az utasítás egyszer mindenképpen végrehajtódik, és csak azután értékelıdik ki a kilépésiFeltétel. Ennél a változatnál akkor fejezıdik be az utasítás ismétlése, ha a kilépésiFeltétel értéke igaz (true). // Ismétlés – elöltesztelt ciklus: ISMÉTELD AMÍG (ismétlésiFeltétel) utasítás // Ismétlés – hátultesztelt ciklus: ISMÉTELD utasítás1 MÍGNEM (kilépésiFeltétel)

1.8. ábra: Ismétlés – hátultesztelt ciklus 1.7. ábra: Ismétlés – elöltesztelt ciklus

Az ismétlés szerkezetben az utasítás (amelyet másképpen ciklusmagnak is neveznek) lehet egyszerő utasítás, de lehet összetett utasítás is, tehát lehet akár több utasításból álló blokk is, akár beágyazott ismétlés is. // Példa elöltesztelı ciklusra: i := 1; // Az ismétlés (ciklus) elıkészítése ISMÉTELD AMÍG (i <= elemekSzáma) { // Blokk (azaz a ciklusmag) kezdete kiír(elem[i].érték); // Az i-edik elem értékét kiírató utasítás i:=i+1 // Az i növelése, enélkül az ismétlés soha nem fejezıdne be. } // Blokk vége, egyben az ismétlés utasítás vege. // Folytatás. Ide kerül a vezérlés, ha már i > elemekSzáma.

A fenti példa pszeudokódja, akkor is jól mőködik, ha az elem vektor üres, azaz ha elemekSzáma = 0.

26


OBJEKTUMORIENTÁLT TERVEZÉS ESETTANULMÁNYOK

Recommend Documents