!!" KÉSZÍTK: ERDÉLYI LAJOS KOLLÁR NÁNDOR WD6OGW BUK8Y7

Átírás

1 !!" KÉSZÍTK: ERDÉLYI LAJOS KOLLÁR NÁNDOR WD6OGW BUK8Y7

2 #$%#&'( 1. Bevezet Feladatkiírás: Specifikáció A kidolgozás munkafázisai, szakaszai Fejlesztési irányelvek Fejleszti csapat: Felhasználói felület: Fejleszti környezet: Implementáció: A webes kliens use-case modellje Web felület design A kommunikációs interfész kialakítása Alapvet mködés activity diagramja Statikus UML felépítés Csomagleírás webclient.server package webclient.client package webclient.generated package webclient.server package webclient.client package Eszköz környezet Fejlesztéshez ajánlott környezet Mködéshez szükséges környezet Mködtetés Tesztelés Terhelési kérdések Optimalizálás Bvíthetségi lehetségek oldal, összesen: 21 vasárnap, december 13.

3 )$#*+,-./0 1. ábra: Architektúrális felépítés ábra: A kliens use-case modellje ábra: Áttekint: A mködés activity diagramja ábra: webclient.server package ábra: Agent és Element osztályok kapcsolata ábra: BorkerService osztály ábra:brokerserviceasync osztály ábra: Az agentnode és ElementNode viszonya ábra: Grafikus felület alap osztálya ábra: A terhelésteszt eredménye oldal, összesen: 21 vasárnap, december 13.

4 %4 11 +&#5#%067$89 A cél olyan szoftver fejlesztése, ami ágens alapú. Az ágensek szabványos protokollt használnak (SNMP, WMI, stb.), hogy lekérdezzék és beállítsák a különböz elemek paramétereit. Ebben a feladatban egy webes klienst kell fejleszteni, ami a bróker szolgáltatásait veszi igényben egy jól definiált interfészen keresztül. A készítknek egyeztetniük kell a Bróker fejlesztivel, hogy egyértelm legyen az interfész. 1 :+;6<608;6= Az elkészítend kliens egy fejlett infrastruktúra-menedzsment alkalmazás egyik alapvet összetevje, amellyel könnyen és egyszeren, webes felületen keresztül lehet megvalósítani a különböz infrastruktúra-menedzsment feladatokat. A teljes eszköz egyrészt biztosítja a szabványos környezetben megvalósított menedzsment lehetségek kihasználását, valamint szabványos protokollok használata révén többplatformos megoldást kínál. Az általunk fejlesztett grafikus felületen keresztül lehetség nyílik az infrastruktúra aktív elemeinek monitorozására, felügyeletére, és az egyes komponensek paramétereinek módosítására. A webes kliens alapját tekintve egy kis szerver oldali szolgáltatás által kínált lehetségeket fogja igénybe venni és azt a felhasználók felé továbbítani. A szolgáltatás megvalósításához szükséges egy szerver oldali szolgáltatás, amelyet JAVA nyelven implementáltunk, és ehhez kapcsoltuk a webes felületet. A megvalósítás során alkalmaztuk a GWT és smartgwt kiterjesztések adta lehetségeket, míg a háttérben pedig web service hívásokra kerül sor. Ez a szolgáltatás valósítja a brókerrel való kommunikációt, azaz a megjelenítésre kerül információk begyjtését. A szükséges információk begyjtésének folyamatát úgy valósítjuk meg, hogy ez a szolgáltatás meghívja a bróker ágensek felsorolására szolgáló szolgáltatását. Amely eredményeként egy listában megjelennek az ágensek által nyújtott szolgáltatások, és az általuk menedzselt eszközök állapotai. A lista ismeretében pedig lehetség nyílik az esetleges beavatkozásra. A háttérben mköd logika vizualizálásához készítettük el a webes felületet, amely teljes az imént felsorolt szolgáltatásokat biztosítja. 4. oldal, összesen: 21 vasárnap, december 13.

5 A konkrét grafikus felület megvalósításához a google által fejlesztett google web toolkit-et és smartgwt kiterjesztést alkalmaztuk, amely lehetséget ad a komplex vizualizáció megvalósításához, valamint egyben a felhasználóbarát küls kialakításához. A konkrét megvalósításhoz szükséges a brókert megvalósító logika interfész szint ismerete. A konkrét interfészt a bróker készítivel való megállapodás során egyeztettük, majd implementáltuk az egyeztetéseknek megfelelen. A brókerrel való kommunikációt az igényeknek megfelelen XML alapon végezzük, így megvalósítva a szabványos és egyértelm adatáramlást. A teljes eszköz mködését áttekint ábra: 1. ábra: Architektúrális felépítés 5. oldal, összesen: 21 vasárnap, december 13.

6 065'&,'.89( A kidolgozást az alábbi fázisokra osztottuk és végeztük el a félév során: 1. Specifikáció kialakítása: a feladatkiírásnak megfelel specifikáció kialakítása, alapvet funkciók kijelölése 2. Tervezési fázis: a program alapjául szolgáló modell megalkotása 3. Csapategyeztetés a közös interfészt illeten 4. Modell validálás: a modell által támogatott funkciókkal ellátható feladatok egyeztetése a specifikációban kitzöttel 5. Implementáció: a kialakított modellnek megfelel kód implementálása 6. Felülvizsgálat: a fejleszett eszköz funkcionális ellenrzése 7. Tesztelés: a projekt tesztelése funkcionális és felhasználási szempontból 8. Optimalizálási feladatok: mködésbeli optimalizálás 9. Véglegesítés: végleges programverzió kijelölése, bináris verzió készítése 10. Prezentáció készítés: a projekt bemutatásának elkészítése 6. oldal, összesen: 21 vasárnap, december 13.

7 A +*&+9.%/966$8?-+&3+0 A1 +*&+9.%46;9#:#% ;9#:#% A webes kliens elkészítésénél a tökéletes munkamegosztás mellett kialakuló csapatmunkára helyeztük a hangsúlyt, mindezt úgy, hogy a csapattagok képességeinek komparatív elnyeinek érvényre jussanak az egyes munkafázisok elvégzés alatt, így célnak kitzve az idnkhöz mérten elérhet legmagasabb hozzáadott érték elállítását. A +&B#9.?8&=6<+&C&+% A felhasználói felület tervezésénél alapvet szempont volt a közvetlen kezelhetség, egyszer, és egyben hatékony webes felület kialakítása, amely a célnak funkcionálisan leginkább megfelel komponenseket tartalmazza. Mindezt amellett, hogy a felület könnyen bvíthet, valamint felhasználóbarát maradjon. A megoldás során törekedtünk a felületen elvégzend feladatok olyan megvalósítására, hogy a felhasználó számára a kívánt módosítás elvégzése az elérhet legkevesebb járulékos kattintás nélkül következzen be, mindezt a biztonságos felhasználhatóság megtartása mellett. AA +*&+9.%460D$?-+.+% A fejleszti környezettel szemben támasztott követelményeket úgy állapítottuk meg, hogy azok teljes mértékben a fejlesztés gördülékeny és hatékony menetét támogassák. Valamint a közvetlen fejleszti környezet elemként alapvet fontosságúnak ítéltük egy verziókövet rendszer alkalmazását, amely hatékonyan támogatja az egymástól független fejlesztés lehetségét. AE ( :&+( +?%8;6= A kódírás során ügyeltünk az legjobban olvasható kód fejlesztésére, így a beszédes névkonvencióknak megfelelen fejlesztettük a programot. 7. oldal, összesen: 21 vasárnap, december 13.

8 E F +)+90&6+?9>9+;#9+( '5+&&*+ A feladatkiírásnak megfelelen alakítottuk ki az implementálásra kerül webes kliens használati eseteit, azaz use-case modelljét. Alapvet követelmény, hogy a felhasználó értesüljön az elérhet ágensekrl, majd a választásának megfelel ágens esetében, le tudja kérdezni annak pontos attribútum listáját, valamint az egyes attribútumokhoz tartozó aktuális állapotot leíró értéket. Attribútumok ismeretében a felhasználónak lehetsége legyen az egyes attribútumok értékeinek a megváltoztatatására, amely a brókeren keresztül pedig érvényre jut a kiválasztott ágens által menedzselt, felügyelt eszközön. Mindezt úgy teszi, hogy a felhasználó számára transzparens módon valósítja meg, azaz a felhasználó nem értesül arról, hogy az adott ágens éppen SNMP, vagy WMI protokollon keresztül menedzseli az adott eszközt, hálózati komponenst. Ennek megfelelen a webes kliens use-case modellje: 2. ábra: A kliens use-case modellje A fenti követelményeknek megfelelen a három használati eset: 1. Az elérhet ágensek listájának lekérdezése, megjelenítése. 2. Egy kiválasztott ágens által támogatott attribútumok listájának, valamint az attribútum értékeknek a megjelenítése. 3. A kiválasztott ágens attribútum értékeinek a módosítása, hogy az a bróker által szolgáltatott web szervizen keresztül érvényre jut. 8. oldal, összesen: 21 vasárnap, december 13.

9 +)<+&C&+%5+96,? A webes felületet a könnyen kezelhetség és egyértelmség elvének megfelelen terveztük meg. Így alakult ki a végleges design, ami két szekcióból tevdik össze: Egy fels, amely az elérhet ágensek listáját tartalmazza fa struktúrában megjelenítve Az alsó pedig az éppen a fastruktúrában kijelölt elem attribútumainak és értékeinek a megjelenítését végzi. o Az alsó felület két tabra osztódik, egyik az attribútumok megjelenítésére, o míg a másik a kiválasztott elem attribútumainak módosítására szolgál. A web felület kialakításánál fontos szempont volt, hogy az böngész független legyen, így a felhasználóknak megadva a lehetséget saját böngészjük alkalmazására. 9. oldal, összesen: 21 vasárnap, december 13.

10 G 0'( ( >?608;6=96?%+$</9.06#&#07%89# A brókert készít csapat, valamint a többi klienst készít csapat együttes megállapodásán keresztül alakult ki a végleges interfész a brókerrel való kommunikációra. A megállapodásnak híven a web szerviz interfész 3 féle szolgáltatást nyújt a kliensek felé: 1. discoveragents(): A függvény meghívásakor az visszaadja az elérhet ágensek listáját, azokat a nevükkel azonosítva. 2. getelements(): Ez a függvény a megállapodás szerint az argumentumában adott ágens attribútumait, és azok értékét adja vissza egy listában. A lista elemei String típusú keyvalue párokból állnak. 3. setelement(): Az egyeztetés szerinti függvény a beállítja az argumentumában adott ágens attribútumának értékét, és visszatérési értéke igaz, ha a beállítás sikeres. Így ennek megfelelen terveztük meg a webes kliens szerver oldali back-end logikáját. 10. oldal, összesen: 21 vasárnap, december 13.

11 H &#:3+%4( I0D5/9#;%636%-56#,$#( *# A webes kliens alapvet mködési módját úgy terveztük meg, hogy az megfeleljen a specifikációban meghatározott elveknek. Így alkalmaztuk a rétegezett felépítést, amely magában a bróker-kliens rétegzettséget kiterjeszti a kliens oldalon, azaz maga a kliens is két rétegre tagolódik. A két réteg amely specifikációban látható képen is elkülönül a következ, egy front-end grafikus felület, valamint egy back-end alkalmazás logika. Az alkalmazáslogika valósítja meg a kitzött feladatokat modell szinten és ehhez illeszkedik a view szinten a grafikus felület. 3. ábra: Áttekint: A mködés activity diagramja A mködési elve a következképpen alakul: a webes felület megjelenítése az oldal letöltésével adódik. Az oldalbetöltés kezdetén a kliens oldalon található alkalmazáslogika (back-end) felkeresi a megadott címen található a web szervizt, amelyet a bróker ajánl ki. A bróker web szervize a kérést továbbítja a brókerhez, amely elvégzi a kérés eredményének megfelel adatok kiválasztását és azokat a saját kezelési struktúrájának megfelelen visszaadja a web szerviznek. A webszerviz pedig a közös interfész megállapodásnak megfelel formában xml struktúrában átadja a kívánt adatot a kliens oldali alkalmazáslogikának. Miután ezek az adatok elértek a kliens oldalra, megtörténik a grafikus felület frissítése és megjelennek az elérhet ágensek. A webes felületen egy ágenst kiválasztva hasonló mechanizmus indul el, csak ágens specifikus információk közvetítésével, így megjeleníthetek és módosíthatóak az egyes attribútumok. 11. oldal, összesen: 21 vasárnap, december 13.

12 J %#%60>9 <+&/:7%/9 A feladatkiírásból készített specifikációnak és use-case-nek megfelel osztálystruktúrát a következképpen készítettük el. Itt is figyelmet szenteltünk a bemutatott mködési mechanizmus optimális megoldásának, valamint a rétegzett architektúra követelménynek való megfelelésnek, továbbá az egyszer bvíthetség kialakításának. J1 9'( #,&+7$89 A program által használt osztályok három csomagba oszlanak a rétegzett architektúrális felépítésbl adódóan. J11 F +);&6+?%9+$3+$:#;0#,+ Ez a csomag tartalmazza a back-end üzleti logikának a server oldali részét, ez kommunikál a brókerrel és közvetíti a kért információt a web felület felé. J1 F +);&6+?%;&6+?%:#;0#,+ Ez a konkrét webes felület osztályait tartalmazza. J1A F +);&6+?%,+?+$#%+5:#;0#,+ Ez a package a bróker fejleszti csapattól kapott wsdl-bl a wsdl2java eszköz által automatikusan generált osztályokat tartalmazza. J F +);&6+?%9+$3+$:#;0#,+ A webclient.server package tartalmazza a BrokerServiceImpl osztályt, mely megvalósítja a brókerrel való kommunikációt, felépíti a kapcsolatot a brókerrel és a függvényei segítségével, pedig visszaadja a kívánt adatokat. A brokerserviceimpl valósítja meg a bróker csapattal kialakított közös interfészt, így lehetvé téve a kommunikációt a brókerrel. 12. oldal, összesen: 21 vasárnap, december 13.

13 4. ábra: webclient.server package A getagents() függvény a brókertl kapott ágens listát adja vissza a definiált List<Agent> formátumban. A getelements() függvény az argumentumában kapott ágens attribútumait adja visszatérési értékül egy ugyancsak definiált List<Element> formátumban. Míg a setelements() függvény argumentumában megadható az ágens azonosítója, attribútum neve, valamint annak értéke, és ezt továbbítja a brókerhez, amely beállítja az ágens értékét a kapottra, és true-val tér vissza, ha a beállítás sikeres volt. JA F +);&6+?%;&6+?%:#;0#,+ Ez a csomag tartalmazza a kliens oldalán kezelt (front-end) osztályokat, a grafikus felület osztályait, valamint a server oldali back-end osztállyal való kommunikációt megvalósító függvényéket. 5. ábra: Agent és Element osztályok kapcsolata Az Agent osztály a nevéhez hen valósítja meg az ágensek reprezentációit. Az osztályban megtalálhatóak a szokásos private attribútumok kezeléséhez szükséges get-set 13. oldal, összesen: 21 vasárnap, december 13.

14 függvénypárok. Fontos kiemelni a getelements függvényt, amely visszaadja az ágenshez tartozó attribútumok listáját a List<Element> létrehozott típusban. Az Element osztály képviseli az ágenshez tartozó attribútumokat és ezeknek a listába formázott típusa a Lsit<Element>, amelyet a korábban említett ágensek getelements() függvényei visszaadnak. Természetesen itt is megtalálhatóak a private változók kezeléséhez szükséges get-set metódusok, amelyekkel biztonságosan változtathatóak a kívánt értékek. 6. ábra: BorkerService osztály A BrokerService osztály valósítja meg a kliens oldalán a back-end üzleti logikával a szükséges függvények meghívásának lehetségét. A függvényei ebbl fakadóan ugyanazok, mint a korábban mutatott BrokerServiceImpl osztálynak. 7. ábra:brokerserviceasync osztály A BrokerserviceAsync függvény valósítja meg a felhasználó számára az oldalletöltés után való újabb lekérdezések oldalletöltés nélküli elvégzését. Ez a függvény kerül meghívásra, amikor a felhasználó a grafikus felületen egy ágensre kattint és meg kívánja tekinteni annak attribútumait. Ekkor ez a függvény oldalletöltés nélkül lekérdezi a BrokerService, valamint szerver oldalon a BrokerServiceImpl osztályon keresztül a brókert, a korábban egyeztetett interfészen keresztül. Majd az eredményt visszaküldi a grafikus felület számára, amely megjeleníti a felhasználó számára. 14. oldal, összesen: 21 vasárnap, december 13.

15 8. ábra: Az agentnode és ElementNode viszonya Az AgentNode osztály közvetlenül a grafikus felületen való megjelenítéshez szükséges, hiszen ott a már említett fa struktúrában jelennek meg az ágensek, valamint alattuk a hozzájuk tartozó attribútumok. Ennek megfelelen minden egyes AgentNode-hoz tartozik egy ágens reprezentáció és azon lehet elvégezni az egyes mveleteket. A setelements függvénnyel lehet manipulálni az egyes attribútumok értékeit, míg a setagent függvény a bvíthetség miatt került be, hiszen ezzel lehetségessé válik, hogy egy ágens ál akár másik ágens is tartozzon. Míg a getagent is hasonló kiterjeszthetségi megfontolások miatt került be, míg a getattributes függvénnyel az ágens attribútumainak listája és aktuális állapota kérdezhet le. Az ElementNode osztály egy ágenshez tartozó attribútumot reprezentál a fa struktúrában, és ennek megfelelek a függvényei is. A tostring metódus visszaadja az Element nevét, míg a getattributes visszaadja az attribútumok neveit. A set típusú függvényekkel állíthatóak be az Element osztály változói és építhetek a be a fa struktúrába. 9. ábra: Grafikus felület alap osztálya 15. oldal, összesen: 21 vasárnap, december 13.

16 A SzoftArch osztály hozza létre a valódi grafikus felületet, így ennek megfelelek az egyes változói, hogy egy egyszer és könnyen kezelhet grafikus interfészt adjon a felhasználó számára. Az onmuduleload függvény valósítja meg az oldallehívás után a grafikus felület felépítését, valamint a Brókerszerviz elérését kezdeményezi. Míg a discoverdataarrived függvény a fastruktúrához szükséges adatokat a kéri le és tölti be a struktúrába, miután a az onmudelload sikeresen létrehozta a kapcsolatot a BrokerService-en keresztül a brókerrel. 16. oldal, összesen: 21 vasárnap, december 13.

17 " D.0D$?-+.+% D.0D$?-+.+% "1 +*&+9.%/9B+.#*8?&'%%0D$?-+.+% A fejlesztéshez Eclipse keretrendszer annak is a JEE változata alkalmazható, amelyhez szükséges a GWT plugin letöltése, majd ezek után még a projekt Library-hez hozzá kell adni az ugyancsak letölthet smartgwt.jar-t és a CFX használatához szükséges jar file-okat. Csapatunk a fejlesztést a következ fejleszti környezet konfiguráción végeztük: Eclipse Java EE IDE for Web Developers 1 Version: Build id: GWT SDK smartgwt CFX A fejlesztés során szükséges egy futtatókörnyezet kialakítása, amelyet a GWT SDK plugin letöltésével automatikusan kialakít az eclipse keretrendszer, így egyszersítve a környezet kialakításának lépéseit. De alkalmazható a Tomcat rendszer is, amelyet a teszteléshez használtunk. Továbbá fontos a fejlesztés során, hogy legyen javascript képes böngész a fejleszti környezetben, hiszen az implementált JAVA kódot a fordító javascript kóddá fordítja, és teljes javascript oldalként jeleníti meg a rendszer. " I0D5/9B+.9.C09/,+90D$?-+.+% A mködéshez egyértelmen szükség van a Bróker szerviz meglétére, valamint az ágensek rendelkezésre állására, hiszen ezek nélkül a grafikus felület elveszti a funkcionalitását, mivel úgy terveztük, hogy ekkor semmilyen érdemi vezérl elem sem jelenik meg a felületen. A back-end rendszer mködéséhez szükséges egy alkalmazásszerveri környezet, a megfelel kommunikációs portok rendelkezésre állásával, hogy az üzleti logika el tudja érni a 1 Elérhet: 2 Elérhet: 3 Elérhet: 4 Elérhet: 5 Elérhet: oldal, összesen: 21 vasárnap, december 13.

18 Bróker szervizt. Míg kifelé pedig a webszerver felé, amely a lefordított oldalt tartalmazza ugyancsak egy nyitott porttal. A kliens oldalon pedig szükséges egy javascript futtatására alkalmas böngész, amelynek ablakában megfelelen tud futni a fejlesztett eszköz. "A I0D5%+%/9 Az eszköz mködtetéséhez szükséges a már korábban leírtak szerint egy alkalmazásszerver és a szükséges webszerver amely a felhasználók felé a kéréseket kiszolgálja. Ennek megfelelen a rendszer rétegzett architektúrájú, így az igényeknek megfelelen dinamikusan bvíthet. 18. oldal, összesen: 21 vasárnap, december 13.

19 1! +9.%+&/9 A fejlesztés során folyamatosan felügyeltük a funkcionális elvárások teljesülését, így ennek megfelelen alakítottunk ki tesztelési környezetet. Amíg a bróker csapat rendelkezésünkre nem bocsátotta a kész WSDL definíciót, addig saját magunk által készített dummybrokerservice készítésével szimuláltuk a mködést. A bróker csapat WSDL-jének átvétele után pedig azzal szinkronizáltuk a mi megoldásunkat és azzal futtattuk a fejlesztési folyamatot. A grafikus felület tesztelésénél, arra helyeztük a hangsúlyt, hogy minden lehetséges felhasználási esetet szimuláljunk, valamint minden lehetséges esetben kipróbáljuk a felület mködését. Mindemellett a fejleszti csapatunkon kívül néhány átlagos felhasználó bevonásával is teszteltük a megoldást, és a javaslatoknak megfelelen módosítottuk a rendszer mködését. 1!1 +$B+&/960/$5/9+0 A terhelési tesztek esetében a lehetségeinkhez mérten elvégezhet tesztekre hagyatkoztunk és így választottuk a korlátozott mértékben ingyenesen elérhet WAPT 6 eszközt, amely weboldalak terhelés és stressz tesztjeinek elvégzésére alkalmazható eszköz. A terhelésteszt elvégzéshez a tesztkörnyezetet localhoston alakítottuk ki. A terhelésteszthez használt erforrás konfiguráció: 1700 MHz Intel core duo 1 GB RAM Windows XP SP3 Tomcat 5.5 Tesztesetet úgy alakítottuk ki, hogy folyamatosan növekedjen a felhasználószám egészen húszig, és úgy mértük az oldal átlagos válaszidejét. Ezzel a terheléssel szimuláltuk a konkurens felhasználók általi felhasználás módját. Az tesztelés során tapasztalt viselkedés, és adatok: 6 Elérhet: oldal, összesen: 21 vasárnap, december 13.

20 10. ábra: A terhelésteszt eredménye A terhelési grafikonon látszik, hogy miként emelkedett a felhasználószám az id függvényében, míg el nem éri a maximális értéket. A maximális felhasználószámot 20-ra állítottuk, hiszen egy menedzsment szoftver esetében a nagy mennyiség konkurens felhasználás nem alkalmazott. Látható, hogy az oldal a terhelés növekedésére a válaszid növekedésével válaszol, de abszolút lineáris az összefüggés a két adat között, ami azt bizonyítja, hogy a rendszer méretezhet a felhasználószám növekedésére válaszolva úgy, hogy az erforrások bvítését írjuk el. 1! :%6( #&6.8&89 Optimalizálási kérdések esetében arra helyeztük hangsúlyt, hogy a megoldásunk az elvárt funkcionalitás megvalósítása mellett egyszer, ám mégis hatékony legyen. Mindemellett a tesztelés során alkalmazott szimulált erforrásokról a lehet legtökéletesebb módon lehessen átállni a valódi a szerviz alkalmazására. Optimalizálás esetében a terhelésteszt eredményeit is figyelembe vettük és elvégeztünk egy-két módosítást a forráson, ám a kialakított és rendelkezésre álló tesztkörnyezetben nem produkált szignifikáns javulást az módosítás elvégzése. 20. oldal, összesen: 21 vasárnap, december 13.

21 %B+%49/,6&+B+%49/,+0 A bvíthetség jegyében készültek el egyes modulokban függvények, amelyeket a jelen verzióban a bróker szolgáltatásinak szkössége miatt nem alkalmazunk, ám lehetséges vele komplexebb adatstruktúrák kezelése is, a grafikus felület módosítása nélkül. A TreeNode osztály által kezelhet adatstruktúra a bróker szolgáltatásaitól függ, és jelen esetben a bróker szerviz nem támogatja az egyes ágensek illetve attribútumok egymás alá tartozását, azonban a mi megoldásunk támogatja ennek a kibvíthetségét. 21. oldal, összesen: 21 vasárnap, december 13.